Микаел |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 2 раз |
День добрый! Столкнулся с проблемой подписания XML на линуксе. Вот основные шаги. Шаг 1. CertOpenStore() Дальше надо проинициализировать xmlSecDSigCtxPtr для функции xmlSecDSigCtxSign(), которая как раз и принимает значение xmlSecDSigCtxPtr. Но вот тут проблема. Как правильно создать xmlSecDSigCtxPtr имея контекст серта? xmlSecCryptoAppKeysMngrCertLoadMemory? При таких инициализациях получаю ошибку при подписании Буду признателен за работающий пример. |
 |
|
|
Микаел |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 2 раз |
Коллеги, очень нужен совет… |
|
|
|
|
Микаел |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 2 раз |
HCERTSTORE hStore = NULL; xmlSecKeyPtr signKey = xmlSecKeyCreate(); dsigCtx->signKey = ???; // Как сюда вставить ключ? xmlSecDSigCtxSign(dsigCtx, signNode); Перепробовал уже все что можно… |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Скопировать прямую
ссылку на статью
Сертификат, предоставляемый удостоверяющим центром, содержит открытый ключ – это файл с расширением .cer, и закрытый – папка с 6 файлами:
Для настройки подписи в адаптере, необходимо поместить ключи электронной подписи в определенную директорию.
При этом, при настройке ИС в адаптере при проверке подписи, может возникнуть такая ошибка:
То есть, во-первых, адаптер видит доступный псевдоним, но пишет, что не находит его. Во-вторых, возникает ошибка генерации тестовой подписи: private key or certificate not set.
Фактически, это значит, что в файлах закрытого ключа сертификата нет данных об его открытой части.
Как исправить ошибку?
1. На любом ПК, где установлено ПО Крипто про JPC, поместить ключи электронной подписи в целевую директорию. (CentOS: /var/opt/cprocsp/keys/ИМЯ ПОЛЬЗОВАТЕЛЯ, Windows: C:UsersИМЯ ПОЛЬЗОВАТЕЛЯAppDataLocalCrypto Pro).
2. Открыть панель JCP_ControlPanel.
3. На вкладке «Хранилища ключей и сертификатов» найти сертификат, и открыть его, указав пароль:
4. Нажать «Добавить»
5. Выбрать открытый ключ сертификата – файл с расширением .cer.
Должно получиться так:
6. Из целевой директории скопировать папку с закрытой частью сертификата (должна поменяться дата изменения и объем у 4 вложенных файлов) и далее при настройке адаптера использовать её.
После обновления ключа, в адаптере должны увидеть успешную проверку подписи:
На чтение 15 мин Просмотров 1.1к. Опубликовано 13.04.2021
Содержание
- Причины ошибки
- Как решить проблему генерации сертификата
- Что еще можно сделать?
- Нагрузка сервера сайта ФНС
- Заключение
- Виды и типы электронных подписей
- Механизм отправки документов подписанных усиленной электронной подписью
- Как создать электронную подпись в личном кабинете налогоплательщика
- Ошибка генерации сертификата ЭП
- Что делать если Вы забыли пароль для доступа к сертификату ключа проверки электронной подписи
- Схема создания ЭП
- Инструкция получения ЭП
- Возникновение ошибки генерации сертификата
- Варианты решения проблемы
- Просмотр реквизитов сертификата
- Остались вопросы?
После обновления личного кабинета в ИФНС пользователи массово столкнулись с проблемой «Ошибка генерации сертификата». Работа личного кабинета была переведена на новую версию и при подаче деклараций или уточнении люди столкнулись с проблемой. В новой версии кабинета необходимо получить новую электронную подпись. И как раз таки при выборе способа получения ЭП появляется «Ошибка генерации сертификата».
По отзывам пользователей в старом кабинете все функционирует нормально, однако на данный момент там нельзя уточнить, создать декларацию за 2017 год.
Поскольку вопросов много вначале кратко расскажем о возможных причинах этого сбоя, а ниже дадим советы и рекомендации как попытаться сгенерировать новый сертификат самостоятельно.
Причины ошибки
Официальный ответ от разработчиков содержит информацию, что в личном кабинете проводились регламентные работы, в связи с которыми появлялся данный сбой и советуют повторить операцию позже. Однако следующие попытки безрезультатны. Такое программное обеспечение необходимо тестировать и проверять под все популярные версии операционных систем и браузеров. А так как систем и веб браузеров много — система должна работать на 100%. И перед обновлением должна быть протестирована на ошибки и баги.
Ситуация усугубляется тем, что по отзывам пользователей данная ситуация продолжается с февраля 2019, а за это время можно было провести необходимые тесты и проверить работоспособность.
Ниже мы будем публиковать инструкции, которые помогли пользователям в получении электронной подписи.
Как решить проблему генерации сертификата
По мере поступления проверенной рабочей информации мы будем публиковать ниже инструкции для решения ошибок с генераций электронной подписи и других сбоев в ЛК.
- Выбираем вариант «Электронная подпись хранится на Вашей рабочей станции».
Электронная подпись хранится на Вашей рабочей станции
Что еще можно сделать?
- Просмотреть график проведения работы над порталом ФНМ и перенести работу с порталом на другой день.
- После подачи запроса на регистрацию ключа — выходим из ЛК. Сообщение о присвоении сертификата вы получите при следующем входе в кабинет.
- И не забываем что можно обратиться в техническую поддержку сайта или в отделение налоговой с паспортом и ИНН.
Нагрузка сервера сайта ФНС
Во время частых запросов и обращений к сайту налоговой «Ошибка генерации сертификата» частое явление, из-за постоянных обращений к сайту сервер может не выдерживать нагрузки. Как одна из причин сбой может появляться из-за большой загруженности портала Федеральной Налоговой Службы. Самый пик приходится на последние дни подачи налоговых деклараций от физических лиц и организаций. Большая часть из которых выпадает на первые кварталы года. Как вариант в таком случае действительно приходится ждать и повторять выпуск снова.
Заключение
Надеюсь мы разъяснили некоторые моменты в работе нового ЛК ФНС. Пробуйте исправить ошибку создания сертификата с помощью инструкции выше и сообщите помог ли вам способ. Если вам известные другие методы решения проблемы — сообщите нам в форме комментариев ниже и мы дополним нашу статью для помощи будущим читателям.
Информация представлена для ознакомления, более свежие новости смотрите на официальном сайте Госуслуг.
В прошлой статье мы разбирались с декларацией 3-НДФЛ и перед отправкой документов в личном кабинете налогоплательщика вводили пароль к сертификату электронной подписи, или выражаясь простым языком подписывали наши «толмуты» электронной подписью.
Отчёты по ИП и ООО можно сделать бесплатно здесь.
Как-то я упустил из виду, что не все знают что это такое. Тема полезная как для помощи при создании электронной подписи в своём личном кабинете налогоплательщика так и для общего образования. Учитывая, что многие мои читатели пенсионеры — люди преклонного возраста и недостаточно уверенные в общении с компьютером, «разложу всё по полочкам».
Прежде всего, давайте разберёмся для чего нужна электронная подпись и что за пароль от сертификата. Здесь всё просто, как и простая подпись из под ручки, она нужна для придания какому-либо документу юридической силы. Но простую-то можно сверить с той, что в паспорте и на худой конец провести графологическую экспертизу её подлинности. А как же сверить и проверить электронную? Здесь всё гораздо сложнее. Но сначала о видах и типах.
Виды и типы электронных подписей
Скажу сразу, видов не великое множество, а всего два:
- простая электронная подпись;
- усиленная;
Простая — это логин и пароль. Она подтверждает, что электронное сообщение отправлено именно их владельцем. И больше ничего. Нам же интересна усиленная. Она помимо идентификации отправителя ещё и подтверждает, что после подписания документ не менялся и приравнивается к документальной бумажке с подписанной ручкой.
Бывают усиленные тоже двух типов:
- квалифицированная электронная подпись;
- неквалифицированная;
В налоговой создаётся неквалифицированная усиленная электронная подпись и использоваться она может в документообороте только в рамках ИФНС! А вот использование квалифицированной подписи гораздо шире, но для её получения необходимо лично обратиться в удостоверяющий цент, аккредитованный Минкомсвязи России. И эта услуга платная.
Если же Вы её всё-таки приобретёте, то у Вас появиться возможность зарегистрироваться в личном кабинете налогоплательщика без мытарств по налоговым органам. А потом и входить туда с помощью этой самой подписи вместо логина и пароля при выборе этого способа авторизации. Кстати и в госуслуги тоже. Ну и конечно, подписывать ей все возможные электронные документы, в том числе и в налоговой конечно.
Далее следует общеобразовательный ликбез. Если он Вас не интересует, можете пропустить этот раздел и прокрутить вниз. Там уже расписано, как создать электронную подпись в личном кабинете налогоплательщика и само сабой про пароль к сертификату тоже. А специалистов в области криптографии прошу не судить меня строго за некоторые неточности и упрощения в этом опусе.
Механизм отправки документов подписанных усиленной электронной подписью
Правильнее было бы использовать слово алгоритм вместо механизм. Но не буду пугать основную часть нашей аудитории — пенсерменов «заумными» словами. И далее не пугайтесь, всё разъясню. Итак, как же, например, товарищ Иванов передаёт Налоговой через интернет подписанные документы? Да ещё чтоб их никто не смог прочитать и подменить. Научным языком примерно так:
Вначале Иванов и Налоговая генерируют открытые и закрытые ключи шифрования. Затем обмениваются открытыми между собой. На следующем этапе:
- Иванов шифрует «послание» своим закрытым ключом и как результат происходит его подписывание.
- Далее Иванов шифрует открытым ключом, который перед этим ему отправила Налоговая то, что получилось после выполнения пункта 1. Теперь никто посторонний не сможет ничего прочитать, если даже перехватит.
- После того как Налоговая получила «послание» Иванова, она сначала расшифровывает его своим закрытым ключом и видит там зашифрованный документ Иванова.
- Тут-то «Налоговая» расшифровывает его с помощью открытого ключа переданного ей Ивановым в самом начале. В результате чего происходит сверка подписи Иванова.
А на «рабоче-крестьянском» языке «явок и паролей» это будет приблизительно похоже на такое мероприятие:
Сначала Иванов готовит чемодан с запасным ключом и бумагу с собственноручно подписанными реквизитами, а Налоговая шкатулку тоже с запасным ключом. Идут на почту и отправляют друг другу посылки. Иванов укладывает в бандероль ключик от чемодана, а в ценное письмо бумагу со своими реквизитами и отправляет по отдельности. Налоговая — шкатулку посылкой и бандероль с одним ключиком тоже отдельно.
Иванов, получив посылку и бандероль прячет, например, свою подписанный документ в шкатулку и закрывает её ключом из полученной бандероли. Укладывает эту секретную шкатулку в свой чемодан и тоже закрывает уже на свой ключ. А потом посылкой отправляет эту «матрёшку» в Налоговую. Ключи от шкатулки и чемодана оставляет у себя.
Налоговая получает посылку и бандероль. Все ключики у неё уже имеются и если они подходят, она открывает ими и чемодан и шкатулку. Смотрит и сверяет подпись и реквизиты, указанные в документе с теми , что пришли ценной бандеролью ранее. Если всё совпадает и никаких исправлений и подозрений нет, то принимает их в работу.
Эту «белеберду» я написал для того, чтобы было понятно — усиленная электронная подпись это очень серьёзная штука с высочайшем уровнем защиты. И тот пароль, который Вы вводите для отправки электронного документа, это не просто пароль, как например для входа в «Одноклассники», а можно сказать, очень сложный механизм для запуска всех этих процессов шифрования, обмена данными, дешифрования, сверки данных.
Я уже не буду вдаваться в подробности о терминах. Например, что значит сертификат ключа проверки электронной подписи. Почему так, а не просто подпись. Хватит, и так столько ахинеи нанёс, что у самого голова пухнет. Ближе к теме.
Как создать электронную подпись в личном кабинете налогоплательщика
Если у Вас уже была электронная подпись в старой версии личного кабинета, то в новой (с 2018 года) её уже не будет и пароля естественно тоже. Так что сертификат ЭП придётся создавать заново.
Итак, заходите в личный кабинет и открываете свой профиль. Для этого сразу же на первой страничке находите наверху справа свою фамилию, имя, отчество и клацаете. Ну а в открывшемся окне всё по пунктам, как на картинке:
- выбираете вкладку «Получить ЭП»;
- вариант хранения электронной подписи;
- устанавливаете пароль для доступа к сертификату;
- вводите его ещё раз;
- жмёте кнопку «Отправить запрос»:
Почему лучше выбрать хранение ключа в системе ФНС России, думаю у Вас вопросов не вызовет. Если Вы прочитали разъяснения, то заметили и сами неоспоримые преимущества именно этого варианта.
После отправки запроса появляется окно ожидания с крутящимся кружочком. Иногда оно может задержаться на довольно таки продолжительное время:
Потом появиться окно, сообщающее о том, что сертификат успешно выпущен. Здесь можно будет вызвать окно со своим сертификатом, нажав на ссылку «Просмотреть сертификат»:
во всплывшем после этого окне ввести пароль, который Вы уже вводили дважды в самом начале и кнопка «Далее»:
А уже в следующем окне любуйтесь своим сертификатом, смотрите эти самые реквизиты, которые сверяют в налоговой при получении от Вас документов. Выглядит он примерно так:
Ошибка генерации сертификата ЭП
В первое время после запуска сайта налоговой это было довольно таки частое явление. Потом как бы всё «устаканилось». Сейчас вновь стали возникать такие «глюки». Я, например, об этом узнаю глядя на статистику посещаемости этого блога. Она резко возрастает. И всё за счёт статьи, которую вы сейчас читаете.
По этому поводу могу лишь сказать, что тут дело, скорее всего, не в вас и не в пароле, а в перегруженности портала ФНС. Особенно сильно это проявляется в последние дни сдачи налоговых деклараций организаций и прочих налоговых выплат физических лиц. Львиная доля их приходится обычно на первый квартал, то есть начало года.
Так что если на Вашем мониторе вышла надпись «Ошибка генерации сертификата электронной подписи» особо не расстраивайтесь. Наберитесь терпения и попробуйте проделать эту операцию ещё раз. А лучше вернитесь к этому в другой день. Возможно «глюки» к этому времени закончатся и Вам повезёт.
Что делать если Вы забыли пароль для доступа к сертификату ключа проверки электронной подписи
Не огорчайтесь. Ничего страшного в этом нет. Это же не пароль от личного кабинета налогоплательщика, в случае утраты которого, придётся повторно посещать ИФНС. Это в том случае, если Вы не потрудились задать кодовое слово для его восстановления по электронной почте.
Здесь всё гораздо проще. Обратите внимание на нижнее окно там есть ссылка «Отозвать текущий сертификат». Смело щёлкайте по ней и после этого создавайте новый сертификат и у Вас будет новый пароль:
Если Вы всё-таки опасаетесь сразу это делать, можете для убедительности сначала щёлкнуть на «Просмотреть сертификат»:
Перед вами откроется следующее окно, которое, надеюсь развеет Ваши сомнения:
На этом можно и закончить. И помните, что электронная подпись открывает перед Вами массу возможностей как в экономии своего времени, так и в плане экономии средств. Я уже не говорю о том, что это уже более прогрессивная ступень ведения Ваших дел. И не огорчайтесь, если Вы утеряли пароль к сертификату ЭП, его всегда можно восстановить.
Удачи Вам ! И до скорых встреч на страницах блога «ПенсерМен».
При пользовании онлайн-кабинетом налогоплательщика введен упрощенный механизм заверения документов путем электронной подписи (ЭП). Нововведения в последнее время связаны с установкой новой ЭП для пользователей старой версии аккаунта. При процедуре регистрации часто возникает ошибка генерации сертификата в личном кабинете налогоплательщика, решить которую можно несколькими способами.
Схема создания ЭП
Электронная подпись является усиленным вариантом подтверждения того, что документ признается действительным и приравнивается к бумажному виду, где ставятся письменные инициалы. В процессе регистрации кабинета на сайте налоговой службы есть возможность создания неквалифицированного типа ЭП, обладающей следующими свойствами:
- применяется в документообороте в рамках ФНС;
- система шифрования характеризуется высоким уровнем защиты.
Как было уже сказано выше, в старом кабинете была доступна электронная подпись, но в обновленной версии приходится регистрировать новый сертификат. Причем предлагается хранение регистрируемой ЭП на станции пользователя или на сервисе ФНС. Ввиду мошеннических действий рекомендуется обращаться к последнему варианту, так как он преимущественно безопасен и допускает применение на мобильных гаджетах. Когда налогоплательщик желает установить ЭП на свой ПК, потребуется обеспечить защиту ключа особыми программами. Ответственность ложится на плечи пользователя.
Инструкция получения ЭП
Следуя описанной ниже схеме, пользователь быстро зарегистрирует сертификат. Для этого нужно:
- авторизоваться в личном кабинете (ввести логин, пароль или применить данные учетной записи в Госуслугах);
- открыть профиль – кликнуть по пункту, где указаны ФИО и ИНН;
- в профиле кликнуть на услугу «Получить электронную подпись»;
- отметить нужный вариант хранения в списке предложенных;
- установить паролевую комбинацию для открытия сертификата;
- подтвердить ранее введенные данные повторным набором;
- нажать на команду «Отправить запрос».
Внимание! Когда происходит направление информации на сервис, на странице появляется «Генерация электронной подписи».
Обратите внимание! Для процесса требуется установка программы, которая занимается генерацией ключей. Все характеристики указываются под пунктом «Требования к системе». Предусмотрены версии для операционных систем Windows и MacOs.
На этапе создания есть функция регистрации имеющейся квалифицированной ЭП. Она подразумевает владение сертификатом, выданным удостоверенным на то центром, а именно: организация должна быть аккредитована Минкомсвязью России. Для успешной работы в кабинете налогоплательщика следует произвести обмен данными, чтобы в дальнейшем использовать ЭП в системе электронного документооборота налоговой службы.
Возникновение ошибки генерации сертификата
В процессе регистрации пользователь может получить сообщение: «Ошибка генерации сертификата». Инцидент случается по разным причинам:
- проведение технических работ на сайте ФНС;
- регистрация ЭП занимает в большинстве случае продолжительное время.
По отзывам уже давно пользующихся электронной подписью ФНС граждан напрашивается вывод, что регистрация кодовых комбинаций занимает 30 минут, а в некоторых случаях удлиняется до 2 дней. Тогда встает вопрос, сколько формируется личный кабинет налогоплательщика.
Обратите внимание! При запуске услуги появляется сообщение о продолжительности регистрации и возможности выхода из кабинета при необходимости, что не мешает процедуре формирования данных.
Не исключены ситуации, когда не произведена установка дополнительных программ для генерации кодов (пользователь не воспользовался ссылкой при ознакомлении с требованиями к системе). В результате сервис не сможет найти рабочую станцию для сохранения сведений.
Варианты решения проблемы
Если происходит выявление проблемы ошибки при формировании ЭП в кабинете налогоплательщика, стоит прибегнуть к одному из способов:
- повторно попробовать загрузить сертификат – часто вторичная или третичная попытка заканчивается успехом, так как система может быть перезагружена заявками;
- ознакомиться с графиком проведения технических работ на сайте ФНС и перенести процедуру на другой день;
- после отправки запроса на регистрацию электронного ключа выйти из кабинета, так как уведомление о присвоении сертификата поступит при следующей авторизации;
- обратиться в отделение налоговой службы, предъявив ИНН и паспорт.
Важно знать! Часто первичный запуск генерации сертификата не позволяет получить данные. Однако при повторе операции все заканчивается удачно. Причем вторичный запрос производится в тот же день или спустя неделю.
Просмотр реквизитов сертификата
Когда пользователю удается получить ЭП из системы ФНС, появляется сообщение о выпуске ключей. При этом доступны две опции:
- просмотр;
- отзыв.
Если выбирается «Просмотр сертификата», необходимо ввести ранее установленный в процессе регистрации пароль. В результате открывается окно с информацией:
Ввиду безопасности использования ЭП устанавливается короткий период функционирования кода. По прошествии 3 месяцев следует повторно запросить формирование ключей.
Функция отзыва полезна в случае потери пароля для доступа к сертификату или подозрении на риск взлома аккаунта. Тогда необходимо кликнуть по соответствующей команде и выполнить ряд действий. В результате сервис удалит все сведения, после чего можно будет приступить к созданию новых ключей.
Ошибка генерации сертификата ЭП не всегда становится непреодолимой проблемой. Стоит повторно сделать запрос и дождаться положительных результатов, ведь в будущем данный вариант позволит сэкономить время при сдаче отчетности в налоговые органы. Если все-таки в данный момент не удается сформировать ключи, рекомендуется попробовать запустить процесс на следующий день.
Остались вопросы?
Проконсультируйтесь у юриста (бесплатно, круглосуточно, без выходных):
Внимание! Юристы не записывают на приём, не проверяют готовность документов, не консультируют по адресам и режимам работы МФЦ, не оказывают техническую поддержку по порталу Госуслуг!
Содержание
- Настройка CryptoDE для ЕГИССО
- Где скачать Crypto+DE
- Ошибка
- Настройка CryptoDE для ЕГИССО
- PKCS#11 для самых маленьких
- Про APDU
- Репозиторий с примерами
- Цикл работы с токеном
- Подготовительный этап
- Основной этап
- Завершающий этап
- Классификация функций PKCS#11
- Стандартные функции и функции расширения
- Разделение по предназначению
- Атомарные и составные операции
- Работа со слотами
- Получение списка слотов
- Мониторинг событий слотов и получение информации о слоте
- Объекты
- Создание объектов — на примере генерации ключевых пар
- Поиск объектов и создание сырой подписи
- Работа с функциями расширения на примере создания запроса на сертификат
- Импорт сертификата на токен. Создание объекта вручную
- Формирование CMS-подписи
- Получение и установка атрибутов публичных объектов
- Про механизмы
- Работа с механизмами, на примере зашифрования сообщения
- Проверка поддержки механизмов
- Утилита pkcs11-tool
- Дополнительный материал
- Выводы
Настройка CryptoDE для ЕГИССО
Произошла небольшая неприятность на работе. Ноутбук, на котором настроено рабочее место для ЕГИССО срочно понадобилось отдать на время другому пользователю. «Ничего страшного» — подумал я, — «настрою портал на другом компьютере, благо как настраивать давно уже известно».
Но после того как все необходимые компоненты были установлены, средство для работы с электронной подписью CryptoDE начало капризничать и никак не хотело подписывать документы. Постоянно выскакивающее окно сообщало: «Ни один из сертификатов в хранилище не прошел проверку на квалифицированность в соответствии с настройками». Чтобы избавиться от этой ошибки, понадобилось немного поковыряться в настройках программы. В данной статье речь пойдет о том, как провести настройку CryptoDE для ЕГИССО.
Где скачать Crypto+DE
Скачать актуальную версию программы можно:
- С официального сайта ПФР ( ссылка )
- Яндекс Диск ( ссылка )
Ошибка
Если правой кнопкой мыши нажать на значок Crypto+DE, а затем «Выбрать сертификат по умолчанию», то программа успешно предложит выбрать сертификат из установленных сертификатов. Но это действие ничего не решит, т.к. при подписании документа выскочило окно, которое оповещает о том, что сертификат по умолчанию не соответствует требованиям текущего режима КЭП.
Настройка CryptoDE для ЕГИССО
Итак, для решения данной проблемы необходимо немного поковыряться в настройках программы.
- Нажимаем правой кнопкой мыши на значок Crypto+DE в трее и переходим в раздел «Настройки»
- Во вкладке «Настройки клиента» все значения оставляем по умолчанию.
- Нас интересует вкладка «Криптосервер 3».
- «Какие сертификаты проверять» выставляем значение «Только конечный сертификат»
- «Режим проверки» выставляем значение «С помощью списка отзыва сертификатов с подключением к сети»
- «Режим проверки квалифицированной ЭП» ставим «Не проверять»
На этом настройка CryptoDE завершена. Все документы успешно подписываются и загружаются на портал в кабинете поставщика информации. Оставлю на всякий случай скриншот настроек, которые действуют у меня в данный момент. Если у Вас не заработало или что-то не получилось, можете смело написать в комментариях. Постараюсь всем помочь!
Источник
PKCS#11 для самых маленьких
В этой статье мы познакомимся со стандартом PKCS#11, предназначенным для работы с различными криптографическими устройствами. Для демонстрации мы будем использовать токены и смарт-карты Рутокен ЭЦП 2.0.
Чтобы вам было проще понять эту информацию, перед её прочтением желательно:
Исходя из определения из Википедии:
PKCS #11 — один из стандартов семейства Public-Key Cryptography Standards (PKCS). Он определяет платформонезависимый программный интерфейс доступа к криптографическим устройствам смарт-картам, токенам, криптографическим ускорителям, серверам ключей и другим средствам криптографической защиты информации. Иногда именуется Cryptoki.
Проще говоря, PKCS#11 определяет платформонезависимый набор функций, структуры, константы и т.п. для работы с криптографическими устройствами. Эти функции могут быть реализованы внутри различных библиотек, например, opensc-pkcs11 или в нашей библиотеке по работе с устройствами Рутокен rtpkcs11ecp. Библиотеки могут отличаться не только реализацией, но и самим набором функций, типов и констант. Это возможно, так как стандарт PKCS#11 описывает различные способы расширения, что позволяет добавлять свои функции, например, для работы с CMS-подписью, флеш-памятью и т.п.
Но давайте обо всем по порядку. В первую очередь, определимся, что из себя представляют функции PKCS#11-библиотек. Функции PKCS#11 внутри — это обертки для работы с токенами и смарт-картами через APDU команды…
Про APDU
APDU — “язык ассемблера” для устройств.
Более подробно об APDU-формате написано в этой статье, мы же опишем его проще. APDU-формат описывает способ общения с различными устройствами с помощью байтовых последовательностей. На практике это происходит следующим образом:
Токену или смарт-карте посылается байтовая последовательность;
Операционная система устройства обрабатывает эту последовательность в команду и посылает в ответ код возврата и, при необходимости, дополнительную информацию.
Что же могут содержать внутри себя такие команды? Все, что угодно! Начиная с просьбы отправить информацию об устройстве или записать какие-то данные на него и заканчивая просьбой зашифровать указанное сообщение. Более того, эти команды могут быть разбиты на несколько, что позволяет оптимизировать работу с токеном и сделать ее конвейерной. К примеру, при шифровании сообщения устройству может передаваться небольшая часть сообщения, а он в ответ будет высылать результат шифрования только этой части. Эта особенность может быть использована при работе с данными больших размеров.
И вот вроде бы все хорошо: APDU даёт полную возможность для общения с токеном и смарт-картой, но зачем же тогда нужна PKCS#11-обертка? Причины достаточно очевидны:
Работать с шестнадцатеричными байтовыми последовательностями весьма неудобно, каждый раз надо заглядывать в спецификацию команд. Хотелось бы иметь их текстовый эквивалент, а лучше целую библиотеку для разработки.
Программирование через APDU-команды имеет “низкий КПД”. При выполнении даже самой простой операции надо написать множество команд. PKCS#11 устраняет эту проблему: при выполнении одной функции PKCS#11 посылается несколько APDU команд. Меньше пишешь — больше делаешь.
Теперь, когда мы знаем что лежит в основе PKCS#11-команд, перейдем к рассмотрению цикла работы с устройством.
Репозиторий с примерами
Чтобы улучшить понимание представленных ниже примеров рекомендуем:
Выполнить настройку системы согласно README.
Попробовать собрать примеры.
Отформатировать устройство семейства Рутокен ЭЦП 2.0 с помощью примера ex0_format_token.
Цикл работы с токеном
Придержим пока описание содержимого стандарта PKCS#11 и дадим поверхностное представление о том, как происходит работа с токеном в целом. Для этого рассмотрим листинг смены PIN-кода Пользователя на токене и смарт-карте:
Внутри заголовочного файла utils.h находится описание функций init_pkcs11, free_pkcs11, get_slot_list. Их определение мы дадим ниже.
Всю работу с токеном можно разделить на три этапа:
Подготовительный этап
Мы реализовали его внутри функции init_pkcs11:
Здесь происходит следующее:
В память процесса подгружается PKCS#11-библиотека, хранящаяся по пути PKCS11ECP_LIBRARY_NAME, с помощью функции LoadLibrary (стандартная функция для Windows-систем, для Linux-систем определена обертка).
Далее из библиотеки вытаскиваются указатели на функции C_GetFunctionList и C_EX_GetFunctionListExtended. Первая функция определена в стандарте PKCS#11 и позволяет получить структуру указателей на функции библиотеки. Вторая — является специфичной для библиотеки rtpkcs11ecp и позволяет получить схожую структуру указателей на функции расширения библиотеки. О функциях расширения мы поговорим позже.
Потом мы вызываем полученную функцию C_GetFunctionList и получаем уже саму структуру указателей на функции.
С помощью функции C_Initialize инициализируется загруженная библиотека. Функция C_Initialize в качестве аргумента принимает параметры инициализации библиотеки. Подробнее о них можно почитать здесь, для нас же важен флаг CKF_OS_LOCKING_OK. Его необходимо использовать, если мы хотим использовать библиотеку в нескольких потоках. В нашем примере мы могли бы опустить этот флаг.
Основной этап
Основной этап можно разделить на работу со слотами и работу внутри сессии
Этап работы со слотами
Слот — это дескриптор виртуального интерфейса, куда подключен токен. Конкретно в нашем примере весь этап работы со слотами уместился в определение одной функции get_slot_list:
Работа со слотами происходит примерно в такой последовательности:
Получение списка слотов с помощью функции C_GetSlotList или через функцию ожидания событий, связанных со слотами (пример будет рассмотрен ниже).
Выполнение различных функций работы со слотами. В нашей программе этот этап отсутствует, но его пример можно найти здесь для функции форматирования устройства C_EX_InitToken. Подробнее функции работы со слотами будут описаны ниже.
Этап работы внутри сессии
Сессия — это дескриптор контекста выполнения последовательности операций. Обычно во время сессий выполняются основные функции работы с токеном или смарт-картой: шифрование, подпись и т.п. В нашем случае выполняется смена PIN-кода:
Работу внутри сессий можно разделить на несколько этапов:
Открытие сессии в слоте с помощью функции C_OpenSession.
Аутентификация пользователя с помощью функции C_Login. Стандартно на Рутокене присутствуют два пользователя: Администратор (CKU_SO) и Пользователь (CKU_USER). Аутентификация на устройстве — не является обязательной операцией. Она нужна, когда мы хотим получить доступ к операциям и объектам, которые требуют наличия соответствующих прав доступа. В нашем случае, это операция смены PIN-кода Пользователя.
Выполнение различных функций по работе с сессиями. В нашем случае это функция C_SetPIN.
Далее по нисходящей могут идти операции сброса прав доступа (C_Logout) и завершения сессии (C_CloseSession).
Завершающий этап
Весь наш завершающий этап поместился внутри определения функции free_pkcs11:
Завершающий этап можно разделить на:
Деинициализацию библиотеки с помощью функции C_Finalize.
Выгрузку библиотеки из памяти процесса через функцию FreeLibrary (для Linux-систем имеется обертка).
Классификация функций PKCS#11
Стандартные функции и функции расширения
В общем виде все функции внутри PKCS#11-библиотек можно разделить на:
Стандартные — те, что явно описаны в стандарте. Список указателей на эти функции можно получить с помощью функции C_GetFunctionList, хранящейся в этой же библиотеке. Сами же стандартные функции имеют префикс «C_».
Расширения — те, что были добавлены разработчиками библиотеки и не описаны в стандарте. Стандарт явно не определяет функцию для получения списка расширенных функций. Но в библиотеке rtpkcs11ecp этой функцией является C_EX_GetFunctionListExtended. Сами же функции-расширения обычно имеют префикс «C_EX_».
Описание стандартных функций можно найти в документации PKCS#11. Про то, как работать с расширениями — надо смотреть у разработчиков конкретных библиотек. Например, у нас для этого есть отдельная страница на портале документации.
Разделение по предназначению
С другой стороны, функции PKCS#11 можно классифицировать по их предназначению. Логично выделить следующие виды функций:
Функции общего назначения. Например, для получения списка функций или получения информации о библиотеке.
Функции работы со слотами. Они не зависят от контекста работы с токеном. Например, C_GetSlotInfo, C_GetTokenInfo и т.п.
Функции для работы с сессиями. Как уже говорилось ранее, обычно во время выполнения этих функций осуществляется основное взаимодействие с токеном. При выполнении функции внутри сессии контекст работы с токеном не теряется. Самый простой пример этих функций: функция аутентификации (C_Login), функции работы с закрытым ключом на токене (C_Sign, C_Encrypt) и т.п.
Атомарные и составные операции
Некоторые операции в PKCS#11 работают привычным для нас образом: вызвал функцию — получил результат. Но есть и операции, реализация которых выстроена через многократный вызов функций. Ярким примером такой операции является блочное шифрование: чтобы зашифровать данные нужно вызвать функции: C_EncryptInit, C_EncryptUpdate, C_EncryptFinal. Пример этого будет приведен ниже. Эта особенность связана с тем, что внутри библиотеки PKCS#11 скрыт вызов APDU-команд, который как раз предусматривает разбиение некоторых команд на несколько итераций. Как уже говорилось ранее, это способствует эффективному использованию PKCS#11 с потоками данных.
Работа со слотами
Слоты — это виртуальные устройства библиотеки для подключения токенов и смарт-карт. PKCS#11 предоставляет функции для получения списка слотов и ожидания изменения состояний слотов. Также с помощью специальных функций можно получать информацию о состоянии слота, например, наличие токена в нем, информация о подключенном токене и т.п. Давайте подробнее рассмотрим функции по работе со слотами.
Получение списка слотов
Одна из самых важных операций, которую мы будем использовать в 99 процентах случаев — это получение списка активных слотов. Для этого в PKCS#11 есть функция C_GetSlotList. Примером ее использования является функция get_slot_list, определенная ниже:
Первый вызов функции C_GetSlotList позволяет получить количество доступных слотов. Это позволяет в дальнейшем выделять память под необходимое количество слотов. Второй вызов позволяет получить список слотов.
Первым аргументом C_GetSlotList является флаг, говорящий библиотеке, возвращать ли только слоты с подключенными устройствами (CK_TRUE) или нет (CK_FALSE).
Мониторинг событий слотов и получение информации о слоте
Тем не менее, хоть функция C_GetSlotList и является самой часто используемой, она неудобна при написании приложений, которые хотят динамически следить за состоянием слотов. Особенно это может быть критично при написании многопоточных приложений. На помощь может прийти функция мониторинга событий слотов C_WaitForSlotEvent. Она прерывает свою работу при любом изменении состояния какого-либо слота и возвращает идентификатор измененного слота. Работа с этой функцией выглядит примерно следующим образом:
Как можно заметить, функция отлавливает помимо событий подключения и извлечения токена и смарт-карты, еще и событие деинициализации библиотеки PKCS#11 (код возврата CKR_CRYPTOKI_NOT_INITIALIZED). Данная особенность позволяет использовать эту функцию внутри многопоточных приложений без дополнительной возни с обработкой событий при завершении работы приложения.
Первым аргументом в функцию C_WaitForSlotEvent передается флаг блокировки (CKF_DONT_BLOCK). Если он установлен, то функция не является блокирующей. В таком случае, если никакой слот не был изменен, то возвращается код CKR_NO_EVENT.
Также стоит обратить внимание на использование функции получения информации о слоте C_GetSlotInfo. Мы использовали ее для определения наличия токена по флагу CKF_TOKEN_PRESENT. Подробнее с этой структурой можно ознакомиться здесь.
В этом файле представлен пример получения информации о подключенных токенах или смарт-картах с помощью функции C_GetTokenInfo. С помощью этой функции можно получить серийный номер, метку и другие характеристики подключенного устройства.
Объекты
Всё есть объект — это почти про PKCS#11.
Теперь начнём знакомство с PKCS#11-объектами. А чтобы закрепить материал по функциям, будем рассматривать множество примеров с их использованием. Поскольку одним из самых важных объектов, которые обычно хранятся на токене или смарт-карте является ключевая пара, мы начнём знакомство с объектами через генерацию ключевой пары.
Создание объектов — на примере генерации ключевых пар
В этом примере для нас много нового. Можно заметить, что здесь вызывается всего одна функция C_GenerateKeyPair. Эта функция является стандартной функцией генерации ключей, работающей внутри открытой сессии. Также стоит отметить, что пользователь должен быть аутентифицирован перед вызовом этой функции.
Теперь перейдём к объектам. Внутри функции gen_gost_key_pair происходит создание двух объектов на токене: открытого и закрытого ключей. Вот, что стандарт PKCS#11 говорит про объекты:
Cryptoki recognizes a number of classes of objects, as defined in the CK_OBJECT_CLASS data type. An object consists of a set of attributes, each of which has a given value. Each attribute that an object possesses has precisely one value.
То есть стандарт не даёт явное определение объекта, но из того, что там написано, мы знаем:
объект относится к определенному классу;
объект состоит из множества атрибутов, имеющих заданное значение;
каждый атрибут имеет ровно одно значение.
Также в стандарте представлена классификация объектов:
Иерархия PKCS#11 объектов
Заголовок диаграммы определяет класс объекта, а то что ниже — некоторые из его атрибутов.
Видно, что объектом может являться некоторый механизм (о механизмах мы поговорим позже), встроенные функции токена (Hardware feature), некоторые данные на токене (Storage). В нашем случае мы выполнили действие с данными.
Название всех атрибутов начинается с префикса «CKA_». Одним из самых важных атрибутов является CKA_ID. Он задаёт идентификатор объекта и используется для связи ключевых пар и сертификатов. Атрибут CKA_TOKEN является булевым и показывает, является ли объект — объектом токена. Атрибут CKA_PRIVATE тоже является булевым и определяет нужна ли предварительная аутентификация для получения доступа к объекту. Атрибут CKA_ID — задаёт шестнадцатеричный идентификатор объекта. Также есть булевые атрибуты CKA_MODIFIABLE, CKA_COPYABLE, CKA_DESTROYABLE для более тонкой настройки доступа к объекту. Подробнее про возможные атрибуты конкретных классов объектов можно прочитать непосредственно в самом стандарте для каждого класса объектов.
Объекты данных могут быть самыми разнообразными: асимметричные ключи, симметричные ключи, сертификаты, просто какая-либо информация на токене. В нашем примере мы создали два объекта, но сделали это неявно с помощью механизма генерации ключей. C_GenerateKeyPair приняла на вход механизм генерации ключевой пары, шаблоны открытого и закрытого ключа и с помощью механизма сгенерировала объекты ключевой пары (publicKey и privateKey). Мы пока ещё не описывали механизмы, но, говоря простым языком, механизм — это идентификатор операции, которая выполняет какую-то криптографическую функцию. В нашем случае — это функция генерации объекта.
Поиск объектов и создание сырой подписи
В прошлом разделе мы сгенерировали ключевую пару. На этот раз будем считать, что у нас нет хендлов на сгенерированные ключи, но мы знаем их идентификатор – CKA_ID. Попробуем найти объект закрытого ключа на токене:
Данный пример иллюстрирует работу с функцией поиска объекта по заданным атрибутам. Как можно заметить, операция поиска объекта на токене является составной и работа с ней сводится как минимум к вызову трёх функций: C_FindObjectsInit, C_FindObjects, C_FindObjectsFinal. Функция C_FindObjects может вызываться по несколько раз, и каждый раз она будет возвращать следующие объекты поиска. Предпоследний аргумент функции C_FindObjects задаёт размер выходного массива объектов. А последний — количество полученных объектов после очередного поиска.
Поиск приватного ключа производился по атрибуту его класса и идентификатору. Мы рассчитывали, что найдётся хотя бы один объект по заданному шаблону и брали любой из них. Используем найденный ключ для вычисления сырой подписи:
В этом примере подпись и хеш можно считать одновременно. Такой вариант рекомендован для безопасности: цепочку «хеширование-подпись» лучше не «разрывать». Чтобы показать, какой алгоритм хеширования использовать, мы передали его OID.
Также имеется возможность считать сырую подпись в два этапа: сначала брать хеш от данных, а затем вычислялась подпись от хеша. Такой подход более модульный, т.к. алгоритмы хеширования и вычисления подписи могут быть любыми и их можно комбинировать. Естественно, комбинировать можно с некоторыми ограничениями, которые налагаются стандартами, например, на длину хеша.
Работа с функциями расширения на примере создания запроса на сертификат
Пришло время показать, как работать с функциями-расширениями. Сделаем это на примере библиотеки PKCS#11 от Рутокен и создадим запрос на сертификат для нашей ключевой пары. Генерация запроса на сертификат не описана в стандарте, поэтому сделаем это через функцию-расширение C_EX_CreateCSR.
Можно заметить, что работа с функциями расширения очень похожа на работу со стандартными функциями. Основное отличие лишь в том, что мы обращаемся к другому списку функций CK_FUNCTION_LIST_EXTENDED_PTR. Создание запроса на сертификат происходит в одну строчку функцией C_EX_CreateCSR и возвращает запрос в DER-формате. Также стоит обратить внимание, что память, выделенную внутри библиотеки, следует высвобождать с помощью функции C_EX_FreeBuffer.
По полученному запросу можно получить сертификат в Удостоверяющем центре. Например, воспользуемся тестовым УЦ КриптоПро для получения сертификата. Полученный сертификат необходимо скачать в DER-формате, сохранить в файле с именем «cert_2012-256.cer» и положить в директорию, из которой вы запускаете примеры. Полученный сертификат можно импортировать на токен.
Импорт сертификата на токен. Создание объекта вручную
Сертификаты на токене так же как и ключи — являются объектами. Сертификат можно импортировать на токен, создав объект с нужными атрибутами. Для этого мы реализовали функцию: import_cert:
На этот раз мы создали объект напрямую с помощью функции C_CreateObject. Для создания объекта сертификата мы аналогично передали шаблон с атрибутами объекта: тело сертификата, идентификатор, тип доступа, тип сертификата и т.п.
Функцию C_CreateObject можно использовать не только для создания сертификата на токене, но и для создания других объектов, например, публичных ключей (CKO_PUBLIC_KEY), закрытых ключей (CKO_PRIVATE_KEY), симметричных ключей (CKO_SECRET_KEY), обычных данных (CKO_DATA). Их значение будет также содержаться внутри атрибута CKA_VALUE.
Теперь, когда у нас на токене имеется и ключевая пара и сертификат, для закрепления материала рассмотрим операцию создания CMS-подписи.
Формирование CMS-подписи
Данная возможность является расширением библиотеки Рутокен и может работать только с ГОСТ-ключами. Для создания подписи в формате CMS требуется наличие закрытого ключа и сертификата (неявно содержащего в себе открытый ключ). Создание CMS-подписи реализовано в функции sign_cms:
Создание CMS-подписи произошло вызовом всего лишь одной функции расширения C_EX_PKCS7Sign. А объект сертификата нашелся так же просто, как и объект ключа с минимальными отличиями в коде. Все это показывает, как просто и лаконично (по меркам языка C) спроектирован стандарт PKCS#11 с идеей объектного подхода.
Получение и установка атрибутов публичных объектов
В завершение главы про объекты хотелось бы отметить, что атрибуты публичных объектов можно получать и изменять. Делается это с помощью функций C_SetAttributeValue и C_GetAttributeValue.
Логика работы с функцией C_SetAttributeValue очень похожа на логику создания объектов — создаётся шаблон, атрибуты заполняются указанными значениями. Все это передаётся на вход функции C_SetAttributeValue. Изменять атрибуты можно, если у объекта атрибут CKA_MODIFIABLE равен CK_TRUE.
При получении значений атрибутов иногда неизвестно, какой будет выходной размер атрибута. В таком случае создается шаблон с нулевыми значениями указателей на выходные объекта атрибутов и их размеров. Этот шаблон передаётся функции C_GetAttributeValue. Функция заполняет значение выходных размеров атрибутов в этом шаблоне. Мы может воспользоваться этой информацией для выделения памяти под атрибуты в шаблоне и дальнейшего вызова функции C_GetAttributeValue.
Для демонстрации работы функций C_GetAttributeValue и C_SetAttributeValue рассмотрим пример получения тела сертификата и изменения текстовой метки сертификата:
Про механизмы
Мы уже ранее встречались с механизмами в примерах и дали краткое описание. Давайте теперь опишем их подробнее. Описание механизмов в PKCS#11 было вынесено в отдельный документ, с которым можно ознакомиться здесь. В этом документе написано:
A mechanism specifies precisely how a certain cryptographic process is to be performed. PKCS #11 implementations MAY use one of more mechanisms defined in this docuоment.
Отсюда следует, что механизмы:
Определяют некоторое криптографическое преобразование.
PCKS#11 может использовать механизмы, определенные в этом документе.
Более того, некоторые PKCS#11-библиотеки могут использовать и другие механизмы.
Согласно документации механизмы можно разделить на:
Механизмы шифрования и расшифрования (Encrypt & Decrypt);
Механизмы подписи и проверки подписи (Sign & Verify);
Механизм формирования хеша (Digest);
Механизм генерации симметричных и асимметричных ключей (Gen. Key/Key Pair);
Экспорт и импорт ключей (Wrap & Unwrap);
Выработка общего ключа на основе асимметричных ключей (Derive).
Каждый механизм идентифицирует одну или несколько из этих функций. Так, например, ранее рассмотренный механизм CKM_GOSTR3410_KEY_PAIR_GEN предназначен для генерации ключей, а механизм CKM_AES_ECB может использоваться как для зашифрования/расшифрования, так и для свертки/развертки ключей.
Работа с механизмами, на примере зашифрования сообщения
Механизмы в PKCS#11 задаются через структур CK_MECHANISM. Объекты типа CK_MECHANISM в дальнейшем передаются PKCS#11-функциям для указания нужного механизма. Сама структура CK_MECHANISM состоит из трех элементов:
Идентификатор механизма (mechanism);
Указатель на параметры механизма (pParameter);
Длина в байтах параметров механизма (ulParameterLen).
Самый простой пример параметра механизма — вектор инициализации для алгоритмов шифрования. Попробуем на примере показать, как можно зашифровать сообщение через механизм CKM_GOST28147 с указанным вектором инициализации. Пример реализован внутри функции encrypt_data:
В этом примере стоит обратить внимание на то, как передаётся вектор инициализации механизму шифрования. Стоит заметить, что после вызова функции C_Encrypt вызывать функцию C_EncryptFinal не нужно: для многих механизмов вызов C_Encrypt эквивалентен последовательному вызову функций C_EncryptUpdate и C_EncryptFinal.
Проверка поддержки механизмов
Ранее в примерах мы всегда надеялись на то, что токен поддерживает используемые механизмы, но, вообще говоря, — это может быть не так. Так, например, Рутокен Lite не поддерживает криптографические механизмы. Поэтому перед началом работы с каким-либо механизмом желательно убедиться в том, что он поддерживается устройством. Это можно сделать с помощью функции C_GetMechanismList, которая возвращает список поддерживаемых механизмов токена. Напишем удобную обертку для проверки поддержки определенного механизма:
Эта обертка удобна для одноразовой проверки поддержки механизма. Если же мы хотим проверить поддержку сразу нескольких механизмов, то лучше получить список поддерживаемых механизмов токена один раз и проверить наличие требуемых механизмы. Это позволит сократить количество обращений к токену и время работы программы, соответственно.
Утилита pkcs11-tool
Часто бывает необходимо просто и быстро выполнить какое-либо обращение к PKCS#11-библиотеке, не прибегая к написанию кода. На помощь может прийти утилита pkcs11-tool, которая распространяется в составе пакета (opensc)[https://github.com/OpenSC/OpenSC].
Утилита pkcs11-tool может гибко выполнять огромное количество стандартных PKCS#11-операций. Например:
Генерация ключевых пар:
pkcs11-tool —module /usr/lib/librtpkcs11ecp.so —keypairgen —key-type GOSTR3410-2012-256:B —id 45 -l
Создание сырой подписи:
pkcs11-tool —module /usr/lib/librtpkcs11ecp.so —sign —id 45 -l -i file.txt —mechanism GOSTR3410-WITH-GOSTR3411-12-256
Генерация псевдослучайных последовательностей:
pkcs11-tool —module /usr/lib/librtpkcs11ecp.so —generate-random 16
Получение списка объектов на токене:
pkcs11-tool —module /usr/lib/librtpkcs11ecp.so -O
Получение механизмов, поддерживаемых токеном:
pkcs11-tool —module /usr/lib/librtpkcs11ecp.so -M
Список не является исчерпывающим, более подробно о полных возможностях утилиты можно прочитать в мануале.
Дополнительный материал
Если вы захотите узнать, как работать с более специфичными функциями, то большое количество примеров по работе с PKCS#11 можно найти в нашем SDK. Все примеры по работе с PKCS#11-библиотекой находятся в директории sdkpkcs11samples.
Выводы
Зачастую библиотека PKCS#11 является основным кирпичиком при написании приложений или других библиотек для работы со смарт-картами на других языках программирования. Поэтому знание основ работы с PKCS#11 на языке C может помочь разобраться с тем, как работать с обертками или как лучше реализовать архитектуру новой обертки.
Кроме PKCS#11 с объектами на смарт-картах/токенах можно работать через:
OpenSSL API (pkcs11 engine, rutoken engine);
Java c JDK 8 или новее через интерфейсы PKCS#11-wrapper и JCA;
C++ с использованием библиотеки pki-core;
Если вы хотите узнать про какую-то реализацию подробнее, то напишите в комментариях и мы постараемся в ближайшее время выпустить новую статью с её разбором.
Источник
When trying to build (generate rpms) for a tizen project using gbs, I set up gbs, install mic and set up the .gbs.conf file with the appropriate profiles, repos and urls.
when i try to build for target architecture (armv7l) using
sudo gbs build -A armv7l --debug --clean
when it tries to sign the builds in the temp folder,
it tries to generate author signature and distributor signature and it fails with [542s] Error: xmlsec crypto intialization failed. Following is the log.
> [541s] Sign as platform level
> [541s] Generate Author Signature
> [541s] Key type rsa
> [541s] Package is a directory
> [542s] func=xmlSecOpenSSLAppLoadRANDFile:file=app.c:line=1499:obj=unknown:subj=RAND_load_file:error=4:crypto library function failed:file=/home/abuild/.rnd
> [542s] func=xmlSecOpenSSLAppInit:file=app.c:line=68:obj=unknown:subj=xmlSecOpenSSLAppLoadRANDFile:error=1:xmlsec library function failed:
> [542s] func=xmlSecAppCryptoInit:file=crypto.c:line=26:obj=unknown:subj=xmlSecCryptoAppInit:error=1:xmlsec library function failed:
> [542s] Error: xmlsec crypto intialization failed.
> [542s] Error: initialization failed
> [542s] Usage: xmlsec <command> [<options>] [<files>]
> [542s]
> [542s] xmlsec is a command line tool for signing, verifying, encrypting and
> [542s] decrypting XML documents. The allowed <command> values are:
> [542s] --help display this help information and exit
> [542s] --help-all display help information for all commands/options and exit
> [542s] --help-<cmd> display help information for command <cmd> and exit
> [542s] --version print version information and exit
> [542s] --keys keys XML file manipulation
> [542s] --sign sign data and output XML document
> [542s] --verify verify signed document
> [542s] --sign-tmpl create and sign dynamicaly generated signature template
> [542s] --encrypt encrypt data and output XML document
> [542s] --decrypt decrypt data from XML document
> [542s]
> [542s]
> [542s] Report bugs to http://www.aleksey.com/xmlsec/bugs.html
> [542s]
> [542s] Written by Aleksey Sanin <aleksey@aleksey.com>.
> [542s]
> [542s] Copyright (C) 2002-2016 Aleksey Sanin <aleksey@aleksey.com>. All Rights Reserved..
> [542s] This is free software: see the source for copying information.
> [542s]
> [542s] Failed to generate Author Signature. [1]
> [542s] Generate Distributor Signature
> [542s] Key type rsa
> [542s] Package is a directory
> [542s] func=xmlSecOpenSSLAppLoadRANDFile:file=app.c:line=1499:obj=unknown:subj=RAND_load_file:error=4:crypto library function failed:file=/home/abuild/.rnd
> [542s] func=xmlSecOpenSSLAppInit:file=app.c:line=68:obj=unknown:subj=xmlSecOpenSSLAppLoadRANDFile:error=1:xmlsec library function failed:
> [542s] func=xmlSecAppCryptoInit:file=crypto.c:line=26:obj=unknown:subj=xmlSecCryptoAppInit:error=1:xmlsec library function failed:
> [542s] Error: xmlsec crypto intialization failed.
> [542s] Error: initialization failed
> [542s] Usage: xmlsec <command> [<options>] [<files>]
> [542s]
> [542s] xmlsec is a command line tool for signing, verifying, encrypting and
> [542s] decrypting XML documents. The allowed <command> values are:
> [542s] --help display this help information and exit
> [542s] --help-all display help information for all commands/options and exit
> [542s] --help-<cmd> display help information for command <cmd> and exit
> [542s] --version print version information and exit
> [542s] --keys keys XML file manipulation
> [542s] --sign sign data and output XML document
> [542s] --verify verify signed document
> [542s] --sign-tmpl create and sign dynamicaly generated signature template
> [542s] --encrypt encrypt data and output XML document
> [542s] --decrypt decrypt data from XML document
> [542s]
> [542s]
> [542s] Report bugs to http://www.aleksey.com/xmlsec/bugs.html
> [542s]
> [542s] Written by Aleksey Sanin <aleksey@aleksey.com>.
> [542s]
> [542s] Copyright (C) 2002-2016 Aleksey Sanin <aleksey@aleksey.com>. All Rights Reserved..
> [542s] This is free software: see the source for copying information.
> [542s]
> [542s] Failed to generate Distributor Signature. [1]
> [542s] error: Bad exit status from /var/tmp/rpm-tmp.2K6qZw (%install)
> [542s]
> [542s]
> [542s] RPM build errors:
> [542s] Bad exit status from /var/tmp/rpm-tmp.2K6qZw (%install)
asked Jul 24, 2019 at 21:49
siddharthsnsiddharthsn
1,7091 gold badge21 silver badges32 bronze badges
The ‘buildroot‘ folder in gbs.conf should be a folder owned by root or you should run the build as root.
«unable to write to /dev/null» is an error you’ll likely see in your logs when you’re not the root. this is the same reason why the xmlsec crypto initialization fails (unable to load RAND file and unable to sign signature1.xml, author-signature.xml file).
so the solution or at least a work around could be changing the ‘buildroot’ to /tmp/ or any other folder under root.
answered Jul 25, 2019 at 19:09
siddharthsnsiddharthsn
1,7091 gold badge21 silver badges32 bronze badges