gerenciamento de certificados e autoridades de certificação no dcmtls
Certificado do sistema e chave privada
O protocolo TLS exige que um servidor (ou seja, um aplicativo que aceita conexões de rede TLS de entrada) deve se identificar criptograficamente por meio de um certificado e uma chave privada, enquanto um cliente (um aplicativo que inicia conexões de rede TLS de saída) pode se identificar por meio de um certificado e uma chave privada, ou permanecer anônimo.
Todas as ferramentas do DCMTK que oferecem suporte a conexões de rede criptografadas por TLS disponibilizam opções de linha de comando para selecionar comunicação de rede não criptografada, TLS com certificados ou (no caso de aplicativos cliente) TLS em modo anônimo:
-tls --disable-tls- usa uma conexão TCP/IP normal (padrão)
+tls --enable-tls [p]rivate key file, [c]ertificate file: string- usa uma conexão TLS segura autenticada
+tla --anonymous-tls- usa conexão TLS segura sem certificado
Há suporte a dois formatos de arquivo diferentes para certificados, chaves privadas e outros materiais criptográficos: o formato PEM baseado em texto ("Privacy Enhanced Mail"), que é o padrão, e arquivos binários ASN.1 em codificação DER ("Distinguished Encoding Rules"). O formato de arquivo pode ser selecionado por meio das seguintes opções:
-pem --pem-keys- lê chaves e certificados como arquivo PEM (padrão)
-der --der-keys- lê chaves e certificados como arquivo DER
Observe que o formato PEM oferece suporte a múltiplos certificados em um único arquivo, o que é um recurso importante quando certificados emitidos por uma CA intermediária são usados com TLS. O formato DER oferece suporte a apenas um certificado por arquivo.
Em muitos casos, a chave privada é armazenada de forma criptografada, e é necessária uma senha para descriptografar o arquivo de chave privada. Nesse caso, são disponibilizadas as seguintes opções:
+ps --std-passwd- solicita que o usuário digite a senha na entrada padrão (padrão)
+pw --use-passwd [p]assword: string- usa a senha especificada na linha de comando
-pw --null-passwd- usa uma string vazia como senha
Perfis de segurança
O padrão DICOM define uma série de perfis de segurança para o uso do protocolo de rede DICOM sobre TLS. O DCMTK oferece suporte aos seguintes perfis:
+pg --profile-8996- Perfil TLS BCP 195 RFC 8996 (padrão)
+pm --profile-8996-mod- Perfil TLS BCP 195 RFC 8996 modificado # only available if underlying TLS library supports # all TLS features required for this profile
+py --profile-bcp195-nd- Perfil TLS BCP 195 sem downgrade (obsoleto)
+px --profile-bcp195- Perfil TLS BCP 195 (obsoleto)
+pz --profile-bcp195-ex- Perfil TLS BCP 195 estendido (obsoleto)
+pb --profile-basic- perfil básico de conexão de transporte seguro TLS (obsoleto) # disponível apenas se a biblioteca TLS subjacente oferecer suporte a 3DES
+pa --profile-aes- AES TLS Secure Transport Connection Profile (obsoleto)
+pn --profile-null- Comunicação autenticada não criptografada (retirada, era usada no IHE ATNA)
O BCP 195 RFC 8996 TLS Profile, selecionado por padrão, é uma escolha segura e, ao mesmo tempo, oferece retrocompatibilidade com os perfis BCP 195 anteriores. Ele não oferece retrocompatibilidade com os perfis mais antigos. Usa a versão TLS 1.2 ou 1.3 e usará TLS 1.3 por padrão sempre que possível.
O Non-downgrading BCP 195 TLS Profile, que era o padrão no DCMTK 3.6.7, também desativa versões de protocolo e conjuntos de cifras mais antigos. Ele oferece suporte, no entanto, a conjuntos de cifras DHE, embora a RFC 9325 recomende que eles não sejam usados. Usa a versão TLS 1.2 ou 1.3 e usará TLS 1.3 por padrão sempre que possível.
O BCP 195 TLS Profile, que era o padrão até o DCMTK 3.6.6, tenta negociar algoritmos criptográficos atualmente considerados seguros, mas oferece retrocompatibilidade com aplicativos mais antigos que implementam o perfil obsoleto AES ou Basic TLS. Esse perfil não está mais em conformidade com o BCP 195 conforme alterado pela RFC 8996 (2021).
O Extended BCP 195 TLS Profile é semelhante ao Non-downgrading BCP 195 TLS Profile, mas usa uma seleção mais restrita de conjuntos de cifras e está limitado à versão TLS 1.2.
O AES TLS Secure Transport Connection Profile usa criptografia AES e a versão TLS 1.0 ou posterior, e foi retirado do padrão DICOM. Deve ser usado somente quando for necessária retrocompatibilidade com dispositivos que implementam esse perfil.
O Basic TLS Secure Transport Connection Profile usa criptografia Triple DES e a versão TLS 1.0 ou posterior, e também foi retirado do padrão DICOM. Deve ser usado somente quando for necessária retrocompatibilidade com dispositivos que implementam esse perfil, principalmente porque o comprimento efetivo de chave de 112 bits não é mais suficientemente seguro contra ataques de força bruta.
Por fim, a comunicação não criptografada autenticada é um perfil obsoleto definido em versões mais antigas do perfil IHE Audit Trail and Node Authentication. Ela usa uma comunicação não criptografada com somas de verificação criptográficas. Esse perfil deve ser evitado.
Deve-se observar que o suporte ao perfil Basic TLS só estará disponível quando a biblioteca OpenSSL tiver sido compilada de modo a habilitar o suporte a Triple DES, o que não é mais o padrão.
A lista de conjuntos de cifras TLS oferecidos durante o handshake TLS pode ser estendida usando a seguinte opção:
+cs --cipher [c]iphersuite name: string
add ciphersuite to list of negotiated suites
A lista de conjuntos de cifras TLS 1.0-1.2 com suporte pode ser exibida usando a seguinte opção:
+cc --list-ciphers
list supported TLS ciphersuites and exit
A opção --cipher pode ser especificada mais de uma vez para adicionar múltiplos conjuntos de cifras.
Autenticação do par
Por padrão, a implementação TLS do dcmtls exige que tanto o cliente quanto o servidor forneçam um certificado como prova de identidade, e verifica a validade e a confiabilidade do certificado. Esse processo tem várias etapas:
- O handshake TLS exigirá uma prova de que o aplicativo tem acesso à chave privada correspondente à chave pública codificada no certificado.
- A assinatura digital do certificado será verificada.
- O período de validade do certificado será verificado.
- Será verificado se o certificado foi emitido por uma autoridade de certificação (CA) confiável (consulte Autoridade de certificação).
- Dependendo das opções de linha de comando, as listas de revogação de certificados (CRLs) de todas as CAs até a CA raiz podem ser verificadas para checar se algum certificado na cadeia de certificação foi revogado (consulte Listas de revogação de certificados).
Esse comportamento pode ser modificado com as seguintes opções de linha de comando:
-rc --require-peer-cert- verifica o certificado do par, falha se ausente (padrão)
-vc --verify-peer-cert- verifica o certificado do par se presente
-ic --ignore-peer-cert- não verifica o certificado do par
A primeira opção fará a conexão falhar se o par não apresentar um certificado (ou seja, estiver funcionando em modo anônimo) ou se o certificado não puder ser totalmente verificado. A segunda opção realizará uma verificação do certificado se houver um presente, mas também aceitará conexões anônimas. A terceira opção não realiza nenhuma verificação de certificado e também aceita conexões anônimas.
Deve-se observar que os dois últimos modos são suscetíveis a ataques man-in-the-middle e, portanto, devem ser evitados.
A opção --verify-peer-cert não está disponível em aplicativos cliente, pois os servidores TLS sempre apresentarão um certificado.
Autoridade de certificação
Todas as ferramentas do DCMTK que oferecem suporte a conexões de rede criptografadas por TLS precisam ter uma lista de certificados raiz confiáveis (ou seja, certificados autoassinados) usados na verificação do certificado do par ao estabelecer a conexão TLS.
Existem duas formas de gerenciar essa lista de certificados confiáveis: por arquivo e por diretório. As ferramentas de linha de comando do DCMTK oferecem as seguintes opções de linha de comando para essa finalidade:
+cf --add-cert-file [f]ilename: string- adiciona um arquivo de certificado à lista de certificados
+cd --add-cert-dir [d]irectory: string- adiciona os certificados de d à lista de certificados
Ambas as opções podem ser especificadas mais de uma vez, inclusive combinadas.
Gerenciamento por arquivo de certificados raiz confiáveis
A opção baseada em arquivo carrega um arquivo e adiciona todos os certificados ou CRLs presentes nesse arquivo ao pool de certificados confiáveis. O formato do arquivo é texto ASCII contendo certificados PEM e CRLs concatenados, a menos que o formato ASN.1 DER tenha sido selecionado.
Gerenciamento por diretório de certificados raiz confiáveis
A opção baseada em diretório especifica um diretório que contém certificados e CRLs. Esses certificados e CRLs são carregados sob demanda e armazenados em cache na memória depois de carregados.
O diretório deve conter um certificado ou CRL por arquivo em formato PEM, com um nome de arquivo no formato hash.N para um certificado, ou hash.rN para uma CRL. O hash é calculado a partir do nome do titular (para certificados) ou do nome do emissor (para CRLs). O valor do hash pode ser obtido chamando a ferramenta de linha de comando openssl:
openssl x509 -hash -noout -in <infile.pem>
onde
O sufixo .N ou .rN é um número de sequência que começa em zero e é incrementado consecutivamente para cada certificado ou CRL com o mesmo valor de hash. Não há suporte a lacunas nos números de sequência; presume-se que não existam mais objetos com o mesmo hash além do primeiro número ausente na sequência.
Os números de sequência tornam possível que o diretório contenha múltiplos certificados com o mesmo valor de hash de nome do titular. Por exemplo, é possível ter no repositório vários certificados com o mesmo titular ou várias CRLs com o mesmo emissor (e, por exemplo, período de validade diferente).
CAs intermediárias
Em muitos casos, os certificados do sistema não são assinados diretamente por uma CA raiz (ou seja, uma CA que usa um certificado autoassinado), mas por uma CA intermediária. O certificado da CA intermediária será assinado pela CA raiz (ou por outro nível de CA intermediária).
No handshake TLS, um aplicativo pode fornecer mais de um certificado: pode fornecer seu próprio certificado, seguido pelos certificados de quaisquer CAs intermediárias até, opcionalmente, incluir o certificado da CA raiz.
As ferramentas do DCMTK fornecerão esses certificados intermediários durante o handshake TLS se estiverem presentes no mesmo arquivo que o certificado do sistema, fornecido como o segundo parâmetro da opção --enable-tls. Isso exige o uso do formato PEM, já que o DER não oferece suporte a múltiplos certificados em um único arquivo.
O formato PEM permite que os certificados sejam simplesmente concatenados em um arquivo de texto, começando pelo certificado do sistema, seguido pelos certificados das CAs intermediárias e, opcionalmente, pelo certificado da CA raiz. Em sistemas Linux/Posix, esse arquivo pode ser criado da seguinte forma:
cat system_cert.pem intermediate_ca.pem root_ca.pem > fullchain.pem
Usuários que utilizam certificados LetsEncrypt notarão que o LetsEncrypt fornece automaticamente um arquivo "fullchain.pem" contendo uma cadeia de certificação desse tipo.
Os certificados definidos como confiáveis usando --add-cert-file ou --add-cert-dir só podem ser certificados de CA raiz. Não é possível adicionar certificados de CA intermediária ao "repositório de confiança".
Listas de revogação de certificados
A última etapa, opcional, da verificação de certificados é a consulta às listas de revogação de certificados (CRLs) para verificar se algum certificado na cadeia de certificação foi revogado. As CRLs não podem ser transmitidas no handshake TLS; elas precisam ser pré-configuradas, e deve-se observar que as CRLs também têm um período de validade limitado, definido no arquivo.
As seguintes opções de CRL estão disponíveis a partir do DCMTK 3.6.7:
+crl --add-crl-file [f]ilename: string- adiciona um arquivo de lista de revogação de certificados (implica --enable-crl-vfy)
+crv --enable-crl-vfy- ativa a verificação de CRL do certificado folha
+cra --enable-crl-all- habilita a verificação de CRL de toda a cadeia
A opção --add-crl-file carregará um arquivo de CRL que pode ser usado para consulta de CRL. Essa opção pode ser especificada mais de uma vez. Alternativamente, os arquivos de CRL podem ser localizados no diretório de CA especificado com --add-cert-dir. Consulte Gerenciamento por diretório de certificados raiz confiáveis para uma discussão sobre como os arquivos de CRL devem ser nomeados nesse caso.
A opção --enable-crl-vfy habilitará a consulta da CRL da CA folha, ou seja, apenas uma única CRL será verificada para determinar se o certificado do sistema do par está revogado. A opção --enable-crl-all habilitará a consulta de todas as CRLs até a CA raiz, o que também cobrirá o caso em que um certificado de CA intermediária tenha sido revogado.
Uma vez habilitada a verificação de CRL, a verificação de certificado falhará se uma das CRLs exigidas estiver ausente.