E agora, quando quase adicionei a geração de
certificados autoassinados à estação de trabalho criptográfica baseada nos tokens PKCS # 11 cryptoarmpkcs e estava pronta para começar a escrever o artigo, recebi uma carta como esta:
Somos a CA da UZNIREK, tivemos dificuldade em emitir ES no formato pkcs # 11 para EGAIS, o portal não entende o ES no formato CSP Znamerek, solicitamos que você ajude nesse problema.
Eu não conhecia todos os meandros de trabalhar com o EGAIS, mas como era o PKCS # 11, sugeri o uso do utilitário cryptoarmpkcs para
gerar uma solicitação e instalar um certificado para um token após o recebimento da CA. A resposta que recebi foi um pouco perturbadora:
Infelizmente, o fato é que gravamos ES no RuToken 2.0 por meio do CryptoPro CSP, mas com todas as configurações adequadas, o portal EGAIS não viu o ES no meio-chave, o cliente entrou em contato conosco e descobrimos que o problema não é o certificado da chave está escrito nesse formato, eis o manual dev.rutoken.ru/display/KB/RU1051
.
Eu (e não apenas eu) já escrevi muitas vezes que muitos usam tokens criptográficos com o suporte da criptografia russa como
drives flash comuns . E esse foi o caso quando a chave e o certificado não chegaram ao token como objetos PKCS # 11. Foi uma pena que eles não seguiram o conselho e nem tentaram criar uma solicitação. Mas então decidi deixar tudo de lado e descobrir como e em quais certificados o EGAIS Rosalkogolregulirovanie são emitidos. E consideraremos apenas os tokens criptográficos PKCS # 11. A maior decepção é o acesso ao EGAIS apenas através do Windows e do navegador IE. Por outro lado, a geração de uma solicitação de certificado e instalação de certificado também pode ser realizada em qualquer sistema operacional, se houver drivers / bibliotecas para o token correspondente.
Pelo menos os tokens PKCS # 11 JaCarta, RutokenECP-2.0, o token de software LS11SW2016 e até o
token de nuvem têm suporte no MS Windows, Linux e OS X. E não apenas nesses SOs.
De fato, devemos prestar homenagem aos desenvolvedores do EGAIS. Eles propuseram uma tecnologia interessante que permite o acesso ao uso de certificados pessoais (certificado mais par de chaves) armazenados em tokens criptográficos com suporte para criptografia russa e protege o canal nos certificados RSA. Embora se dissessem A, então poderia-se dizer B, ou seja, proteger o canal nos algoritmos GOST-ov. A única coisa triste é que tudo isso é adaptado apenas para o MS Windows (ou estou enganado?), Ou melhor, para o Internet Explorer. E os utilitários para gerar solicitações de certificado para EGAIS estão vinculados a um token específico.
Mas o utilitário cryptoarmpkcs é multiplataforma. Além disso, é capaz de trabalhar com qualquer token criptográfico PKCS # 11 que suporta criptografia russa.
Então, qual é a peculiaridade da solicitação de certificado para EGAIS? A principal característica é a presença obrigatória no nome distinto do titular do certificado (sujeito do DN) de um campo adicional não-estruturadoName (UN) (oid - 1.2.840.113549.1.9.2). Se o proprietário do certificado for um empreendedor individual, a linha "KPP =" será escrita neste campo e, se o proprietário for uma entidade legal, essa linha será escrita neste campo:
PPC = reason_code_of_tax_account_account:
Nesse sentido, o requisito na primeira página da guia de solicitação de certificado foi adicionado ao botão EGAIS:
Outra característica é que os titulares de certificados para o EGAIS podem ser licenciados do sistema de declaração FSRAP (oid - 1.2.643.3.6.78.4.4). Isso também precisa ser considerado ao criar uma solicitação:
Depois que todos os campos da solicitação de certificado forem preenchidos e você confirmar a correção dos dados, um par de chaves será gerado e a solicitação será criada:
Se você olhar para a solicitação, poderá ver o oid-s (uso da chave extendida), necessário para o EGAIS Rosalkogolregulirovanie:
Aqui você deve prestar atenção (na captura de tela anterior) ao rótulo do par de chaves. Na terminologia PKCS # 11, esse é o atributo CKA_LABEL para a chave pública e privada. É por esse esquema que um rótulo (nome da chave) é criado pelo gerador de consultas EGAIS para JaCarta do CenterInform FSUE:
Tradicionalmente
certificado triplo
x chave_ pública x chave privada
no token é conectado através do
atributo CKA_ID
:
A maneira mais comum de especificar CKA_ID é usar o valor da função de hash do valor da chave pública. É esse método para vincular um triplo de objetos usado no projeto NSS (Network Security Services). Ao mesmo tempo, o algoritmo SHA1 é usado como uma função hash.
Infelizmente, CKA_LABEL e CKA_ID podem ser configurados / alterados a qualquer momento e com qualquer valor. Portanto, sempre há a possibilidade de o certificado ser associado à chave privada de outra pessoa. Não há necessidade de explicar quais serão as consequências disso.
Em geral, existe um algoritmo matemático estrito que permite conectar o triplo CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY em um único todo?
Sim,
existe um algoritmo baseado em mecanismos criptográficos (CKM_) do token.
Infelizmente (embora possa ser objetivamente entendido), ele considera um grupo triplo através de CKA_LABEL, formado pelo método acima mencionado. Além disso, para as chaves públicas e privadas, SKA_ID é formado de maneira semelhante. Para chaves, isso é apenas um desastre, porque no entanto, nem CKA_ID nem CKA_LABEL estão vinculados de maneira alguma à própria chave. Isso também se aplica ao certificado após a instalação no token. Se na formação tradicional de CKA_ID como um hash da chave pública, você sempre pode verificar se um corresponde ao outro e, ao configurar CKA_ID e CKA_LABEL da maneira descrita acima, isso não pode ser feito.
Pode surgir uma pergunta, mas como verificar a conformidade de uma chave privada? A resposta é simples - calculando o valor da chave pública em relação à privada. Quanto ao certificado, o valor de sua chave pública está, naturalmente, nele. Além disso, o próprio certificado contém o valor CKA_ID para o detentor do certificado (identificador da chave do sujeito do certificado) e o editor do certificado (identificador da chave da autoridade de certificação):
O mais desagradável foi que, ao instalar o certificado, não é a presença da chave privada que está marcada, mas apenas a chave pública é suficiente. Nesse caso, o certificado será instalado, mas não haverá chave privada nele. Outro problema Esta é uma pesquisa de chave pública pelo TIN. Imagine que uma pessoa tenha um NIF e várias chaves para vários certificados. A qual pertence? Depois disso, fica claro o requisito para o JaCarta ter
apenas um certificado e um par de chaves:
Este erro pode estar relacionado à duplicação de certificado. No JaCarta Single Client no modo administrador, na guia GOST Depois de inserir o código PIN, uma pública, uma chave privada e um certificado devem estar visíveis. Nesse caso, a duplicação de chave é visível. Você precisa remover os extras. Reinsira a mídia no conector USB e tente instalar o UTM novamente. Se o erro persistir, inicialize Jacarta de acordo com o link 1 e continue com o processo de geração novamente.
Vamos torcer para que essa lacuna seja eliminada. Você pode perguntar como o utilitário cryptoarmpkcs para EGAIS instala o certificado. Para total compatibilidade com o JaCarta, mantivemos a ideologia de que CKA_ID e CKA_LABEL para chaves são iguais. Mas somente depois de instalar o certificado no token e vinculá-lo ao par de chaves. Até então, o par de chaves CKA_ID é mantido igual ao valor do hash da chave pública.
Depois de instalar o certificado, você pode usá-lo para
assinar documentos .
Você pode ler sobre certificados autoassinados
aqui :
As distribuições estão no mesmo lugar.