Neste documento, o Comitê de Gerenciamento do OpenSSL descreve os princípios básicos da arquitetura estratégica do OpenSSL. A partir do 3.0.0, várias versões serão necessárias para passar da arquitetura atual (versão 1.1.1) para o futuro.Inúmeras mudanças são esperadas na arquitetura. Oferecemos um possível caminho de migração. O lançamento do OpenSSL 3.0.0 afeta minimamente a grande maioria dos aplicativos existentes; quase todos os aplicativos alfabetizados precisam apenas ser recompilados.
A funcionalidade atual fornecida pela interface do mecanismo será substituída pela interface do software ao longo do tempo. O OpenSSL 3.0.0 manterá o suporte do mecanismo. A arquitetura futura pode ser totalmente implementada não antes do OpenSSL 4.0.0.
Arquitetura atual
O OpenSSL atualmente possui quatro componentes principais:
- libcrypto. A biblioteca principal para fornecer implementações de várias primitivas criptográficas. Além disso, fornece um conjunto de serviços de suporte para libssl e libcrypto, além de implementações de protocolo como CMS e OCSP.
- O motor A funcionalidade do libcrypto pode ser estendida através da API do mecanismo.
Normalmente, os mecanismos são módulos carregados dinamicamente registrados na libcrypto e usando ganchos disponíveis para implementar algoritmos criptográficos, na maioria das vezes implementações alternativas de algoritmos já fornecidos pela libcrypto (por exemplo, com suporte à aceleração de hardware), mas também podem incluir algoritmos não implementados no OpenSSL por por padrão (por exemplo, o mecanismo GOST implementa a família russa de algoritmos GOST). Alguns mecanismos vêm com a distribuição OpenSSL, enquanto outros vêm com terceiros (novamente, GOST).
- libssl. Uma biblioteca que depende da libcrypto e implementa os protocolos TLS e DTLS.
- Aplicações Um conjunto de ferramentas de linha de comando que usam os componentes básicos da libssl e libcrypto para fornecer um conjunto de funções criptográficas e outras, como:
- Geração e verificação de chaves e parâmetros
- Geração e verificação de certificado
- Ferramentas de teste SSL / TLS
- Verificação ASN.1
- e outros
O OpenSSL atualmente possui os seguintes recursos:
- EVP A API da camada EVP (envelope) fornece uma interface abstrata de alto nível para a funcionalidade criptográfica, sem estar vinculada a uma implementação específica. O uso direto de implementações específicas de algoritmos criptográficos ignorando as interfaces EVP não é recomendado. Ele também fornece operações compostas, como assinatura e verificação. Algumas operações compostas também são fornecidas como uma operação no nível EVP (por exemplo, HMAC-SHA256). O EVP também permite o uso de algoritmos criptográficos de maneira algorítmica-agnóstica (por exemplo, EVP_DigestSign funciona para os algoritmos RSA e ECDSA).
- O FIPS140 não é suportado, está disponível apenas no OpenSSL-1.0.2, que é anterior à arquitetura atual e não é compatível com API ou ABI.
Conceito de componente
A arquitetura existente é uma estrutura simples de quatro níveis com uma camada de criptografia na parte inferior. A camada TLS depende da camada criptográfica e os aplicativos dependem da camada TLS e da camada criptográfica.
Nota: a presença de um componente no diagrama não significa que o componente é uma API pública ou se destina ao acesso / uso direto pelo usuário final.
Diagrama de Pacotes
Os componentes descritos acima são empacotados em bibliotecas (libcrypto e libssl) e nas interfaces correspondentes do kernel, bem como na linha de comando executável (openssl) para iniciar vários aplicativos. Isso é mostrado no diagrama abaixo.
Arquitetura futura
Recursos da arquitetura futura:
- Os serviços do kernel formam os blocos de construção usados por aplicativos e provedores (por exemplo, BIO, X509, SECMEM, ASN1, etc.).
- Os fornecedores usam algoritmos criptográficos e serviços de suporte. Um provedor implementa uma ou mais das seguintes funções:
- Primitivas criptográficas para o algoritmo: criptografia, descriptografia, assinatura, hash, etc.
- Serialização para o algoritmo, por exemplo, a função de converter a chave privada em um arquivo PEM. A serialização pode estar em formatos ou formatos não suportados no momento.
- Armazene o back-end do carregador. Atualmente, o OpenSSL é fornecido com um gerenciador de inicialização para ler chaves, parâmetros e outros elementos dos arquivos. Os fornecedores podem implementar downloaders para ler dados de outros lugares (por exemplo, de um diretório LDAP).
O provedor pode ser totalmente autônomo ou usar serviços fornecidos por diferentes provedores ou serviços de kernel. Por exemplo, um aplicativo pode usar primitivas criptográficas para um algoritmo implementado por um fornecedor de acelerador de hardware, mas usa os serviços de serialização de outro fornecedor para exportar chaves para o formato PKCS # 12.
O provedor padrão (que contém o núcleo das implementações atuais do algoritmo criptográfico OpenSSL) será "incorporado", mas outros provedores poderão carregar dinamicamente no tempo de execução.
O (s) módulo (s) de provedores herdados fornecerá implementações criptográficas para algoritmos mais antigos (por exemplo, DES, MDC2, MD2, Blowfish, CAST). Publicaremos regras sobre como e quando os algoritmos passam de um provedor padrão para um provedor desatualizado.
O provedor FIPS que implementa o módulo criptográfico OpenSSL FIPS pode carregar dinamicamente no tempo de execução.
- O kernel fornece acesso aos serviços oferecidos pelos provedores de aplicativos (e outros). Os fornecedores dão ao kernel acesso aos métodos. Um kernel é um mecanismo pelo qual implementações específicas de coisas como algoritmos são descobertas.
O kernel implementa uma função de pesquisa baseada em propriedades para encontrar algoritmos. Por exemplo, isso encontrará um algoritmo em que "fips = true" ou "tamanho da chave = 128, tempo_ constante = verdadeiro". Os detalhes serão publicados nos documentos subseqüentes do projeto.
- Implementações de protocolo como TLS, DTLS.
A arquitetura futura possui as seguintes características:
- A camada EVP se torna um invólucro fino para serviços implementados por meio de fornecedores. A maioria das chamadas é realizada com pré-processamento, pós-processamento ou nenhum processamento.
- Novas APIs de EVP aparecerão para pesquisar no kernel a implementação do algoritmo que será usado para qualquer chamada de EVP.
- As informações serão transferidas entre a biblioteca principal e os fornecedores da mesma maneira, independentemente de sua implementação.
- APIs obsoletas (como APIs criptográficas de baixo nível que não passam pela camada EVP) serão excluídas. Observe que existem APIs desatualizadas para algoritmos que não estão desatualizados (por exemplo, o AES não é um algoritmo desatualizado, mas AES_encrypt é uma API desatualizada).
- O módulo criptográfico OpenSSL FIPS será implementado como um provedor carregado dinamicamente. Ele será autônomo (ou seja, pode depender apenas das bibliotecas e serviços de tempo de execução do sistema fornecidos pelo kernel).
- Outras interfaces também podem ser convertidas para o uso do kernel ao longo do tempo (por exemplo, OSSL_STORE).
- O uso do mecanismo vai para os fornecedores. "Adeus, engenheiros, olá, fornecedores . "
Conceito de componente
O diagrama abaixo fornece uma visão geral dos componentes da futura arquitetura OpenSSL.
Nota: a presença de um componente no diagrama não significa que o componente é uma API pública ou se destina ao acesso / uso direto pelo usuário final.
Os seguintes componentes são mostrados aqui:
- Aplicações: utilitários de linha de comando: ca, cifras, cms, dgst etc.
- Protocolos: o componente fornece a capacidade de se comunicar entre os pontos de extremidade usando protocolos padrão:
- Protocolos TLS: implementação de todos os protocolos TLS / DTLS suportados e infraestrutura de atendimento:
- BIO SSL: BIO para comunicação TLS
- Statem: máquina de estado TLS
- Registro: camada de registro TLS
- Outros protocolos
- CMS: implementando o padrão de sintaxe de mensagem criptográfica
- OCSP: Implementação do Protocolo de Status do Certificado Online
- TS: Implementação do Protocolo de Registro de Data e Hora
- Serviços de suporte: Componentes projetados especificamente para suportar a implementação de código de protocolo
- Pacote: componente interno para leitura de mensagens de protocolo
- Wpacket: um componente interno para gravar mensagens de protocolo
- Kernel: este é o componente fundamental que conecta solicitações de serviço (por exemplo, criptografia) ao provedor de serviços. Permite que os fornecedores registrem seus serviços junto com suas propriedades. O kernel também fornece a capacidade de encontrar um serviço com um determinado conjunto de propriedades que o serviço deve executar. Por exemplo, as propriedades do serviço de criptografia podem incluir "aead", "aes-gcm", "fips", "security-bits = 128" e assim por diante.
- Provedor padrão: implementa um conjunto de serviços padrão registrados no kernel.
- Serviços de Suporte
- Implementações de baixo nível: este é um conjunto de componentes que realmente implementam primitivas criptográficas.
- Fornecedor de FIPS: implementa um conjunto de serviços que são verificados e disponíveis para o núcleo do FIPS. Inclui os seguintes serviços de suporte:
- POST: Power On Self Test
- KAT: testes de resposta conhecida
- Verificação de integridade
- Implementações de baixo nível: este é um conjunto de componentes que realmente implementam primitivas criptográficas (para satisfazer o requisito FIPS independente).
- Provedor de algoritmos herdados: fornece implementações de algoritmos herdados que serão fornecidos por meio da API EVP.
- Fornecedor de terceiros: não faz parte da distribuição OpenSSL. Terceiros podem vender seus próprios fornecedores.
- Serviços gerais: formam os blocos de construção usados por aplicativos e fornecedores (por exemplo, BIO, X509, SECMEM, ASN1, etc.).
- APIs obsoletas. API "de baixo nível": aqui a palavra "obsoleto" refere-se especificamente à API e não ao próprio algoritmo. Por exemplo, o AES não é um algoritmo desatualizado, mas existem APIs desatualizadas para ele (por exemplo, AES_encrypt).
Diagrama de Pacotes
Os vários componentes descritos acima no diagrama conceitual dos componentes estão fisicamente empacotados em:
- Aplicativos executáveis para usuários
- Biblioteca (s) para aplicativos
- Módulos carregáveis dinamicamente para o kernel.
Os seguintes pacotes reais são mostrados aqui:
- O arquivo executável é OpenSSL. Aplicativo de linha de comando.
- Libssl. Contém tudo o que está diretamente relacionado ao TLS e DTLS. Seu conteúdo é o mesmo que no libssl atual. Observe que alguns serviços de suporte serão movidos para a libcrypto.
- Libcrypto Esta biblioteca contém os seguintes componentes:
- Implementações dos principais serviços: X509, ASN1, EVP, OSSL_STORE, etc.
- O núcleo
- Protocolos não TLS ou DTLS
- Serviços de suporte a protocolos (por exemplo, pacotes e pacotes)
- Provedor padrão contendo implementações de todos os algoritmos padrão
- Libcrypto-legado. Fornece APIs de baixo nível herdadas. A implementação dos algoritmos para essas APIs pode vir de qualquer provedor.
- Módulo FIPS. Contém um provedor FIPS que implementa um conjunto de serviços verificados pelo FIPS e registrados no kernel.
- Módulo herdado. Contém um provedor desatualizado.