Por Eder Souza
Eder Alvares P. Souza – Co-fundador da eSafer e Colunista do Crypto ID
No artigo “Certificados Digitais Codesign – Será que não estamos fornecendo munição aos inimigos?” eu falei um pouco sobre o uso e os riscos que envolvem a utilização de certificados digitais Codesign.
A principal questão é que a cada dia que passa, as empresas desenvolvedoras de software e sistemas operacionais depositam mais responsabilidade nesse tipo de certificado e hoje, para se instalar um driver ou outro software que necessite de privilégios mais restritos é necessário assinar esse driver ou software com um certificado digital do tipo Codesign.
Com a assinatura digital aplicada através da utilização de um certificado Codesign que foi emitido por uma Autoridade Certificadora reconhecida pelo Sistema Operacional, esse driver poderá ter acesso às chamadas no Sistema Operacional que são restritas somente aos softwares confiáveis.
Assim, os desenvolvedores de rootkits e malwares que obtém acesso a esses certificados conseguem criar armas poderosas, pois terão acesso ao centro do Sistema Operacional e além de ter o controle do ambiente do usuário, poderá esconder seus processos maliciosos de ferramentas de detecção comumente utilizadas.
Esses certificados Codesign há algum tempo são vistos como itens de muito valor para esses criminosos, que chegam a pagar alguns milhares de dólares por um que foi emitido para alguma empresa desenvolvedora de drivers e softwares e que precise assiná-los.
Vendo isso tudo, o CA/Browser Fórum iniciou os trabalhos para a elaboração de um guia nomeado “Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates” que atualmente está sendo refinado pelo CA Security Council e tem como objetivo apresentar os requerimentos mínimos e outros detalhes para a emissão e armazenamento desses certificados.
Analisando a versão atual do documento, que é a Versão 1.0 (November 19, 2015), é possível notar o cuidado em deixar claro os papeis e responsabilidades das entidades que fazem parte dos processos que envolvem a emissão e uso do certificado, além de detalhar diversas questões como na sessão 9, “Certificate Content and Profile”, que apresenta alguns atributos que até então não eram considerados pelas ACs anteriormente.
Já na sessão 10 “Certificate Request”, o documento detalha algumas técnicas necessárias para a geração e transporte de chaves criptográficas, como a utilização do algoritmos AES com chaves de 128 bits ou o uso do PKCS#12 para envio das chaves privadas, quando a mesma não é gerada pelo solicitante.
Na sessão 11 “Verification Practices” do documento é detalhado o procedimento e as informações que deverão ser verificadas pela entidade que irá aprovar a emissão do certificado antes de sua efetiva liberação.
Na sessão 13 “Certificate Revocation and Status Checking” fica claro dos motivadores da revogação de um cerificado digital Codesign, o processo para comunicação e a disponibilidade da AC em receber essas informações 24 horas por dia durante os 7 dias por semana, além de deixar claro que o OCSP é o protocolo definido para as verificações de estado do certificado.
A sessão 15 “Data Records” apresenta as informações que precisam ser gravadas em registro de log refere a operação da Autoridade de Tempo vinculada ao processo de emissão do certificado digital.
Na sessão 16 “Data Security and Private Key Protection”, fica claro que as Autoridades Certificadoras deverão disponibilizar Autoridades de Carimbo de Tempo em conformidade com a RFC-3161 para seus clientes, além de orientá-los sobre a sua utilização no processo de assinatura digital de códigos.
Ainda na sessão 16.3 “Subscriber Private Key Protection” a Autoridade Certificadora deverá obter evidências de que o solicitante do certificado codesing está armazenando sua chave privada em um HSM padrão FIPS 140 Level 2, em um Trusted Platform Module (TPM) ou em um módulo de armazenamento que deverá ser mantido separado do ambiente utilizado para as assinaturas digitais até o momento de sua utilização.
Finalizando as sessões de maior relevância, a sessão 17 “Audit” cita a necessidade das Autoridades Certificadoras de estar em conformidade com o “WebTrust for Certification Authorities v2.0” e com a “ETSI TS 102 042”.
Para efetuar o download do documento completo é necessário acessar a URL https://casecurity.org/wp-content/uploads/2016/07/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf
Esta iniciativa iniciada pelo CA/Browser Fórum e agora conduzida pelo CA Security Council deixa claro a importância dos certificados Codesign e os riscos envolvidos na sua utilização e assim serão exigidas garantias referente ao armazenamento seguro das chaves privadas, a segurança no seu transporte e caso esses pontos não sejam atendidos a Autoridade Certificadora poderá revogar sem comunicação prévia ao titular.
Só o tempo mostrará a eficiência destas ações e neste momento o documento ainda está passando por alterações e discussões com os membros do conselho.
Bom é isso, e até a próxima!
- Mestre em Engenharia de Software pelo IPT-SP, com MBA em Gestão Empresarial pela FGV e especialização em Segurança da Informação pelo IBTA e bacharel em Ciências da Computação pela FAC-FITO.
- Professor do curso de Segurança da Informação do Instituto Brasileiro de Tecnologia Avançada e responsável pelo tema Criptografia e Certificação Digital.
- Atua há quinze anos na área de Tecnologia e Segurança da Informação e atualmente é Diretor Técnico na e-Safer Consultoria.
- Vivência no desenvolvimento de produtos e implantação de soluções de Segurança e Certificação Digital em empresas de grande porte.
- Eder é colunista e membro do conselho editorial do CryptoID.
Leia outros artigos do Colunista Eder Souza. Aqui!
Fale com o Eder Souza por meio dos comentários do site ou se preferir escreva diretamente para ele.
Tel.: +55 11 3576-4539
e-mail: esouza@e-safer.com.br / skype: eder_souza
