Pacote de serviços de segurança de rede e utilitário oidcalc

Quando o projeto associado ao uso dos algoritmos criptográficos russos no cliente de email KMail de, na aplicação do GnuPG e Kleopatra , tradução russa oid Feminino de uma forma decimal pontilhada de um DER-codificado, eu decidi usar o utilitário oidcalc do pacote do NSS (os Serviços de Segurança de Rede) , que é pré-instalado em todas as distribuições Linux, incluindo clones domésticos. O código resultante foi usado no trabalho.

E tudo correu bem até que um oid foi encontrado , no qual havia um dígito decimal 0 (zero), ou seja, “1.2.643.2.2.36.0” (szOID_GostR3410_2001_CryptoPro_XchA_ParamSet). E aqui uma surpresa desagradável me esperava - meu código parou de funcionar. Em algum momento, eu decidi olhar para o que esse oid é traduzido :

# oidcalc 1.2.643.2.2.36.0
0x2a, 0x85, 0x3, 0x2, 0x2, 0x24,
#

Mas deveria ter sido 0x2a, 0x85, 0x3, 0x2, 0x2, 0x24, 0x0 - não havia zero hexadecimal à direita.

Tentei traduzir outro oid "1.2.643.3.6.0.1" (CryptoPro CA, período de validade do certificado 1 mês):

# oidcalc 1.2.643.3.6.0.1
0x2a, 0x85, 0x3, 0x3 0x3, 0x6, 0x1,
#

O mesmo resultado triste - não há penúltimo byte com zero. Ficou claro que o utilitário oidcalc lança zeros do oid. O exemplo a seguir confirma apenas essa suposição:

# oidcalc 1.2.643.3.6.1
0x2a, 0x85, 0x3, 0x3 0x3, 0x6, 0x1,
#

Para outra verificação, tive que usar o utilitário oid e obtive o resultado esperado:

# ./oid 1.2.643.2.2.36.0
06 07 2A 85 03 02 02 24 00
# ./oid 1.2.643.3.6.0.1
06 07 2A 85 03 03 06 00 01
#

O utilitário oid exibe o resultado já na codificação ASN1, onde o primeiro byte determina o tipo de sequência, o segundo byte - o comprimento da sequência em bytes e depois o próprio oid em notação hexadecimal.

Depois disso, resta analisar o código fonte do utilitário oidcalc.c e reunir as alterações mínimas:

       . . .
        memset(buf, 0, sizeof(buf));
        val = atoi(curstr);
        count = 0;
/* */
    if(curstr[0] != '0')
	
        while (val) {
            buf[count] = (val & 0x7f);
            val = val >> 7;
            count++;
        }
/*   */
    else
	buf[count++] = 0x00;
        . . . 

Agora, se você reconstruir o utilitário, tudo funcionará bem:

#oidcalc 1.2.643.2.2.36.0
0x2a, 0x85, 0x3, 0x2, 0x2, 0x24, 0x0,
#oidcalc 1.2.643.3.6.0.1
0x2a, 0x85, 0x3, 0x3, 0x6, 0x0, 0x1,
#

Qual é o erro do desenvolvedor de utilitário? Nas pequenas coisas. Para converter um número de uma string em um todo, o autor usa a função atoi , que retorna 0 (zero) no caso da tradução do caractere '0' e no caso de impossibilidade de traduzir (nenhum número é especificado). Acabou sendo suficiente para adicionar verificação adicional e funcionou.

Escrevi para desenvolvedores do NSS? Eu escrevi sim Além disso, o pacote NSS com plug-in com tokens / smartcards criptográficos que suportam a interface PKCS # 11 é realmente o núcleo criptográfico dos aplicativosda Mozilla e também usado nos navegadores Chrome do Google. Não houve resposta, o código não foi corrigido. Portanto, esta nota apareceu para que outra pessoa não pisasse nessa comissão como seu humilde servo. Bem, é claro, esperamos que os fornecedores de forks / clones domésticos do Linux consertem esse erro em seus pacotes.

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


All Articles