Certificados em HSM na ICP-Brasil: Responsabilidade sobre a geração de chaves

Cristian Thiago Moecke 50 views0

Um tema que tem atraído muito interesse recentemente no contexto da certificação digital é o armazenamento de certificados digitais em HSMs: muito mais rápidos que tokens e smartcards, os HSMs permitem trabalhar com algoritmos mais fortes e processar lotes grandes de assinaturas em segundos. Um certificado em um HSM conectado em um sistema em rede pode ser utilizado da Intranet ou até mesmo da Internet a partir de qualquer dispositivo, incluindo smartphones e tablets, dispensando leitoras, portas USB e drivers, que estão cada vez menos disponíveis nos equipamentos. HSMs também contam com muito mais mecanismos de segurança física e lógica do que smartcards e tokens.

Entretanto também surgiram questionamentos quanto à segurança técnica e jurídica de armazenar certificados nestes equipamentos. Menke e Bertol [6] 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 do tipo A3. Tipicamente, esta questão aparece sob duas formas:

  1. como uma Autoridade Certificadora pode ter certeza que está emitindo o certificado para chave gerada em hardware criptográfico; e
  2. como o titular do certificado pode ter certeza de que sua chave foi gerada em hardware criptográfico, e não existe cópia fora de seu controle.

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 responde pelos atos praticados através da utilização da chave privada que passa a ser vinculada à sua pessoa. Mas cabe à Autoridade Certificadora qualquer responsabilidade neste sentido?

Neste artigo buscamos lançar luz e debate sobre o que a legislação e conjunto normativo existente dizem sobre este assunto, e também abordamos aspectos técnicos envolvidos.

 

Responsabilidade legal e normativa

A MP 2.200-2, que institui a ICP-Brasil, é clara no seu Artigo 6o., parágrafo único, de que a responsabilidade pela geração das chaves, e seu exclusivo controle, uso e conhecimento, é do titular (grifo do autor):

“O par de chaves criptográficas será gerado sempre pelo próprio titular e sua chave privada de assinatura será de seu exclusivo controle, uso e conhecimento.” [1]

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.

O DOC-ICP-5 [2], documento normativo que trata dos requisitos mínimos para as declarações de prática de certificação das Autoridades Certificadoras, reforça a responsabilidade do titular sobre a proteção da sua chave privada. No item 2.1.3, lê-se (grifo do autor):

“2.1.3. Obrigações do Titular do Certificado

Neste item devem ser incluídas as obrigações dos titulares de certificados emitidos pela AC responsável pela DPC, constantes dos termos de titularidade de que trata o item 4.1.1, devendo incluir no mínimo os itens abaixo relacionados:

(…)

b) garantir a proteção e o sigilo de suas chaves privadas, senhas e dispositivos criptográficos;

(…)”

Como se vê, um dos requisitos mínimos das Declarações de Práticas de Certificação é delegar ao titular do certificado a responsabilidade da garantia do sigilo de suas chaves privadas.

O DOC-ICP-4 [3], documento normativo que trata dos requisitos mínimos para as Políticas de Certificado da ICP-Brasil, informa que certificados A3 devem ser gerados em “Cartão Inteligente ou Token, ambos com capacidade de geração de chave e protegidos por senha e/ou identificação biométrica, ou hardware criptográfico homologado junto à ICP-Brasil”, e no item 6.1 novamente atribui ao titular, de forma exclusiva, a responsabilidade sobre a geração de chaves (grifo do autor):

“6.1.1.1. Quando o titular de certificado for uma pessoa física, esta será a responsável pela geração dos pares de chaves criptográficas. Quando o titular de certificado for uma pessoa jurídica, esta indicará por seu(s) representante(s) legal(is), a pessoa responsável pela geração dos pares de chaves criptográficas e pelo uso do certificado.”

Finalmente, no MCT11 [4], Manual de Condutas Técnicas para homologação de sistemas de AC, 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, este 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, ou seja, a AC pode não oferecer tal componente, ou o titular optar por não utilizá-lo. Que, como vimos, o item 6.1 do DOC-ICP-04, citado no texto, não atribui qualquer responsabilidade à AC ou AR de verificar o tipo de mídia de geração de certificado, muito pelo contrário, atribui exclusivamente ao titular a responsabilidade pela geração de chaves. Finalmente, 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 aplicando o disposto nesta 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. Neste caso, e apenas neste caso, a Autoridade Certificadora torna-se responsável por fornecer um componente que gere o certificado na mídia correta. Caso o usuário opte por não utilizar o componente de software fornecido pela AC, torna-se ele o único responsável por garantir que a mídia correta é utilizada. Conforme vimos na análise do DOC-ICP-04, HSMs são uma das mídias onde é permitido o armazenamento de certificados A3.

 

Viabilidade técnica

Independente das responsabilidades legais, há de se analisar a viabilidade técnica de se 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. No padrão PKCS#11 [5], por exemplo, é preciso identificar se o slot tem a flag CKF_HW_SLOT, indicando tratar-se de um dispositivo implementado em hardware. Também é possível identificar se uma chave foi gerada no próprio dispositivo, no caso do PKCS#11 basta identificar se a chave tem o atributo CKA_LOCAL. 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 também 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 também confiar na máquina utilizada para acionar o dispositivo criptográfico.

Do ponto de vista do titular, a questão da confiança no computador e sistema utilizado é mais simples: o titular sendo responsável pela geração segura das chaves, deve se resguardar utilizando um equipamento e sistema tão confiável quanto possível para acionar a geração de chaves, arcando com o ônus da sua escolha. Já do ponto de vista da Autoridade Certificadora é muito difícil assumir qualquer responsabilidade sobre a confiabilidade do equipamento, que é escolhido pelo usuário, e por consequência é igualmente difícil assumir responsabilidade de um acionamento de geração de chaves através deste equipamento. 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, e resta pouco que a AC poderia fazer 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.

Em HSMs, 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 chaves 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.

 

Conclusão

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, esta 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, não atribuindo às ACs responsabilidades difíceis de cumprir.

Em especial entendemos que a AC, caso emita certificados para uma chave gerada 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 através 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. Neste caso a responsabilidade recai exclusivamente sobre o titular, que não pode ter ferido o seu direito de utilizar a solução que lhe for mais conveniente, desde que respeitadas as exigências legais e normativas, nem se esquivar do seu dever de fazê-lo.

Para soluções que sejam contratadas para armazenar chaves em HSM, o titular pode se resguardar através de garantias contratuais com os prestadores de serviço (e é importante que o faça). Note-se que, para usuários leigos, é mais simples ter uma garantia contratual do que realmente garantir, por conta própria, que o computador e sistema que usou para acionar a geração de chaves é suficientemente seguro para evitar ataques.

O tema do armazenamento de certificados digitais 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 que se pense “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, porque não, oferecer a este usuário níveis de segurança e controle não existentes nos mecanismos atuais que utilizam tokens e smartcards.

 

Referências

[1] http://www.planalto.gov.br/ccivil_03/mpv/Antigas_2001/2200-2.htm

[2] http://www.iti.gov.br/images/twiki/URL/pub/Certificacao/DocIcp/DOC_ICP_05_V4.0.pdf

[3] http://www.iti.gov.br/images/legislacao/Docicp/DOC_ICP_04_V6.0_.pdf

[4] http://www.iti.gov.br/images/servicos/homologacao/MCT_11_1.pdf

[5] http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm

[6] https://cryptoid.com.br/banco-de-noticias/nota-do-iti-sobre-uso-de-hsm-por-viviane-bertol-e-fabiano-menke/

COMPARTILHE ESSA POSTAGEM

Cristian Thiago Moecke

Mestre em Ciências da Computação pela Universidade Federal de Santa Catarina. Atuou desde a graduação em projetos relacionados à ICP-Brasil no Laboratório em Segurança em Computação da Universidade Federal de Santa Catarina, tendo participado do desenvolvimento, gestão de qualidade e gestão de projeto do Sistema de Gestão de Autoridades Certificadoras do projeto João de Barro, plataforma criptográfica nacional para as Autoridades Certificadoras Raiz e Intermediárias da ICP-Brasil. Atuou também em pesquisa e aprimoramento dos padrões brasileiros de assinatura digital. Foi pesquisador em Usable Security no CASED (Center for Advanced Security Research), em Darmstadt, Alemanha. Hoje é colaborador da BRy Tecnologia, onde lidera projetos de inovação na área de segurança em documento eletrônico.

Deixe um comentário

Seu e-mail não será publicado.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>