Um tema que tem atraído muito interesse recentemente no contexto da certificação digital é o armazenamento de certificados em HSM. Muito mais rápidos que tokens e smartcards, os HSMs permitem trabalhar com algoritmos mais fortes e processar lotes grandes de assinaturas em segundos.
Os servidores HSM (sigla para o inglês Hardware Security Module) são dispositivos físicos que fornecem segurança extra para chaves criptográficas, como um certificado digital. O HSM armazena as chaves e também executa as operações criptográficas, e as aplicações apenas fazem as solicitações, sem nunca manipular as chaves.
Entretanto, já surgiram questionamentos quanto à segurança técnica e jurídica de armazenar certificados em HSM. Neste artigo, reunimos algumas informações e legislações importantes sobre o assunto para discutir as responsabilidades das Autoridades Certificadoras e do Titular sobre a geração de chaves em HSM. Confira!
A ICP-Brasil permite que sejam utilizados certificados em HSM e outros dispositivos criptográficos, como cartões ou tokens. Eles podem guardar as chaves de titulares de certificados A3, A4, S3 e S4. O importante é que esses dispositivos sejam homologados pela ICP-Brasil, de acordo com os Padrões e Algoritmos Criptográficos da entidade.
O processo de homologação na ICP-Brasil está definido no documento Regulamento para Homologação de Sistemas e Equipamentos de Certificação Digital no mbito da ICP-Brasil.
Esses documentos buscam garantir que todos os equipamentos usados para a certificação digital possuam os padrões e especificações técnicas necessárias para estar de acordo com as normas da ICP-Brasil e garantir a segurança de todos os usuários.
Menke e Bertol realizaram uma análise muito completa e bem fundamentada de diversos aspectos jurídicos e normativos envolvidos, mas ainda há pontos em aberto a serem explorados. Um dos questionamentos diz respeito à validação dos requisitos de geração de chave privada em hardware para certificados em HSM do tipo A3. Tipicamente, esta questão aparece sob duas formas:
Antes de responder sobre como garantir tal propriedade, cabe responder outra questão: de quem, afinal, é a responsabilidade por garantir que o par de chaves foi gerado em hardware criptográfico? O interesse do titular do certificado em ter essa garantia parece ser evidente, já que ele é o usuário que responde pelos atos praticados através da utilização da chave privada que passa a ser vinculada à sua pessoa. Em seguida, veremos o que diz a legislação.
A MP 2.200-2, que institui a ICP-Brasil, é clara no seu Artigo 6º., parágrafo único: a responsabilidade pela geração das chaves, e seu exclusivo controle, uso e conhecimento, é do titular. Ou seja: o dono do certificado digital deve ter o controle sobre a segurança do dispositivo onde o certificado está armazenado.
No restante da Medida Provisória não há qualquer transferência de responsabilidade sobre as chaves do titular para as Autoridades Certificadoras e Autoridades de Registro. Portanto, do ponto de vista legal, é clara a responsabilidade do titular sobre a geração da chave privada. Continuamos, entretanto, a análise do restante do conjunto normativo sobre este aspecto.
Um dos requisitos mínimos das Declarações de Práticas de Certificação, documento que detalha o processo de emissão de certificados das Autoridades Certificadoras, é delegar ao titular do certificado a responsabilidade da garantia do sigilo de suas chaves privadas.
No Manual de Condutas Técnicas para homologação de sistemas de ACs, encontramos a primeira informação que pode soar conflitante com o até aqui verificado (grifo do autor):
“RECOMENDAÇÃO I.04: Um Software de AC pode entregar um componente para o titular do certificado digital com a finalidade de gerar um par de chaves criptográficas assimétricas. Este componente deve ser capaz de verificar a mídia de geração e armazenamento do par de chaves baseando-se no tipo de certificado digital ICP-Brasil (A1, A2, A3, A4, S1, S2, S3, S4, T3 ou T4) conforme definido no item 6.1 do DOC-ICP-04 [5].”
O texto informa que o componente de geração de chaves criptográficas assimétricas, que pode ser entregue pela AC para o titular gerar suas chaves, deve ser capaz de verificar a mídia de geração conforme o tipo de certificado. Ou seja, o componente deve garantir que cada certificado seja gerado na mídia específica conforme seu tipo.
Note-se, entretanto, que trata-se de uma recomendação, não um requisito. A AC pode não oferecer tal componente, ou o titular optar por não utilizá-lo. Como vimos, o item 6.1 do DOC-ICP-04, citado acima, não atribui qualquer responsabilidade à AC ou AR de verificar o tipo de mídia de geração de certificado. Ele atribui exclusivamente ao titular a responsabilidade pela geração de chaves.
Caso o titular contrate um serviço de hospedagem em HSM independente da AC, e gere suas chaves neste sistema, o titular do certificado não está utilizando componente fornecido pela AC para geração de chaves criptográficas. Portanto, não se aplica o disposto pela recomendação do MCT.
Concluímos, da análise acima, que não é responsabilidade da Autoridade Certificadora ou Autoridade de Registro verificar a mídia onde a chave foi gerada, exceto quando a Autoridade Certificadora oferece ao seu cliente o componente de software para a geração das chaves criptográficas.
Agora que já aprofundamos as questões legais, vamos analisar a viabilidade técnica de garantir a segurança do certificado digital em HSM. É necessário garantir que uma determinada chave criptográfica foi de fato gerada em hardware criptográfico.
Os principais padrões para acesso a dispositivos criptográficos permitem identificar se o dispositivo em uso é uma implementação em hardware ou software. Também é possível identificar se uma chave foi gerada no próprio dispositivo.
Portanto, alguém com acesso ao dispositivo pode a qualquer momento utilizar este tipo de informação para verificar como se deu a geração da chave. Além disso, com base em informações de identificação do dispositivo obtidas pela API, poderia se verificar se o equipamento está entre a lista de homologados da ICP-Brasil.
Entretanto, é possível produzir drivers “intermediários” que filtram as chamadas para dispositivos criptográficos, ou ainda drivers falsos que se apresentam como uma implementação em hardware mas são, na realidade, implementados em software.
Desta forma, as respostas para as chamadas que permitiriam identificar o tipo de mídia utilizada e a forma de geração de chave podem ser forjados por alguém interessado em fazê-lo. A verificação passa, portanto, em validar a confiabilidade do driver em questão. Esta não é uma tarefa tão trivial e também poderia ser manipulada, restando a necessidade de confiar na máquina utilizada para acionar o dispositivo criptográfico.
Um usuário mal intencionado ou um atacante com controle do equipamento do usuário poderia, com certa facilidade, burlar as verificações técnicas que sejam implementadas. Neste caso, restariam poucas ações que a AC poderia tomar para se resguardar se tiver alguma responsabilidade sobre a mídia utilizada na geração de chave.
Existem Autoridades Certificadoras que exigem que o titular utilize o mecanismo de geração de chave em computador nas instalações da Autoridade de Registro. Desta forma, podem manter controle não apenas sobre o componente de software que aciona o driver do dispositivo criptográfico, mas também sobre o próprio driver do dispositivo e sistema utilizado. Embora mais efetivo, isto parece violar a liberdade (e responsabilidade) do titular de controlar a geração da sua chave privada da forma que desejar.
Para certificados em HSM, os mesmos princípios se aplicam: tanto do ponto de vista do titular, quanto do ponto de vista de uma eventual necessidade de verificação por parte da Autoridade Certificadora, há necessidade de confiar no sistema em utilização para acionar a geração de chaves. Cabe lembrar, entretanto, que para usuários leigos a tarefa de analisar a segurança de um sistema e garantir que seu computador não está comprometido não é trivial.
Ao utilizar seu próprio computador, o usuário não tem com quem compartilhar esta responsabilidade, assumindo todo ônus e risco. Já ao contratar um prestador do serviço de hospedagem de certificados em HSM o usuário poderia (e deveria) se resguardar exigindo, por exemplo, atestado assinado do prestador de serviço, declarando que a chave foi de fato gerada em hardware criptográfico e de forma não exportável, o que o prestador de serviço deve ter capacidade técnica para fornecer.
O conjunto normativo da ICP-Brasil é explícito sobre a responsabilidade do titular do certificado sobre a geração e controle exclusivo da sua chave privada. Delega à AC esta responsabilidade se, e somente se, ela oferecer componente de software para acesso ao dispositivo para geração de chaves criptográficas.
Mediante a dificuldade técnica de implantar tal verificação, e de que as formas mais efetivas de fazê-lo ferem o direito do titular sobre o controle exclusivo de suas chaves, consideramos saudável que assim seja. Assim, não atribuímos às ACs responsabilidades difíceis de cumprir.
Em especial entendemos que a AC, caso emita certificados em HSM, apenas torna-se obrigada a validar o tipo de mídia utilizada caso ela mesmo ofereça o mecanismo de geração de certificado em HSM por meio dos seus sistemas. Entendemos, entretanto, que este não é o caso quando o titular contrata de maneira independente um serviço de hospedagem da sua chave e a AC para emitir seu certificado.
O tema do armazenamento de certificados em HSM, por sua característica inovadora, tem diversos desafios a serem explorados que devem ser encarados com seriedade e profundidade, buscando evitar conclusões precipitadas ou soluções simplistas.
É importante pensar “fora da caixa”, na busca de soluções que propiciem a praticidade e usabilidade para o usuário de ter seu certificado “na nuvem” sem abrir mão da segurança – e talvez até mesmo, oferecer a este usuário níveis de segurança e controle não existentes nos mecanismos atuais que utilizam tokens e smartcards.
O Bry KMS é uma solução que torna o certificado digital acessível a partir dos mais variados tipos de dispositivos, incluindo celulares e tablets. Compatível com diversos sistemas e aplicações, dispensa o gerenciamento da implantação dos certificados e oferece total independência de plataforma aos usuários.
*Post originalmente publicado em 21/02/2017 e atualizado em 13/11/2018
