Geekly articles weekly

Tokens PKCS # 11: geração de par de chaves e extração de chaves privadas (Continuação)

imagemNo artigo anterior “Tokens PKCS # 11: certificados e chaves privadas ”, examinamos como associar exclusivamente o trio Certificado x Chave pública x Chave privada armazenada no token / cartão inteligente com a interface PKCS # 11 v.2.40. Neste artigo, falaremos sobre a geração de pares de chaves. Vamos contar, como da última vez, em “GOST R 34.10-2012 Tecnologia da Informação. Segurança da informação criptográfica. Os processos de formação e verificação de assinaturas digitais eletrônicas . ”

Então, o que é um par de chaves?


O par de chaves inclui duas chaves:

  • / /Private key — , . / ;

  • / / Public key — , , .

Deve-se lembrar que as chaves pública e privada não são apenas seus valores (para a chave pública GOST R 34.10-2001 são 512 bits), mas também os parâmetros do esquema de assinatura digital (seção 5.2 do GOST R 34.10-2012 ). No futuro, por simplicidade, chamaremos os parâmetros do esquema de assinatura digital de parâmetros (criptoparâmetros) do par de chaves.

A chave pública da assinatura é calculada como o valor de alguma função da chave privada, mas o conhecimento da chave pública torna impossível determinar a chave privada.

Para os pares de chaves GOST R 34.10-2001 e GOST R 34.10-2012 com um comprimento de chave privada de 256 bits (respectivamente, uma chave pública é 512 bits), os seguintes parâmetros criptográficos são definidos:
  1. id-GostR3410-2001-CryptoPro-A-ParamSet;
  2. id-GostR3410-2001-CryptoPro-B-ParamSet;
  3. id-GostR3410-2001-CryptoPro-C-ParamSet;
  4. id-GostR3410-2001-CryptoPro-XchA-ParamSet;
  5. id-GostR3410-2001-CryptoPro-XchB-ParamSet.

Para pares de chaves GOST R 34.10-2012 com um comprimento de chave privada de 512 bits (respectivamente, uma chave pública é 1024 bits), são definidos os seguintes parâmetros criptográficos ("Tecnologia da informação. Proteção criptográfica da informação. Parâmetros elípticos da curva para algoritmos e protocolos criptográficos"):
  1. id-tc26-gost-3410-2012-512-paramSetA;
  2. id-tc26-gost-3410-2012-512-paramSetB.

A composição dos parâmetros criptográficos é definida na cláusula 5.2 do GOST R 34.10-2012 . Essa estrutura inclui um q primo - a ordem do subgrupo do grupo de pontos da curva elíptica:

imagem

E determina o comprimento da chave privada / pública e a correção da chave privada:

imagem- o comprimento da chave privada é de 256 bits;

imagem- O comprimento da chave privada é de 512 bits.
E assim, a chave pública é obtida da chave privada.

E de onde vem a chave privada?


Para obter uma chave privada, primeiro você precisa decidir por quanto tempo a chave privada será (256 ou 512 bits) e depois decidir os parâmetros criptográficos do par de chaves. Agora pegamos o sensor de número aleatório e obtemos um número aleatório do comprimento correspondente. Na verdade, esse número aleatório deve se tornar o valor d da chave privada (chave de assinatura d). Este valor deve atender à seguinte regra:

0 <d <q , em que q é um número primo dos parâmetros de criptografia.

E se essa condição não for atendida? Se d == 0 , basta gerar um novo número aleatório. Caso contrário, basta dividir por um número inteiro o valor de d , que excede q , porq (d% q) . O restante se tornará o valor da chave privada.

É por isso que o regulador (FSB da Rússia) faz exigências especiais ao sensor de números aleatórios.

Como um exemplo da fonte principal para preencher o buffer:

  • números aleatórios incluem:
  • registro TSC do processador - contador de clock do processador;
  • Contador de tempo GTC
  • contador de incremento automático em um thread separado;
  • função padrão rand ();
  • coordenadas do mouse.

Como fontes adicionais para preencher esse buffer, podem ser:

  • O contador de processos no modo de usuário;
  • Temporizador de alta resolução do Windows.

Portanto, para que o token / smart card PKCS # 11 gere um par de chaves dentro de si, é necessário ter um token / smart card do sensor de número aleatório de hardware interno que atenda aos requisitos do controlador. E só então podemos falar sobre a não removibilidade da chave privada.

Para gerar um par de chaves, a função C_GenerateKeyPair é usada . Dependendo do par de chaves (com qual comprimento de chave privada é de 256 ou 512 bits) que geramos, o mecanismo apropriado será usado nele:

  • CKM_GOSTR3410_KEY_PAIR_GEN para um par de chaves com uma chave privada de 256 bits;
  • CKM_GOSTR3410_512_KEY_PAIR_GEN para um par de chaves com uma chave privada de 512 bits.

Ao gerar um par de chaves, seus atributos são configurados, por exemplo, cryptoparameters:

imagem

Estamos interessados ​​em atributos de recuperação de chave privada.


Anteriormente, esse é o atributo CKA_SENSITIVE, responsável por obter o valor da chave privada. Se o valor do atributo CKA_SENSITIVE estiver definido como CK_TRUE, a chave privada não poderá ser extraída do token de forma limpa. O segundo atributo CKA_EXTRACTABLE permite obter a chave privada em formato criptografado. Para fazer isso, ele deve ser definido como CK_TRUE.

Definir o atributo CKA_SENSITIVE como CK_TRUE e o atributo CKA_EXTRACTABLE como CK_FALSE ao gerar o par de chaves torna a chave privada completamente irrecuperável. A capacidade de determinar se a chave é exportável está disponível no navegador Redfox:

imagem

Alguém dirá - e se mudarmos os valores desses atributos. Como regra, isso não pode ser feito, a proteção não pode ser reduzida, assim como “você não pode diminuir o grau”. Da mesma maneira, você pode tornar a chave privada não recuperável depois de importada para o token (a menos que o token / cartão inteligente permita a importação). Após criar (ou durante a criação) o objeto CKO_PRIVATE_KEY, é necessário definir CKA_SENSITIVE = CK_TRUE e o atributo CKA_EXTRACTABLE = CK_FALSE .

No último caso (na importação), deve-se ter em mente que, embora a chave privada tenha se tornado não recuperável, ela apareceu de lado (por exemplo, do PKCS # 12 ) e não há garantia de que não haja duplicata em outro lugar.

E aqui não faria mal lembrá-lo, caro leitor, quea segurança é fornecida apenas pelo COMPLEXO de medidas técnicas e organizacionais . Portanto, não funcionará para consertar brechas na segurança organizacional às custas de meios técnicos e vice-versa - tudo deve ser organizado organicamente. Inclusive, ao acessar o valor da chave privada.

Verifique se o token / cartão inteligente contém objetos PKCS # 11 completos (CKO_PRIVATE_KEY, CKO_PUBLIC_KEY, CKO_CERTIFICATE) envolvidos nas operações criptográficas do próprio token, usando o utilitário p11conf disponível para download gratuito:

$ /usr/local/bin64/p11conf -h
usage:  /usr/local/bin64/p11conf [-hitsmIupPred] -A APIpath [-c slotID -U userPin -S SOPin -n newPin -L label]
        -h display usage
        -i display PKCS#11 library info
        -s display slot(s) info (-c slotID is optional)
        -t display token(s) info (-c slotID is optional)
Others must use -c slotID
        -m display mechanism list
        -I initialize token 
        -u initialize user PIN
        -p set the user PIN
        -P set the SO PIN
        -r remove all objects
        -e enumerate objects
        -d dump all object attributes
Copyright(C) 2011-2016
$

Para ver quais objetos estão no token, basta executar um comando do formulário:

bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 -e
Enter user PIN: ********
Token objects:
1: CKO_PRIVATE_KEY
         label: 'LS11SW2016:; ..;0x23855(145493)'
2: CKO_PUBLIC_KEY
         label: 'LS11SW2016:; ..;0x23855(145493)'
3: CKO_CERTIFICATE
         label: 'LS11SW2016:; ..;0x23855(145493)'
…
OK
bash-4.3$

Se esses objetos estiverem ausentes no token e eles disserem que o token PKCS # 11 com a chave não extraível é usado, provavelmente não é esse o caso. Provavelmente, o token é usado simplesmente como uma unidade flash com um código PIN, e o certificado e as chaves são armazenados como objetos CKO_DATA .

E, finalmente, para ver não apenas quais tipos de objetos estão armazenados no token, mas objetos com todos os atributos, você deve usar o sinalizador –d :

bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 –e -d
Enter user PIN: ********
Token objects:
1: CKO_PRIVATE_KEY
	 label: 'LS11SW2016:; ..;0x23855(145493)'
==================================
Object handle: 0x1
----------------------------------
CKA_CLASS
0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
CKA_TOKEN
0x01, 
CKA_PRIVATE
0x01, 
CKA_LABEL
0x4c, 0x53, 0x31, 0x31, 0x53, 0x57, 0x32, 0x30, 
0x31, 0x36, 0x3a, 0xd0, 0x9e, 0xd0, 0x9e, 0xd0, 
0x9e, 0x20, 0xd0, 0x9b, 0xd0, 0x98, 0xd0, 0xa1, 
0xd0, 0xa1, 0xd0, 0x98, 0x2d, 0xd0, 0xa1, 0xd0, 
0xbe, 0xd1, 0x84, 0xd1, 0x82, 0x3b, 0xd0, 0x9c, 
0xd0, 0xb0, 0xd1, 0x81, 0xd0, 0xbb, 0xd0, 0xbe, 
0x20, 0xd0, 0x90, 0x2e, 0xd0, 0x90, 0x2e, 0x3b, 
0x30, 0x78, 0x32, 0x33, 0x38, 0x35, 0x35, 0x28, 
0x31, 0x34, 0x35, 0x34, 0x39, 0x33, 0x29, 
CKA_VALUE: attribute sensitive
CKA_KEY_TYPE
0x03, 0x10, 0x32, 0xd4, 0x00, 0x00, 0x00, 0x00, 
CKA_SUBJECT
0x30, 0x81, 0x9b, 0x31, 0x0b, 0x30, 0x09, 0x06, 
0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x52, 0x55, 
0x31, 0x1a, 0x30, 0x18, 0x06, 0x03, 0x55, 0x04, 
0x03, 0x0c, 0x11, 0xd0, 0x9c, 0xd0, 0xb0, 0xd1, 
0x81, 0xd0, 0xbb, 0xd0, 0xbe, 0x20, 0xd0, 0x90, 
0x2e, 0xd0, 0x90, 0x2e, 0x31, 0x1c, 0x30, 0x1a, 
0x06, 0x03, 0x55, 0x04, 0x0a, 0x0c, 0x13, 0xd0, 
0x9b, 0xd0, 0x98, 0xd0, 0xa1, 0xd0, 0xa1, 0xd0, 
0x98, 0x2d, 0xd0, 0xa1, 0xd0, 0xbe, 0xd1, 0x84, 
0xd1, 0x82, 0x31, 0x1f, 0x30, 0x1d, 0x06, 0x09, 
0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x09, 
0x01, 0x16, 0x10, 0x61, 0x6d, 0x61, 0x73, 0x6c, 
0x6f, 0x76, 0x40, 0x6c, 0x69, 0x73, 0x73, 0x69, 
0x2e, 0x72, 0x75, 0x31, 0x31, 0x30, 0x2f, 0x06, 
0x03, 0x55, 0x04, 0x08, 0x0c, 0x28, 0x35, 0x30, 
0x20, 0x20, 0xd0, 0x9c, 0xd0, 0xbe, 0xd1, 0x81, 
0xd0, 0xba, 0xd0, 0xbe, 0xd0, 0xb2, 0xd1, 0x81, 
0xd0, 0xba, 0xd0, 0xb0, 0xd1, 0x8f, 0x20, 0xd0, 
0xbe, 0xd0, 0xb1, 0xd0, 0xbb, 0xd0, 0xb0, 0xd1, 
0x81, 0xd1, 0x82, 0xd1, 0x8c, 0x20, 
CKA_ID
0x97, 0x46, 0x4e, 0xcc, 0x7c, 0xa9, 0xea, 0xb1, 
0x0a, 0xda, 0xec, 0x10, 0xf4, 0x49, 0x7e, 0x7f, 
0x2d, 0x71, 0x4b, 0xa7, 
CKA_SENSITIVE
0x01, 
. . .
CKA_GOSTR3410_PARAMS
0x06, 0x09, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x02, 
0x01, 0x02, 0x01, 
CKA_GOSTR3411_PARAMS
0x06, 0x08, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 
0x02, 0x03, 
CKA_GOST28147_PARAMS
0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x1f, 
0x01, 
…
OK
bash-4.3$

Tudo o que foi dito aqui é válido para um token / cartão inteligente com interface PKCS # 11, incluindo um token na nuvem.

Concluindo, lembramos que tokens / cartões inteligentes com a interface PKCS # 11 são amplamente utilizados em projetos Mozilla (navegadores, clientes de email), em navegadores Chrome do Google e outros projetos. Se falamos sobre a Rússia, os tokens / cartões inteligentes com a interface PKCS # 11 são usados ​​com sucesso para acessar o portal de Serviços de Estado.

Source: https://habr.com/ru/post/pt400943/

More articles:


All Articles