Anúncios

Security and Technology

Últimas

Open Distributed Threat Intelligence: Yeti » CyberPunk

Open Distributed Threat Intelligence: Yeti CyberPunk Open Distributed Threat Intelligence Yeti is a platform meant to organize observables, indicators of compromise, TTPs, and knowledge on threats in a single, unified repository. Yeti will also… http://ift.tt/2mVefFO http://ift.tt/2aM8QhC
Anúncios

Open Source Malware Analysis Platform: FAME » CyberPunk

Open Source Malware Analysis Platform: FAME CyberPunk Open Source Malware Analysis Platform FAME is an open source malware analysis platform that is meant to facilitate analysis of malware-related files, leveraging as much knowledge as possible in… http://ift.tt/2mYSUMo http://ift.tt/2aM8QhC

Sapataria utiliza RFID e Biometria para dar mais agilidade aos negócios | CRYPTOID

Sapataria utiliza RFID e Biometria para dar mais agilidade aos negócios Regina Tupinambá

A Sapati – Sapataria Inteligente é a primeira loja laboratório do Brasil, que foi criada pela SetaDigital após 2 anos de pesquisa e desenvolvimento de soluções inovadoras para o varejo calçadista.

Murilo Caetano Dal Molim

Por Murilo Caetano Dal Molim

O Projeto visa a melhoria de processos, pessoas, tecnologias e visual merchandising gerando uma nova experiência de compra para o consumidor e melhores resultados para os lojistas.

Tecnologias utilizadas

A Sapati proporciona a aplicação de diversas tecnologias aliadas a processos e pessoas, como RFID (Radio-Frequency Identification), Biometria, IOT (Internet of Things), realidade aumentada e realidade virtual que colaboram na experiência de compra, venda e necessidades diárias de uma loja de calçados.

A tecnologia RFID (Radio-Frequency Identification) possibilita a comunicação automática e de forma remota entre dispositivos específicos pela emissão e captação de sinais de rádio. Na Sapati – Sapataria Inteligente a tecnologia RFID foi empregada no atendimento ao cliente e na administração eficiente do estoque da loja.

Para o consumidor, a tecnologia RFID potencializou o autoatendimento com interações inteligentes aliadas a um processo mais eficaz e divertido. Nesta oportunidade o consumidor tem a liberdade de visualizar detalhes do produto (Marca, modelo, tamanho, imagem, valor) somente aproximando a um toten equipado com um leitor RFID e uma tela sensível ao toque. Com a escolha do produto, o consumidor pode adicioná-lo a sua “cesta virtual” que é representado por um cartão RFID já em posse do programa de fidelidade ou disponível nos totens para novos clientes. Durante sua experiência na loja o consumidor tem a total liberdade para administrar os produtos que fazem parte de sua “cesta virtual” nos totens de autoatendimento e, quando desejar, finalizar a compra para desfrutar de seus produtos.

Para maior aproximação com o consumidor, o programa de fidelidade se estende na possibilidade da identificação do acesso do consumidor a loja e oportuniza o atendimento e/ou propaganda direcionada.

O modelo de autoatendimento da Sapataria acompanha a evolução do mercado e do consumidor promovendo o vendedor consultor, aquele que agrega a experiência de venda/compra, assessorando o consumidor e desenvolvendo um relacionamento duradouro.

Como apresentado anteriormente, as tecnologias estão atreladas aos processos, deste modo os produtos estão dispostos na loja segmentados por tamanho e modelo para auxiliar o consumidor em um fluxo assertivo no encontro aos produtos desejados.
Todo o processo de autoatendimento é realizado em 5 passos:

Para o lojista, a tecnologia RFID teve foco no atendimento das necessidades diárias, automatizando e maximizando os processos de forma segura, ágil e adaptável.

No processo de inventário o RFID apresenta grande vantagem comparado ao convencional código de barras, onde o processo de coleta é simples e ocorre em poucos minutos, além de apresentar um índice de acerto superior e capturar produtos que não tem fácil acesso ao leitor de barras. Para a segurança, o RFID é aplicado na identificação de saída indevida de produtos da loja para posterior acionamento de alerta sonoro e/ou segurança. No gerenciamento do produto é utilizando para o armazenando correto tanto em local físico como em produtos distintos em uma mesma embalagem.

A Biometria por leitura da impressão digital é utilizada na garantia de identificação de unicidade da pessoa para a segurança nos processos do SetaERP (ERP utilizado na Sapati), por exemplo, no controle de um procedimento de autorização gerencial, onde exige a presença do responsável e na identificação do cliente no processo de venda e condicional.

Conclusão

O propósito da SetaDigital é fazer a diferença na vida das pessoas, desenvolvendo soluções simples, rápidas e confiáveis para lojas de calçados, e a Sapati vem de encontro por ofertar um ambiente real que possibilita a aplicação de inovações, validação de processos e melhoria contínua.

O post Sapataria utiliza RFID e Biometria para dar mais agilidade aos negócios apareceu primeiro em CRYPTOID. http://ift.tt/2nH9vrO http://ift.tt/2aM8QhC

Faraday v2.4 – Collaborative Penetration Test and Vulnerability Management Platform

Faraday is the Integrated Multiuser Risk Environment you were looking for! It maps and leverages all the knowledge you generate in real time, letting you track and understand your audits. Our dashboard for CISOs and managers uncovers the impact and risk being assessed by the audit in real-time without the need for a single email. Developed with a specialized set of functionalities that helps users improve their own work, the main purpose is to re-use the available tools in the community taking advantage of them in a collaborative way!

LDAP support

Yes, Faraday’s bucket list is an item shorter as of this release! LDAP support has been on the horizon for quite some time now, but not anymore – this brand new version comes with LDAP support out of the box, no additional modules required, isn’t that neat?

Why LDAP? Well, because a great number of companies around the world use it to centralize their user account management. The protocol provides total control over the credentials in all the platforms, which comes in pretty handy when managing large volumes of data. In fact, LDAP is so popular that some companies have a policy to only use tools that support LDAP authentication.

By adding LDAP support to Faraday, we give our clients the possibility to manage larger teams, implement large-scale installations and maintain a granular and simple control over their user accounts.

In addition, using Faraday over LDAP provides better configuration than ever, allowing complex credential policies such as password expiration and quality standards, or credential lockout.

Faraday Plugin

There are some changes to the Faraday Plugin, improving its functionality by allowing users to run it through the GTK interface, performing actions in batch and filtering objects.

One of the best things about this new version of the Plugin is that you can now use it to script some of the most boring tasks needed in every assessment.

Example of task automation using Faraday Plugin – Running ping for every host that has a service on port 22
We also added a menu option to run directly from GTK!
New menu item in GTK allows users to run Fplugin without having to type anything!Read more about FPlugin in our documentation
Details are everything

And that is what this release is all about. We believe that correcting very specific details and introducing small improvements also adds quality and efficiency to a platform like ours. So it is in those items that we focused on the last iteration.
Changes

Added LDAP support for authentication

Removed grouping by issue tracker option in status report

Added command line option to automatically install the license files before launching Faraday

Fixed bug when editing workspaces with maximum allowed workspaces reached

Improved login in Web UI

Improved the validation applied to passwords when editing them in the Web UI

Better password validation

Improved UX in users list Web UI

Improved GTK UX when the client loses connection to the server

Added link to name column in Hosts list

Host names with links

Fixed bug in SQLMap plugin that made the client freeze

Fixed bug when creating/updating Credentials

Fixed bug in the WEB UI – menu explanation bubbles were hidden behind inputs

Fixed conflict resolution when the object was deleted from another client before resolving the conflict

Improved FPlugin

Improved the installation process

Improved SQLMap plugin to support –tables and –columns options

Improved navigation in Web UI

Merged PR #137 – CScan improvements: bug fixing, change plugin format and removed unnecessary file output

Merged PR #173 – Hostnames: added hostnames to plugins

Merged PR #105 – OSint: added the possibility of using a DB other than Shodan

The Status Report now remembers the sorting column and order

Created a requirements_extras.txt file to handle optional packages for specific features

We hope you enjoy it, and let us know if you have any questions or comments.https://www.faradaysec.comhttps://github.com/infobyte/faradayhttps://twitter.com/faradaysec
Download Faraday v2.4 http://ift.tt/2nh0yo7 http://ift.tt/2aM8QhC

Faraday v2.4 – Collaborative Penetration Test and Vulnerability Management Platform

Faraday is the Integrated Multiuser Risk Environment you were looking for! It maps and leverages all the knowledge you generate in real time, letting you track and understand your audits. Our dashboard for CISOs and managers uncovers the impact and risk being assessed by the audit in real-time without the need for a single email. Developed with a specialized set of functionalities that helps users improve their own work, the main purpose is to re-use the available tools in the community taking advantage of them in a collaborative way!

LDAP support

Yes, Faraday’s bucket list is an item shorter as of this release! LDAP support has been on the horizon for quite some time now, but not anymore – this brand new version comes with LDAP support out of the box, no additional modules required, isn’t that neat?

Why LDAP? Well, because a great number of companies around the world use it to centralize their user account management. The protocol provides total control over the credentials in all the platforms, which comes in pretty handy when managing large volumes of data. In fact, LDAP is so popular that some companies have a policy to only use tools that support LDAP authentication.

By adding LDAP support to Faraday, we give our clients the possibility to manage larger teams, implement large-scale installations and maintain a granular and simple control over their user accounts.

In addition, using Faraday over LDAP provides better configuration than ever, allowing complex credential policies such as password expiration and quality standards, or credential lockout.

Faraday Plugin

There are some changes to the Faraday Plugin, improving its functionality by allowing users to run it through the GTK interface, performing actions in batch and filtering objects.

One of the best things about this new version of the Plugin is that you can now use it to script some of the most boring tasks needed in every assessment.

Example of task automation using Faraday Plugin – Running ping for every host that has a service on port 22
We also added a menu option to run directly from GTK!
New menu item in GTK allows users to run Fplugin without having to type anything!Read more about FPlugin in our documentation
Details are everything

And that is what this release is all about. We believe that correcting very specific details and introducing small improvements also adds quality and efficiency to a platform like ours. So it is in those items that we focused on the last iteration.
Changes

Added LDAP support for authentication

Removed grouping by issue tracker option in status report

Added command line option to automatically install the license files before launching Faraday

Fixed bug when editing workspaces with maximum allowed workspaces reached

Improved login in Web UI

Improved the validation applied to passwords when editing them in the Web UI

Better password validation

Improved UX in users list Web UI

Improved GTK UX when the client loses connection to the server

Added link to name column in Hosts list

Host names with links

Fixed bug in SQLMap plugin that made the client freeze

Fixed bug when creating/updating Credentials

Fixed bug in the WEB UI – menu explanation bubbles were hidden behind inputs

Fixed conflict resolution when the object was deleted from another client before resolving the conflict

Improved FPlugin

Improved the installation process

Improved SQLMap plugin to support –tables and –columns options

Improved navigation in Web UI

Merged PR #137 – CScan improvements: bug fixing, change plugin format and removed unnecessary file output

Merged PR #173 – Hostnames: added hostnames to plugins

Merged PR #105 – OSint: added the possibility of using a DB other than Shodan

The Status Report now remembers the sorting column and order

Created a requirements_extras.txt file to handle optional packages for specific features

We hope you enjoy it, and let us know if you have any questions or comments.https://www.faradaysec.comhttps://github.com/infobyte/faradayhttps://twitter.com/faradaysec
Download Faraday v2.4 http://ift.tt/2nh0yo7 http://ift.tt/2aM8QhC

Sobre uso de HSM para guarda de certificados digitais – Por Viviane Bertol e Fabiano Menke | CRYPTOID

Uso de HSM para guarda de certificados digitais – Por Viviane Bertol e Fabiano Menke Regina Tupinambá

Devem ser consideradas inválidas, sob a ótica jurídica, as assinaturas digitais apostas com base em chave privada armazenada em HSM hardware secure module?

Por Viviane Bertol e Fabiano Menke

O presente artigo foi escrito no mês de novembro de 2012. Em 12.02.2014, a Procuradoria Federal Especializada do Instituto Nacional de Tecnologia da Informação veiculou Nota Pública em que registrou: “Em revisão de seu posicionamento anterior, externado em nota pública datada de 03 de outubro de 2012, não se pode afirmar, antecipadamente, que assinaturas digitais de pessoas físicas providas por meio de certificados armazenados em soluções mercadológicas de uso compartilhado de HSM (Hardware Secure Module), em modelo de rede, seja inválida“. Para a íntegra da Nota Pública de 12.02.2014, acessar: http://ift.tt/2nFVzOB

Fabiano Menke

Professor da Faculdade de Direito da Universidade Federal do Rio Grande do Sul. Doutor em Direito pela Universidade de Kassel, Alemanha. Mestre em Direito pela Universidade Federal do Rio Grande do Sul. Autor dos livros Die elektronische Signatur im deutschen und brasilianischen Recht: Eine rechtsvergleichende Studie, publicado pela Editora Nomos, na Alemanha, em 2009, e A Assinatura Eletrônica no Direito Brasileiro, publicado pela Editora Revista dos Tribunais, em 2005.

Viviane Bertol

Consultora em certificação digital, com Mestrado e Doutorado nessa área pela Universidade de Brasília. Trabalhou no Instituto Nacional de Tecnologia da Informação (ITI) na Coordenadoria-Geral de Auditoria e Fiscalização e Coordenadoria-Geral de Normalização e Pesquisa, tendo participado da elaboração de metodologias de auditoria e realizado auditorias em Autoridades de Registro e Autoridades Certificadoras. Participou da elaboração de diversos normativos da ICP-Brasil.

Sumário: 1- Introdução; 2- O funcionamento dos Hardware Secure Module (HSM); 3 – A questão da validade jurídica no âmbito da ICP-Brasil; 4 – O controle da chave privada no âmbito da Medida Provisória nº 2.200-2 e das regras da ICP-Brasil; 5 – Conclusões.

1- Introdução

Em 03.10.2012 o Instituto Nacional de Tecnologia da Informação exarou Notificação Pública com o seguinte teor[1]:

“A geração e a guarda da chave privada de pessoa física em HSM (Hardware Secure Module), compartilhado por outras pessoas físicas (modelo de rede, com o HSM controlado por um servidor), contraria o padrão ICP-Brasil, de forma que as manifestações eletrônicas que utilizem essa solução não terão validade jurídica, haja vista que a Medida Provisória nº 2.200-2, de 24 de agosto de 2001, em seu art. 6º, parágrafo único, é expressa:

Art.6º(…).

Parágrafo único. 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.

Logo, a validade jurídica da assinatura digital ICP-Brasil encontra-se condicionada à tutela exclusiva da chave privada pelo seu titular, fato esse inocorrente acaso se utilize a solução de HSM como um centralizador de diversas chaves privadas de pessoas físicas, haja vista que o controle, uso e conhecimento exclusivo da chave privada pelo seu titular é requisito imprescindível para a segurança das manifestações eletrônicas e a sua consequente validade jurídica.”

Ou seja, de acordo com a Notificação Pública, não terão validade jurídica os documentos eletrônicos assinados com base em chave privada armazenada nos denominados HSM (Hardware Secure Module, que vem sendo traduzido para o português como “módulo criptográfico de segurança”), quando este (o HSM) for compartilhado, ou seja, quando mais de uma pessoa tenha a sua chave privada gravada no mesmo HSM.

A seguir, faremos uma análise da referida Notificação Pública, confrontando-a com a Medida Provisória nº 2.200-2 e com as normas pertinentes da ICP-Brasil (resoluções do Comitê Gestor e demais regras) a fim de chegarmos a uma conclusão de se é correto afirmar que os denominados HSMs compartilhados efetivamente gerarão assinaturas digitais inválidas sob o ponto de vista jurídico.

A fim de responder esse questionamento, descreveremos o funcionamento do HSM compartilhado (2); analisaremos a questão a partir do exame da validade jurídica do documento eletrônico assinado digitalmente (3); passando pelo aspecto do controle da chave privada de acordo com o disposto na Medida Provisória 2.200-2 e nas regras da ICP-Brasil (4) e finalizaremos com a conclusão (5).

2. O Funcionamento dos HSMs

2.1 Introdução

A sigla HSM significa “Hardware Security Module” ou, em Português, Módulo de Segurança Criptográfica (MSC).

Um HSM é um dispositivo de criptografia baseado em hardware, fisicamente seguro e resistente à violação, que fornece funcionalidades criptográficas com capacidade de geração e armazenamento de chaves criptográficas simétricas e assimétricas voltadas para utilização em uma Infraestrutura de Chaves Públicas (ICP).

Um HSM gera, armazena e protege chaves criptográficas e geralmente fornece aceleração de hardware para operações criptográficas. Pode se constituir de um dispositivo independente ou apenas de uma placa auxiliar. Nesse último caso, atende unicamente ao servidor em que está instalado. Caso seja um dispositivo independente, um HSM pode atender a diversos servidores, via rede, dependendo de seu modelo e da forma como foi configurado.

Para prover segurança às chaves criptográficas e parâmetros críticos nele armazenados, um HSM mantém conformidade com padrões de construção de hardware, levando em consideração os mais diversos ataques possíveis. Exemplos de padrões são:

FIPS PUB 140-2 (publicado pelo governo americano)

ITSEC Common Criteria (ISO/IEC 15408) (baseado no padrão europeu ITSEC para avaliação de segurança de produtos e sistemas)

Manuais de Condutas Técnicas 7 (MCT-7) da ICP-Brasil (publicado pelo Instituto Nacional de Tecnologia da Informação)

Esses padrões estabelecem requisitos de conformidade e classificam os equipamentos em níveis crescentes, levando em consideração projeto, especificação, ambiente operacional, contenções de ataques e procedimentos de autenticação.

2.2 Utilização de HSMs na ICP-Brasil

A ICP-Brasil admite a utilização de HSMs e de outros dispositivos criptográficos, como cartões ou tokens, para a geração e guarda de chaves de titulares de certificados do tipo A3, A4, S3 e S4, desde que tais dispositivos estejam homologados na ICP-Brasil (ver documento Padrões e Algoritmos Criptográficos da ICP-Brasil (DOC ICP-01.01) – Versão 2.3 de 06 de julho de 2012):

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 (DOC-ICP-10) – Versão 3.0 de 27 de setembro de 2012.

Segundo aquele documento, a homologação tem por objetivo “asseverar a plena aderência dos sistemas e equipamentos avaliados aos padrões e especificações técnicas mínimos estabelecidos nas normas editadas ou adotadas pela ICP-Brasil, tendo como enfoque específico a garantia da interoperabilidade desses sistemas e equipamentos e a confiabilidade dos recursos de segurança da informação por eles utilizados.“

Os sistemas e equipamentos homologados devem atender aos requisitos técnicos definidos nos Manuais de Conduta Técnica (MCT) elaborados pelo Instituto Nacional de Tecnologia da Informação (ITI).

Para obter a homologação o fabricante ou outra parte interessada solicita a avaliação do dispositivo criptográfico a um laboratório acreditado, municiando-o de documentação e exemplares do dispositivo, para avaliação e testes. Caso o produto atenda ao disposto no MCT respectivo, a homologação é concedida e publicada no Diário Oficial da União.

Uma relação completa dos dispositivos homologados é mantida na página http://ift.tt/2nUMpLx

No caso específico de HSMs, aplica-se o MCT 7 – Volume I – Requisitos, Materiais e Documentos Técnicos para Homologação de Módulos de Segurança Criptográfica (MSC) no Âmbito da ICP-Brasil – versão 1.0 – São Paulo, 23 de novembro de 2007.

Segundo o MCT-7:

“O objetivo do processo de homologação do módulo de segurança criptográfico é propiciar a interoperabilidade e operação segura do serviço criptográfico ICP oferecido por um módulo de segurança criptográfico por meio da avaliação técnica de aderência aos requisitos técnicos definidos para este processo.”

…..

“O processo de homologação é baseado em um conjunto de requisitos técnicos que devem ser atendidos por um módulo de segurança criptográfico para garantia da interoperabilidade e operação segura.

Esses requisitos técnicos são avaliados segundo ensaios de aderência aos requisitos técnicos. Para a realização dos ensaios, a parte interessada deve submeter ao processo de homologação um conjunto de materiais requisitados, através de um procedimento denominado depósito de material.”

Segundo o MCT-7, os HSMs utilizados na ICP-Brasil devem atender a requisitos técnicos relativos às seguintes áreas:

Documentação do módulo criptográfico

Identificação de portas e interfaces do módulo criptográfico

Nível de identificação de papéis, serviços e autenticação do operador

Descrição do modelo de estado finito

Nível de segurança física

Ambiente operacional

Gerenciamento de chaves criptográficas

Interferência e compatibilidade eletromagnética

Auto-testes

Garantia do projeto

Mitigação de outros ataques

Algoritmos criptográficos obrigatórios

Gerenciamento

Interoperabilidade

Restrição de substâncias nocivas.

Para o estudo ora em foco, ou seja, para avaliar se é viável a utilização de um HSM para armazenamento de chaves privadas de diferentes titulares de certificados, vamos analisar alguns desses requisitos, a saber:

Nível de identificação de papéis, serviços e autenticação do operador

O MCT 7 prevê diferentes papéis para acesso a um HSM:

“REQUISITO III.3.3: [FIPS 140-2, 4.3.1] O módulo criptográfico deve suportar, no mínimo, os seguintes “papéis autorizados”:

– Oficial de segurança (SO): Necessário para realizar funções de gerenciamento, inicialização, distribuição e fechamento de acesso ao módulo.

– Usuário: Necessário para realização de serviços de segurança oferecidos pelo módulo depois de sua inicialização, incluindo operações criptográficas, criação de chaves criptográficas, o uso do sistema de arquivos, sobrescrita do valor de chaves criptográficas com zeros binários (key zeroization), etc….. “

Com relação ao papel de usuário, especifica o MCT os seguintes requisitos:

“3.3.1.1 Papel de acesso Usuário

REQUISITO III.3.6: Funcionalidades atribuídas ao papel de acesso “Usuário” devem incluir:

Manipulação (leitura, escrita, criação e remoção) de chaves criptográficas e PCS no módulo criptográfico;

Acesso às funcionalidades de segurança, como por exemplo: autenticação, transferência segura de mensagens por meios eletrônicos (secure messaging), criptografia, decifração, assinaturas digitais, geração de resumos criptográficos (hashing) e códigos MAC, etc;

Geração de chaves RSA;

Requisição de informações de estado do módulo criptográfico.”

Do acima visto, conclui-se que é possível a utilização do HSM por diferentes usuários e que esses usuários podem e realizar funções geração de chaves criptográficas e assinatura digital .

Ambiente Operacional

Entre as definições e requisitos sobre o ambiente operacional do HSM, constantes no MCT-7, destacamos o que segue:

“DEFINIÇÃO III.6.1: Caminho confiável (Trusted path): um caminho protegido entre o operador e o MSC com o qual ambos acreditam que estejam interagindo. Um caminho confiável reflete um canal protegido. O software malicioso que se injeta neste caminho pode ser identificado.

Um caminho confiável pode ser visto como um mecanismo que fornece autenticidade entre o operador e o módulo criptográfico, garantindo que ataques não consigam interceptar ou modificar informações sendo transmitidas no caminho.

REQUISITO III.6.8: [FIPS 140-2 nível 2, 4.6] Todas as chaves criptográficas e PCSs, dados de autenticação, entradas de controle e saídas de status devem comunicar através de um mecanismo confiável que utilize portas físicas de I/O dedicadas ou caminho confiável.

RECOMENDAÇÃO III.6.1: [FIPS 140-2 nível 2, 4.6] Acrescentando os requisitos de auditoria, os seguintes eventos devem ser armazenados por mecanismos de auditoria:

– Tentativa de usar uma função de caminho confiável (read, write, open e close);

– identificação da origem e do destino de um caminho confiável.”

Do texto acima, concluímos que o HSM pode ser operado via rede, desde que seja utilizado um caminho confiável para a comunicação e seja feito registro dessa operação, incluindo a identificação da sua origem e destino.

Gerenciamento de Chaves

Segundo o MCT-7, os HSMs devem atender a diversos requisitos de gerenciamento de chaves, entre eles:

“REQUISITO III.7.1: [FIPS 140-2, 4.7] Chaves secretas, chaves assimétricas privadas e PCSs devem estar protegidas dentro do módulo contra divulgação, modificação e substituição não autorizada.”

….

REQUISITO III.7.23: Deve ser possível configurar no módulo criptográfico com atributo não exportável uma chave criptográfica assimétrica privada, para fins de assinatura digital, compatível com certificados digitais ICP-Brasil de tipo A3 ou A4. Uma vez definido tal atributo como não exportável, não deve ser possível alterar seu valor para exportável.

REQUISITO III.7.26: [FIPS 140-2, 4.7.5] Chaves criptográficas devem ser armazenadas dentro do módulo criptográfico em texto claro ou de forma cifrada.

REQUISITO III.7.27: [FIPS 140-2, 4.7.5] Chaves privadas e secretas em texto claro não devem ser acessíveis por operadores não autorizados.

REQUISITO III.7.28: [FIPS 140-2, 4.7.5] O módulo criptográfico deve associar a cada chave (simétrica ou assimétrica) armazenada o seu respectivo operador (pessoa, grupo, processo, servidor, etc).

REQUISITO III.7.29: [FIPS 140-2, 4.7.5] A documentação deve especificar os métodos de armazenamento de chaves criptográficas empregados pelo módulo.

Do acima visto, conclui-se que é possível utilizar um HSM homologado na ICP-Brasil para criar e armazenar chaves criptográficas de diferentes usuários, desde que atendidos os requisitos de segurança previstos para esses processos.

Analisando os aspectos técnicos acima levantados, conclui-se que o próprio Instituto Nacional de Tecnologia da Informação prevê, em seus regramentos, que um HSM homologado pode ser utilizado por mais de um usuário para gerar e armazenar chaves privadas e realizar assinatura digital, desde que sejam observados requisitos de segurança apropriados, entre os quais a autenticação dos usuários, a utilização de um caminho confiável entre o operador e o módulo criptográfico, o registro de eventos apropriados para auditoria e a adoção de cuidados para geração, importação, exportação e armazenamento das chaves.

Considere-se ainda que um HSM é um equipamento bastante caro e sua utilização por um único usuário seria economicamente pouco justificável, na maior parte dos casos, fato esse que é reforçado pela observação de que mesmo autoridades certificadoras da ICP-Brasil utilizam HSMs compartilhados para a geração e armazenamento de suas chaves privadas, por motivos econômicos.

Aqui vai, portanto, uma importante observação: não há compartilhamento algum de chave privada, pois isso colidiria frontalmente com as normas da ICP-Brasil. O que efetivamente ocorre é o compartilhamento do HSM, sem a possibilidade de que qualquer pessoa ou recurso computacional tenha acesso à chave privada. Eventuais soluções de HSM baseadas em compartilhamento da chave privada, que são tecnicamente possíveis e existem, sequer serão consideradas nesta análise, por não serem compatíveis, nem com a Medida Provisória nº 2.200-2 e nem com as demais normas da ICP-Brasil.

2.4 – O funcionamento dos Hardware Security Modules (HSM)

Uma das formas utilizadas pelos fabricantes de HSM para separar de forma segura as chaves privadas de diferentes usuários é compartimentá-las em partições lógicas, cada qual com acesso segregado.

Nesse caso, o que se tem é o funcionamento do HSM de forma bastante similar a um conjunto de cartões ou tokens, suportando, cada um desses cartões ou tokens uma partição ou compartimento autônomo, controlado, cada qual, por um detentor diferente, que comprova a sua identidade para acessar a chave privada por meio de um PIN ou senha.

De estudo específico sobre o funcionamento de HSM compartilhado com base em partições, realizado por Jeandré Sutil[2], podemos destacar os seguintes trechos:

“Diferentemente de um token ou cartão, entretanto, o HSM possui controles de segurança mais restritivos contra tentativas de acesso indevido às chaves armazenadas em seu interior, como sensores de luminosidade, variação de tensão, dentre outros dispositivos que visam a evidenciar e destruir os dados sensíveis, ao menor sinal de uma tentativa de intrusão.

Tendo essa arquitetura em vista, os procedimentos para a emissão de um certificado são:

1) Uma nova partição é criada para o usuário no interior do HSM. Nesse momento, é gerado o PIN de conhecimento exclusivo do usuário, para acesso e criação de objetos em sua partição do HSM;

2) O usuário, quando quiser solicitar a emissão de um certificado, deverá se autenticar com seu PIN em sua partição, solicitar a geração de seu par de chaves e a exportação de sua requisição (CSR);

3) Com essa requisição em mãos, o usuário acessará o sistema da AC e concluirá a solicitação de seu certificado digital;

4) O usuário encaminhar-se-á até uma AR, para validação de seus documentos e assinatura de um termo de titularidade, em que atesta que sua chave foi gerada em um dispositivo criptográfico, como é exigência para um certificado do tipo A3;

5) Com a validação finalizada e o certificado emitido, o usuário volta a acessar o sistema da AC e efetua o download de seu certificado digital;

6) O usuário novamente se autentica junto a sua partição no HSM, informando o PIN, dessa vez para importar seu certificado digital.

Não há nenhuma inovação nos passos acima descritos, pois são exatamente os executados na emissão de um certificado em token. Cada usuário será o único capaz de gerar e utilizar um par de chaves criptográficas armazenado no compartimento de sua propriedade. Para fazer uma assinatura digital, o usuário precisará necessariamente informar o PIN para liberar o uso de sua chave.”

Da descrição do funcionamento de um HSM compartilhado, se verifica que é perfeitamente possível a observância dos requisitos de segurança que permitam o armazenamento de chaves privadas no âmbito da ICP-Brasil. É plenamente possível que apenas o HSM seja compartilhado, sem que o mesmo ocorra com a respectiva chave privada do usuário, pois esta sim deverá estar sob o exclusivo controle do titular do par de chaves criptográficas.

Após uma melhor compreensão do funcionamento do HSM compartilhado, perquiriremos a seguir se as assinaturas digitais geradas a partir deste equipamento sempre serão consideradas inválidas sob o ponto de vista jurídico.

3 – A questão da validade jurídica no âmbito da ICP-Brasil

Primeiramente, e antes de entrar no mérito de se as assinaturas geradas com base no HSM serão sempre consideradas inválidas, há que se fazer uma breve digressão sobre a questão da validade jurídica em si das assinaturas digitais no âmbito da legislação brasileira. Como se sabe, a questão do valor jurídico da assinatura digital foi regrada pela Medida Provisória nº 2.200-2, de 2001, que permanece em vigor, em virtude da edição da Emenda Constitucional nº 32/2001[3]. De acordo com o Art. 10, §1°, da Medida Provisória nº 2.200-2: “As declarações constantes dos documentos em forma eletrônica produzidos com a utilização de processo de certificação disponibilizado pela ICP-Brasil presumem-se verdadeiros em relação aos signatários, na forma do art. 131 da Lei nº 3.071, de 1º de janeiro de 1916 – Código Civil.”

Este dispositivo legal realiza o que se chama de equivalência funcional[4], reconhecendo a equiparação jurídica entre a assinatura manuscrita e a assinatura digital aposta com os meios técnico-organizacionais disponibilizados pela ICP-Brasil.

Como já tivemos a oportunidade de registrar[5], o artigo 131 do Código Civil de 1916, com correspondência exata ao que dispõe o artigo 219 do Código Civil de 2002, ao prever que serão consideradas verdadeiras em relação ao signatário as declarações assinadas, tem por finalidade atribuir uma presunção relativa[6] de autoria às mensagens assinadas de próprio punho.

Ao transpor este dispositivo para o meio eletrônico, a Medida Provisória nº 2.200-2 atribuiu presunção (também relativa) de autoria ao documento eletrônico assinado com certificado digital da ICP-Brasil[7]. Por mais que a Medida Provisória nº 2.200-2 tenha, em seu artigo 1º, feito referência ao escopo de garantir “a validade jurídica” dos documentos em forma eletrônica[8], esta “garantia da validade jurídica” significa primordialmente o intuito de afastar entendimentos que discriminem as manifestações de vontade exaradas pelo meio eletrônico, pelo simples fato de terem sido produzidas neste meio. É o reconhecimento do postulado que no âmbito da UNCITRAL leva a nomenclatura de princípio da não-discriminação[9]. A Medida Provisória nº 2.200-2 não pretendeu reservar para o seu regramento, ou para os mecanismos de atribuição de autoria que prevê, a exclusividade do atributo de validade. Em outras palavras, a Medida Provisória nº 2.200-2 não determina que ou bem se observe os requisitos da ICP-Brasil, ou se estará diante de invalidade.

Até porque, não se pode perder de vista o contido no §2º do art. 10 da Medida Provisória nº 2.200-2, segundo o qual: ”O disposto nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento“. Este dispositivo tem o intuito de flexibilizar a referida regra do §1º, esclarecendo que as partes têm a liberdade de escolher outros meios de atribuição de autoria que não a assinatura digital ICP-Brasil.

A Medida Provisória nº 2.200-2, portanto, não criou uma forma especial[10] obrigatória para o meio eletrônico. E mais, sua disciplina sobre forma e prova dos atos e negócios jurídicos se situa no âmbito do disciplinado no Código Civil, que determina, em seu art. 107, que “A validade da declaração de vontade não dependerá de forma especial, senão quando a lei expressamente a exigir“. Não se verifica no seu texto esta “avocação” da forma especial para os procedimentos de atribuição de autoria da ICP-Brasil, muito pelo contrário, justamente em virtude do § 2º do art. 10.

Acrescente-se a isso a existência de outras regras, tanto do Código Civil quanto do Código de Processo Civil[11], que disciplinam a questão da prova e de sua valoração, e que estão em consonância com os princípios da liberdade de formas[12] e da livre apreciação das provas, como o art. 332 deste último diploma legal, que determina: “Todos os meios legais, bem como os moralmente legítimos, ainda que não especificados neste Código, são hábeis para provar a verdade dos fatos, em que se funda a ação ou a defesa“.

Examine-se ainda os requisitos de validade do negócio jurídico, previstos nos três incisos do art. 104 do Código Civil[13], observando-se que os mesmos requisitos são aplicados ao ato jurídico, conforme determina o art. 185 do Código Civil[14]. No que interessa à questão em exame, qual seja a forma, se vê que o inciso III do art. 104 do Código Civil prevê que a forma é um requisito de validade do negócio e do ato jurídico, no sentido de que deve ser observada a forma prescrita em lei e evitada a forma proibida por dispositivo legal. Mas note-se que os requisitos gerais de validade do art. 104 remetem à lei, que poderá ou não prescrever forma especial. E, como se viu, essa forma especial não foi prevista pela Medida Provisória nº 2.200-2[15].

Em assim sendo, não se podem considerar corretas assertivas no sentido de que os métodos de atribuição de autoria que não estiverem de acordo com as regras da ICP-Brasil serão considerados inválidos tout court, como o faz a Notificação Pública do Instituto Nacional de Tecnologia da Informação. Analisada sobre outro enfoque, e ainda que não refira expressamente, a assertiva também traz a ideia de plenitude, no sentido de que a assinatura digital ICP-Brasil faria prova plena da autoria da declaração de vontade, apta a atribuir uma certeza praticamente inabalável quanto à autoria e a integridade da mensagem eletrônica. Neste contexto, o Manual de Perguntas & Respostas Jurídicas da ICP-Brasil[16] registra: “Apenas o certificado da ICP-Brasil, e nenhum outro, gera a certeza da validade jurídica do documento eletrônico, pois se sabe, com garantia legal (MP 2.200-2/01, art. 1º), quem assinou (autenticidade) e que o documento não sofre modificação entre o emissor e seu destinatário (integridade)“.

Esta afirmativa atribui ao certificado digital ICP-Brasil, e ao documento eletrônico assinado com base neste certificado, uma certeza que a rigor não se pode extrair dos dispositivos legais examinados da Medida Provisória nº 2.200-2. Ao mencionar a “certeza”, dá a entender o aludido Manual que mesmo assinando o documento com o certificado ICP-Brasil jamais haverá possibilidade de impugnação. Em outro trecho da resposta à pergunta 51, apesar de conceder que ainda que mais inseguros, outros certificados digitais que não os da ICP-Brasil podem ser utilizados, faz a seguinte colocação sobre a possibilidade de impugnação quanto a vícios da vontade dos documentos assinados digitalmente com base nestes certificados: “Isso porque o interessado em utilizá-los fica a depender da aceitação do outro contratante e, uma vez dada, ainda pode ser impugnada judicialmente, sob a alegação, por exemplo, de qualquer vício de consentimento (coação, erro)“. Pela leitura do trecho transcrito, chega-se à conclusão, a contrario sensu, de que o documento eletrônico assinado digitalmente com base em certificado digital ICP-Brasil não é suscetível às hipóteses de anulação previstas na Parte Geral do Código Civil em virtude de vício da vontade.

Com a devida vênia, a esta conclusão não se pode chegar. É que nem a Medida Provisória nº 2.200-2, nem a técnica que ela reconhece, a criptografia assimétrica, alteraram e jamais teriam a pretensão de alterar a disciplina do Código Civil relativa à possibilidade de invalidação das declarações de vontade viciadas por erro, dolo ou coação. É verdade que a utilização do meio eletrônico, de modo geral, pode dificultar ainda mais a já difícil comprovação dos vícios da vontade, tendo em vista que a manifestação da vontade por esta via, como regra geral, é realizada pelos contratantes de forma isolada, sem a presença de outras pessoas que poderiam figurar como testemunhas para comprovarem os vícios. Ricardo Lorenzetti chega a falar na denominada irrelevância dos estados subjetivos para o meio eletrônico[17]. Mas não se pode chegar ao ponto de afirmar que não é mais possível fazer valer a tradicional dogmática dos defeitos dos atos e negócios jurídicos no meio eletrônico. E isso porque a vontade do declarante (livre de vícios), mesmo após a edição do Código Civil de 2002, continua ocupando um local de destaque na teoria do negócio jurídico, como bem assevera Antônio Junqueira de Azevedo, ao comentar a disciplina do erro[18]: “É no capítulo do erro que mais intensamente se vê a influência da vontade sobre a declaração.“.

Relacionado a este assunto, já tivemos a oportunidade de registrar, ao comentar sobre o denominado não-repúdio, e a possibilidade de impugnar documentos eletrônicos assinados digitalmente, mesmo com base em certificado da ICP-Brasil, que: “o não-repúdio de origem é uma presunção relativa de que aquele que assinou digitalmente, a princípio, estará vinculado à declaração de vontade manifestada. Por ser uma presunção relativa ou juris tantum, é possível a prova em contrário. Por exemplo, o suposto autor da manifestação de vontade poderá provar que foi coagido a assinar determinado documento eletrônico, e, assim, fazer cessar a presunção de autoria. Todavia, tudo dependerá da análise do conjunto probatório, e se o caso chegar ao Poder Judiciário, o magistrado competente deverá investigar fatos como, se após cessada a coação, o coagido tomou as devidas cautelas para comunicar ao destinatário da mensagem sobre o ocorrido, a fim de paralisar eventual execução contratual (comunicando até mesmo a necessidade de revogação do certificado perante a autoridade certificadora). Enfim, existem infinitas possibilidades de combinação de fatos que deverão ser analisados com prudência e cuidado pelo juiz.[19]”

O diferencial da assinatura digital da ICP-Brasil em nossa ótica, não é o atributo de uma pretensa validade exclusiva e absoluta para o meio eletrônico, mas sim o de efeitos jurídico-probatórios diferenciados que o documento eletrônico comum não dispõe. Consoante o já observado:

“Em decorrência, no direito brasileiro, via de regra, só terá os mesmos efeitos da assinatura manuscrita aquela assinatura digital aposta com base em certificado digital emitido por uma das autoridades certificadoras credenciadas pelo Instituto Nacional de Tecnologia da Informação, entidades que têm a obrigação de cumprir com todos os requisitos técnicos, administrativos, operacionais e jurídicos elencados nas normas da ICP-Brasil”.[20]

A questão se resolve, portanto, no plano da eficácia e não da validade. Esses efeitos jurídico-probatórios diferenciados da ICP-Brasil agregam um maior poder de convencimento sobre a autoria e a integridade do documento eletrônico, portanto uma segurança jurídica muito mais robusta, ao dificultar sobremaneira (mas não impossibilitar de todo) as alegações de ausência de autoria.

Em vista do exposto, ainda que abaixo se chegue à conclusão de que as assinaturas digitais apostas com base em chave privada localizada em HSM violam as regras da ICP-Brasil, não se pode concluir como o fez a Notificação Pública do Instituto Nacional de Tecnologia da Informação, que dá conta de que as manifestações eletrônicas que utilizem essa solução não terão validade jurídica. Ainda assim, e após o exame acerca do tema validade jurídica das assinaturas digitais, cumpre questionar se o denominado HSM efetivamente viola as normas da ICP-Brasil. É o que faremos a partir do próximo item.

4 – O controle da chave privada no âmbito da MP 2.200-2 e das regras da ICP-Brasil

O fundamento central da Notificação Pública exarada pelo Instituto Nacional de Tecnologia da Informação reside na alegação de que o HSM viola o disposto no art. 6º, Paragrafo único, da Medida Provisória nº 2.200-2[21]. É a expressão contida na parte final do suporte fático da regra que dá conta de que a chave privada será do exclusivo controle, uso e conhecimento do titular do par de chaves.

O intuito da regra é evidente, qual seja o de vedar soluções técnicas em que outras pessoas tenham o controle, utilizem e conheçam a chave privada do titular. De acordo com a Notificação Pública, “a validade jurídica da assinatura digital ICP-Brasil encontra-se condicionada à tutela exclusiva da chave privada pelo seu titular, fato esse inocorrente acaso (sic) se utilize a solução de HSM“

Primeiramente, há que se considerar que a Notificação Pública em exame parte do pressuposto de que a solução de HSM não está de acordo com o requisito que denomina de “tutela exclusiva da chave privada pelo seu titular”. Todavia, há que se diferenciar aqui o controle, uso e conhecimento exclusivos do titular da chave privada de assinatura, conforme o suporte fático do Parágrafo único do art. 6º da Medida Provisória nº 2.200-2, do que poderia se entender por controle físico, ou posse física da chave privada. A toda evidência, a interpretação que a Notificação Pública faz do referido dispositivo é no sentido de que o titular da chave privada deve obrigatoriamente ter a posse física da chave privada.

Porém, não parece ser essa a melhor exegese da expressão “controle, uso e conhecimento exclusivos” da chave privada. Isso porque, ao utilizar o substantivo “controle”, a Medida Provisória nº 2.200-2 não disse textualmente, nem quis dizer, que esse controle só poderá ser exercido mediante a posse física da mídia onde está armazenada a chave privada[22]. Fosse essa a intenção da regra, certamente teria sido eleita expressão que não deixasse margem para dúvidas, como fez outro dispositivo da própria Medida Provisória nº 2.200-2, no que diz respeito à identificação do indivíduo, que só pode ser feita mediante a presença deste[23], o que, necessariamente será apenas atendido mediante a presença física do interessado em obter o certificado digital.

Como o dispositivo em questão não contempla expressões como “posse física” ou “controle físico”, poderão satisfazer as exigências do suporte fático todas aquelas soluções que viabilizem o controle, acesso e conhecimento exclusivo do par de chaves por seu titular. Enquadra-se neste conceito, inclusive, o HSM compartilhado que seja de tal forma concebido, que permita o controle exclusivo pelo titular da chave privada, ainda que este tenha apenas acesso remoto, mas de forma segura, ao dispositivo.

Daí decorre a conclusão no sentido de que a Medida Provisória nº 2.200-2 não veda a utilização do HSM. Bem pelo contrário, ao valer-se da expressão “controle” abre a possibilidade para que não apenas o controle físico sobre a mídia que armazena a chave privada seja permitido, mas também o controle realizado à distância: um poder de controle fático.

Da mesma forma, quando se recorre às regras infralegais no âmbito da ICP-Brasil, aprovadas pelo Comitê Gestor, não se vislumbra uma vedação à possibilidade de utilização do HSM. Note-se, por exemplo, os requisitos técnicos para a mídia de armazenamento da chave privada, contidos no item 6.1.1.6, do DOC-ICP-03[24]:

“6.1.1.6. A mídia de armazenamento da chave privada deverá assegurar, por meios técnicos e procedimentais adequados, no mínimo, que:

a) a chave privada é única e seu sigilo é suficientemente assegurado;

b) a chave privada não pode, com uma segurança razoável, ser deduzida e deve estar protegida contra falsificações realizadas através das tecnologias atualmente disponíveis;

c) a chave privada pode ser eficazmente protegida pelo legítimo titular contra a utilização por terceiros.

6.1.1.7. Essa mídia de armazenamento não deve modificar os dados a serem assinados, nem impedir que esses dados sejam apresentados ao signatário antes do processo de assinatura.”

Com relação ao que mais interessa para a análise que ora se procede, qual seja a questão do controle da chave privada, verifica-se que da regra se extrai a norma de que a chave privada deve ter o seu sigilo suficientemente assegurado, bem como deve ser passível de proteção pelo legítimo titular contra a utilização de terceiros. Ora, todos esses requisitos podem ser satisfeitos por mecanismo de segurança adotado, como o HSM, sem que isso se dê obrigatoriamente com a posse física da mídia.

Neste contexto, há que se relembrar que as regras da ICP-Brasil dispõem acerca de três espécies de mídias para o armazenamento da chave privada, estabelecidas em ordem crescente de segurança, quais sejam[25]: 1) repositório cifrado por software; 2) cartão inteligente ou token; e 3) hardware criptográfico (que é o caso do HSM). De modo que o hardware criptográfico está no mais alto nível de segurança dentre as mídias da ICP-Brasil e só por esta razão não poderia ser, de antemão, considerado que as manifestações eletrônicas produzidas com base nesta solução sejam inválidas.

Poder-se-ia argumentar, entretanto, que o item 6.1.1.7 do DOC-ICP-03 exige a homologação do hardware criptográfico perante a ICP-Brasil. Ocorre que mesmo o hardware criptográfico não homologado perante a ICP-Brasil é mais seguro, por exemplo, que o certificado A1, por meio do qual a chave privada pode ser armazenada em repositório protegido por senha e/ou identificação biométrica cifrado por software. Esta possibilidade prevista nas normas da ICP-Brasil constitui evidente vulnerabilidade, pois a chave privada poderá, de acordo com o previsto, ser armazenada no disco rígido de um computador. Ainda assim, não se sustenta que as manifestações eletrônicas que utilizem este tipo de certificado sejam consideradas inválidas.

Portanto, por qualquer prisma que se encare a questão, não se chega à conclusão de que o HSM compartilhado gerará assinaturas inválidas sob o ponto de vista jurídico. A utilização do HSM para o armazenamento de chaves privadas de usuários comuns pode até mesmo ser considerada uma tendência mundial, rumo a um maior dinamismo e funcionalidade (mas sem abrir mão da segurança) no contexto da utilização das assinaturas digitais.

A seguir, arrolamos as principais ideias do presente texto na forma de conclusões.

5 – Conclusões

(a) não se pode confundir o HSM (Hardware Secure Module) compartilhado com o compartilhamento de chaves privadas;

(b) o HSM, na hierarquia das mídias armazenadoras de chaves privadas mais seguras, mesmo no âmbito normativo da ICP-Brasil, ocupa a primeira posição, estando acima do cartão inteligente e do token, bem como acima do dispositivo cifrado por software.

(c) assim, não se pode de antemão afirmar que as manifestações de vontade eletrônicas serão inválidas, sob o ponto de vista jurídico, caso sejam produzidas com base em HSM compartilhado;

(d) a Medida Provisória nº 2.200-2 não criou uma forma especial obrigatória para o meio eletrônico, mas sim um dispositivo legal que equipara a assinatura digital produzida com base em certificado digital ICP-Brasil à assinatura manuscrita;

(e) portanto, não é requisito de validade para o meio eletrônico a utilização do certificado digital ICP-Brasil, pois os dispositivos da Medida Provisória nº 2.200-2, art. 10, §§ 1º e 2º, se situam num sistema de regras mais amplo, onde há a previsão da liberdade de formas e do livre convencimento judicial;

(f) também por essas razões, não se pode, ex ante, decretar a invalidade de manifestações eletrônicas produzidas com base em certificado digital que não seja da ICP-Brasil, bem como de soluções que eventualmente estejam em desacordo com as regras da ICP-Brasil;

(g) todavia, os documentos assinados com base em certificado digital ICP-Brasil desfrutam, isso sim, de um status jurídico probatório diferenciado, estabelecendo uma presunção relativa de autoria e integridade, apta a agregar maior segurança jurídica para os atos e negócios praticados no meio eletrônico, daí a enorme importância da Infraestrutura de Chaves Públicas Brasileira;

(h) o “exclusivo controle, uso e conhecimento” da chave privada de que trata o art. 6º, Parágrafo único, da Medida Provisória nº 2.200-2 não se refere exclusivamente ao controle físico da mídia armazenadora, mas meramente ao poder de controle fático, que pode se estabelecer mesmo à distância, sem o acesso físico à chave privada, desde que o mesmo possa ser realizado de maneira segura e sem o compartilhamento da mídia que a armazena;

(i) a análise dogmática da Medida Provisória nº 2.200-2, bem como das regras da ICP-Brasil não autoriza a que se chegue à conclusão de que a utilização do HSM invalida as manifestações de vontade eletrônicas com base nele assinadas;

(j) para a finalidade de se obter uma segurança jurídica ainda maior, é recomendável a regulação da utilização do HSM homologado na ICP-Brasil.

[1] Disponível em http://www.iti.gov.br.

[2] Estudo não publicado.

[3] Mais precisamente, de acordo com o previsto no art. 2º da EC 32/2001: “Art. 2º As medidas provisórias editadas em data anterior à da publicação desta emenda continuam em vigor até que medida provisória ulterior as revogue explicitamente ou até deliberação definitiva do Congresso Nacional.”

[4] Há que se referir como um dos documentos fundantes do reconhecimento da equivalência funcional a Lei Modelo de Comércio Eletrônico da UNCITRAL, do ano de 1996: “The Model Law thus relies on a new approach, sometimes referred to as the “functional equivalent approach”, which is based on an analysis of the purposes and functions of the traditional paper-based requirement with a view to determining how those purposes or functions could be fulfilled through electronic-commerce techniques. For example, among the functions served by a paper document are the following: to provide that a document would be legible by all; to provide that a document would remain unaltered over time; to allow for the reproduction of a document so that each party would hold a copy of the same data; to allow for the authentication of data by means of a signature; and to provide that a document would be in a form acceptable to public authorities and courts. It should be noted that in respect of all of the above-mentioned functions of paper, electronic records can provide the same level of security as paper and, in most cases, a much higher degree of reliability and speed, especially with respect to the identification of the source and content of the data, provided that a number of technical and legal requirements are met. However, the adoption of the functional-equivalent approach should not result in imposing on users of electronic commerce more stringent standards of security (and the related costs) than in a paper-based environment”, p. 20, UNCITRAL Model Law on Electronic Commerce with Guide to Enactment 1996. Disponível em: http://www.uncitral.org.

[5] Menke, F. Assinatura Eletrônica no Direito Brasileiro, São Paulo: Editora Revista dos Tribunais, 2005, p. 138-139.

[6] As presunções relativas admitem prova em contrário, diferentemente das presunções absolutas.

[7] Há que se acrescentar à presunção de autoria a presunção de integridade da mensagem, ou seja, a de que o seu conteúdo não foi alterado. Esta presunção advém da combinação de dois fatores: 1) utilização da criptografia assimétrica, que proporciona a possibilidade de se tomar conhecimento acerca de eventual alteração do conteúdo do documento e; 2) confirmação positiva de que o documento efetivamente não foi alterado.

[8] Dispositivo com a seguinte redação: “Fica instituída a Infra-Estrutura de Chaves Públicas Brasileira – ICP-Brasil, para garantir a autenticidade, a integridade e a validade jurídica de documentos em forma eletrônica, das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais, bem como a realização de transações eletrônicas seguras“.

[9] Com efeito, determina o artigo 5º da Lei Modelo de Comércio Eletrônico da UNCITRAL: “Article 5. Legal recognition of data messages: Information shall not be denied legal effect, validity or enforceability solely on the grounds that it is in the form of a data message.” No guia para a incorporação da Lei Modelo, consta o seguinte comentário ao artigo 5º: “Article 5 embodies the fundamental principle that data messages should not be discriminated against, i.e., that there should be no disparity of treatment between data messages and paper documents. It is intended to apply notwithstanding any statutory requirements for a “writing” or an original“.

[10] Sobre o conceito de forma especial, ensina Pontes de Miranda: “Diz-se forma especial a forma que o sistema jurídico exige para determinado ato, ou quando se trate de alguma pessoa ou coisa. Só a lei especializa“. Tratado de Direito Privado, Tomo III, Campinas, Bookseller, 2003, p. 394.

[11] A matéria da prova é localizada numa zona de fronteira no direito brasileiro, regulada tanto pelo Código Civil quanto pelo Código de Processo Civil. Conforme ensina Caio Mário da Silva Pereira: “A prova é, na verdade, objeto de disciplina pela lei civil, como pela lei processual. O direito civil define os ‘meios de prova’, enuncia os lineamentos do regime a que se submeterá a comprovação do fato jurídico, natural ou voluntário, e especialmente a declaração de vontade. O direito processual afirma os preceitos que presidem a apreciação da prova em Juízo e a técnica de trazê-la à consciência do julgador. Assim, não cabe ao processo, porém ao direito civil, determinar o requisito formal para a emissão de vontade visando a certo efeito, e via de consequência a condição legal de sua comprovação. Mas não compete ao direito civil, e sim ao processual, adotar ou rejeitar o princípio da liberdade do juiz para decidir segundo a sua convicção íntima, ex informata conscientia, ou segundo o que no correr do litígio for produzido pelos interessados, secundum allegatum et probatum iudex iudicare debet (com conhecimento de causa, o juiz deve julgar de acordo com o que foi alegado e provado)“. Instituições de Direito Civil – Introdução ao Direito Civil: Teoria Geral do Direito Civil. Rio de Janeiro: Forense, 2009, p. 503-504. Ainda sobre a questão da disciplina da prova tanto pelo Código Civil quanto pelo Código de Processo Civil, Clóvis do Couto e Silva salienta que quando da edição do Código Civil de 1916 não havia Código de Processo Civil em vigor no Brasil, daí a necessidade de que um mínimo de segurança jurídica sobre a matéria fosse estabelecida pelo Código que estava sendo editado. Ver em Direito material e processual em tema de prova, Revista de Processo 13, p. 135. A problemática também não escapou da análise de Pontes de Miranda, que defendeu a abordagem da matéria pelo Código Civil sob o fundamento de que o destinatário da prova não é apenas o juiz, uma vez que fora do processo as partes também precisam ser convencidas sobre a credibilidade das provas dos atos e negócios jurídicos que se lhe apresentam. Ob. cit., nota de rodapé nº 10, p. 451. Para uma análise da questão, ver Menke, F., Die elektronische Signatur im deutschen und brasilianischen Recht: Eine Rechtsvergleichende Studie, Baden-Baden: Nomos, 2009, p. 189-190.

[12] Sobre o princípio da forma livre no direito brasileiro, Maria Helena Diniz assevera: “De modo que vige em nosso direito a regra geral de que: qualquer que seja a forma, a emissão de vontade, em princípio, é dotada de poder criador, exceto quando a solenidade integra a substância do negócio“. Curso de direito civil brasileiro, volume 1: teoria geral do direito civil, São Paulo: Saraiva, 2011, p. 541-542.

[13] São eles: “I – agente capaz; II – objeto lícito, possível, determinado ou determinável; III- forma prescrita ou não defesa em lei“.

[14] “Art. 185. Aos atos jurídicos lícitos, que não sejam negócios jurídicos, aplicam-se, no que couber, as disposições do Título anterior“.

[15] A forma especial poderá, isso sim, ser prevista pela legislação marginal que regula os mais diversos atos e negócios a serem celebrados pelo meio eletrônico. Tome-se como exemplo o processo eletrônico. Neste caso, a Lei 11.419, de 2006, determinou as formas possíveis para a prática de atos processuais eletrônicos, fixando que a assinatura digital baseada em certificado digital emitido por Autoridade Certificadora credenciada, na forma de lei específica, poderá ser utilizada (art. 1º, § 2º, III, a). Outro exemplo é o da Lei 11.977, que dispôs, entre outras matérias, sobre a obrigação de os serviços de registros públicos instituírem o sistema de registro eletrônico (art. 37), sendo que os documentos eletrônicos apresentados aos serviços de registros públicos ou por eles expedidos deverão atender aos requisitos da ICP-Brasil (art. 38), o que significa que terão de ser assinados digitalmente com certificado digital obtido no âmbito desta infraestrutura.

[16] Ver, quanto ao ponto, a pergunta 51 e respectiva resposta, no Manual de Perguntas & Respostas Jurídicas/ICP-Brasil, versão 0.0, disponível em http://www.iti.gov.br, clicar em “Publicações” e após em “Manuais”, acesso em 11.10.2012.

[17] Lorenzetti, R. L. Comércio Eletrônico. Tradução de Fabiano Menke. São Paulo: Editora Revista dos Tribunais, 2004, p. 299.

[18] Azevedo, A. J. de. Negócio jurídico: existência, validade e eficácia. 4ª ed. São Paulo: Saraiva, 2002.

[19] Menke, F. Assinatura Eletrônica no Direito Brasileiro, São Paulo: Editora Revista dos Tribunais, 2005, p. 141-142.

[20] Menke, F. Assinatura Eletrônica no Direito Brasileiro, São Paulo: Editora Revista dos Tribunais, 2005, p. 140-141. Os grifos apostos no destaque não estão no original da publicação.

[21] “Parágrafo único. 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.”

[22] Na Alemanha, por exemplo, o assunto em questão já provocou o estudo de técnicos e juristas, uma vez que também as regras da Diretiva Europeia 1999/93 e da Lei de Assinaturas alemã determinam que um dos requisitos da assinatura eletrônica avançada é o controle dos mecanismos de criação da assinatura. Na Alemanha, Alexander Rossnagel e Stefanie Fischer-Dieskau, da Universidade de Kassel, se debruçaram sobre o tema, analisando as denominadas “assinaturas eletrônicas criadas de forma automática” (automatisiert erzeugte elektronische Signaturen), nas quais nem sempre o dispositivo de criação de assinaturas está na posse física do titular do par de chaves. Neste trabalho, chegaram à conclusão de que as assinaturas automáticas podem satisfazer o requisito do “controle exclusivo”, desde que sejam utilizados mecanismos seguros de exclusão de terceiros do acesso à chave privada. Trata-se do artigo Automatisiert erzeugte elektronische Signaturen, publicado na Revista Multimedia und Recht, 2004, p. 133- 139.

[23] É o que se depreende do art. 7º da MP 2.200-2: “às AR, entidades operacionalmente vinculadas a determinada AC, compete identificar e cadastrar usuários na presença destes, encaminhar solicitações de certificados às AC e manter registros de suas operações”.

[24] Para o texto integral do DOC-ICP-03, conferir em http://www.iti.gov.br, acessando “legislação” e “documentos principais”.

[25] Conforme tabela 4 constante do item 6.1.1.7 do DOC-ICP-03.

Fonte: PKIconsulting Blog › PKIconsulting

O Blog apresenta sempre novidades sobre certificação digital. Conheça e divulgue.

* Viviane Bertol e Fabiano Menke

Posted on 02/03/2014

O post Uso de HSM para guarda de certificados digitais – Por Viviane Bertol e Fabiano Menke apareceu primeiro em CRYPTOID. http://ift.tt/2nG2fwg http://ift.tt/2aM8QhC

Sobre uso de HSM para guarda de certificados digitais – Por Viviane Bertol e Fabiano Menke | CRYPTOID

Uso de HSM para guarda de certificados digitais – Por Viviane Bertol e Fabiano Menke Regina Tupinambá

Devem ser consideradas inválidas, sob a ótica jurídica, as assinaturas digitais apostas com base em chave privada armazenada em HSM hardware secure module?

Por Viviane Bertol e Fabiano Menke

O presente artigo foi escrito no mês de novembro de 2012. Em 12.02.2014, a Procuradoria Federal Especializada do Instituto Nacional de Tecnologia da Informação veiculou Nota Pública em que registrou: “Em revisão de seu posicionamento anterior, externado em nota pública datada de 03 de outubro de 2012, não se pode afirmar, antecipadamente, que assinaturas digitais de pessoas físicas providas por meio de certificados armazenados em soluções mercadológicas de uso compartilhado de HSM (Hardware Secure Module), em modelo de rede, seja inválida“. Para a íntegra da Nota Pública de 12.02.2014, acessar: http://ift.tt/2nFVzOB

Fabiano Menke

Professor da Faculdade de Direito da Universidade Federal do Rio Grande do Sul. Doutor em Direito pela Universidade de Kassel, Alemanha. Mestre em Direito pela Universidade Federal do Rio Grande do Sul. Autor dos livros Die elektronische Signatur im deutschen und brasilianischen Recht: Eine rechtsvergleichende Studie, publicado pela Editora Nomos, na Alemanha, em 2009, e A Assinatura Eletrônica no Direito Brasileiro, publicado pela Editora Revista dos Tribunais, em 2005.

Viviane Bertol

Consultora em certificação digital, com Mestrado e Doutorado nessa área pela Universidade de Brasília. Trabalhou no Instituto Nacional de Tecnologia da Informação (ITI) na Coordenadoria-Geral de Auditoria e Fiscalização e Coordenadoria-Geral de Normalização e Pesquisa, tendo participado da elaboração de metodologias de auditoria e realizado auditorias em Autoridades de Registro e Autoridades Certificadoras. Participou da elaboração de diversos normativos da ICP-Brasil.

Sumário: 1- Introdução; 2- O funcionamento dos Hardware Secure Module (HSM); 3 – A questão da validade jurídica no âmbito da ICP-Brasil; 4 – O controle da chave privada no âmbito da Medida Provisória nº 2.200-2 e das regras da ICP-Brasil; 5 – Conclusões.

1- Introdução

Em 03.10.2012 o Instituto Nacional de Tecnologia da Informação exarou Notificação Pública com o seguinte teor[1]:

“A geração e a guarda da chave privada de pessoa física em HSM (Hardware Secure Module), compartilhado por outras pessoas físicas (modelo de rede, com o HSM controlado por um servidor), contraria o padrão ICP-Brasil, de forma que as manifestações eletrônicas que utilizem essa solução não terão validade jurídica, haja vista que a Medida Provisória nº 2.200-2, de 24 de agosto de 2001, em seu art. 6º, parágrafo único, é expressa:

Art.6º(…).

Parágrafo único. 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.

Logo, a validade jurídica da assinatura digital ICP-Brasil encontra-se condicionada à tutela exclusiva da chave privada pelo seu titular, fato esse inocorrente acaso se utilize a solução de HSM como um centralizador de diversas chaves privadas de pessoas físicas, haja vista que o controle, uso e conhecimento exclusivo da chave privada pelo seu titular é requisito imprescindível para a segurança das manifestações eletrônicas e a sua consequente validade jurídica.”

Ou seja, de acordo com a Notificação Pública, não terão validade jurídica os documentos eletrônicos assinados com base em chave privada armazenada nos denominados HSM (Hardware Secure Module, que vem sendo traduzido para o português como “módulo criptográfico de segurança”), quando este (o HSM) for compartilhado, ou seja, quando mais de uma pessoa tenha a sua chave privada gravada no mesmo HSM.

A seguir, faremos uma análise da referida Notificação Pública, confrontando-a com a Medida Provisória nº 2.200-2 e com as normas pertinentes da ICP-Brasil (resoluções do Comitê Gestor e demais regras) a fim de chegarmos a uma conclusão de se é correto afirmar que os denominados HSMs compartilhados efetivamente gerarão assinaturas digitais inválidas sob o ponto de vista jurídico.

A fim de responder esse questionamento, descreveremos o funcionamento do HSM compartilhado (2); analisaremos a questão a partir do exame da validade jurídica do documento eletrônico assinado digitalmente (3); passando pelo aspecto do controle da chave privada de acordo com o disposto na Medida Provisória 2.200-2 e nas regras da ICP-Brasil (4) e finalizaremos com a conclusão (5).

2. O Funcionamento dos HSMs

2.1 Introdução

A sigla HSM significa “Hardware Security Module” ou, em Português, Módulo de Segurança Criptográfica (MSC).

Um HSM é um dispositivo de criptografia baseado em hardware, fisicamente seguro e resistente à violação, que fornece funcionalidades criptográficas com capacidade de geração e armazenamento de chaves criptográficas simétricas e assimétricas voltadas para utilização em uma Infraestrutura de Chaves Públicas (ICP).

Um HSM gera, armazena e protege chaves criptográficas e geralmente fornece aceleração de hardware para operações criptográficas. Pode se constituir de um dispositivo independente ou apenas de uma placa auxiliar. Nesse último caso, atende unicamente ao servidor em que está instalado. Caso seja um dispositivo independente, um HSM pode atender a diversos servidores, via rede, dependendo de seu modelo e da forma como foi configurado.

Para prover segurança às chaves criptográficas e parâmetros críticos nele armazenados, um HSM mantém conformidade com padrões de construção de hardware, levando em consideração os mais diversos ataques possíveis. Exemplos de padrões são:

FIPS PUB 140-2 (publicado pelo governo americano)

ITSEC Common Criteria (ISO/IEC 15408) (baseado no padrão europeu ITSEC para avaliação de segurança de produtos e sistemas)

Manuais de Condutas Técnicas 7 (MCT-7) da ICP-Brasil (publicado pelo Instituto Nacional de Tecnologia da Informação)

Esses padrões estabelecem requisitos de conformidade e classificam os equipamentos em níveis crescentes, levando em consideração projeto, especificação, ambiente operacional, contenções de ataques e procedimentos de autenticação.

2.2 Utilização de HSMs na ICP-Brasil

A ICP-Brasil admite a utilização de HSMs e de outros dispositivos criptográficos, como cartões ou tokens, para a geração e guarda de chaves de titulares de certificados do tipo A3, A4, S3 e S4, desde que tais dispositivos estejam homologados na ICP-Brasil (ver documento Padrões e Algoritmos Criptográficos da ICP-Brasil (DOC ICP-01.01) – Versão 2.3 de 06 de julho de 2012):

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 (DOC-ICP-10) – Versão 3.0 de 27 de setembro de 2012.

Segundo aquele documento, a homologação tem por objetivo “asseverar a plena aderência dos sistemas e equipamentos avaliados aos padrões e especificações técnicas mínimos estabelecidos nas normas editadas ou adotadas pela ICP-Brasil, tendo como enfoque específico a garantia da interoperabilidade desses sistemas e equipamentos e a confiabilidade dos recursos de segurança da informação por eles utilizados.“

Os sistemas e equipamentos homologados devem atender aos requisitos técnicos definidos nos Manuais de Conduta Técnica (MCT) elaborados pelo Instituto Nacional de Tecnologia da Informação (ITI).

Para obter a homologação o fabricante ou outra parte interessada solicita a avaliação do dispositivo criptográfico a um laboratório acreditado, municiando-o de documentação e exemplares do dispositivo, para avaliação e testes. Caso o produto atenda ao disposto no MCT respectivo, a homologação é concedida e publicada no Diário Oficial da União.

Uma relação completa dos dispositivos homologados é mantida na página http://ift.tt/2nUMpLx

No caso específico de HSMs, aplica-se o MCT 7 – Volume I – Requisitos, Materiais e Documentos Técnicos para Homologação de Módulos de Segurança Criptográfica (MSC) no Âmbito da ICP-Brasil – versão 1.0 – São Paulo, 23 de novembro de 2007.

Segundo o MCT-7:

“O objetivo do processo de homologação do módulo de segurança criptográfico é propiciar a interoperabilidade e operação segura do serviço criptográfico ICP oferecido por um módulo de segurança criptográfico por meio da avaliação técnica de aderência aos requisitos técnicos definidos para este processo.”

…..

“O processo de homologação é baseado em um conjunto de requisitos técnicos que devem ser atendidos por um módulo de segurança criptográfico para garantia da interoperabilidade e operação segura.

Esses requisitos técnicos são avaliados segundo ensaios de aderência aos requisitos técnicos. Para a realização dos ensaios, a parte interessada deve submeter ao processo de homologação um conjunto de materiais requisitados, através de um procedimento denominado depósito de material.”

Segundo o MCT-7, os HSMs utilizados na ICP-Brasil devem atender a requisitos técnicos relativos às seguintes áreas:

Documentação do módulo criptográfico

Identificação de portas e interfaces do módulo criptográfico

Nível de identificação de papéis, serviços e autenticação do operador

Descrição do modelo de estado finito

Nível de segurança física

Ambiente operacional

Gerenciamento de chaves criptográficas

Interferência e compatibilidade eletromagnética

Auto-testes

Garantia do projeto

Mitigação de outros ataques

Algoritmos criptográficos obrigatórios

Gerenciamento

Interoperabilidade

Restrição de substâncias nocivas.

Para o estudo ora em foco, ou seja, para avaliar se é viável a utilização de um HSM para armazenamento de chaves privadas de diferentes titulares de certificados, vamos analisar alguns desses requisitos, a saber:

Nível de identificação de papéis, serviços e autenticação do operador

O MCT 7 prevê diferentes papéis para acesso a um HSM:

“REQUISITO III.3.3: [FIPS 140-2, 4.3.1] O módulo criptográfico deve suportar, no mínimo, os seguintes “papéis autorizados”:

– Oficial de segurança (SO): Necessário para realizar funções de gerenciamento, inicialização, distribuição e fechamento de acesso ao módulo.

– Usuário: Necessário para realização de serviços de segurança oferecidos pelo módulo depois de sua inicialização, incluindo operações criptográficas, criação de chaves criptográficas, o uso do sistema de arquivos, sobrescrita do valor de chaves criptográficas com zeros binários (key zeroization), etc….. “

Com relação ao papel de usuário, especifica o MCT os seguintes requisitos:

“3.3.1.1 Papel de acesso Usuário

REQUISITO III.3.6: Funcionalidades atribuídas ao papel de acesso “Usuário” devem incluir:

Manipulação (leitura, escrita, criação e remoção) de chaves criptográficas e PCS no módulo criptográfico;

Acesso às funcionalidades de segurança, como por exemplo: autenticação, transferência segura de mensagens por meios eletrônicos (secure messaging), criptografia, decifração, assinaturas digitais, geração de resumos criptográficos (hashing) e códigos MAC, etc;

Geração de chaves RSA;

Requisição de informações de estado do módulo criptográfico.”

Do acima visto, conclui-se que é possível a utilização do HSM por diferentes usuários e que esses usuários podem e realizar funções geração de chaves criptográficas e assinatura digital .

Ambiente Operacional

Entre as definições e requisitos sobre o ambiente operacional do HSM, constantes no MCT-7, destacamos o que segue:

“DEFINIÇÃO III.6.1: Caminho confiável (Trusted path): um caminho protegido entre o operador e o MSC com o qual ambos acreditam que estejam interagindo. Um caminho confiável reflete um canal protegido. O software malicioso que se injeta neste caminho pode ser identificado.

Um caminho confiável pode ser visto como um mecanismo que fornece autenticidade entre o operador e o módulo criptográfico, garantindo que ataques não consigam interceptar ou modificar informações sendo transmitidas no caminho.

REQUISITO III.6.8: [FIPS 140-2 nível 2, 4.6] Todas as chaves criptográficas e PCSs, dados de autenticação, entradas de controle e saídas de status devem comunicar através de um mecanismo confiável que utilize portas físicas de I/O dedicadas ou caminho confiável.

RECOMENDAÇÃO III.6.1: [FIPS 140-2 nível 2, 4.6] Acrescentando os requisitos de auditoria, os seguintes eventos devem ser armazenados por mecanismos de auditoria:

– Tentativa de usar uma função de caminho confiável (read, write, open e close);

– identificação da origem e do destino de um caminho confiável.”

Do texto acima, concluímos que o HSM pode ser operado via rede, desde que seja utilizado um caminho confiável para a comunicação e seja feito registro dessa operação, incluindo a identificação da sua origem e destino.

Gerenciamento de Chaves

Segundo o MCT-7, os HSMs devem atender a diversos requisitos de gerenciamento de chaves, entre eles:

“REQUISITO III.7.1: [FIPS 140-2, 4.7] Chaves secretas, chaves assimétricas privadas e PCSs devem estar protegidas dentro do módulo contra divulgação, modificação e substituição não autorizada.”

….

REQUISITO III.7.23: Deve ser possível configurar no módulo criptográfico com atributo não exportável uma chave criptográfica assimétrica privada, para fins de assinatura digital, compatível com certificados digitais ICP-Brasil de tipo A3 ou A4. Uma vez definido tal atributo como não exportável, não deve ser possível alterar seu valor para exportável.

REQUISITO III.7.26: [FIPS 140-2, 4.7.5] Chaves criptográficas devem ser armazenadas dentro do módulo criptográfico em texto claro ou de forma cifrada.

REQUISITO III.7.27: [FIPS 140-2, 4.7.5] Chaves privadas e secretas em texto claro não devem ser acessíveis por operadores não autorizados.

REQUISITO III.7.28: [FIPS 140-2, 4.7.5] O módulo criptográfico deve associar a cada chave (simétrica ou assimétrica) armazenada o seu respectivo operador (pessoa, grupo, processo, servidor, etc).

REQUISITO III.7.29: [FIPS 140-2, 4.7.5] A documentação deve especificar os métodos de armazenamento de chaves criptográficas empregados pelo módulo.

Do acima visto, conclui-se que é possível utilizar um HSM homologado na ICP-Brasil para criar e armazenar chaves criptográficas de diferentes usuários, desde que atendidos os requisitos de segurança previstos para esses processos.

Analisando os aspectos técnicos acima levantados, conclui-se que o próprio Instituto Nacional de Tecnologia da Informação prevê, em seus regramentos, que um HSM homologado pode ser utilizado por mais de um usuário para gerar e armazenar chaves privadas e realizar assinatura digital, desde que sejam observados requisitos de segurança apropriados, entre os quais a autenticação dos usuários, a utilização de um caminho confiável entre o operador e o módulo criptográfico, o registro de eventos apropriados para auditoria e a adoção de cuidados para geração, importação, exportação e armazenamento das chaves.

Considere-se ainda que um HSM é um equipamento bastante caro e sua utilização por um único usuário seria economicamente pouco justificável, na maior parte dos casos, fato esse que é reforçado pela observação de que mesmo autoridades certificadoras da ICP-Brasil utilizam HSMs compartilhados para a geração e armazenamento de suas chaves privadas, por motivos econômicos.

Aqui vai, portanto, uma importante observação: não há compartilhamento algum de chave privada, pois isso colidiria frontalmente com as normas da ICP-Brasil. O que efetivamente ocorre é o compartilhamento do HSM, sem a possibilidade de que qualquer pessoa ou recurso computacional tenha acesso à chave privada. Eventuais soluções de HSM baseadas em compartilhamento da chave privada, que são tecnicamente possíveis e existem, sequer serão consideradas nesta análise, por não serem compatíveis, nem com a Medida Provisória nº 2.200-2 e nem com as demais normas da ICP-Brasil.

2.4 – O funcionamento dos Hardware Security Modules (HSM)

Uma das formas utilizadas pelos fabricantes de HSM para separar de forma segura as chaves privadas de diferentes usuários é compartimentá-las em partições lógicas, cada qual com acesso segregado.

Nesse caso, o que se tem é o funcionamento do HSM de forma bastante similar a um conjunto de cartões ou tokens, suportando, cada um desses cartões ou tokens uma partição ou compartimento autônomo, controlado, cada qual, por um detentor diferente, que comprova a sua identidade para acessar a chave privada por meio de um PIN ou senha.

De estudo específico sobre o funcionamento de HSM compartilhado com base em partições, realizado por Jeandré Sutil[2], podemos destacar os seguintes trechos:

“Diferentemente de um token ou cartão, entretanto, o HSM possui controles de segurança mais restritivos contra tentativas de acesso indevido às chaves armazenadas em seu interior, como sensores de luminosidade, variação de tensão, dentre outros dispositivos que visam a evidenciar e destruir os dados sensíveis, ao menor sinal de uma tentativa de intrusão.

Tendo essa arquitetura em vista, os procedimentos para a emissão de um certificado são:

1) Uma nova partição é criada para o usuário no interior do HSM. Nesse momento, é gerado o PIN de conhecimento exclusivo do usuário, para acesso e criação de objetos em sua partição do HSM;

2) O usuário, quando quiser solicitar a emissão de um certificado, deverá se autenticar com seu PIN em sua partição, solicitar a geração de seu par de chaves e a exportação de sua requisição (CSR);

3) Com essa requisição em mãos, o usuário acessará o sistema da AC e concluirá a solicitação de seu certificado digital;

4) O usuário encaminhar-se-á até uma AR, para validação de seus documentos e assinatura de um termo de titularidade, em que atesta que sua chave foi gerada em um dispositivo criptográfico, como é exigência para um certificado do tipo A3;

5) Com a validação finalizada e o certificado emitido, o usuário volta a acessar o sistema da AC e efetua o download de seu certificado digital;

6) O usuário novamente se autentica junto a sua partição no HSM, informando o PIN, dessa vez para importar seu certificado digital.

Não há nenhuma inovação nos passos acima descritos, pois são exatamente os executados na emissão de um certificado em token. Cada usuário será o único capaz de gerar e utilizar um par de chaves criptográficas armazenado no compartimento de sua propriedade. Para fazer uma assinatura digital, o usuário precisará necessariamente informar o PIN para liberar o uso de sua chave.”

Da descrição do funcionamento de um HSM compartilhado, se verifica que é perfeitamente possível a observância dos requisitos de segurança que permitam o armazenamento de chaves privadas no âmbito da ICP-Brasil. É plenamente possível que apenas o HSM seja compartilhado, sem que o mesmo ocorra com a respectiva chave privada do usuário, pois esta sim deverá estar sob o exclusivo controle do titular do par de chaves criptográficas.

Após uma melhor compreensão do funcionamento do HSM compartilhado, perquiriremos a seguir se as assinaturas digitais geradas a partir deste equipamento sempre serão consideradas inválidas sob o ponto de vista jurídico.

3 – A questão da validade jurídica no âmbito da ICP-Brasil

Primeiramente, e antes de entrar no mérito de se as assinaturas geradas com base no HSM serão sempre consideradas inválidas, há que se fazer uma breve digressão sobre a questão da validade jurídica em si das assinaturas digitais no âmbito da legislação brasileira. Como se sabe, a questão do valor jurídico da assinatura digital foi regrada pela Medida Provisória nº 2.200-2, de 2001, que permanece em vigor, em virtude da edição da Emenda Constitucional nº 32/2001[3]. De acordo com o Art. 10, §1°, da Medida Provisória nº 2.200-2: “As declarações constantes dos documentos em forma eletrônica produzidos com a utilização de processo de certificação disponibilizado pela ICP-Brasil presumem-se verdadeiros em relação aos signatários, na forma do art. 131 da Lei nº 3.071, de 1º de janeiro de 1916 – Código Civil.”

Este dispositivo legal realiza o que se chama de equivalência funcional[4], reconhecendo a equiparação jurídica entre a assinatura manuscrita e a assinatura digital aposta com os meios técnico-organizacionais disponibilizados pela ICP-Brasil.

Como já tivemos a oportunidade de registrar[5], o artigo 131 do Código Civil de 1916, com correspondência exata ao que dispõe o artigo 219 do Código Civil de 2002, ao prever que serão consideradas verdadeiras em relação ao signatário as declarações assinadas, tem por finalidade atribuir uma presunção relativa[6] de autoria às mensagens assinadas de próprio punho.

Ao transpor este dispositivo para o meio eletrônico, a Medida Provisória nº 2.200-2 atribuiu presunção (também relativa) de autoria ao documento eletrônico assinado com certificado digital da ICP-Brasil[7]. Por mais que a Medida Provisória nº 2.200-2 tenha, em seu artigo 1º, feito referência ao escopo de garantir “a validade jurídica” dos documentos em forma eletrônica[8], esta “garantia da validade jurídica” significa primordialmente o intuito de afastar entendimentos que discriminem as manifestações de vontade exaradas pelo meio eletrônico, pelo simples fato de terem sido produzidas neste meio. É o reconhecimento do postulado que no âmbito da UNCITRAL leva a nomenclatura de princípio da não-discriminação[9]. A Medida Provisória nº 2.200-2 não pretendeu reservar para o seu regramento, ou para os mecanismos de atribuição de autoria que prevê, a exclusividade do atributo de validade. Em outras palavras, a Medida Provisória nº 2.200-2 não determina que ou bem se observe os requisitos da ICP-Brasil, ou se estará diante de invalidade.

Até porque, não se pode perder de vista o contido no §2º do art. 10 da Medida Provisória nº 2.200-2, segundo o qual: ”O disposto nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento“. Este dispositivo tem o intuito de flexibilizar a referida regra do §1º, esclarecendo que as partes têm a liberdade de escolher outros meios de atribuição de autoria que não a assinatura digital ICP-Brasil.

A Medida Provisória nº 2.200-2, portanto, não criou uma forma especial[10] obrigatória para o meio eletrônico. E mais, sua disciplina sobre forma e prova dos atos e negócios jurídicos se situa no âmbito do disciplinado no Código Civil, que determina, em seu art. 107, que “A validade da declaração de vontade não dependerá de forma especial, senão quando a lei expressamente a exigir“. Não se verifica no seu texto esta “avocação” da forma especial para os procedimentos de atribuição de autoria da ICP-Brasil, muito pelo contrário, justamente em virtude do § 2º do art. 10.

Acrescente-se a isso a existência de outras regras, tanto do Código Civil quanto do Código de Processo Civil[11], que disciplinam a questão da prova e de sua valoração, e que estão em consonância com os princípios da liberdade de formas[12] e da livre apreciação das provas, como o art. 332 deste último diploma legal, que determina: “Todos os meios legais, bem como os moralmente legítimos, ainda que não especificados neste Código, são hábeis para provar a verdade dos fatos, em que se funda a ação ou a defesa“.

Examine-se ainda os requisitos de validade do negócio jurídico, previstos nos três incisos do art. 104 do Código Civil[13], observando-se que os mesmos requisitos são aplicados ao ato jurídico, conforme determina o art. 185 do Código Civil[14]. No que interessa à questão em exame, qual seja a forma, se vê que o inciso III do art. 104 do Código Civil prevê que a forma é um requisito de validade do negócio e do ato jurídico, no sentido de que deve ser observada a forma prescrita em lei e evitada a forma proibida por dispositivo legal. Mas note-se que os requisitos gerais de validade do art. 104 remetem à lei, que poderá ou não prescrever forma especial. E, como se viu, essa forma especial não foi prevista pela Medida Provisória nº 2.200-2[15].

Em assim sendo, não se podem considerar corretas assertivas no sentido de que os métodos de atribuição de autoria que não estiverem de acordo com as regras da ICP-Brasil serão considerados inválidos tout court, como o faz a Notificação Pública do Instituto Nacional de Tecnologia da Informação. Analisada sobre outro enfoque, e ainda que não refira expressamente, a assertiva também traz a ideia de plenitude, no sentido de que a assinatura digital ICP-Brasil faria prova plena da autoria da declaração de vontade, apta a atribuir uma certeza praticamente inabalável quanto à autoria e a integridade da mensagem eletrônica. Neste contexto, o Manual de Perguntas & Respostas Jurídicas da ICP-Brasil[16] registra: “Apenas o certificado da ICP-Brasil, e nenhum outro, gera a certeza da validade jurídica do documento eletrônico, pois se sabe, com garantia legal (MP 2.200-2/01, art. 1º), quem assinou (autenticidade) e que o documento não sofre modificação entre o emissor e seu destinatário (integridade)“.

Esta afirmativa atribui ao certificado digital ICP-Brasil, e ao documento eletrônico assinado com base neste certificado, uma certeza que a rigor não se pode extrair dos dispositivos legais examinados da Medida Provisória nº 2.200-2. Ao mencionar a “certeza”, dá a entender o aludido Manual que mesmo assinando o documento com o certificado ICP-Brasil jamais haverá possibilidade de impugnação. Em outro trecho da resposta à pergunta 51, apesar de conceder que ainda que mais inseguros, outros certificados digitais que não os da ICP-Brasil podem ser utilizados, faz a seguinte colocação sobre a possibilidade de impugnação quanto a vícios da vontade dos documentos assinados digitalmente com base nestes certificados: “Isso porque o interessado em utilizá-los fica a depender da aceitação do outro contratante e, uma vez dada, ainda pode ser impugnada judicialmente, sob a alegação, por exemplo, de qualquer vício de consentimento (coação, erro)“. Pela leitura do trecho transcrito, chega-se à conclusão, a contrario sensu, de que o documento eletrônico assinado digitalmente com base em certificado digital ICP-Brasil não é suscetível às hipóteses de anulação previstas na Parte Geral do Código Civil em virtude de vício da vontade.

Com a devida vênia, a esta conclusão não se pode chegar. É que nem a Medida Provisória nº 2.200-2, nem a técnica que ela reconhece, a criptografia assimétrica, alteraram e jamais teriam a pretensão de alterar a disciplina do Código Civil relativa à possibilidade de invalidação das declarações de vontade viciadas por erro, dolo ou coação. É verdade que a utilização do meio eletrônico, de modo geral, pode dificultar ainda mais a já difícil comprovação dos vícios da vontade, tendo em vista que a manifestação da vontade por esta via, como regra geral, é realizada pelos contratantes de forma isolada, sem a presença de outras pessoas que poderiam figurar como testemunhas para comprovarem os vícios. Ricardo Lorenzetti chega a falar na denominada irrelevância dos estados subjetivos para o meio eletrônico[17]. Mas não se pode chegar ao ponto de afirmar que não é mais possível fazer valer a tradicional dogmática dos defeitos dos atos e negócios jurídicos no meio eletrônico. E isso porque a vontade do declarante (livre de vícios), mesmo após a edição do Código Civil de 2002, continua ocupando um local de destaque na teoria do negócio jurídico, como bem assevera Antônio Junqueira de Azevedo, ao comentar a disciplina do erro[18]: “É no capítulo do erro que mais intensamente se vê a influência da vontade sobre a declaração.“.

Relacionado a este assunto, já tivemos a oportunidade de registrar, ao comentar sobre o denominado não-repúdio, e a possibilidade de impugnar documentos eletrônicos assinados digitalmente, mesmo com base em certificado da ICP-Brasil, que: “o não-repúdio de origem é uma presunção relativa de que aquele que assinou digitalmente, a princípio, estará vinculado à declaração de vontade manifestada. Por ser uma presunção relativa ou juris tantum, é possível a prova em contrário. Por exemplo, o suposto autor da manifestação de vontade poderá provar que foi coagido a assinar determinado documento eletrônico, e, assim, fazer cessar a presunção de autoria. Todavia, tudo dependerá da análise do conjunto probatório, e se o caso chegar ao Poder Judiciário, o magistrado competente deverá investigar fatos como, se após cessada a coação, o coagido tomou as devidas cautelas para comunicar ao destinatário da mensagem sobre o ocorrido, a fim de paralisar eventual execução contratual (comunicando até mesmo a necessidade de revogação do certificado perante a autoridade certificadora). Enfim, existem infinitas possibilidades de combinação de fatos que deverão ser analisados com prudência e cuidado pelo juiz.[19]”

O diferencial da assinatura digital da ICP-Brasil em nossa ótica, não é o atributo de uma pretensa validade exclusiva e absoluta para o meio eletrônico, mas sim o de efeitos jurídico-probatórios diferenciados que o documento eletrônico comum não dispõe. Consoante o já observado:

“Em decorrência, no direito brasileiro, via de regra, só terá os mesmos efeitos da assinatura manuscrita aquela assinatura digital aposta com base em certificado digital emitido por uma das autoridades certificadoras credenciadas pelo Instituto Nacional de Tecnologia da Informação, entidades que têm a obrigação de cumprir com todos os requisitos técnicos, administrativos, operacionais e jurídicos elencados nas normas da ICP-Brasil”.[20]

A questão se resolve, portanto, no plano da eficácia e não da validade. Esses efeitos jurídico-probatórios diferenciados da ICP-Brasil agregam um maior poder de convencimento sobre a autoria e a integridade do documento eletrônico, portanto uma segurança jurídica muito mais robusta, ao dificultar sobremaneira (mas não impossibilitar de todo) as alegações de ausência de autoria.

Em vista do exposto, ainda que abaixo se chegue à conclusão de que as assinaturas digitais apostas com base em chave privada localizada em HSM violam as regras da ICP-Brasil, não se pode concluir como o fez a Notificação Pública do Instituto Nacional de Tecnologia da Informação, que dá conta de que as manifestações eletrônicas que utilizem essa solução não terão validade jurídica. Ainda assim, e após o exame acerca do tema validade jurídica das assinaturas digitais, cumpre questionar se o denominado HSM efetivamente viola as normas da ICP-Brasil. É o que faremos a partir do próximo item.

4 – O controle da chave privada no âmbito da MP 2.200-2 e das regras da ICP-Brasil

O fundamento central da Notificação Pública exarada pelo Instituto Nacional de Tecnologia da Informação reside na alegação de que o HSM viola o disposto no art. 6º, Paragrafo único, da Medida Provisória nº 2.200-2[21]. É a expressão contida na parte final do suporte fático da regra que dá conta de que a chave privada será do exclusivo controle, uso e conhecimento do titular do par de chaves.

O intuito da regra é evidente, qual seja o de vedar soluções técnicas em que outras pessoas tenham o controle, utilizem e conheçam a chave privada do titular. De acordo com a Notificação Pública, “a validade jurídica da assinatura digital ICP-Brasil encontra-se condicionada à tutela exclusiva da chave privada pelo seu titular, fato esse inocorrente acaso (sic) se utilize a solução de HSM“

Primeiramente, há que se considerar que a Notificação Pública em exame parte do pressuposto de que a solução de HSM não está de acordo com o requisito que denomina de “tutela exclusiva da chave privada pelo seu titular”. Todavia, há que se diferenciar aqui o controle, uso e conhecimento exclusivos do titular da chave privada de assinatura, conforme o suporte fático do Parágrafo único do art. 6º da Medida Provisória nº 2.200-2, do que poderia se entender por controle físico, ou posse física da chave privada. A toda evidência, a interpretação que a Notificação Pública faz do referido dispositivo é no sentido de que o titular da chave privada deve obrigatoriamente ter a posse física da chave privada.

Porém, não parece ser essa a melhor exegese da expressão “controle, uso e conhecimento exclusivos” da chave privada. Isso porque, ao utilizar o substantivo “controle”, a Medida Provisória nº 2.200-2 não disse textualmente, nem quis dizer, que esse controle só poderá ser exercido mediante a posse física da mídia onde está armazenada a chave privada[22]. Fosse essa a intenção da regra, certamente teria sido eleita expressão que não deixasse margem para dúvidas, como fez outro dispositivo da própria Medida Provisória nº 2.200-2, no que diz respeito à identificação do indivíduo, que só pode ser feita mediante a presença deste[23], o que, necessariamente será apenas atendido mediante a presença física do interessado em obter o certificado digital.

Como o dispositivo em questão não contempla expressões como “posse física” ou “controle físico”, poderão satisfazer as exigências do suporte fático todas aquelas soluções que viabilizem o controle, acesso e conhecimento exclusivo do par de chaves por seu titular. Enquadra-se neste conceito, inclusive, o HSM compartilhado que seja de tal forma concebido, que permita o controle exclusivo pelo titular da chave privada, ainda que este tenha apenas acesso remoto, mas de forma segura, ao dispositivo.

Daí decorre a conclusão no sentido de que a Medida Provisória nº 2.200-2 não veda a utilização do HSM. Bem pelo contrário, ao valer-se da expressão “controle” abre a possibilidade para que não apenas o controle físico sobre a mídia que armazena a chave privada seja permitido, mas também o controle realizado à distância: um poder de controle fático.

Da mesma forma, quando se recorre às regras infralegais no âmbito da ICP-Brasil, aprovadas pelo Comitê Gestor, não se vislumbra uma vedação à possibilidade de utilização do HSM. Note-se, por exemplo, os requisitos técnicos para a mídia de armazenamento da chave privada, contidos no item 6.1.1.6, do DOC-ICP-03[24]:

“6.1.1.6. A mídia de armazenamento da chave privada deverá assegurar, por meios técnicos e procedimentais adequados, no mínimo, que:

a) a chave privada é única e seu sigilo é suficientemente assegurado;

b) a chave privada não pode, com uma segurança razoável, ser deduzida e deve estar protegida contra falsificações realizadas através das tecnologias atualmente disponíveis;

c) a chave privada pode ser eficazmente protegida pelo legítimo titular contra a utilização por terceiros.

6.1.1.7. Essa mídia de armazenamento não deve modificar os dados a serem assinados, nem impedir que esses dados sejam apresentados ao signatário antes do processo de assinatura.”

Com relação ao que mais interessa para a análise que ora se procede, qual seja a questão do controle da chave privada, verifica-se que da regra se extrai a norma de que a chave privada deve ter o seu sigilo suficientemente assegurado, bem como deve ser passível de proteção pelo legítimo titular contra a utilização de terceiros. Ora, todos esses requisitos podem ser satisfeitos por mecanismo de segurança adotado, como o HSM, sem que isso se dê obrigatoriamente com a posse física da mídia.

Neste contexto, há que se relembrar que as regras da ICP-Brasil dispõem acerca de três espécies de mídias para o armazenamento da chave privada, estabelecidas em ordem crescente de segurança, quais sejam[25]: 1) repositório cifrado por software; 2) cartão inteligente ou token; e 3) hardware criptográfico (que é o caso do HSM). De modo que o hardware criptográfico está no mais alto nível de segurança dentre as mídias da ICP-Brasil e só por esta razão não poderia ser, de antemão, considerado que as manifestações eletrônicas produzidas com base nesta solução sejam inválidas.

Poder-se-ia argumentar, entretanto, que o item 6.1.1.7 do DOC-ICP-03 exige a homologação do hardware criptográfico perante a ICP-Brasil. Ocorre que mesmo o hardware criptográfico não homologado perante a ICP-Brasil é mais seguro, por exemplo, que o certificado A1, por meio do qual a chave privada pode ser armazenada em repositório protegido por senha e/ou identificação biométrica cifrado por software. Esta possibilidade prevista nas normas da ICP-Brasil constitui evidente vulnerabilidade, pois a chave privada poderá, de acordo com o previsto, ser armazenada no disco rígido de um computador. Ainda assim, não se sustenta que as manifestações eletrônicas que utilizem este tipo de certificado sejam consideradas inválidas.

Portanto, por qualquer prisma que se encare a questão, não se chega à conclusão de que o HSM compartilhado gerará assinaturas inválidas sob o ponto de vista jurídico. A utilização do HSM para o armazenamento de chaves privadas de usuários comuns pode até mesmo ser considerada uma tendência mundial, rumo a um maior dinamismo e funcionalidade (mas sem abrir mão da segurança) no contexto da utilização das assinaturas digitais.

A seguir, arrolamos as principais ideias do presente texto na forma de conclusões.

5 – Conclusões

(a) não se pode confundir o HSM (Hardware Secure Module) compartilhado com o compartilhamento de chaves privadas;

(b) o HSM, na hierarquia das mídias armazenadoras de chaves privadas mais seguras, mesmo no âmbito normativo da ICP-Brasil, ocupa a primeira posição, estando acima do cartão inteligente e do token, bem como acima do dispositivo cifrado por software.

(c) assim, não se pode de antemão afirmar que as manifestações de vontade eletrônicas serão inválidas, sob o ponto de vista jurídico, caso sejam produzidas com base em HSM compartilhado;

(d) a Medida Provisória nº 2.200-2 não criou uma forma especial obrigatória para o meio eletrônico, mas sim um dispositivo legal que equipara a assinatura digital produzida com base em certificado digital ICP-Brasil à assinatura manuscrita;

(e) portanto, não é requisito de validade para o meio eletrônico a utilização do certificado digital ICP-Brasil, pois os dispositivos da Medida Provisória nº 2.200-2, art. 10, §§ 1º e 2º, se situam num sistema de regras mais amplo, onde há a previsão da liberdade de formas e do livre convencimento judicial;

(f) também por essas razões, não se pode, ex ante, decretar a invalidade de manifestações eletrônicas produzidas com base em certificado digital que não seja da ICP-Brasil, bem como de soluções que eventualmente estejam em desacordo com as regras da ICP-Brasil;

(g) todavia, os documentos assinados com base em certificado digital ICP-Brasil desfrutam, isso sim, de um status jurídico probatório diferenciado, estabelecendo uma presunção relativa de autoria e integridade, apta a agregar maior segurança jurídica para os atos e negócios praticados no meio eletrônico, daí a enorme importância da Infraestrutura de Chaves Públicas Brasileira;

(h) o “exclusivo controle, uso e conhecimento” da chave privada de que trata o art. 6º, Parágrafo único, da Medida Provisória nº 2.200-2 não se refere exclusivamente ao controle físico da mídia armazenadora, mas meramente ao poder de controle fático, que pode se estabelecer mesmo à distância, sem o acesso físico à chave privada, desde que o mesmo possa ser realizado de maneira segura e sem o compartilhamento da mídia que a armazena;

(i) a análise dogmática da Medida Provisória nº 2.200-2, bem como das regras da ICP-Brasil não autoriza a que se chegue à conclusão de que a utilização do HSM invalida as manifestações de vontade eletrônicas com base nele assinadas;

(j) para a finalidade de se obter uma segurança jurídica ainda maior, é recomendável a regulação da utilização do HSM homologado na ICP-Brasil.

[1] Disponível em http://www.iti.gov.br.

[2] Estudo não publicado.

[3] Mais precisamente, de acordo com o previsto no art. 2º da EC 32/2001: “Art. 2º As medidas provisórias editadas em data anterior à da publicação desta emenda continuam em vigor até que medida provisória ulterior as revogue explicitamente ou até deliberação definitiva do Congresso Nacional.”

[4] Há que se referir como um dos documentos fundantes do reconhecimento da equivalência funcional a Lei Modelo de Comércio Eletrônico da UNCITRAL, do ano de 1996: “The Model Law thus relies on a new approach, sometimes referred to as the “functional equivalent approach”, which is based on an analysis of the purposes and functions of the traditional paper-based requirement with a view to determining how those purposes or functions could be fulfilled through electronic-commerce techniques. For example, among the functions served by a paper document are the following: to provide that a document would be legible by all; to provide that a document would remain unaltered over time; to allow for the reproduction of a document so that each party would hold a copy of the same data; to allow for the authentication of data by means of a signature; and to provide that a document would be in a form acceptable to public authorities and courts. It should be noted that in respect of all of the above-mentioned functions of paper, electronic records can provide the same level of security as paper and, in most cases, a much higher degree of reliability and speed, especially with respect to the identification of the source and content of the data, provided that a number of technical and legal requirements are met. However, the adoption of the functional-equivalent approach should not result in imposing on users of electronic commerce more stringent standards of security (and the related costs) than in a paper-based environment”, p. 20, UNCITRAL Model Law on Electronic Commerce with Guide to Enactment 1996. Disponível em: http://www.uncitral.org.

[5] Menke, F. Assinatura Eletrônica no Direito Brasileiro, São Paulo: Editora Revista dos Tribunais, 2005, p. 138-139.

[6] As presunções relativas admitem prova em contrário, diferentemente das presunções absolutas.

[7] Há que se acrescentar à presunção de autoria a presunção de integridade da mensagem, ou seja, a de que o seu conteúdo não foi alterado. Esta presunção advém da combinação de dois fatores: 1) utilização da criptografia assimétrica, que proporciona a possibilidade de se tomar conhecimento acerca de eventual alteração do conteúdo do documento e; 2) confirmação positiva de que o documento efetivamente não foi alterado.

[8] Dispositivo com a seguinte redação: “Fica instituída a Infra-Estrutura de Chaves Públicas Brasileira – ICP-Brasil, para garantir a autenticidade, a integridade e a validade jurídica de documentos em forma eletrônica, das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais, bem como a realização de transações eletrônicas seguras“.

[9] Com efeito, determina o artigo 5º da Lei Modelo de Comércio Eletrônico da UNCITRAL: “Article 5. Legal recognition of data messages: Information shall not be denied legal effect, validity or enforceability solely on the grounds that it is in the form of a data message.” No guia para a incorporação da Lei Modelo, consta o seguinte comentário ao artigo 5º: “Article 5 embodies the fundamental principle that data messages should not be discriminated against, i.e., that there should be no disparity of treatment between data messages and paper documents. It is intended to apply notwithstanding any statutory requirements for a “writing” or an original“.

[10] Sobre o conceito de forma especial, ensina Pontes de Miranda: “Diz-se forma especial a forma que o sistema jurídico exige para determinado ato, ou quando se trate de alguma pessoa ou coisa. Só a lei especializa“. Tratado de Direito Privado, Tomo III, Campinas, Bookseller, 2003, p. 394.

[11] A matéria da prova é localizada numa zona de fronteira no direito brasileiro, regulada tanto pelo Código Civil quanto pelo Código de Processo Civil. Conforme ensina Caio Mário da Silva Pereira: “A prova é, na verdade, objeto de disciplina pela lei civil, como pela lei processual. O direito civil define os ‘meios de prova’, enuncia os lineamentos do regime a que se submeterá a comprovação do fato jurídico, natural ou voluntário, e especialmente a declaração de vontade. O direito processual afirma os preceitos que presidem a apreciação da prova em Juízo e a técnica de trazê-la à consciência do julgador. Assim, não cabe ao processo, porém ao direito civil, determinar o requisito formal para a emissão de vontade visando a certo efeito, e via de consequência a condição legal de sua comprovação. Mas não compete ao direito civil, e sim ao processual, adotar ou rejeitar o princípio da liberdade do juiz para decidir segundo a sua convicção íntima, ex informata conscientia, ou segundo o que no correr do litígio for produzido pelos interessados, secundum allegatum et probatum iudex iudicare debet (com conhecimento de causa, o juiz deve julgar de acordo com o que foi alegado e provado)“. Instituições de Direito Civil – Introdução ao Direito Civil: Teoria Geral do Direito Civil. Rio de Janeiro: Forense, 2009, p. 503-504. Ainda sobre a questão da disciplina da prova tanto pelo Código Civil quanto pelo Código de Processo Civil, Clóvis do Couto e Silva salienta que quando da edição do Código Civil de 1916 não havia Código de Processo Civil em vigor no Brasil, daí a necessidade de que um mínimo de segurança jurídica sobre a matéria fosse estabelecida pelo Código que estava sendo editado. Ver em Direito material e processual em tema de prova, Revista de Processo 13, p. 135. A problemática também não escapou da análise de Pontes de Miranda, que defendeu a abordagem da matéria pelo Código Civil sob o fundamento de que o destinatário da prova não é apenas o juiz, uma vez que fora do processo as partes também precisam ser convencidas sobre a credibilidade das provas dos atos e negócios jurídicos que se lhe apresentam. Ob. cit., nota de rodapé nº 10, p. 451. Para uma análise da questão, ver Menke, F., Die elektronische Signatur im deutschen und brasilianischen Recht: Eine Rechtsvergleichende Studie, Baden-Baden: Nomos, 2009, p. 189-190.

[12] Sobre o princípio da forma livre no direito brasileiro, Maria Helena Diniz assevera: “De modo que vige em nosso direito a regra geral de que: qualquer que seja a forma, a emissão de vontade, em princípio, é dotada de poder criador, exceto quando a solenidade integra a substância do negócio“. Curso de direito civil brasileiro, volume 1: teoria geral do direito civil, São Paulo: Saraiva, 2011, p. 541-542.

[13] São eles: “I – agente capaz; II – objeto lícito, possível, determinado ou determinável; III- forma prescrita ou não defesa em lei“.

[14] “Art. 185. Aos atos jurídicos lícitos, que não sejam negócios jurídicos, aplicam-se, no que couber, as disposições do Título anterior“.

[15] A forma especial poderá, isso sim, ser prevista pela legislação marginal que regula os mais diversos atos e negócios a serem celebrados pelo meio eletrônico. Tome-se como exemplo o processo eletrônico. Neste caso, a Lei 11.419, de 2006, determinou as formas possíveis para a prática de atos processuais eletrônicos, fixando que a assinatura digital baseada em certificado digital emitido por Autoridade Certificadora credenciada, na forma de lei específica, poderá ser utilizada (art. 1º, § 2º, III, a). Outro exemplo é o da Lei 11.977, que dispôs, entre outras matérias, sobre a obrigação de os serviços de registros públicos instituírem o sistema de registro eletrônico (art. 37), sendo que os documentos eletrônicos apresentados aos serviços de registros públicos ou por eles expedidos deverão atender aos requisitos da ICP-Brasil (art. 38), o que significa que terão de ser assinados digitalmente com certificado digital obtido no âmbito desta infraestrutura.

[16] Ver, quanto ao ponto, a pergunta 51 e respectiva resposta, no Manual de Perguntas & Respostas Jurídicas/ICP-Brasil, versão 0.0, disponível em http://www.iti.gov.br, clicar em “Publicações” e após em “Manuais”, acesso em 11.10.2012.

[17] Lorenzetti, R. L. Comércio Eletrônico. Tradução de Fabiano Menke. São Paulo: Editora Revista dos Tribunais, 2004, p. 299.

[18] Azevedo, A. J. de. Negócio jurídico: existência, validade e eficácia. 4ª ed. São Paulo: Saraiva, 2002.

[19] Menke, F. Assinatura Eletrônica no Direito Brasileiro, São Paulo: Editora Revista dos Tribunais, 2005, p. 141-142.

[20] Menke, F. Assinatura Eletrônica no Direito Brasileiro, São Paulo: Editora Revista dos Tribunais, 2005, p. 140-141. Os grifos apostos no destaque não estão no original da publicação.

[21] “Parágrafo único. 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.”

[22] Na Alemanha, por exemplo, o assunto em questão já provocou o estudo de técnicos e juristas, uma vez que também as regras da Diretiva Europeia 1999/93 e da Lei de Assinaturas alemã determinam que um dos requisitos da assinatura eletrônica avançada é o controle dos mecanismos de criação da assinatura. Na Alemanha, Alexander Rossnagel e Stefanie Fischer-Dieskau, da Universidade de Kassel, se debruçaram sobre o tema, analisando as denominadas “assinaturas eletrônicas criadas de forma automática” (automatisiert erzeugte elektronische Signaturen), nas quais nem sempre o dispositivo de criação de assinaturas está na posse física do titular do par de chaves. Neste trabalho, chegaram à conclusão de que as assinaturas automáticas podem satisfazer o requisito do “controle exclusivo”, desde que sejam utilizados mecanismos seguros de exclusão de terceiros do acesso à chave privada. Trata-se do artigo Automatisiert erzeugte elektronische Signaturen, publicado na Revista Multimedia und Recht, 2004, p. 133- 139.

[23] É o que se depreende do art. 7º da MP 2.200-2: “às AR, entidades operacionalmente vinculadas a determinada AC, compete identificar e cadastrar usuários na presença destes, encaminhar solicitações de certificados às AC e manter registros de suas operações”.

[24] Para o texto integral do DOC-ICP-03, conferir em http://www.iti.gov.br, acessando “legislação” e “documentos principais”.

[25] Conforme tabela 4 constante do item 6.1.1.7 do DOC-ICP-03.

Fonte: PKIconsulting Blog › PKIconsulting

O Blog apresenta sempre novidades sobre certificação digital. Conheça e divulgue.

* Viviane Bertol e Fabiano Menke

Posted on 02/03/2014

O post Uso de HSM para guarda de certificados digitais – Por Viviane Bertol e Fabiano Menke apareceu primeiro em CRYPTOID. http://ift.tt/2nG2fwg http://ift.tt/2aM8QhC

%d blogueiros gostam disto: