Some content of this application is unavailable at the moment.
If this situation persist, please contact us atFeedback&Contact
1. (WO2019033193) CRYPTOGRAPHIC SECURITY MODULE EQUIPMENT WITH NATIVE IMPLEMENTATION OF A CRYPTOGRAPHIC KEY MANAGEMENT COMMUNICATION PROTOCOL AND REMOTE CONFIDENCE ENHANCEMENT SYSTEM FOR AUTHORIZATION OF OPERATIONS
Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters

EQUIPAMENTO MÓDULO DE SEGURANÇA CRIPTOGRAFICA COM IMPLEMENTAÇÃO NATIVA DE PROTOCOLO DE COMUNICAÇÃO DE GERENCIAMENTO DE CHAVES CRIPTOGRÁFICAS E SISTEMA DE AMPLIFICAÇÃO REMOTA DE CONFIANÇA PARA AUTORIZAÇÃO DE OPERAÇÕES

Campo da invenção

[001 ]. A presente invenção se refere ao campo de módulos de segurança criptográfica, com implementação de protocolo de gerenciamento de chaves criptográficas que acrescenta funcionalidades de execução segura de aplicativos em ambiente confiável e separação de serviços de armazenamento e gerenciamento de objetos através de múltiplos módulos de segurança lógicos implementados em um único dispositivo físico.

Estado da arte

[002]. Módulos de Segurança Criptográfica (MSC) são equipamentos utilizados para a proteção de objetos criptográficos sensíveis de seus usuários. Esse equipamento possui proteções físicas e lógicas para dificultar o acesso às informações nele contidas e interfaces seguras para sua utilização, além de, geralmente, alto desempenho para operações criptográficas.

[003]. Existem vários fabricantes estabelecidos de MSC, e os produtos disponíveis usualmente se caracterizam por serem um módulo externo que é conectado diretamente a um computador ou servidor. O usuário se comunica com o MSC por meio de uma interface, estabelecida em cima de um protocolo de comunicação adotado entre o servidor e aplicações externas.

[004]. O aumento de operações realizadas entre diferentes plataformas e redes impulsionou a demanda por compartilhamento de chaves e objetos criptográficos entre diferentes aplicações, como serviços de e-mail, bancos de dados, e dispositivos de armazenamento. Contudo, os protocolos atuais de comunicação segura entre sistemas criptográficos são diversos, gerando diversas redundâncias e potenciais fontes de vulnerabilidades de segurança.

[005]. Assim, observa-se o desenvolvimento de novos protocolos de comunicação entre sistemas criptográficos e diversas aplicações. Recentemente, o Key Management Interoperability Protocol (KMIP) é um dos protocolos estabelecidos com o objetivo de diminuir a redundância e incompatibilidade de diferentes processos de gerenciamento de chaves.

[006]. Dentre esses protocolos, destaca-se o desenvolvimento e aceitação do KMIP, o que acarretou no lançamento de adaptações de MSC de diversos fornecedores. Nessas adaptações, foram lançados softwares intermediários 3 para estabelecer comunicação entre interfaces KMIP e o MSC. Do ponto de vista do cliente, a inclusão do servidor intermediário 3 aumenta a quantidade de softwares intermediários para integração e manutenção, como bibliotecas e drivers específicos, além de, possivelmente, aumentar a demanda por hardware dedicado.

[007]. Além da necessidade de uma maneira mais otimizada de compartilhar chaves criptográficas, a crescente utilização de serviços de armazenamento em nuvem como base para diversas aplicações também gera novas demandas para implementações de MSC.

[008]. O pedido de patente US2013179676 - CLOUD-BASED HARDWARE SECURITY MODULES, com prioridade em 29/12/201 1 , descreve o uso das funcionalidades de um MSC estabelecido em nuvem. Assim, o usuário não precisa ter acesso direto ao MSC físico para poder armazenar com segurança objetos criptográficos. Nesta implementação, há a necessidade de pilhas de software intermediárias, como drivers USB, para a utilização do MSC.

[009]. O conceito de fornecer as funcionalidades de segurança de MSC por meio de serviços na nuvem também é abordada pela patente US2015134953 -METHOD AND APPARATUS FOR OFFERING CLOUD-BASED HSM SERVICES, com prioridade em 08/1 1 /2013. Esta implementação apresenta um método para segmentar o MSC físico em várias partições, e propõe o uso de um controlador baseado em software para gerenciar e rotear as requisições de clientes às partições. Questões como redundâncias de protocolos de comunicação podem ser intensificadas nessa configuração, caso cada cliente e aplicação utilizem um protocolo distinto. Além disso, a inclusão de mais uma camada de comunicação, neste caso o controlador, acrescenta mais um ponto de potencial vulnerabilidade ao sistema.

[010]. Outra demanda crescente é a criação de ambientes seguros para execução de código. Aplicações sensíveis a questões de segurança se beneficiam em serem executadas em ambientes com os níveis de proteção garantidos por um MSC. Já existem MSC que oferecem essa funcionalidade, embora eles possuam seus protocolos de comunicação próprios.

[01 1 ]. Ou seja, destaca-se a diversificação de cenários de utilização de um MSC, como o aumento da demanda da separação lógica dos serviços de armazenamento e gerenciamento seguro de objetos criptográficos. Contudo, a inclusão de softwares intermediários entre o MSC e essas aplicações, embora relativamente mais simples de implementar, acarretam em aumento nas camadas de comunicação. Com isso, há o aumento no volume de manutenção do sistema, assim como em potenciais vulnerabilidades.

[012]. Portanto, observa-se que alguns problemas ainda permanecem não resolvidos pelo estado da técnica. Para aumentar o escopo de funcionalidades de um MSC, mas sem acrescentar camadas de vulnerabilidade e manutenção, se faz necessário um MSC que seja capaz de executar, sem intermediários, as atividades requeridas por esses novos cenários de utilização, assim como se comunicar diretamente com protocolos de interoperabilidade de chaves criptográficas.

[013]. Além disso, o protocolo KMIP não prevê credenciais que possibilitem o uso de mais de uma credencial simultânea para a autenticação e autorização de operações. Portanto, um MSC que rode em KMIP sem intermediários também necessita apresentar mecanismos alternativos para realizar autenticação multi-fator.

Descrição resumida da invenção

[014]. A presente invenção descreve um módulo de segurança criptográfica (MSC) 5, utilizado para o armazenamento de objetos criptográficos com implementação nativa de protocolo de comunicação utilizado em diversas interfaces de gerenciamento de chaves criptográficas. Esta configuração possibilita que o MSC estabeleça comunicação segura 4 diretamente com o usuário 1 , dispensando o uso de servidores intermediários, atualmente utilizados no estado da técnica.

[015]. A interação direta e sem intermediários entre o MSC 5 e aplicações do usuário 1 também contribuem para resolver os problemas do estado da técnica no oferecimento de serviços de MSC virtual e execução segura de código.

[016]. Também é descrito um sistema de amplificação de confiança para autorização de operações de entidades ou papéis com dois ou mais fatores de autenticação, via conexão remota, de forma a garantir acesso aos objetos da mesma entidade ou papel protegidos pelo MSC. Neste sistema toda autenticação da entidade ou papel é realizada via conexão direta ao MSC, sem necessidade de software ou hardware intermediário, conforme esquematizado na FIGURA 06.

Descrição detalhada das figuras

[017]. As configurações do sistema podem ser entendidas com a seguinte descrição das figuras em conjunto com os respectivos desenhos.

[018]. A FIGURA 01 apresenta um esquema do estado da técnica de MSC 2 com servidor intermediário 3 para interoperabilidade entre interface para usuários 1 e o MSC, por meio de protocolos como o KMIP. O servidor intermediário KMIP 3 garante que toda conexão entre cliente e servidor é feita de maneira segura 4, protegida por meio de Transport Layer Security (TLS).

[019]. A FIGURA 02 apresenta o esquema da presente invenção, com um MSC com KMIP implementado nativamente 5, de modo que a comunicação segura 4 seja implementada diretamente com o usuário 1.

[020]. A FIGURA 03 apresenta a arquitetura utilizada pelo MSC com KMIP nativo 5 para proporcionar a separação lógica dos serviços de armazenamento e gerenciamento do MSC, assim como compartilhamento de recursos por meio de Virtual MSC 6.

[021 ]. A FIGURA 04 apresenta a arquitetura utilizada pelo MSC com KMIP nativo 5 para proporcionar a separação lógica dos serviços de armazenamento e gerenciamento seguro de objetos criptográficos, com destaque à comunicação segura 4 de cada virtual MSC com usuários distintos 1.

[022]. A FIGURA 05 apresenta a arquitetura utilizada pelo MSC com KMIP nativo 5 para proporcionar a execução segura de código dentro de seu ambiente criptográfico. Antes de um aplicativo ser executado, a sua verificação de integridade e confiabilidade é realizada através de assinatura digital. Em seguida, o aplicativo é executado em ambiente sandbox 7, para mitigação de problemas de segurança.

[023]. A FIGURA 06 demonstra a arquitetura para autenticação com multi fatores para o MSC 5. Neste caso, é dado destaque à interface KMIP 8, implementada nativamente no MSC 5. Os outros elementos apresentados na FIGURA 06 são:

[024]. (9): Aplicação para operação do MSC;

[025]. (10): Aplicação de credenciamento.

[026]. (1 1 ): Entidade ou papel responsável pela operação

[027]. (12): Aplicativo de geração de segundo fator

[028]. (13): Entidade ou papel responsável pelo credenciamento

[029]. A FIGURA 07 ilustra como essa arquitetura é empregada para a autenticação com dois fatores, utilizando como gerador de segundo fator 12 um aplicativo de geração de One Time Password (OTP). Essa figura é apresentada a título de ilustrar uma das configurações possíveis de autenticação, já que esse sistema pode ser utilizado para outros mecanismos de segundo fator de autenticação, e, portanto, não deve ser encarada como limitadora do escopo da invenção.

Descrição detalhada da invenção

[030]. A presente invenção descreve um módulo de segurança criptográfica (MSC) 5, utilizado para o armazenamento de objetos criptográficos com implementação nativa de protocolo de gerenciamento de chaves criptográficas. Esta configuração possibilita que o MSC estabeleça comunicação segura 4 diretamente com o usuário 1 , dispensando o uso de servidores intermediários, conforme disponível no estado da técnica, representado na FIGURA 01 .

[031 ]. O protocolo utilizado na descrição desse equipamento é o Key Management Interoperability Protocol (KM IP), já que, além de sua crescente adoção, este é um protocolo de comunicação abrangente para interação entre sistemas criptográficos e aplicações que precisam gerenciar chaves criptográficas. Essas características fazem com que o KMIP seja o protocolo de comunicação ideal para a elaboração de um MSC que dispensa servidores intermediários 3, e não deve ser encarado como limitador do escopo da invenção.

[032]. Para utilizar o MSC 5, um usuário 1 deve ser capaz de se comunicar com o módulo através de uma interface. Na presente descrição, a interface consiste no protocolo KMIP. O KMIP é um protocolo que especifica quais operações de gerenciamento de chaves podem ser realizadas entre um cliente e um servidor e o comportamento esperado para essas operações. Por exemplo, o KMIP especifica operações para que o cliente possa criar chaves criptográficas no servidor, e operações para que o cliente possa utilizar uma chave para realizar uma assinatura digital. Além disso, o KMIP garante que toda conexão entre cliente e servidor é feita de maneira segura 4, protegida por meio de TLS -Transport Layer Security.

[033]. Com o suporte nativo ao protocolo KMIP do MSC 5 descrito, uma requisição KMIP pode ser feita diretamente ao MSC 5, sem qualquer software intermediário entre o cliente e o servidor. Assim, é dispensado o uso de servidores ou softwares intermediários para se comunicar com o cliente.

[034]. Além de reduzir a demanda por softwares e hardwares intermediários, a implementação nativa de protocolo de comunicação utilizado em diversas interfaces de gerenciamento de chaves criptográficas no MSC 5 proporciona a extensão da proteção física, característica desse equipamento, para o processo de autenticação de usuários 1.

[035]. A título de comparação, no estado da técnica, a autenticação do cliente é realizada com o servidor intermediário 3, que não possui a robustez de segurança de um MSC. Esse servidor, tipicamente, obteria acesso às credenciais informadas pelo usuário e as compararia com os dados armazenados em um banco de dados externo ao MSC 2. O servidor então acessaria os objetos criptográficos do usuário utilizando algum outro tipo de credencial específico do MSC 2, mas de posse do servidor 3. Esse método adiciona pontos de vulnerabilidade ao sistema, já que apenas o MSC possui garantias de proteção física e lógica. No caso da presente invenção, o usuário se autentica diretamente com o MSC 5, possuindo garantias de que suas credencias de acesso não foram informadas a nenhum servidor intermediário e de que a conexão está sendo estabelecida com o próprio MSC.

[036]. A arquitetura do MSC 5 também proporciona a implementação de funcionalidades adicionais para o usuário, descritas a seguir.

[037]. MSC Virtual: um MSC Virtual (VMSC) é uma entidade lógica que utiliza recursos do MSC físico. Essa entidade possui seus próprios usuários, chaves e credenciais de acesso, de forma a possibilitar inúmeras aplicações para o detentor do MSC. Algumas aplicações de um MSC com a funcionalidade de VMSC incluem a separação de setores dentro de uma empresa para utilizarem VMSC específicos, assim como a criação de planos de aluguel de VMSC, limitando os recursos que podem ser usados por cada um dos usuários.

[038]. A FIGURA 03 demonstra como é feita essa separação, com cada MSC Virtual 6 tendo uma especificação de memória própria dentro do MSC 5. Assim, cada VMSC 6 não tem acesso aos dados nem usuários dos demais.

[039]. Na FIGURA 04 é exposto como diferentes usuários 1 , com acesso a diferentes unidades de VMSC 6 (representados por cores distintas). A

comunicação entre o usuário 1 e o VMSC 6 é realizada por comunicação KMIP 4. Do ponto de vista do usuário 1 , a interação é tal como um MSC 5, sendo que ele só possuirá acesso aos seus próprios dados e objetos criptográficos.

[040]. A implementação de VMSC 6 a partir de um MSC 5 que não demanda servidores intermediários 3, garante que o usuário 1 de cada unidade lógica 6 será autenticado diretamente pelo MSC 5. Já a autenticação de um usuário dos demais MSCs 2 é realizada pelo servidor intermediário 3. Assim, o MSC 5 proporciona proteção lógica e física na autenticação de usuários, algo que um servidor intermediário 3 não consegue oferecer, já que este não é um MSC.

[041 ]. Execução segura de código: uma das extensões do VMSC 6 é a possibilidade de o usuário registrar código a ser executado pelo MSC 5. Antes de ser executado, esse código é verificado pelo MSC 5 para verificar se ainda está íntegro e é executado em uma sandbox 7 para mitigar problemas de segurança, como código defeituoso ou malicioso, e garantir a proteção fornecida pelo MSC 5.

[042]. Cada uma das sandboxes 7 possui um código sendo executado (Trusted Application), mas todas são executadas dentro do MSC 5 físico, na mesma memória onde também estão sendo executados os VMSCs 6. Destaca-se que não há correspondência entre o VMSC 6 e os códigos confiáveis/Trasfecf Applications. Em outras palavras, é possível haver só um VMSC 6 e vários códigos confiáveis 7 registrados e em execução.

[043]. Autenticação com múltiplos fatores de autenticação: grande parte das situações de autenticação de usuário envolve o fornecimento de uma senha, previamente estabelecida. Contudo, há várias situações que demandam um ou mais fatores adicionais de autenticação para aumentar o nível se segurança do sistema, de forma que a aumentar a garantia da identidade do usuário antes que lhe seja concedida permissão para utilização de seus objetos criptográficos.

[044]. Para o MSC 5, com KMIP implementado nativamente, é descrito um sistema de amplificação de confiança com vistas de autorização de operações de entes em um MSC 5 com dois ou mais fatores de autenticação, via conexão remota, de forma a garantir acesso aos objetos do mesmo usuário protegidos pelo MSC 5. Nesta solução toda autenticação e autorização do usuário é realizada via conexão direta ao MSC, sem necessidade de software ou hardware intermediário. Esta solução utiliza o protocolo KMIP {Key Management Interoperability Protocol) como base, com algumas modificações que serão descritas.

[045]. Os módulos e papéis definidos na arquitetura são:

[046]. Entidade ou papel responsável pelo credenciamento (13):

Responsável por adicionar novos operadores no MSC 5.

[047]. Entidade ou papel responsável pela operação (11): Responsável pela operação do MSC 5.

[048]. Aplicação de geração ou captura de segundo fator (12): Aplicação para plataforma computacional, seja smartphone, desktop ou qualquer outra que será utilizado para acesso ao segundo fator de autenticação pela entidade ou papel. Este segundo fator pode ser elemento entendido como credencial que amplie a confiança na entidade ou papel: senha de uso único baseada em tempo ou resumo criptográfico, biometria, certificados digitais, números de identificação pessoal, dentre outros.

[049]. Aplicação para operação do MSC (9): Aplicativo utilizado pela entidade ou papel de operação para operar o MSC, após devida autenticação.

[050]. Aplicação de Credenciamento (10): Aplicação para credenciamento de entidades ou papéis no MSC.

[051 ]. Na solução apresentada, é necessário criar uma credencial do tipo OTP, não previsto até então pelo protocolo KMIP.

[052]. Com esse novo tipo de credencial, o usuário precisa passar dois tipos de credenciais na autenticação, o "Usuário e Senha" e também o "Second Factor", e o MSC valida os dois campos para liberar o uso dos objetos do usuário.

[053]. Conforme demonstrado na FIGURA 07, a primeira etapa do fluxo de uso é o Credenciamento 14. Durante o credenciamento, a Entidade ou papel responsável pelo credenciamento requisita a criação de um novo operador (via KMIP), indicando que o mesmo necessita de um segundo fator de autenticação para utilizar seus objetos e cadastrando seu nome de usuário e senha. Entidade ou papel responsável pelo credenciamento indica ao operador 1 como instalar e utilizar seu aplicativo de segundo fator.

[054]. Após isso, ocorre a Inicialização do Segundo Fator. Esse processo pode ser feito pelo próprio usuário através do aplicativo de segundo fator momento da primeira conexão utilizando seu usuário e senha

[055]. A próxima etapa no fluxo é o Acesso ao MSC 15. Com o segundo fator configurado adequadamente, agora operador pode realizar o acesso ao MSC 5, utilizando seu usuário e senha e o segundo fator gerado pelo aplicativo de segundo fator 12.

[056]. Por fim, a última etapa do fluxo é a Operação do MSC. Depois disso, o operador pode utilizar suas credenciais para operar o MSC.