BR112019013586A2 - Selagem de dados com um enclave de selagem - Google Patents

Abstract

são apresentadas técnicas para de forma segura selar e retirar a selagem de dados de enclave através de plataformas. dados de enclave a partir de um enclave fonte hospedado em um primeiro computador podem ser de forma segura selados a um enclave de selagem em um segundo computador, e podem ainda ter de forma segura a selagem retirada para um enclave destino em um terceiro computador. é revelado de forma segura transferir uma carga de trabalho do enclave de um computador para outro.

Description

Relatório Descritivo da Patente de Invenção para SELAGEM DE DADOS COM UM ENCLAVE DE SELAGEM.

CAMPO TÉCNICO [001] Esta revelação se relaciona com sistemas de computação seguros

ANTECEDENTES [002] Regiões isoladas seguras ou ambientes de execução confiáveis proporcionam um container seguro, referido como enclave neste documento, para executar código confiável em um computador que pode possuir menos código confiável em uma região fora da região isolada. Uma região isolada do enclave inclui uma parte de memória que é protegida durante a execução de código residindo fora do enclave. A memória isolada pode conter tanto código como dados para o enclave, e a proteção desta memória pode incluir código executando restrições contidas na memória do enclave em adição às restrições quando da leitura ou gravação na memória do enclave. Aspectos de segurança de enclave, tais como isolamento de memória e restrições de execução, podem ser impostos, por exemplo, por hardware no processador do computador. A atestação de software pode proporcionar confiança na segurança de isolamento de um enclave particular e no código do enclave que é carregado dentro da região de memória isolada deste enclave particular. A atestação pode ainda proporcionar prova da integridade da plataforma de hardware e software na qual o enclave atestado está executando.

[003] Os sistemas de enclave, tais como o Virtual Secure Mode (VSM) da Microsoft e o Software Guard Extensions (SGX) da Intel proporcionam segurança em parte por isolar um enclave de outro código executando no modo usuário ou no modo kernel. As garantias de integridade e de confiabilidade podem proporcionar para um enclave um nível superior de confiança na autenticidade de código

Petição 870190060870, de 28/06/2019, pág. 13/143

2/102 executando em um enclave, e a confiança na execução segura do código do enclave. Uma garantia de integridade pode ser proporcionada pela atestação de software de um enclave particular. A atestação de software pode incluir um hash criptograficamente assinado dos conteúdos (instruções e dados) dentro de um enclave e pode ser combinada com dados sobre o ambiente do enclave. Quando um enclave é utilizado em combinação com um módulo de segurança de hardware (HSM), tal como hardware de acordo com um padrão do Módulo de Plataforma Confiável (TPM) do Grupo de Computação Confiável (TCG), o enclave pode proporcionar um nível adicional de garantias de segurança e sigilo.

[004] Em adição à segurança proporcionada pelo isolamento de um enclave local confiável de um código de local não confiável do isolamento do enclave, a atestação de software de um enclave pode permitir computação remota confiável. A atestação de um enclave remoto pode proporcionar confiança tanto na integridade da execução de instruções no enclave, como no sigilo de dados processados pelo enclave. Quando a atestação de um enclave remoto é proporcionada por hardware a partir de um fabricante confiável, um enclave pode ser confiável mesmo quando o enclave reside em um computador desconhecido que é possuído e mantido por uma parte não confiável. Isto é frequentemente o caso, por exemplo, quando recursos de computação são alugados em um recurso de computação baseado em nuvem Internet.

SUMÁRIO [005] São apresentados métodos e sistemas para abstrair uma plataforma de enclave. O método pode compreender receber, por uma plataforma de abstração de enclave, uma primeira solicitação para utilizar um enclave a partir e um cliente do enclave. A primeira solicitação pode ser de acordo com um protocolo de abstração de

Petição 870190060870, de 28/06/2019, pág. 14/143

3/102 cliente. A primeira solicitação pode ser convertida para uma segunda solicitação que é de acordo com um protocolo nativo do enclave associado com uma plataforma nativa do enclave. A segunda solicitação pode então ser enviada para a plataforma nativa do enclave. A primeira solicitação pode ser, por exemplo, uma solicitação para instanciar um enclave, uma solicitação para verificar um relatório de atestação de um enclave, uma solicitação para pedir ajuda a um enclave, ou uma solicitação para alocar memória que é compartilhada tanto com o enclave como com o cliente do enclave. A plataforma nativa pode ser de acordo com a arquitetura de enclave Software Guard Extensions (SGX) da Intel a plataforma nativa pode ser de acordo com a arquitetura de enclave Virtual Secure Mode (VSM) da Microsoft.

BREVE DESCRIÇÃO DOS DESENHOS [006] A Figura 1 representa um diagrama de blocos de alto-nível ilustrativo de um sistema de enclave.

[007] A Figura 2 representa um processo ilustrativo para passagem de mensagem com uma garantia de sigilo.

[008] A Figura 3 representa um processo ilustrativo para passagem de mensagem com uma garantia de integridade.

[009] A Figura 4 representa um processo ilustrativo para passagem de mensagem com uma garantia de frescor.

[0010] A Figura 5 representa um processo ilustrativo para atestação de software de um enclave.

[0011] A Figura 6 representa um protocolo de Troca de Chaves de Diffe-Hellman (DKE).

[0012] A Figura 7 representa uma cadeia de confiança para atestação de software ilustrativa.

[0013] A Figura 8 é um diagrama de blocos de interfaces de componente de software para um sistema de enclave local ilustrativo.

Petição 870190060870, de 28/06/2019, pág. 15/143

4/102 [0014] A Figura 9 é um diagrama de blocos de interfaces de componente de software para um sistema de enclave local com uma camada de abstração.

[0015] A Figura 10 é um diagrama de blocos de interfaces de componente de software para um sistema de enclave remoto com uma camada de abstração.

[0016] A Figura 11 representa um ambiente de computação de propósito geral ilustrativo.

[0017] A Figura 12 representa um fluxograma ilustrativo para um método para abstrair uma plataforma de enclave nativa.

[0018] A Figura 13 representa um fluxograma ilustrativo para um método para abstrair uma plataforma de enclave nativa.

[0019] A Figura 14 representa um fluxograma ilustrativo para um método para executar uma operação do enclave com identidade de enclave abstrata.

[0020] A Figura 15 representa um fluxograma ilustrativo para um método 1500 para executar uma operação do enclave com identidade de enclave abstrata.

[0021] A Figura 16 representa um sistema ilustrativo com equivalência de identidade de enclave abstrata.

[0022] A Figura 17 representa um fluxograma ilustrativo para processamento paralelo com dois enclaves equivalentes.

[0023] A Figura 18 representa um fluxograma ilustrativo para processamento serial com dois enclaves equivalentes.

[0024] A Figura 19 é um diagrama de blocos de um sistema de selagem de dados distribuído ilustrativo.

[0025] A Figura 20 é um fluxograma ilustrativo para selagem e retirada de selagem de dados distribuída.

[0026] A Figura 21 é um diagrama de blocos de um enclave de caixa forte de chaves.

Petição 870190060870, de 28/06/2019, pág. 16/143

5/102 [0027] A Figura 22 é um fluxograma ilustrativo de algumas operações do enclave de caixa forte de chaves.

[0028] A Figura 23 é um fluxograma ilustrativo para operação de enclave de caixa forte de chaves com uma chave bloqueada na caixa forte.

DESCRIÇÃO DETALHADA DE MODALIDADES ILUSTRATIVAS [0029] Um modelo de abstração para enclaves é revelado, o que simplifica o desenvolvimento de clientes de enclave e do software que executa dentro de um enclave. Um modelo de abstração pode ser uma simplificação e unificação de arquiteturas de plataforma nativa do enclave, tais como a SGX da Intel e a VSM da Microsoft. Um componente de software de camada de abstração pode traduzir a comunicação entre um cliente do enclave e uma ou mais plataformas nativas, entre o software dentro de um enclave e uma ou mais plataformas nativas do enclave, e entre o software dentro de um enclave e um cliente do enclave. Tal plataforma de abstração pode proporcionar o benefício de permitir que uma única versão do software do enclave e do software do cliente do enclave execute na parte de cima de várias plataformas nativas do enclave, tal como SGX e VSM. Em adição a simplificar a tarefa de escrever software para enclaves e clientes do enclave, isto permite aos usuários finais dos enclaves executarem o software do enclave e do cliente do enclave em um computador que suporta qualquer arquitetura de enclave nativa suportada sem ter que encontrar versões tanto do software do enclave como do cliente do enclave que são ajustadas para uma plataforma de enclave nativa do computador específico.

[0030] Um modelo de abstração de enclave pode, por exemplo, incluir primitivas para gerenciar o ciclo de vida de um enclave, atestação local e remota de um enclave, selar dados para um enclave, programar controle de transferência para dentro e para fora de um

Petição 870190060870, de 28/06/2019, pág. 17/143

6/102 enclave, e outros aspectos de segurança tais como contadores uniformes e tempo confiável. Uma identidade abstrata ou em camadas de um enclave também é apresentada, a qual abstrai a identidade de um enclave além de um único binário ou de um único hash do conteúdo de um enclave. Interfaces de componente de software, tais como uma interface de programação de aplicativo (API) ou interface de binário de aplicativo (ABI) são apresentadas para desenvolvimento de enclaves e de programas de cliente de enclave utilizando primitivas de modelo de abstração.

[0031] Uma identidade abstrata pode incluir uma identidade aninhada ou hierarquia de identidade que pode ser utilizada para de forma segura identificar grupos de instâncias de enclave. Uma instância de enclave neste documento pode se referir ao mesmo código binário do enclave carregado em um enclave na mesma máquina e possuir a mesma identidade. Por outro lado, uma nova versão do código binário, ou o mesmo código binário carregado em uma máquina diferente, podem ser considerados uma instância diferente. Estas diferentes instâncias também podem possuir a mesma identidade em um nível superior em uma hierarquia de identidade. Uma identidade de enclave abstraída permite que grupos de binários de enclave relacionados sejam identificados como relatado. Por exemplo, diferentes versões do mesmo enclave, tais como as versões de binários de enclave antes e após um defeito ser detectado e resolvido, podem receber o mesmo nome, independente de versão. Em uma camada de abstração superior, todos os enclaves em uma família de enclaves podem receber um único nome de família ou identidade. Neste caso, todos os enclaves que executam funções relacionadas, porém diferentes, podem ser identificados juntos. Outras camadas de identidade ou agrupamentos de identidades são descritos abaixo.

Petição 870190060870, de 28/06/2019, pág. 18/143

7/102 [0032] Qualquer camada de uma identidade abstrata pode ser utilizada para várias operações criptográficas, tais como selagem de dados, atestação de um enclave ou garantir frescor de dados (via contadores uniformes). Por exemplo, por selar dados produzidos por uma instância de enclave para uma identidade de nível superior, estes dados então podem posteriormente ser consumidos de forma segura por uma instância de enclave diferente com a mesma identidade de enclave de nível superior. Por selar dados, por exemplo, para uma família de enclaves, qualquer instância de enclave que seja um membro desta família, e somente membros desta família, estarão aptos a retirar a selagem dos dados. A atestação para uma identidade de família a partir de uma instância de enclave proporciona garantia de que a instância de enclave é um membro desta família. Contadores uniformes ligados com uma abstração de identidade podem proporcionar garantias de frescor relacionadas com todas as instâncias de enclave que são membro da identidade de abstração.

[0033] O modelo de abstração revelado inclui interfaces de componente de software, tais como uma interface de programação de aplicativo (API) ou interface de binário de aplicativo (ABU), que podem simplificar desenvolvimento de software de enclaves e de hospedeiros de enclave. Uma API é um conjunto de definições de sub-rotina de programação, protocolos, e ferramentas para criar software. Uma API pode definir as entradas e as saídas de um componente de software, tipos de dados utilizados pelo componente de software, e a funcionalidade ou a operação do componente de software independente de qualquer implementação particular do componente de software. Uma API pode ser definida em uma linguagem de computador de alto-nível, tal como C, C++, C#, dentre outras. Uma definição formalizada de uma API pode facilitar a interação entre os componentes de software, por exemplo, dois componentes de

Petição 870190060870, de 28/06/2019, pág. 19/143

8/102 software escritos em momentos diferentes ou por autores diferentes. Uma API pode ser formalizada em parte com uma linguagem de descrição de interface (IDL) tal como a Linguagem de Definição de Interface (MIDL) ou IDL de Grupo de Gerenciamento de Objeto (OMG) da Microsoft. Uma ABI também é uma interface entre componentes de software, mas é uma interface de código objeto. Por exemplo, uma ABI pode ser pontos de entrada (ou os endereços de instrução) do código objeto resultando de compilar uma implementação de código fonte de uma API junto com protocolos para utilizar estes pontos de entrada, tais como protocolos especificando registrados de máquina que mantêm argumentos quando os pontos de entrada são chamados.

[0034] Em adição a permitir interação com diferentes níveis e identidade de enclave como descrito acima, uma API de enclave pode abstrair para longe as diferenças entre as arquiteturas de plataforma de enclave, por exemplo, entre arquiteturas para execução isolada segura proporcionada pela Software Guard Extensions (SGX) da Intel, pelo Virtual Secure Mode (VSM) da Microsoft, e pelo ARM TrustZone, Secure Encrypted Virtualization (SEV) da AMD, e arquiteturas baseadas em Arranjos de Portas Programáveis em Campo (FPGAs). As APIs incluem interfaces para uma plataforma de enclave que abstraem alguns detalhes das arquiteturas de enclave abstraídas. Estas interfaces de plataforma de enclave incluem uma API do hospedeiro de enclave, uma API da plataforma de enclave, e uma API de atestação remota. A API do hospedeiro do enclave pode ser utilizada por um processo de hospedeiro não confiável para gerenciar o ciclo de vida de um enclave bem como proporcionar comunicação para e a partir de um enclave. A API da plataforma de enclave pode ser proporcionada pela plataforma de enclave confiável para o enclave, e pode incluir primitivas de segurança para atestação, selagem, e comunicação com o código não confiável executando no

Petição 870190060870, de 28/06/2019, pág. 20/143

9/102 computador hospedando o computador de enclave, bem como suporte principal em tempo de execução tal como gerenciamento de memória e programação de encadeamento. A API de atestação remota pode ser utilizada para executar atestação remota, onde um enclave e seu cliente não são hospedados no mesmo computador. Por exemplo, a API de atestação remota pode ser utilizada por um cliente local para verificar que dados originários (ou que foram enviados) a partir de um enclave com alguma identidade executando sob isolamento proporcionado por uma plataforma de enclave em um computador remoto. Mais geralmente, a API de atestação remota pode ser utilizada para estabelecer canais de comunicação seguros entre um cliente local e um enclave remoto.

[0035] Os enclaves geralmente proporcionam soluções para problemas que são específicos para e surgem a partir do âmbito da tecnologia de computador. Mais especificamente, os enclaves proporcionam um mecanismo para segregar código confiável de código não confiável onde segmentos de código tanto confiáveis como não confiáveis residem dentro do espaço de endereços de um único processador de computador. Por exemplo, enclaves proporcionam uma solução de segurança para o problema de código potencialmente não confiável (tal como código potencialmente contendo defeitos ou vírus) executando no mesmo computador de propósito geral como código que pode acessar dados sensíveis ou privados. Modalidades desta revelação proporcionam soluções aprimoradas adicionais para tais problemas de segurança surgindo a partir do âmbito da tecnologia de computador, incluindo: simplificar o desenvolvimento de software por permitir que um único enclave ou cliente de enclave seja criado para várias plataformas nativas de enclave; simplificar o gerenciamento corporativo do computador por reduzir o número de componentes de software que devem ser customizados para aspectos

Petição 870190060870, de 28/06/2019, pág. 21/143

10/102 específicos do hardware de um computador particular; e permitir novos cenários de computação segura com selagem de dados distribuída, tal como distribuir processamento seguro de enclave através de enclaves hospedados em vários computadores.

[0036] A Figura 1 representa um diagrama de blocos de alto-nível de um sistema de enclave junto com algumas relações confiáveis. O sistema de enclave 100 inclui um enclave 176 (alternativamente chamado de um container de enclave ou de ambiente de execução seguro), o qual inclui uma região isolada segura de memória que contém código 180 e dados 182. O código 180 pode ser público ou privado, e os dados 182 podem ser públicos ou privados. Por exemplo, os dados ou código privados podem pertencer (ou serem privados para) um proprietário de dados 142, enquanto os dados ou código públicos podem ter sido proporcionados por outra parte, tal como o provedor de software 148. Em uma modalidade, o código de executa dentro de um container de enclave 176 pode ser completamente público e não privado, enquanto os dados que o código de enclave público utiliza como entrada ou produz como saída podem ser privados. Em outra modalidade, o inverso é possível, onde o código é privado enquanto os dados são públicos. Ainda em outra modalidade, tanto o código como os dados de entrada podem ser públicos, enquanto a saída da execução do código com os dados de entrada pode ser privada. Outras combinações de publico e privado do código, dos dados de entrada e dos dados de saída são possíveis.

[0037] O container do enclave 176 é hospedado no hardware confiável 172, o qual pode simultaneamente hospedar o software não confiável 174. Um propósito principal do sistema de enclave 100 pode incluir pelo menos um aspecto selecionado da lista consistindo: de manter integridade do código 180; manter sigilo do código 180, manter a integridade dos dados 182, e manter sigilo dos dados 182. Proteger

Petição 870190060870, de 28/06/2019, pág. 22/143

11/102 o conteúdo do enclave 176 de software não confiável 174 (por exemplo, revelação para software não confiável, modificação por software não confiável, dentre outros) pode ser uma meta. O hardware confiável é construído pelo fabricante 162, e é possuído e gerenciado pelo proprietário da infraestrutura 152.

[0038] O cliente do enclave 104 pode ser um processo ou programa fora do container do enclave para o qual o enclave 176 executa suas computações com o código 180 e com os dados 182. Em um ambiente de enclave local, o cliente de enclave 104 também pode estar funcionando no hardware confiável 172. Em uma modalidade de enclave remoto, o cliente de enclave pode executar em um computador enquanto o hardware confiável 172 é um computador remoto diferente conectado com o computador do cliente de enclave via uma rede. No caso de enclave local, o processo do cliente de enclave também pode ser o processo hospedeiro do enclave do container do enclave 176 pelo fato de que o processo do cliente de enclave pode gerenciar a criação do enclave local 176. No caso de enclave remoto, o enclave 176 pode, por exemplo, ser executado em um computador de nuvem Internet onde o proprietário da infraestrutura 152 é um provedor de serviço de computação em nuvem, e o computador da nuvem inclui o hardware confiável 172 que é fabricado pelo fabricante 162.

[0039] O cliente de enclave 104 pode incluir um método de configuração 106 para configurar uma computação solicitada pelo enclave 176. O método de configuração 106 pode incluir causar a criação do container seguro do enclave 176, causando a instanciação do enclave (por exemplo, por enviar uma solicitação para o software não confiável 174 para solicitar a instanciação do enclave), o que pode incluir copiar código binário para o container seguro, e causar ou solicitar que uma computação no enclave, por exemplo, por chamar

Petição 870190060870, de 28/06/2019, pág. 23/143

12/102 um método no código copiado para o container seguro. A computação solicitada pode incluir executar código 180, e dados 182 podem ser informados, ou podem ser um resultado da computação solicitada. Os dados informados para a computação solicitada podem ser criptografados quando fora do enclave, e dados de entrada criptografados podem ser decriptografados antes de serem utilizados dentro do enclave. Uma vez que o enclave 176 tenha completado a tarefa solicitada, os dados representando o resultado da tarefa são criptografados e enviados de volta para o cliente de enclave 104. Quando o cliente de enclave 104 recebe os resultados criptografados, um método de verificação 108 pode confirmar a integridade e o frescor dos resultados recebidos. Um único provedor de software 148 pode proporcionar tanto o código 180 para executar dentro do enclave 176, como pelo menos uma parte do método de verificação 108 que executa como parte do cliente de enclave 104.

[0040] Uma confiança do proprietário dos dados na privacidade de uma parte privada dos dados 182 e de uma parte privada de código 180, bem como confiança na correção dos resultados produzidos pelo enclave 176, podem ser baseadas nas relações confiáveis. Por exemplo, um proprietário de dados 142 pode confiar no cliente de enclave 104, o qual pode não estar executando dentro de um próprio container do enclave. O proprietário dos dados pode ainda confiar no provedor de software 148 do próprio enclave. Além disso, o proprietário dos dados pode confiar no fabricante do hardware confiável 172. O hardware confiável 172 pode assumir várias formas dependendo da arquitetura de enclave utilizada, e pode incluir um módulo de segurança de hardware (HSM), onde o HSM é de acordo, por exemplo, com o padrão de Módulo de Plataforma Confiável (TPM). O hardware confiável 172 pode incluir, por exemplo, um TPM e pode de outro modo compreender somente hardware. Por exemplo, uma

Petição 870190060870, de 28/06/2019, pág. 24/143

13/102 implementação de hardware confiável 172 utilizando a arquitetura de enclave VSM da Microsoft pode incluir um processador de produto com instruções para instruções de virtualização de sistema operacional e um TPM. A arquitetura de enclave VSM da Microsoft pode incluir um virtualizador para gerenciar partições convidadas (processadores virtuais), e o virtualizador pode expor interfaces de hypercall para as partições convidadas para permitir que as partições convidadas interajam com o virtualizador. Um container do enclave na arquitetura VSM da Microsoft pode ser implementado como um tipo especial de partição convidada. Um exemplo de hardware confiável 172 com a arquitetura de enclave SGX da Intel pode incluir um processador com instruções especiais específicas do enclave e funcionalidade de segurança.

[0041] Um enclave, tal como o enclave 176, pode proporcionar um ambiente de execução isolado que pode proteger código ou dados, tal como o código 180 e os dados 182, por proporcionar uma região de memória com restrições em relação à leitura, gravação ou execução a partir desta região protegida. Esta região de memória protegida é um container seguro para código e dados confidenciais. Restrições em relação à execução a partir de uma região de memória protegida do enclave podem incluir restrições em relação à execução de transferência, tal como instruções de chamada ou salto, entre código fora do enclave para código dentro do enclave, e vice-versa. Diferentes restrições podem ser impostas entre chamar dentro do enclave a partir do exterior do enclave e chamar fora do enclave a partir do interior do enclave. A imposição destas transferências de execução entre o interior e o exterior de um enclave podem ser proporcionadas por hardware, por exemplo, com tecnologia de hardware de virtualização de produto ou com hardware especializado tal como a plataforma SGX da Intel.

Petição 870190060870, de 28/06/2019, pág. 25/143

14/102 [0042] A Figura 2 representa um processo ilustrativo 200 para passagem de mensagem com uma garantia de sigilo. Uma garantia de sigilo proporciona algum nível de garantia que a comunicação entre duas partes, tal como Anne 210 e Ben 230 neste exemplo, permaneça oculta de terceiras partes quando mensagens são passadas através de um meio de comunicação público ou não protegido tal como a rede 218. Neste exemplo, Anne 212 gostaria de enviar uma mensagem confidencial para Ben 230. Um bloco de mensagem 212 contendo dados confidenciais é criptografado utilizando a chave pública 216 por uma operação de criptografia 214. A operação de criptografia 214 pode ser, por exemplo, o Padrão de Criptografia Avançada - Modo de Galois / Counter (AES-CGM), mas também pode ser qualquer operação de criptografia conhecida pelos versados na técnica de criptografia digital. O bloco criptografado 220 pode passar por uma rede 218 para Ben, onde o bloco criptografado 234 é decriptografado com a chave privada 236 para produzir o bloco de mensagem decriptografado 232 para Ben. Com seleção cuidadosa de chaves e algoritmos de criptografia, como é conhecido na técnica de criptografia de dados de computador, a mensagem pode permanecer confidencial mesmo quando passando através de uma rede pública.

[0043] A Figura 3 representa um processo ilustrativo 300 para passagem de mensagem com uma garantia de integridade. Uma garantia de integridade proporciona algum nível de segurança de que a comunicação entre duas partes, tal como Anne 310 e Ben 350 neste exemplo, não é adulterada ou de outro modo alterada quando as mensagens são passadas através de um meio de comunicações público ou não protegido tal como a rede 340. No exemplo da Figura 3, Anne 310 envia uma mensagem 314 para Ben 350 de modo que existe confiança de que a mensagem 314 não será adulterada ou de outro modo corrompida quando Ben 350 recebe a mesma. Para

Petição 870190060870, de 28/06/2019, pág. 26/143

15/102 proporcionar esta garantia de integridade, um processo de hashing seguro 316 opera em relação à mensagem 314 para produzir um valor hash 318. O valor hash 318 é assinado pelo processo de assinatura 320 utilizando a chave privada de Anne para produzir uma assinatura 342. A assinatura 342 pode ser enviada através de uma rede pública 340 ou de outro processo de comunicação não protegido junto com uma cópia da mensagem 314 como a mensagem 344. Então, Ben recebe uma mensagem 354 para a qual Ben gostaria de verificar a integridade, de modo que Ben pode ter confiança de que a mensagem 354 é a mesma que a mensagem 314 que Anne enviou após ter passado através de uma rede não confiável 340. Para verificar a integridade, a mensagem recebida 354 é processada pelo hashing seguro 356 que é idêntico ao hashing seguro 316 para produzir o valor hash 358. A assinatura recebida 342 é verificada pelo processo de verificação de assinatura 360 utilizando a chave pública de Anne. O valor hash 318 que é extraído a partir da assinatura 342 é então comparado com o valor hash 358 para verificar 380 que as assinaturas são as mesmas. Se elas forem as mesmas, a mensagem é aceita 384 como possuindo integridade. Alternativamente, se a mensagem 314 foi alterada de qualquer modo antes de ser recebida como a mensagem 354, então a assinatura não estará correta e a mensagem será rejeitada 388.

[0044] Em algumas modalidades, o hashing seguro 316 e o hashing seguro 356 podem ser uma função hash criptográfica. Uma função hash criptográfica é uma função unidirecional que mapeia dados de tamanho arbitrário para uma cadeia de bits com um tamanho fixo (tipicamente muito menor). A saída de uma função hash pode ser chamada de um valor hash ou simplesmente de um hash. Uma boa função hash será unidirecional pelo fato de que será difícil determinar a entrada arbitrariamente dimensionada somente dada a saída hash.

Petição 870190060870, de 28/06/2019, pág. 27/143

16/102

Com uma boa função hash, mesmo uma pequena modificação na entrada irá produzir uma modificação na saída.

[0045] Um sistema de comunicação pode combinar as garantias de sigilo e de integridade. Por exemplo, a criptografia de bloco de mensagem da Figura 2 pode ser combinada com a assinatura de um hash da mensagem da Figura 3. O sistema de combinação pode requerer dois conjuntos de pares de chaves pública / privada, um para o remetente e um para o receptor. Um sistema de combinação pode utilizar uma chave privada no receptor para decriptografar uma mensagem (chave privada de Ben como na Figura 2), enquanto utilizando outra chave privada para assinar o hash da mensagem (chave privada de Anne como na Figura 3).

[0046] A Figura 4 representa um processo ilustrativo 400 para passagem de mensagem com uma garantia de frescor. Uma garantia de frescor proporciona algum nível de segurança de que quando as várias mensagens são enviadas a partir de uma parte para outra, tal como a partir de Anne 410 para Ben 450 neste exemplo, a mensagem recebida no receptor é a mensagem mais recente. Uma garantia de frescor pode ser construída sobre uma garantia de integridade, e pode impedir ataque de reprodução. Com uma garantia de integridade, é difícil para uma terceira parte com intenção maldosa criar sua própria mensagem e enviar a mesma para Ben de modo que Ben entenda a mensagem como tendo sido criada por Anne. Entretanto, uma terceira parte pode pegar a mensagem realmente criada por Anne, talvez observada em um momento à medida que ela foi enviada através de uma rede pública, e a terceira parte pode reenviar a mesma para Ben em outro momento posterior (isto é, reproduzir a mensagem). Ben irá determinar que a mensagem foi realmente criada por Anne (devido a ela ter sido), mas Ben não irá saber que Anne não é a pessoa que enviou a mesma naquela hora. Isto pode ser chamado de um ataque

Petição 870190060870, de 28/06/2019, pág. 28/143

17/102 de reprodução em relação a Ben ou Anne pela terceira parte. A Figura 4 é uma solução ilustrativa para impedir ataques de reprodução por proporcionar uma garantia de frescor utilizando nonces e marcas de tempo. Um nonce é um número aleatório de uso único, acoplado com um sistema para garantir que o mesmo número nunca seja utilizado como um nonce mais do que uma vez. Em alguns sistemas, um nonce pode simplesmente ser um número aumentando de forma monotônica, de modo que cada número utilizado é mais elevado do que todos os números que vieram antes do mesmo.

[0047] Na Figura 4, a mensagem da Anne 414 pode ser enviada através de uma rede pública 430 como a mensagem 436 junto com o nonce 434 e a marca de tempo 432. O nonce 434 é gerado por um gerador de número pseudoaleatório criptograficamente seguro (CSPRNG) 426, e a marca de tempo 432 é produzida por um relógio sincronizado 424. Existem vários sistemas CSPRNG que são conhecidos pelos versados na técnica de criptografia digital. O relógio sincronizado 424 no lado da rede 430 da Anne é sincronizado com o relógio sincronizado 480 no lado da rede de Ben. No lado do Ben, quando uma mensagem 454 é recebida, o nonce acompanhante 434 é armazenado em uma cache de nonces recentes 470. O frescor desta mensagem 450 recebida pode ser verificado com dois testes. Primeiro, o nonce 434 é testado na caixa 460 por se comparar o nonce 434 com a cache de nonces recentes 470 para determinar se o nonce atualmente recebido 434 foi visto antes. Se o nonce recebido 434 tiver sido visto antes, a mensagem 454 é rejeitada como uma mensagem de reprodução na caixa 468. Se o nonce recebido 434 não tiver sido visto antes, a mensagem é determinada como OK na caixa 464 para este primeiro teste. Segundo, a marca de tempo recebida 432 é comparada com o relógio sincronizado local 490. Se a marca de tempo for recente, a mensagem 454 é determinada como sendo aceitável na

Petição 870190060870, de 28/06/2019, pág. 29/143

18/102 caixa 494, caso contrário, a mensagem 454 é rejeitada como expirada na caixa 498. A quantidade de retardo tolerado quando determinando se uma marca de tempo recente é recente na caia 490 pode depender do desalinhamento de relógio esperado entre o relógio sincronizado 424 e o relógio sincronizado 480 e nos retardos de tempo no processamento da mensagem e na transmissão através da rede 430.

[0048] Um sistema de comunicação pode combinar uma garantia de frescor com uma ou ambas dentre uma garantia de sigilo como na Figura 2 e uma garantia de integridade como na Figura 3. Em um sistema combinando todas as três, a mensagem 436 enviada através da rede 430 será uma versão criptografada da mensagem original da Anne 414, e uma assinatura compreendendo um hash assinado da mensagem 414 seria incluída junto com a marca de tempo 432, com o nonce 434 e com a mensagem 436.

[0049] A Figura 5 representa um processo ilustrativo 500 para atestação de software de um enclave. A atestação de software, quando combinada com um protocolo de acordo de chave tal como este da Figura 6, pode garantir para um verificador que ele estabeleceu um segredo compartilhado com um pedaço específico de software que é hospedado dentro de um container isolado criado pelo hardware confiável. Na modalidade da Figura 5, um cliente de enclave 510 (o verificador da atestação) pode desejar utilizar os serviços de computação seguros do enclave na plataforma confiável 530. A plataforma confiável 530 é hospedada em um computador (não representado) de modo que a plataforma confiável 530 pode compreender um subconjunto do computador de hospedagem. A plataforma confiável 530 pode compreender elementos de hardware e elementos de software do computador de hospedagem. O enclave compreende um container seguro do enclave 536 e o código e os dados dentro do mesmo, tal como código e dados públicos 538 e

Petição 870190060870, de 28/06/2019, pág. 30/143

19/102 código e dados secretos 542.

[0050] Três processos são combinados no processo ilustrativo 500: um processo de troca de chaves que produz uma chave compartilhada SK; um processo de atestação para atestação para o cliente de enclave 510 do enclave na plataforma confiável 530; e uma computação segura são feitos. A chave compartilhada SK a partir do primeiro processo é utilizada para comunicar entrada e saída da computação segura. Na troca de chaves, o cliente de enclave calcula g^A, armazenada na caixa 512, a partir da chave privada do cliente do enclave A e uma função geradora g, por exemplo, como descrito abaixo para o protocolo de troca de chave de Diffe-Hellman (DKE) da Figura 6. A g^A calculada é então enviada na mensagem 520 para a plataforma confiável 530. A mensagem 520 pode ser seguramente enviada sem criptografia e antes da atestação estar completa. O software dentro do container do enclave seguro 536 pode utilizar uma chave privada do enclave B para calcular g^B utilizando a mesma função geradora g. Tanto B como g^B podem ser armazenadas no container do enclave na caixa 540.

[0051] Para atestar a identidade do enclave (para proporcionar segurança sobre qual código executando dentro do container do enclave seguro 536), uma mensagem de atestação 522 é enviada para o cliente do enclave 510. Uma mensagem de atestação pode ser uma mensagem especial assinada para integridade como na Figura 3. A mensagem especial pode conter informação de identidade sobre o enclave. Quando combinada com DKE como na modalidade da Figura 5, a mensagem especial também pode incluir parâmetros de troca de chave. Na modalidade da Figura 5, o estado inicial 538 do container do enclave seguro 536 de código público e dados públicos é utilizado como uma identidade do enclave, apesar de outras identidades serem possíveis. Ao invés de enviar todo o estado inicial 538 em uma

Petição 870190060870, de 28/06/2019, pág. 31/143

20/102 mensagem de atestação, um hash do estado inicial, M = Hash (Estado Inicial), é ao invés disso enviado. A mensagem de atestação 522 inclui o conteúdo da mensagem (M e g^B) e uma assinatura do conteúdo da mensagem (SignAK(Hash(g^B), Μ)). A assinatura do conteúdo da mensagem pode ser criada, por exemplo, por software dentro do container do enclave seguro 536 solicitando a plataforma confiável 530 hospedando o enclave para atestar um hash da g^B calculada e da identidade do enclave. A plataforma confiável 530 pode fazer isso por proporcionar uma assinatura utilizando a chave de atestação da plataforma (AK) 532 para produzir (SignAK(Hash(g^B), M)). Neste exemplo, a identidade do enclave é um hash M do estado inicial 538, mas outras declarações de identidade são possíveis. Esta assinatura da atestação (SignAK(Hash(g^B), M)) liga o valor g^B com a identidade do enclave M e também liga tanto g^B como M com a plataforma confiável 530. O cliente do enclave 510 pode então verificar a mensagem de atestação por verificar a assinatura da atestação e a identidade do enclave. A assinatura pode ser verificada como na Figura 3 utilizando uma chave pública correspondendo à chave de atestação AK. A variação da assinatura pode proporcionar uma garantia de integridade da identidade do enclave na mensagem de atestação. A identidade do enclave pode ser verificada por se comparar a informação de identidade na mensagem de atestação com um valor de identidade independentemente conhecido. Por exemplo, se a informação de identidade na mensagem de atestação for um hash do estado inicial do enclave, o cliente do enclave 510 pode conhecer o hash do estado inicial, ou pode estar apto a calcular tal hash a partir de um estado inicial conhecido, e este valor pode então ser comparado com o valor de identidade proporcionado na mensagem de atestação.

[0052] Para produzir a chave compartilhada SK, tanto o cliente do enclave 510 como o código dentro do container seguro 536 podem

Petição 870190060870, de 28/06/2019, pág. 32/143

21/102 gerar g^AB (a função geradora g aplicada para o produto de A vezes B) que pode servir como a chave compartilhada SK. A chave compartilhada SK pode ser utilizada para criptografar mensagens para sigilo entre o cliente do enclave 510 e o enclave, por exemplo, para enviar dados de entrada e emitir dados de saída para o código dentro do container do enclave 536. Observe que a chave compartilhada é produzida independentemente em cada lado do canal de comunicação nas caixas 540 e 514 sem o cliente do enclave ou o enclave conhecer a chave privada do outro. Por exemplo, na modalidade da Figura 5, o código e os dados secretos podem ser proporcionados de forma segura pelo cliente do enclave 510 por criptografar o código e os dados secretos com a chave compartilhada SK anteriormente estabelecida, produzindo EncsK(secret code/data) antes de enviar a mesma em uma mensagem 524 para a plataforma confiável 530. Em outras modalidades, o código e os dados secretos 542 executados ou utilizados por um container do enclave seguro 536 podem se originar a partir de outras localizações. Uma computação segura pode ser executada dentro do container do enclave seguro 536 utilizando o código e/ou os dados secretos 542 para produzir um resultado de computação 544. Os resultados de computação 517 podem ser então de forma segura comunicados de volta para o cliente do enclave 510 pela criptografia dos resultados com a chave compartilhada SK (EncsK(results)) antes de enviar os mesmos para o cliente do enclave na mensagem 526.

[0053] O processo da Figura 5 descrito acima proporciona uma garantia para um cliente do enclave que ele está se comunicando com um enclave real de alguma identidade, e que o enclave é protegido pela plataforma de enclave. Isto não proporciona qualquer garantia para o código dentro do container do enclave sobre a entidade no outro lado do canal de comunicação. Em uma modalidade alternativa

Petição 870190060870, de 28/06/2019, pág. 33/143

22/102 (não representada), tal garantia sobre o cliente do enclave pode ser proporcionada por se executar o cliente do enclave como um próprio enclave. Nesta modalidade alternativa, o cliente do enclave pode solicitar que a plataforma de enclave confiável forneça uma assinatura no hash de g^A, o qual então pode ser verificado pelo outro enclave. [0054] A atestação pode ser feita local mente ou remotamente. Na Figura 5, o cliente do enclave 510 pode ou não residir no mesmo computador que a plataforma confiável 530, de modo que as comunicações entre o cliente do enclave 510 e a plataforma confiável 530 podem ocorrer dentro de um único computador (por exemplo, por passar memórias temporárias de dados entre diferentes processos no mesmo computador), ou pode ocorrer através de uma rede de computadores que conecta o cliente do enclave 510 com a plataforma confiável 530. A atestação local pode ser executada quando o cliente do enclave 510 e a plataforma confiável 530 são hospedados no mesmo computador local. O artefato, ou resultado, da atestação local é chamado de um relatório de atestação, e é Sign(Hash(g^A),M) no exemplo da Figura 5. A atestação remota pode ocorrer quando o cliente do enclave 510 e a plataforma confiável 530 estão hospedados em computadores diferentes. O artefato, ou resultado, da atestação remota é chamado de quota de atestação, o que em alguns casos pode ser muito similar ou idêntico a um relatório de atestação local. Em outros casos, uma quota de atestação pode incluir um artefato adicional de confiança relacionado com o computador ou plataforma nativa proporcionando a quota. Tal artefato adicional de confiança pode inclui um certificado de saúde do hospedeiro tal como um registro de ocorrências TCG associado com um TPM. A atestação de um enclave pode ser executada em qualquer camada de uma identidade do enclave. Um enclave pode possuir uma identidade aninhada ou hierárquica, e a atestação para níveis superiores de

Petição 870190060870, de 28/06/2019, pág. 34/143

23/102 identidade pode atestar que um enclave instanciado é um membro de um grupo progressivamente maior de potenciais instanciações de enclave à medida que o nível de identidade aumenta. Os níveis superiores podem corresponder a um superconjunto de potenciais instanciações de enclave de nível inferior. Uma hierarquia de identidades ilustrativa pode incluir, a partir do nível mais baixo, mais especifico, até o mais alto, níveis menos específicos podem ser: ExactHash, InstanceHash, ImagelD, FamilylD e AuthorlD.

[0055] A identidade de um enclave pode ser derivada a partir de arquivos binários (binários do enclave) carregados no container seguro do enclave. Um binário do enclave pode ser assinado por seu autor utilizando uma chave privada do autor. Para uma atestação de nível ExactHash, o estado inicial 538 é utilizado para calcular um relatório de atestação (a entrada para uma função hash para produzir um relatório de atestação) pode incluir todos os conteúdos de cada arquivo binário carregado dentro do container seguro 536, exceto para binários associados com a plataforma confiável 530.

[0056] A atestação no nível de identidade InstanceHash pode incluir um subconjunto do estado inicial 538. O subconjunto pode ser especificado na hora em que os arquivos binários do enclave (os arquivos binários) que são carregados dentro do container seguro 536 foram originalmente assinados pelo autor destes arquivos binários do enclave. Por exemplo, um primeiro (ou principal) arquivo binário do enclave pode incluir uma lista de identidades de outros arquivos binários do enclave dos quais o primeiro arquivo binário do enclave depende. Para cada identidade listada, um indicador pode ser incluído no primeiro arquivo binário para indicar se cada arquivo binário listado é medido ou não pela função hash para produzir um relatório de atestação InstanceHash.

[0057] A atestação de níveis superiores de um ID do enclave pode

Petição 870190060870, de 28/06/2019, pág. 35/143

24/102 não incluir executar todo o conteúdo de quaisquer binários do enclave através de uma função hash. Ao invés disso, somente uma estrutura de dados de IDs pode ser executada através da função hash. Por exemplo, um arquivo binário do enclave pode incluir uma lista de identificadores do enclave de nível superior, tais como identificadores universalmente únicos (UUIDs), indicando: um ID de imagem (ImagelD) único para este arquivo binário do enclave particular; um ID de família (FamilylD) único para um grupo de arquivos binários do enclave que inclui este arquivo binário do enclave particular e que são criados pelo mesmo autor; e um ID de autor (AuthorlD) único para um grupo de famílias de arquivos binários do enclave que são todos criados pelo mesmo autor. O ImagelD, FamilylD e AuthorlD podem ser assinados pelo autor de um binário do enclave na hora em que o binário é originalmente assinado. A falsificação de identidades do enclave pode ser impedida onde o cliente do enclave pode acessar os binários do enclave e verificar a assinatura do autor nestes binários utilizando a chave pública do autor (ou uma chave pública associada com o autor). Isto verifica a integridade dos binários do enclave, incluindo quaisquer identidades de nível superior assinadas pelo autor, como tendo sido criada por este autor do enclave.

[0058] A Figura 6 representa um protocolo de Troca de Chaves e Diffe-Hellman (DKE) ilustrativo 600. O DKE é um processo ilustrativo para estabelecer uma chave compartilhada K através de um canal de comunicação possuindo somente uma garantia de integridade; outros processos para criar chaves compartilhadas conhecidos na técnica de criptografia digital podem ser utilizados. No exemplo DKE da Figura 6, uma chave secreta K é compartilhada entre Anne 610 e Ben 650 sem nunca comunicar K explicitamente através de um meio de comunicação público (não seguro) entre Anne 610 e Ben 650. Antes de o processo iniciar, 1) um número primo grande p e 2) um gerador g

Petição 870190060870, de 28/06/2019, pág. 36/143

25/102 em Zp podem ser estabelecidos e conhecidos tanto por Anne como por Ben. O processo então inicia com tanto Anne como Ben escolhendo um número aleatório entre I e p. O número aleatório de Anne é A, escolhido na caixa 612, e o número aleatório de Ben é B, escolhido na caixa 652. Anne utiliza seu número aleatório para calcular gA mod p na caixa 614, e transmite esta quantidade na caixa 616 que é recebida por Ben na caixa 656. Ben utiliza seu número aleatório para calcular g^B mod p na caixa 654. o que é transmitido na caixa 656 para Anne e recebido na caixa 618. Anne pode produzir a chave compartilhada K como (g^B mod p)^A = g^AB mod p na caixa 620 e Ben pode produzir a chave compartilhada K como (g^A mod p)^B = g^AB mod p na caixa 660. De modo a impedir ataques de homem-no-meio, a comunicação entre Anne e Ben através de uma rede não protegida a partir das caixas 616 e 658 pode inclui uma garantia de integridade de mensagem, por exemplo, criada utilizando um processo tal como este da Figura 3.

[0059] A Figura 7 representa uma cadeia de confiança ilustrativa 700 para atestação de software. A cadeia de confiança ilustrativa na atestação de software pode ter a raiz em uma chave de assinatura possuída pelo fabricante da plataforma confiável, tal como a plataforma confiável 530 da Figura 5. A plataforma confiável pode incluir componentes de hardware tais como um processador seguro ou um módulo de segurança de hardware (HSM), e assim, o fabricante pode ser um provedor de hardware de computador e também pode proporcionar software para a plataforma confiável. O fabricante pode ser acreditado pelo verificador 702, e o verificador pode conhecer a chave pública PubRK da chave raiz do fabricante 736. O cliente do enclave 510 da Figura 5 é um exemplo de um verificador 702 que pode desejar ter garantias sobre um container seguro 708. O fabricante pode atuar como uma autoridade de certificado e

Petição 870190060870, de 28/06/2019, pág. 37/143

26/102 proporcionar para cada instância de plataforma confiável que ele produz, por exemplo, cada processador seguro, uma chave de atestação única 722, a qual é utilizada para produzir assinaturas de atestação. O fabricante também emite um certificado de endosso 728 para cada chave de atestação 722. A chave raiz do fabricante 736 inclui uma chave privada PrivRK 734 que é utilizada para assinar o certificado de endosso 728. A assinatura do certificado de endosso proporciona uma garantia de integridade, por exemplo, como apresentado na Figura 3.

[0060] O certificado de endosso 728 inclui uma chave pública PubAK 724 da chave de atestação 722. O certificado de endosso 728 pode indicar que a chave de atestação 722 é para ser utilizada para atestação de software, e pode ser comunicada para o verificador 702. O verificador pode ser qualquer entidade desejando verificar uma atestação do container seguro 708, por exemplo, o verificador 702 pode ser um cliente do enclave 510 da Figura 5 que deseja que uma computação segura seja feita dentro do container seguro 708. O verificador 702 pode inspecionar o certificado de endosso utilizando a PubRK 732 para verificar a integridade e a origem do certificado de endosso. O verificador também pode extrair a PubAK 724 do certificado de endosso. O certificado de endosso pode ser associado com uma política de certificação, a qual pode requerer que a chave de atestação 722 seja utilizada somente para produzir assinaturas de atestação e que a chave privada PrivAK 726 da chave de atestação 722 seja mantida exclusivamente em armazenamento que seja separado da memória do computador geralmente acessível da plataforma confiável, tal como no armazenamento de hardware à prova de adulteração 730. O hardware à prova de adulteração pode ser, por exemplo, hardware de acordo com um padrão de Módulo de Plataforma Confiável (TPM).

Petição 870190060870, de 28/06/2019, pág. 38/143

27/102 [0061] Um container seguro 708 pode ser instanciado na plataforma confiável 736. A instanciação do container seguro 708 pode incluir definir um espaço de memória isolado para o container seguro que é restrito para acesso por processamento não seguro. O processamento não seguro pode incluir, por exemplo, aceso a partir do exterior da plataforma confiável, mas no computador hospedando a plataforma confiável, ou acesso a partir de dentro de outros containers seguros dentro da plataforma confiável. A instanciação do container seguro 708 também pode incluir carregar código público e dados para dentro do container seguro, por exemplo, o estado inicial 535 da Figura 5.

[0062] O container seguro instanciado 708 pode trocar chaves com o verificador 702 para estabelecer uma chave compartilhada para comunicação confidencial. O processo de troca de chaves pode o processo de troca de chaves da Figura 5 ou o processo DKE da Figura

6. O verificador envia a mensagem de troca de chave 1 704 para a plataforma confiável 736, por exemplo, como na caixa 616 da Figura 6, e a plataforma confiável 736 envia a mensagem de troca de chave 2 706 de volta para o verificador 702, por exemplo, como na caixa 658 da Figura 6.

[0063] A assinatura de atestação 710 pode ser criada após o container seguro 708 ser instanciado e a troca de chave ser completada. O container seguro instanciado 708 pode ser medido pela execução de uma função hash criptográfica em todo ou em parte do container seguro. Isto pode incluir executar a função hash através dos conteúdos da memória isolada, e dos arquivos binários que estão carregados dentro da memória isolada, em qualquer outra memória associada com a plataforma confiável que seja utilizada ou afetada durante a instanciação do container seguro, ou em qualquer subconjunto ou parte destes. A saída da execução desta função hash

Petição 870190060870, de 28/06/2019, pág. 39/143

28/102 é a medição 712, a qual é parte da assinatura de atestação 710. Um hash criptográfico das mensagens de troca de chave 704 e 706 também pode estar incluído na assinatura de atestação 710, representado como os dados 714. A medição 712 e os dados 714 podem ser assinados utilizando a chave privada de atestação PrivAK 726. A assinatura de atestação pode ser então enviada para o verificador 702 junto com a medição 712 e com os dados 714. O verificador pode verificar a integridade da assinatura de atestação utilizando a PubAK 724 a partir do certificado de endosso, o que, no exemplo da Figura 7, também permite verificação da integridade da medição 712 e dos dados 714. O verificador 702 pode verificar a integridade do container seguro 708 por comparar a medição 712 com o resultado esperado (o resultado esperado determinado, por exemplo, por localmente executar o mesmo hash da medição 712), e verificar que a assinatura da atestação foi criada para esta instância do percurso de comunicação do verificador particular 702 por inspecionar os dados 714 (por exemplo, devido ao hash dos dados 714 estar ligado com a mensagem de troca de chave 2 706). Após estas operações de verificação e a verificação do certificado de endosso acima, o verificador agora possui alguma segurança de que ele pode estabelecer comunicações possuindo tanto sigilo como integridade com o container seguro 708 utilizando uma chave compartilhada estabelecida, e que o hardware da plataforma confiável pode ser confiável de acordo com seu fabricante, e que o estado do software da plataforma confiável utilizada para criar o container seguro é conhecido. O verificador 702 está agora pronto para solicitar processamento seguro dentro do container seguro 708 utilizando código privado e/ou dados privados.

PLATAFORMA E PRIMITIVAS DE ABSTRAÇÃO DE ENCLAVE [0064] A Figura 8 é um diagrama de blocos das interfaces de

Petição 870190060870, de 28/06/2019, pág. 40/143

29/102 componente de software para um sistema de enclave local. O sistema de enclave 800 inclui um computador 810 com a plataforma de enclave nativa 812 hospedando o enclave 814 e um cliente 816 do enclave. A plataforma nativa 812 pode ser um componente de hardware e/ou de software baseado, por exemplo no SGX da Intel ou no VSM da Microsoft. O enclave 810 pode ser o enclave 176 da Figura

1. Um protocolo nativo 844 para enclaves pode ser utilizado para comunicação entre o enclave 814, o cliente 816, e a plataforma nativa 812. Como representado na Figura 8, o protocolo nativo 844 inclui a interface 820 no enclave 814, as interfaces 822 e 824 na plataforma nativa e a interface 826 no cliente. Estas interfaces podem ser APIs ou ABUs nos componentes de software.

[0065] O uso destas interfaces de software 820,822, 824 e 826 pode incluir uma transferência de controle de execução entre os componentes de software. Uma transferência de controle pode incluir executar uma instrução de chamada ou de salto para um ponto de entrada (um endereço de uma instrução) no componente de software para o qual o controle está sendo transferido. Por exemplo, se a plataforma nativa 812 for um componente de software, a transferência de controle a partir da plataforma nativa 812 para o cliente 816 pode ocorrer via a interface de software 826 quando uma instrução de chamada ou de salto na plataforma nativa 812 é executada especificando um endereço dentro do cliente 816 a ser chamado o para o qual saltar. O endereço especificado dentro do cliente 816 pode ser um ponto de entrada para uma função ou método na interface 816. A transferência de controle é indicada como uma seta na Figura 8, por exemplo: a partir da plataforma nativa 812 para o enclave 814 via a interface 820; a partir do enclave 814 para a plataforma nativa 812 via a interface 822; a partir do cliente 816 para a plataforma nativa 812 via a interface 824, e a partir da plataforma nativa 812 para o cliente 816

Petição 870190060870, de 28/06/2019, pág. 41/143

30/102 via a interface 826. Um protocolo nativo 844 pode incluir padrões de comunicação vias as interfaces 820, 822,824 e 826.

[0066] Em algumas modalidades, a plataforma nativa 812 pode ser implementada pelo menos em parte como um componente de hardware, por exemplo, com instruções de processador especial para gerenciar um enclave. Tal instrução de hardware especial pode ser executada como parte de uma um componente de software da plataforma nativa 812. Em modalidades alternativas, pode não existir componente de software para algumas ou todas as funções da plataforma nativa 812. Nestas modalidades alternativas, as interfaces da plataforma nativa 822 e 824 podem ser instruções de hardware ao invés de pontos de entrada de software, de modo que uma função da plataforma nativa 812 pode ser utilizada pelo enclave 814 ou pelo cliente 816 ou pode ser utilizada pela execução de uma instrução de hardware especial ao invés de no enclave 814 ou no cliente, respectivamente, ao invés de executar uma instrução de chamada ou de salto.

[0067] Em algumas modalidades, o cliente 816 do enclave 814 pode ele próprio ser um enclave. Por exemplo, um cliente do enclave 816 pode utilizar a interface 824 para solicitar que o enclave 814 seja criado. Nestas modalidades, a comunicação entre o enclave 814 e o cliente 816 através da plataforma nativa 812 é na verdade comunicação entre dois enclaves. Quando o cliente 816 também é um enclave, o cliente do enclave 816 também pode utilizar a interface 822 e expor uma interface similar à 820 (não representada).

[0068] A Figura 9 é um diagrama de blocos de interfaces de componente de software para um sistema de enclave local ilustrativo com uma camada de abstração. O sistema de enclave 900 inclui uma plataforma de abstração 912 para tradução entre o protocolo nativo 944 e os protocolos de abstração 940,942. A plataforma nativa 918

Petição 870190060870, de 28/06/2019, pág. 42/143

31/102 pode ser similar à plataforma de abstração 812 da Figura 8, e as interfaces 928 e 930 podem combinar as funções das interfaces 820, 822, 824, e 825 da Figura 8. O protocolo de abstração de enclave 940 inclui as interfaces 920, 922 para o enclave 914, enquanto o protocolo de abstração do cliente 942 inclui as interfaces 924,926 para o cliente 916. Como na Figura 8, o cliente 916 executando no computador 910 pode solicitar a criação do enclave 914 via a interface 924. A camada de abstração 912 pode causar a criação do enclave 914 utilizando o protocolo nativo 944 e as interfaces 928,930 com a plataforma nativa 918. O cliente 916 e o enclave 914 podem utilizar os protocolos de abstração 940 e 942 quando a plataforma nativa 918 e o protocolo nativo 944 são baseados em diferentes arquiteturas de enclave, tal como SGX da Intel ou VSM da Microsoft. Como na Figura 8, o cliente 916 do enclave 914 pode ele próprio ser um enclave, e a plataforma nativa 918 pode incluir componentes de hardware e/ou de software.

[0069] O enclave 914 e o cliente 916 podem não se comunicar diretamente e podem ao invés disso somente se comunicar via a plataforma de abstração 912. A comunicação direta pode não ser possível ou desejável, por exemplo, devido ao isolamento da memória do enclave 914. O isolamento da memória do enclave pode impedir leitura e gravação ou execução (salto para ou para fora) da memória isolada do enclave.

[0070] O enclave 914 pode incluir instruções localizadas dentro de um container seguro do computador 910. O cliente 916 pode incluir instruções localizadas no espaço de endereços de memória do computador 910, mas fora do container seguro do enclave 914. A plataforma de abstração 912 pode ser implementada de vários modos, incluindo como instruções que estão dentro ou fora do container seguro do enclave 914, e também pode incluir instruções executadas a partir de dentro de hypercalls. No caso onde a plataforma de abstração

Petição 870190060870, de 28/06/2019, pág. 43/143

32/102

912 está incluída pelo menos em parte dentro do container seguro do enclave 914, o código da plataforma de abstração dentro do container seguro pode ser criado separadamente do restante do código do enclave 914 e pode somente interagir com outro código do enclave via APIs /ABIs públicas. Tal código da plataforma de abstração pode ser estaticamente ligado ou dinamicamente ligado com o restante do código dentro do container seguro do enclave. O código da plataforma de abstração estaticamente ligado pode ser código objeto que está associado com a plataforma de abstração e está incluído (estaticamente ligado), junto com código que é mais específico para o enclave 914, dentro de uma imagem binária a partir da qual o enclave 914 pode ser instanciado. No caso de uma plataforma de abstração dinamicamente ligada, o código do enclave que é mais específico para o enclave 914 e o código associado mais geralmente com a plataforma de abstração podem ser originados a partir de imagens binárias separadas. Para um exemplo dinamicamente ligado, veja a Figura 14. [0071] A Figura 10 é um diagrama de blocos de interfaces de componente de software para um sistema de enclave remoto ilustrativo com uma camada de abstração. O sistema de enclave remoto 1000 inclui um enclave 1014 no computador 1010, e um cliente 1056 do enclave 1014 em um computador separado 1050. A combinação do cliente stub 1016 com a plataforma de execução remota de abstração 1052 pode facilitar a interação entre o enclave 1014 e o cliente 1056. Vários elementos no computador 1010 podem ser idênticos ou similares aos elementos identicamente denominados do computador 910 da Figura 9. Em particular, a plataforma de abstração 1012, os protocolos 1040, 1042, 1044 e a plataforma nativa 1018 podem ser similares ou idênticos aos elementos correspondentes 912, 940, 942, 944 e 918, respectivamente.

[0072] O cliente stub 1016 pode se comunicar com a plataforma

Petição 870190060870, de 28/06/2019, pág. 44/143

33/102 de execução remota de abstração 1052 via a comunicação de rede 1080. O protocolo do cliente remoto 1082 e as interfaces 1064, 1066 podem ser similares ao protocolo de abstração de cliente 1042 e às interfaces 1024, 1026. Entretanto, o protocolo do cliente remoto pode incluir funcionalidade adicional para execução remota. Por exemplo, um método na interface 1064 tal como CreateEnclave para solicitar criação de um enclave pode adicionalmente incluir a habilidade de especificar um computador hospedeiro do enclave, tal como o computador 1010, onde se solicita que seja criado um enclave. Uma quota de atestação do enclave 1014 proporcionada para o cliente 1056 via o protocolo do cliente remoto pode ser proporcionada ao invés ou em adição ao relatório de atestação. O computador 1050 com o cliente 1056 pode ou não incluir uma plataforma de enclave nativa 1058. Se a plataforma nativa 1058 estiver presente, ela pode ou não ser de acordo com a plataforma nativa da arquitetura de enclave de amostra 1018, e, por consequência, o protocolo nativo 1044 e o protocolo nativo remoto 1084 podem não ser os mesmos.

[0073] Em uma modalidade alternativa (não representada), o cliente stub 1016 pode não existir, e a plataforma de abstração 1012 pode se comunicar diretamente com a plataforma de execução remota de abstração 1052 através de uma rede.

[0074] Os protocolos de abstração de enclave tais como 940,942,1040,1042, 1082 das Figuras 9 e 10 podem incluir uma variedade de métodos de interface ou de pontos de entrada para gerenciar e utilizar enclaves que são construídos em várias plataformas nativas, tal como a SGX da Intel e a VSM da Microsoft. Estes métodos podem proporcionar primitivas de enclave que podem ser implementadas nas várias plataformas nativas, por consequência, proporcionando uma abstração das plataformas nativas. As primitivas de enclave reveladas neste documento incluem gerenciamento de

Petição 870190060870, de 28/06/2019, pág. 45/143

34/102 ciclo de vida do enclave, atestação, selagem de dados, transferência de controle, contadores monotônicos, e tempo confiável.

[0075] As primitivas para o gerenciamento de ciclo de vida de enclave podem incluir métodos para causar a instanciação ou o término de um enclave tal como o enclave 914. As primitivas de gerenciamento de ciclo de vida podem ser uma parte do protocolo de abstração do cliente 942, e, mais especificamente, podem ser implementadas pela plataforma de abstração 912 como parte da interface 924 para uso pelo cliente 916.

[0076] Um método para instanciar ou criar um enclave pode incluir especificar uma imagem executável do código e/ou dos dados a serem carregados dentro da memória isolada do container do enclave seguro. Este código, antes ou após o mesmo ser carregado dentro do container do enclave, pode se tornar parte do estado inicial utilizado para atestação do enclave instanciado (como explicado acima com respeito à Figura 5). Por exemplo, uma imagem executável (um binário do enclave) do enclave pode ser especificada por um cliente do enclave por proporcionar um ponteiro para uma memória temporária na memória contendo a imagem executável. Alternativamente, uma imagem do enclave pode ser especificada pela indicação de um arquivo em um sistema de arquivos contendo o binário do enclave. Em algumas modalidades, a imagem do enclave especificada pode ser criptografada; e outras modalidades, o enclave pode não criptografado; em outras modalidades, o enclave pode ser parcialmente criptografado. A medição do binário do enclave para atestação pode ocorrer sobre uma imagem executável criptografada ou após a decriptografia.

[0077] O código e/ou os dados a serem carregados inicialmente no enclave podem ser indicados pela especificação de um arquivo contendo a imagem primária do enclave. Em adição este código e/ou

Petição 870190060870, de 28/06/2019, pág. 46/143

35/102 dados, uma imagem primária do enclave pode incluir metadados adicionais, tais como um tamanho desejado do enclave (a quantidade de memória requerida dentro do container do enclave), localizações de pontos de entrada dentro do código no arquivo, e uma lista de arquivos de imagens dependentes. Os arquivos de imagem dependentes são outros (não primários) arquivos de imagem que também podem ser carregados no enclave junto com o código e os dados no arquivo de imagem primário. Os arquivos de imagem dependentes podem eles próprios conter listas de arquivos de imagem dependentes adicionais. No caso do sistema de enclave local da Figura 9, as imagens primárias e dependentes podem ser arquivadas em qualquer dispositivo de armazenamento acessível, tal como via um sistema de arquivos localmente acessível. No caso do sistema de enclave remoto da Figura 10, o arquivo de imagem primária pode estar em qualquer dispositivo de armazenamento acessível para o computador 1010 ou para o computador 1050. Se o cliente 1056 solicitar a criação de um enclave no computador 1010 utilizando a imagem primária localizada no computador 1050, a plataforma de execução remota de abstração e o cliente stub 1016 podem se coordenar para copiar o arquivo de imagem primária especificado para o computador 1010.

[0078] CreateEnclave é um método ilustrativo para instanciar um enclave. O método CreateEnclave pode ser descrito com pseudocódigo:

HANDLE

CreateEndave(

PCWSTR enclavePath, Jn_ DWORD flEndaveType, In DWORD dwFlags,

J'n _ read s_ b y tes „(d w Infol.ength) PCVOID enclavelnformation, In DWORD dwínfoLength, _Out_opt_ PDWORD encIavéError )

Petição 870190060870, de 28/06/2019, pág. 47/143

36/102 [0079] O pseudocódigo utilizado para descrever métodos neste documento pode utilizar várias convenções de pseudocódigo para definir interfaces API. Por exemplo, parâmetros de função, tal como enclavePath acima, podem ser decorados com ln_ ou _Out_ para indicar que um parâmetro é um parâmetro de entrada ou de saída, respectivamente. Out_opt_ pode indicar um parâmetro de saída opcional. Palavras todas em maiúsculas pode indicar um tipo de dado. HANDLE pode ser número, tal como um número de 32 bits, utilizado para indiretamente se referir a alguma coisa. Por exemplo, o método CreateEnclave acima retorna uma HANDLE para o chamador de CreateEnclave, e que HANDLE pode ser um handle do enclave que foi criado; PCWSTR pode ser um ponteiro para algum tipo de cadeia de texto; DWORD pode ser quantidade de 32 bits não sinalizada; PCVOID pode ser um ponteiro para dados de um tipo não especificado; BOOL pode ser um valor binário.

[0080] CreateEnclave pode permitir que um cliente, tal como o cliente 916, crie um enclave e carregue a imagem primária dentro do enclave. Qualquer informação de configuração do enclave nesta imagem pode estar associada com o enclave instanciado. CreateEnclave pode incluir os seguintes parâmetros:

[0081] IpEnclaveName: pode especificar o percurso para a imagem primária do enclave, o que nas implementações pode ser algum outro tipo de identificador para identificar o código e/ou os dados da imagem primária do enclave, tal como uma handle para um arquivo aberto, um identificador de recurso uniforme (URI), ou um identificador que é utilizado em uma consulta externa. Por exemplo, um identificador globalmente único (GUID) pode ser utilizado como uma chave em uma base de dados de imagens primárias. Em outras implementações, este parâmetro pode identificar uma região da memória que contém a imagem primária do enclave.

Petição 870190060870, de 28/06/2019, pág. 48/143

37/102 [0082] flEnclaveType: pode especificar o tipo de enclave a criar (no caso de uma imagem do enclave suportar vários tipos). Pode ser estabelecido para DEFAULT no caso de o binário suportar somente um enclave ou o desenvolvedor tiver explicitamente especificado um valor preestabelecido. dwFlags pode especificar uma ou mais ações predeterminadas a serem executadas quando criando enclaves e carregando a imagem primária do enclave.

[0083] enclavelnformation: pode ser um parâmetro de entrada opcional para configuração em tempo de execução do enclave.

[0084] IpEnclaveError: pode especificar um parâmetro opcional para retornar um código de erro específico da arquitetura.

[0085] Quando da conclusão com sucesso, CreateEnclave pode retornar um handle para o enclave. Quando com erro, NULL pode ser retornar. Outros identificadores (GUID, URI, etc.) também podem ser retornado sem divergência do escopo desta revelação. Por simplicidade, este relatório descritivo irá descrever as APIs utilizando um handle. A criação do enclave pode falhar, por exemplo, devido à ausência de memória do enclave, ausência de suporte para o tipo de enclave especificado na plataforma de abstração ou na plataforma nativa, ou a criação pode falhar devido às políticas explícitas de configuração impedindo um enclave de um tipo específico executar no sistema.

[0086] As implementações de CreateEnclave e de outro método API descritos abaixo podem excluir um ou mais dos parâmetros do método descritos. Por exemplo, com respeito a CreateEnclave, o IpEnclaveName, flEnclaveType, dwFlags,e enclavelnformation podem ser excluídos, utilizando um valor predeterminado especificado para esta API particular. O argumento IpEnclaveError também pode ser excluído da API, e métodos alternativos para verificar erros na chamada de API podem ser opcionalmente implementados.

Petição 870190060870, de 28/06/2019, pág. 49/143

38/102 [0087] CreateEnclave pode ser responsável por carregar todos os módulos dependentes como especificado na imagem primária do enclave. A imagem primária do enclave pode ser um arquivo de execução portátil (PE) que especifica outros arquivos de imagem binários dos quais a imagem primária depende. CreateEnclave também pode executar inicialização específica da plataforma nativa, tal como medições de finalização para atestação, alocar estruturas para segurança da camada de transporte (TLS) e/ou outros protocolo de acordo de chave e de comunicação, etc. As interfaces de protocolo de abstração de enclave 920, 922 (incluindo métodos, por exemplo, para selagem de dados e atestação) podem ser operáveis uma vez que a inicialização do enclave tenha completado.

[0088] TerminateEnclave é um método ilustrativo para terminar um enclave:

V01D

TemtinateEí jd a ve(

HANDL-E hEnclave )

[0089] TerminateEnclave pode ser utilizado para destruir um enclave. Nas implementações, destruir um enclave pode incluir forçar todos os encadeamentos do enclave a retornar para o hospedeiro ou a terminarem, e/ou liberar a memória associada com o enclave. Chamar TerminateEnclave em um enclave em execução pode terminar o mesmo e liberar todos os recursos associados com o enclave.

[0090] A plataforma de abstração de enclave 912 pode incluir primitivas de transferência de controle que podem ser utilizadas, por exemplo, para transferir controle entre um enclave e seu cliente. As primitivas de transferência de controle podem permitir comunicação entre o enclave 914 e o cliente 916 por iniciarem a execução de código em um ponto de entrada no outro componente. As primitivas de transferência de controle de execução permitem passagem de dados

Petição 870190060870, de 28/06/2019, pág. 50/143

39/102 para dentro / fora dos enclaves por permitir que parâmetros sejam associados com uma solicitação de transferência de controle; os parâmetros podem especificar itens de dados individuais (os próprios parâmetros são comunicados) ou os parâmetros podem ser ponteiros para áreas de memória (memória temporárias apontadas pelos parâmetros são comunicadas). Estas primitivas podem permitir transferência de controle independente de limitações em relação a diretamente chamar ou saltar entre o enclave 914 e o cliente 916 devido às restrições de segurança em relação ao container do enclave.

[0091] Para chamar dentro de um enclave, a interface 924 pode incluir mecanismos para permitir que um cliente 916 chame dentro de um enclave 914 via a interface 920. Por exemplo, a interface 924 pode incluir os métodos GetProcAddress e CallEnclave:

typedefPVOJD (*.ENCPROC)(PVOf.D);

ENCPROC

Geâ*rocAddress(

HMODULE hEndave,

In LPCTSTR IpProcName )

BOOL

CdlEndavd.n(

Jn_ ENCPROC pCdlin,

In. PVOID pParatneter,

,.P^UL PVOID pRètuns )

[0092] Um cliente do enclave, tal como o cliente 916, pode chamar dentro do enclave, tal como o enclave 914, utilizando o ponteiro de função retornado por GetProcAddress(). O Parâmetro IpProcName pode associar a função exportada na imagem primária do enclave. Por exemplo:

// Chama função Callin para enclave.

Petição 870190060870, de 28/06/2019, pág. 51/143

40/102

ENCPR.OC pCallín - (ENCPROC) GetProcAddress(hEnchve, ‘'CallínExample);

PVOID pParameter; // Ponteiro para memória

Se (NULL !=pCallin) {

CallEnclaveln(pCallin, pParameter);

} [0093] Em outras modalidades de GetProcAddress, IpProcname pode ser outro identificador da função exportada específica, tal como um número, tal como uma seleção a partir de uma enumeração de pontos de entrada exportados a partir de uma imagem de enclave, ou outro identificador não textual correspondendo à função. Outras modalidades de CallEnclaveln podem adicionalmente pegar um parâmetro de entrada especificando o enclave a ser chamado, por exemplo, o handle retornado de CreateEnclave.

[0094] Quando chamando dentro de um enclave, um encadeamento no processo do cliente pode ser suspenso e um encadeamento do enclave (com ID de encadeamento separado) pode ser utilizado para servir a chamada na solicitação. O código do enclave, executando no encadeamento do enclave, pode então ter acesso à memória que estava anteriormente disponível para o cliente do enclave antes de chamar dentro do enclave. Por exemplo, o cliente pode colocar dados dentro da memória temporária apontada pelo pParameter antes de chamar o método de abstração CallEnclaveln, e então o enclave pode ter acesso à memória temporária apontada por pParameter enquanto servindo a chamada na solicitação. Quando de uma chamada externa, o encadeamento de chamada original (cliente) pode ser utilizado para servir a chamada externa. Reentrância pode ser suportada (por exemplo, uma chamada externa no hospedeiro pode chamar para dentro do enclave novamente).

[0095] Para chamada externa de um enclave, a interface 922 pode

Petição 870190060870, de 28/06/2019, pág. 52/143

41/102 incluir métodos relacionados com os métodos CallEnclavein acima que permitem que um enclave 914 chame externamente o cliente do enclave 916. Por exemplo, o enclave 914 pode chamar externamente qualquer função no processo hospedeiro de um tipo particular, por exemplo, o tipo de função ENCPROC. O ponteiro da função para a mesma pode ser passado utilizando a chamada nos parâmetros para o enclave.

BOOL

Cítl I

In ENCPROC pCaI1out_s _In_ PVOJB pParrnneter, __GuL PVOID pReturn )

[0096] // Chamada externa para função no processo do hospedeiro [0097] ENCPROC pCallout = (ENCPROC) OxFOO, // endereço para alguma função no hospedeiro [0098] PVOID pParameter = // Ponteiro para memória [0099] CallEnclaveOut(pCallout, pSharedMerory [00100] A interface 920 pode incluir pontos de entrada registrados como a função CallinExample acima, e a interface 926 pode incluir pontos de entrada registrados como funções Callout acima. Por exemplo, no caso onde uma imagem primária do enclave está em um formato de imagem executável portátil (PE), os pontos de entrada da função na imagem podem ser listados como pontos de entrada de exportação, e cada tal ponto de entrada exportado pode incluir um nome textual, tal como CallinExample, para identificar e diferenciar os pontos de entrada nesta imagem de enclave PE; em outras implementações, os pontos de entrada de função podem ser marcados com metadados adicionais, tal como um bit indicando que uma função pode ser um ponto de entrada para o enclave. No exemplo acima para chamar externamente ao enclave, o endereço da função de chamada

Petição 870190060870, de 28/06/2019, pág. 53/143

42/102 externa é dado como OxFOO e é somente um exemplo. O endereço real de uma função de chamada externa pode ser determinado de vários modos. Por exemplo, um endereço de função de chamada externa dentro de um cliente pode ser passado para dentro do enclave como um parâmetro para uma função de chamada interna. Em outro exemplo, o endereço de uma função de chamada externa pode ser registrado pelo cliente utilizando uma função tal como RegisterCallOut:

BOOL Regí TOfCal I Out ( hi HNCPROC pCaHoyt,

LPCTSTR IpProcName) [00101] O código dentro do enclave pode obter o endereço da função de chamada externa por chamar uma função complementar tal como GetCallOut:

BOOL GetCaílOtít( _put_ ENCPROC *pCalíout,.

. ia LPCTSTR IpProcName) [00102] Em outras modalidades, os métodos CallEnclaveln e CallEnclaveOut podem na verdade ser o mesmo método. Por exemplo, um único método CallEnclave pode ser utilizado para chamar internamente e chamar externamente a um enclave. Em situações onde o cliente do enclave 916 também é um enclave, a chamada para fora do enclave 914 para o cliente 916 também ser chamar internamente dentro de um enclave.

[00103] A plataforma de abstração 912 pode proporcionar primitivas para selar dados para um enclave. Por exemplo, a interface 922 pode proporcionar serviços para o enclave 914, tal como selar e retirar a selagem dos dados para uma identidade de enclave. Como explicado acima, um enclave pode possuir várias identidades aninhadas, e os dados podem ser selados para qualquer tal identidade. Quando os dados são selados para uma identidade, que corresponde a um conjunto de possíveis instanciações do enclave, os dados selados

Petição 870190060870, de 28/06/2019, pág. 54/143

43/102 podem ter a selagem retirada por qualquer uma deste conjunto correspondente de instanciações. Por exemplo:

srruct S.EALING POLÍCY

ENCL A VEJD. T¥PE end aveWType;

h [00104] Para cada valor de enclaveldType, o enclave irá selar um ID de mapeamento. Tipos possíveis de identidade de enclave (e valores de enclaveldType) incluem:

[00105] ENCLAVE_EXACTHASH [00106] ENCLAVEJNSTANCEHASH: // selagem utilizando MRENCLAVE para SGX, [00107] IMAGE HASH para VSM [00108] ENCLAVEJMAGEIDS: //não suportado no SGX, irá utilizar IMAGE IDS para VSM [00109] ENCLAVE_FAMILYID //irá utilizar PRODUCTID para SGX, FAMILY ID para VSM [00110] ENCLAVE_AUTHORID: //irá utiliza MRSIGNER para SGX, AUTHOR ID para VSM [00111] A plataforma também pode aplicar configuração de depuração adicional (criada e em tempo de execução) para a política de selagem. Para diferentes políticas de depuração, diferentes chaves de selagem podem ser utilizadas. Por exemplo, as configurações de depuração e de liberação podem utilizar diferentes chaves de selagem.

Petição 870190060870, de 28/06/2019, pág. 55/143

44/102

DWORD

EncíaveSeál(

In SEALINGPOUCY mlingPdicy, _In_reEíd5_bytes_opt__(dwP.laintextStze) LPCVOID pPlaintext, Jti DWORD dwPtóntextSÍ2&.

_In_reads_byWs_opt_(4wÁuthdà.uSize) LPCVOID pAudkta, ...,ln... DWORD dwAuíhdataSize,

...Out...writes byt®s u> (dwSealedtexlSize) LPVOID pSealedtext, „Ino«í_ DWORD *'dwSealedtextSi ze

DWORD

EnclaveUnseaI( _ln_reads_bytes_opt_(dwSed.edtextSize) LPCVOID pSealedtext,

Jn... DWORD dwSealedtmSsze,

In__read$._by tes-_pptJdwAuthdataSi ze) LPCVOID pAuthdata.

,In_ DWORD dwAuthdafâSize,

Out'..writes...bytesjto...(dwPlaimex.tSfóe) LPCVOID pPlainw,

Inout DWORD MwPlaÍntextSbe [00112] A plataforma de abstração 912 pode proporcionar primitivas para atestação, tal como para produzir relatórios e quotas de atestação, e para verificar relatórios e quotas. Por exemplo:

Petição 870190060870, de 28/06/2019, pág. 56/143

45/102

DWORD

CreateRèportí

In r eads bytes opt.. ,(d wT&rgetlnfoSi ze) PC VO ID pTargetlnf o,

J.n_ DWORD dwTargednfoSíze* _ln_reads_bytes_opt_(dw AuthData) PCVOID pAuthData,

In DWORD dwAuihData,

..P^yt..3™tes3A'ies__Opt J^pRepG.rtSi.ze) PVOID pReport, Jnom... PDWORD pReponSke,.

Oüt opt PDWORDI pEn.c-1 aveBrtw )

DWORD

VesifyReportí

..reads _ bytes. ..(dwRepoítSize) PCVOID pRepôrt,

In DWORD dwReportSize, (Xrt opt LPDWORD ip'EndaveBrw )

[00113] VerifyReport() pode ser utilizado por um enclave para afirmar a integridade do relatório e que o relatório foi gerado por um enclave na mesma máquina.

DWORD CreateQuote(

In GUID quoteType, _ln_ DWORD authDataSize, _ In.jeads...bytes._opt..Jau thDataSize) const 8YTE* authData,

Out DWORD* quoteSbe,

..pütptr...rBSuk..bytebufFer....opt...(*qBoteSíze)BYTE** quote )

[00114] Em CreateQuote, quoteType pode mapear para um provedor de quota, o qual pode ser uma fonte de confiança para gerar a quota específica. Em CreateQuote, authData pode ser um ponteiro para dados que são criados, e em um formato definido, pelo chamados de CreateQuote. Observe que authData não precisa ser entendido pela plataforma de abstração 912. O authData pode ser empacotado na quota resultante. Espera-se que os provedores de quota suportem

Petição 870190060870, de 28/06/2019, pág. 57/143

46/102 isso.

DWORD VerifyQuote(

Jn,_ DWORD quofcSize, _In_reads_byt©s._(quoteSize) const BYTE* quote,

...Put... DWORD* reponSbe, _Outpu__resuh_bytebi8ffer jll_(*reportSí3©)BYTE** report ) [00115] Em adição às primitivas do enclave descritas acima, uma plataforma de abstração de enclave pode proporcionar gerenciamento de memória (por exemplo, para alocar e liberar memória, tal como memória restrita a um enclave ou memória que é compartilhada entre um enclave e seu cliente); manuseio de exceção (por exemplo,para manusear erro, ou exceções, que ocorrem enquanto executando o código do enclave); sincronização de encadeamento; e funções criptográficas (por exemplo, criptografia, funções hash, e assinatura).

[00116] As técnicas descritas acima podem ser implementadas em um ou mais ambientes ou dispositivos de computação, como descrito abaixo. A Figura 11 representa um ambiente de computação de propósito geral ilustrativo, por exemplo, que pode incorporar um ou mais dentre o hardware confiável 172, a plataforma confiável 736, ou os computadores 810,910, 1010 e 1050, nos quais algumas das técnicas descritas neste documento podem ser incorporadas. O ambiente de sistema de computação 1102 é somente um exemplo de um ambiente de computação adequado e não é pretendido para sugerir qualquer limitação quanto ao escopo de uso ou quanto a funcionalidade do assunto presentemente revelado. O ambiente de computação 1102 também não deve ser interpretado como possuindo qualquer dependência ou requerimento se relacionando com qualquer um ou combinação de componentes ilustrados no ambiente operacional ilustrativo 1102. Em algumas modalidades, os vários elementos de computação representados podem incluir podem incluir

Petição 870190060870, de 28/06/2019, pág. 58/143

47/102 sistema de circuitos configurados para instanciar aspectos específicos da presente revelação. Por exemplo, o termo sistema de circuitos utilizado na revelação pode incluir componentes de hardware especializados configurados para executar função (funções) por firmware ou chaves. Em outras modalidades ilustrativas, o termo sistema de circuitos pode incluir uma unidade de processamento de propósito geral, memória, etc., configurados por instruções de software que incorporam lógica operável para executar função (funções). Nas modalidades ilustrativas onde o sistema de circuitos inclui uma combinação de hardware e software, um desenvolvedor pode escrever código fonte incorporando lógica e o código fonte pode ser compilado em código legível por máquina que pode ser processador pela unidade de processamento de propósito geral. Desde que os versados na técnica podem apreciar que o estado da técnica evoluiu até um ponto onde existe pouca diferença entre hardware, software, ou uma combinação de hardware / software, a seleção de hardware versus software para efetuar funções específicas é uma escolha de projeto deixada para um desenvolvedor. Mais especificamente, os versados na técnica podem apreciar que um processo de software pode ser transformado em uma estrutura de hardware equivalente, e uma estrutura de hardware pode ela própria ser transformada em um processo de software equivalente. Assim, a seleção de uma implementação de hardware versus uma implementação de software é uma escolha de projeto e deixada para o desenvolvedor.

[00117] O computador 1102, o qual pode incluir qualquer um dentre um dispositivo móvel ou smartphone, laptop, computador de mesa, ou coleção de dispositivos em rede, recursos de computação em nuvem, etc., tipicamente inclui várias mídias legíveis por computador. As mídias legíveis por computador pode ser qualquer mídia disponível que possa ser acessada pelo computador 1102 e inclui tanto mídia

Petição 870190060870, de 28/06/2019, pág. 59/143

48/102 volátil como não volátil, mídia removível e não removível. A memória do sistema 1122 inclui mídia de armazenamento legível por computador na forma de memória volátil e/ou não volátil tal como memória somente para leitura (ROM) 1123 e memória de acesso aleatório (RAM) 1160. Um sistema básico de entrada / saída (BIOS) 1124, contendo as rotinas básicas que ajudam a transferir informações entre os elementos dentro do computador 1102, tal como durante a inicialização, tipicamente é armazenada na ROM 1123. A RAM 1160 tipicamente contém dados e/ou módulos de programa que são imediatamente acessíveis e/ou estão sendo atualmente operados, pela unidade de processamento 1159. A título de exemplo e não de limitação, a Figura 11 ilustra o virtualizador 1130, o sistema operacional (OS) 1125, os programas aplicativos 1126, outros módulos de programa 1127 incluindo um cliente do enclave 1165, e o enclave 1128.

[00118] O computador 1102 também pode incluir outras mídias removíveis / não removíveis, voláteis / não voláteis. A título somente de exemplo, a Figura 11 ilustra uma unidade de disco rígido 1138 que lê ou grava junto à mídia magnética não removível, não volátil, uma unidade de disco magnético 1139 que lê ou grava junto a um disco magnético removível, não volátil, 1154, e uma unidade de disco ótico 1104 que lê ou grava junto a um disco ótico removível, não volátil, 1153, tal como um CD ROM ou outra mídia ótica. Outras mídias de armazenamento do computador removíveis / não removíveis, voláteis / não voláteis que podem ser utilizadas no ambiente operacional ilustrativo incluem, mas não estão limitadas aos cassetes de fita magnética, cartões de memória flash, discos versáteis digitais, fita de vídeo digital, RAM de estado sólido, ROM de estado sólido, dentre outros. A unidade de disco rígido 1138 tipicamente é conectada com o barramento do sistema 1121 através de uma interface de memória não

Petição 870190060870, de 28/06/2019, pág. 60/143

49/102 removível tal como a interface 1134, e a unidade de disco magnético 1139 e a unidade de disco ótico 1104 tipicamente são conectados com o barramento do sistema 1121 por uma interface de memória removível, tais como as interfaces 1135 ou 1136.

[00119] As unidades e sua mídia de armazenamento do computador associada discutidas acima e ilustradas na Figura 11 proporcionam armazenamento de instruções legíveis por computador, estruturas de dados, módulos de programa e outros dados para o computador 1102. Na Figura 11, por exemplo, a unidade de disco rígido 1138 é ilustrada como armazenando o sistema operacional 1158, os programas aplicativos 1157, outros módulos de programa 1156, tal como aplicativos do cliente do enclave e arquivos binários do enclave, e dados de programa 1155. Observe que estes componentes podem ser os mesmos ou diferentes do sistema operacional 1125, dos programas aplicativos 1126, dos outros módulos de programa 1127 e dos dados de programa 1128. O sistema operacional 1158, os programas aplicativos 1157, os outros módulos de programa 1156, e os dados de programa 1155 recebem números diferentes aqui para ilustrar que, no mínimo, eles são cópias diferentes. Um usuário pode entrar com comandos e informações no computador 1102 através de dispositivos de entrada tais como um teclado 1151 e um dispositivo apontador 1152, normalmente referido como mouse, TrackBall ou superfície de toque. Outros dispositivos de entrada (não apresentados) podem incluir um microfone, joystick, controle de jogo, antena de satélite, scanner, scanner de retina, dentre outros. Estes e outros dispositivos de entrada são frequentemente conectados com a unidade de processamento 1159 através de uma interface de entrada do usuário 1136 que é acoplada com o barramento do sistema 1121, mas podem ser conectados por outra interface e estruturas de barramento, tal como uma porta paralela, uma porta de jogo ou um

Petição 870190060870, de 28/06/2019, pág. 61/143

50/102 barramento serial universal (USB). Um monitor 1142 ou outro tipo de dispositivo de vídeo também está conectado com o barramento do sistema 1121 via uma interface, tal como uma interface de vídeo 1132. Em adição ao monitor, computadores também podem incluir outros dispositivos periféricos de saída tais como alto-falantes 1144 e a impressora 1143, os quais podem ser conectados através de uma interface de periférico de saída 1133.

[00120] O computador 1102 pode operar em um ambiente em rede utilizando conexões lógicas com um ou mais computadores remotos, tal como um computador remoto 1146. O computador remoto 1146 pode ser um computador pessoal, um servidor, um roteador, um PC de rede, um dispositivo par ou outro nó comum da rede e tipicamente inclui vários ou todos os elementos descritos acima em relação ao computador 1102, apesar de somente um dispositivo de armazenamento de memória 1147 ter sido ilustrado na Figura 11. As conexões lógicas representadas na Figura 11 incluem uma rede de área local (LAN) 1145 e uma rede de longa distância (WAN) 1149, mas também podem incluir outras redes. Tais ambientes em rede são normais em escritórios, rede de computadores de grandes empresas, intranets, na Internet e em recursos de computação em nuvem.

[00121] Quando utilizado em um ambiente em rede LAN, o computador 1102 é conectado com a LAN 1145 através de uma interface ou adaptador de rede 1137. Quando utilizado em um ambiente em rede WAN, o computador 1102 tipicamente inclui um modem 1105 ou outro meio para estabelecer comunicações através da WAN 1140, tal como a Internet. O modem 1105, o qual pode ser interno ou externo, pode ser conectado com o barramento do sistema 1121 via a interface de entrada do usuário 1136, ou via outro mecanismo apropriado. Em um ambiente em rede, módulos de programa representados em relação ao computador 1102, ou partes

Petição 870190060870, de 28/06/2019, pág. 62/143

51/102 dos mesmos, podem ser armazenados no dispositivo de armazenamento em memória remoto. A título de exemplo e não de limitação, a Figura 11 ilustra programas aplicativos remotos 1148 como residindo no dispositivo de memória 1147. Será apreciado que as conexões de rede apresentadas são ilustrativas e outros meios para estabelecer uma ligação de comunicação entre os computadores podem ser utilizados.

[00122] A Figura 12 representa um fluxograma para um método 1200 para abstrair uma plataforma de enclave nativa. Uma plataforma de abstração, tal como 912 na Figura 9, pode receber uma solicitação para uma plataforma de enclave na caixa 1202. A solicitação pode ser originada a partir de um cliente do enclave, tal como o cliente 914, ou a partir de um enclave, tal como o enclave 916.

[00123] Uma solicitação a partir de um enclave pode ser uma solicitação para executar uma primitiva da plataforma de abstração e pode incluir, por exemplo, uma solicitação para: criar um relatório ou quota de atestação de um enclave; selar dados para o enclave; chamar uma função no cliente de um enclave (chamada externa para o cliente); ler um contador monotônico (proporcionar um valor atual de um contador monotônico); proporcionar uma medição de tempo confiável; e alocar memória que pode ser compartilhada entre um enclave e seu cliente (por exemplo, para permitir que um ponteiro para a memória compartilhada seja passado como um parâmetro quando chamando dentro ou fora de um enclave). Em algumas modalidades, todo o espaço de memória virtual de um cliente do enclave pode ser compartilhado com (e acessível a partir do) o enclave, de modo que uma solicitação para alocar memória compartilhada possa ser implementada como uma solicitação para alocar memória para o cliente do enclave. Em algumas modalidades, métodos para alocar memória compartilhada estão disponível tanto para um enclave como

Petição 870190060870, de 28/06/2019, pág. 63/143

52/102 para seu cliente.

[00124] Uma solicitação a partir de um cliente do enclave pode ser uma solicitação para executar uma primitiva da plataforma de abstração e pode incluir, por exemplo, uma solicitação para: instanciar um enclave; verificar um relatório de atestação de um enclave; chamar uma função dentro de um enclave (chamada dentro do enclave); e alocar memória que pode ser compartilhada entre um enclave e seu cliente.

[00125] Uma solicitação da plataforma de abstração pode ser traduzida em uma solicitação de plataforma nativa nas operações 1204 a 1208. Parâmetros incluídos ou implicados na solicitação recebida podem ser convertidos na etapa opcional 1204 se for determinado, por exemplo, que o formato dos dados de um parâmetro na solicitação original não é o mesmo que o formato dos dados para este parâmetro na plataforma nativa. Por exemplo, se uma solicitação a partir de um enclave ou de um cliente incluir um parâmetro derivado a partir do relatório de atestação de formato de abstração, tal como uma identidade de abstração de enclave, ele será convertido para um parâmetro utilizado em um relatório de atestação de formato nativo, tal como uma identidade de enclave nativo.

[00126] Se for determinado que a convenção de chamada da plataforma nativa e da solicitação recebida são diferentes, a convenção de chamada pode ser convertida na etapa opcional 1206. Uma convenção de chamada pode ser convertida, por exemplo, por reordenar parâmetros em uma pilha da chamada, movendo parâmetros entre os registradores do processador e uma pilha da chamada, e convertendo entre métodos de comunicação de condição de erro tal como retornando um valor de erro e chamando um manipulador de exceção.

[00127] Em algumas modalidades, a plataforma nativa pode ser

Petição 870190060870, de 28/06/2019, pág. 64/143

53/102 idêntica à plataforma de abstração para algumas solicitações, caso em que as operações de conversão das caixas 1204 e 1206 podem ser saltadas.

[00128] Na caixa 1208, a solicitação convertida é enviada para a plataforma nativa para causar que a solicitação seja executada pela plataforma nativa. Por exemplo, no caso onde a plataforma nativa é de acordo com a arquitetura de enclave de Extensões de Guarda de Softwares (SGX) da Intel, a plataforma nativa pode incluir instruções do processador para enclaves. Neste caso, o envio da solicitação na caixa 1208 pode incluir executar uma ou mais instruções do processador para enclaves. Em outro exemplo, a plataforma nativa pode ser de acordo com a arquitetura de enclave de Modo Seguro Virtual (VSM) da Microsoft, a qual pode incluir um virtualizador com hypercalls para enclaves. Uma hypercall é um tratador de interrupção de software (trap) para código do virtualizador, e uma hypercall pode causar uma alteração do contexto do processador para um contexto no qual operações privilegiadas podem ser permitidas. Neste exemplo de VSM, o envio da solicitação na caixa 1208 pode incluir fazer hypercalls para o virtualizador e/ou outros mecanismos para trocar o contexto de execução para um contexto no qual operações privilegiadas podem ser permitidas.

[00129] Enviar uma solicitação para uma plataforma nativa aqui geralmente significa executar a solicitação utilizando as características da plataforma nativa. A operação de envio da solicitação para a plataforma nativa 1208 pode envolver várias operações com a plataforma nativa, e pode variar dependendo da operação (ou primitiva) solicitada, tal como criar um enclave, atestação, selagem de dados, transferência de controle, ou uso de contadores monotônicos e tempo confiável.

[00130] A primitiva CreateEnclave pode ser utilizada para instanciar

Petição 870190060870, de 28/06/2019, pág. 65/143

54/102 um enclave. Uma solicitação CreateEnclave para instanciar um enclave pode causar que uma plataforma de abstração crie um container seguro (por exemplo, por alocar alguma memória e estabelecer um limite de segurança ou de isolamento para esta memória), copiar o código do enclave para dentro deste container seguro (por exemplo, a partir de uma imagem do enclave), e configurar ou permitir pontos de entrada dentro do código do enclave (por exemplo, de acordo com metadados de ponto de entrada em uma imagem do enclave).

[00131] O envio de uma solicitação CreateEnclave para uma plataforma nativa com um virtualizador permitido pelo enclave (um virtualizador que proporciona funções de gerenciamento do enclave, tal como VSM), pode incluir alocar memória e fazer hypercalls para configurar tabelas de página do processador para a memória de uma maneira que impeça código fora do container do enclave acessar esta memória. As hypercalls de criação de enclave a partir da plataforma de abstração também podem causar que o virtualizador configure informação de configuração para controlar transferência para dentro do enclave em pontos de entrada designados. Posteriormente, código fora do container seguro pode fazer hypercalls de transferência de controle para transferir a execução nos pontos de entrada designados dentro do container seguro.

[00132] O envio de uma solicitação CreateEnclave para uma plataforma nativa com um processo permitido pelo enclave (um processador com instruções do processador de gerenciamento do enclave, tal como SGX), pode incluir a plataforma de abstração executando uma instrução tal como ECREATE para informar para a CPU que alguma área da memória deve ser criada como um container seguro do enclave, e executar uma instrução tal como EADD para adicionar páginas de dados para este container do enclave. Instruções

Petição 870190060870, de 28/06/2019, pág. 66/143

55/102 especiais do processador também podem ser utilizadas para criar páginas especiais na memória para designar os pontos de entrada no enclave para transferência de controle para dentro do enclave. Posteriormente, código fora do container seguro pode executar uma instrução tal como EENTER especificando um dos pontos de entrada designados para transferir o controle da execução para este ponto de entrada do enclave.

[00133] A primitiva CreateReport pode ser utilizada para criar um relatório de atestação. Uma solicitação CreateReport para criar um relatório de atestação de um enclave pode ser executada por uma camada de abstração como explicado acima com respeito às Figuras 5 e 7. Com um virtualizador permitido pelo enclave, uma camada de abstração pode enviar a solicitação para a plataforma nativa por fazer uma hypercall que altera o estado de execução, por exemplo, para um contexto de monitor de segurança que tem acesso a uma chave secreta tal como PrivAK 726 da Figura 7 que pode ser utilizada para relatórios assinados. Esta chave secreta somente pode ficar disponível para o contexto do monitor de segurança se o computador foi inicializado em uma configuração saudável como verificado com um registrador de ocorrências TCG em um TPM. O monitor de segurança pode marcar os dados do relatório com uma identidade do enclave sendo atestado.

[00134] Com um processador permitido pelo enclave, uma solicitação CreateReport pode ser enviada para a plataforma nativa pela execução de uma instrução, tal como EREPORT, a qual gera um relatório e envia o mesmo para um enclave especial que terá acesso a uma chave privada para assinar relatórios.

[00135] A primitiva EnclaveSeal pode ser utilizada para selar dados para um enclave. Selar dados para um enclave criptografa os dados de uma maneira ou com uma chave que está associada com o

Petição 870190060870, de 28/06/2019, pág. 67/143

56/102 enclave. Uma solicitação EnclaveSeal pode ser uma solicitação para selar dados localizados dentro de um enclave, tal como todo ou parte do estado do enclave, para o enclave utilizando uma política de selagem. A política de selagem, tal como SEALING_POLICY acima, pode especificar um tipo de identidade do enclave que indica quais enclaves devem estar aptos a retirar a selagem dos dados. Os próprios processos de selagem podem utilizar uma chave de criptografia associada com uma identidade de enclave especificada na política de selagem. Posteriormente, uma nova instanciação do enclave pode estar apta a retirar a selagem dos dados se o novo valor de identidade do enclave no tipo de identidade especificada for o mesmo que o valor de identidade do enclave no tipo de identidade especificada.

[00136] A selagem de dados permite que dados secretos ou sensíveis do enclave sejam copiados de forma segura para o armazenamento não seguro, tal como para a memória fora do container seguro do enclave ou para armazenamento persistente tal como um disco rígido. Quando os dados selados são dados do estado do enclave, a selagem permite que um enclave seja reinicializado para um estado anterior, e permite uma operação segura do enclave ser interrompida e posteriormente continuada em outro enclave.

[00137] Para reiniciar um estado do enclave, primeiro um estado do enclave é salvo por selar seu estado para o enclave. A selagem pode ser feita por criptografia dos dados de estado com uma chave associada com o enclave. Posteriormente, talvez após o estado do enclave ter alterado, os dados de estado selados podem ter a selagem retirada para o mesmo enclave pela decriptografia dos dados selados e por então substituir um estado atual do enclave pelos dados decriptografados (por exemplo, por copiar os dados decriptografados para dentro do container seguro do enclave).

Petição 870190060870, de 28/06/2019, pág. 68/143

57/102 [00138] Para interromper uma operação segura e continuar em outro enclave, a operação segura inicia pela execução de uma operação compreendendo várias instruções do processador em um primeiro enclave. Quando o primeiro enclave é interrompido, o estado deste enclave pode ser selado para uma identidade de enclave especificada na política de selagem, e os dados selados podem então ser salvos no armazenamento não seguro, tal como armazenamento persistente local ou baseado em nuvem. O primeiro enclave então pode ser (opcionalmente) terminado ou iniciar outras operações do enclave. Um segundo enclave pode ser instanciado ou adaptado para continuar a operação interrompida por retirar a selagem dos dados de estado selados para dentro do segundo enclave. A operação interrompida pode ser continuada no segundo enclave onde o primeiro enclave descontinuou.

[00139] Com um virtualizador permitido pelo enclave, uma camada de abstração pode enviar uma solicitação EnclaveSeal para a plataforma nativa por fazer uma hypercall. A hypercall pode alterar o estado de execução para um contexto, por exemplo, um contexto de monitor de segurança, que terá acesso a uma chave de selagem secreta associada com o enclave que pode ser utilizada para selar ou retirar a selagem dos dados. A chave de selagem pode ser derivada a partir de uma combinação de uma identidade de enclave com uma chave de plataforma secreta disponível somente para o monitor de segurança. Esta chave de plataforma somente pode ficar disponível para o monitor de segurança quando a máquina é inicializada em uma configuração saudável, e a configuração de inicialização é verificada com um registro de ocorrência de TCG em um TPM. Nesta modalidade de virtualizador permitido pelo enclave, o código do enclave nunca tem acesso à chave de selagem.

[00140] Com um processador permitido pelo enclave, uma

Petição 870190060870, de 28/06/2019, pág. 69/143

58/102 solicitação EnclaveSeal pode ser enviada para a plataforma nativa pela execução de uma instrução, tal como EGETKEY, para obter uma chave de criptografia. Este algoritmo pode gerar uma chave de selagem que é única para o enclave. A chave de selagem pode ser derivada a partir de uma identidade do enclave e um segredo embutido no processador. O código dentro de um enclave então pode criptografar os dados com a chave de selagem. Os dados podem ser selados pela criptografia com a chave de selagem, por exemplo, por código dentro de um enclave, por uma plataforma de abstração, ou por uma plataforma nativa. EnclaveUnseal pode de forma similar utilizar EGETKEY para gerar uma chave de retirada de selagem.

[00141] Uma solicitação de transferência de controle pode ser uma solicitação para transferir o controle de execução do processador a partir de instruções dentro de um enclave para fora para um ponto de entrada fora do enclave (por exemplo, CallEnclaveOut), ou o inversor a partir de instruções fora do enclave para um ponto de entrada dentro do enclave (por exemplo, CallEnclaveln). Isto pode ser feito, por exemplo, para uma operação de base de dados segura. Após instanciar um enclave de base de dados, um cliente do enclave pode solicitar que o enclave execute uma operação específica, tal como consulta a base de dados por utilizar a primitiva CallEnclaveln para transferir controle para um ponto de entrada dentro do enclave de base de dados que irá executar a consulta. Após o enclave completar a consulta, o resultado da consulta pode ser retornado (possivelmente após criptografar o resultado) para o cliente com a primitiva CallEnclaveOut para transferir o controle de volta para o cliente em um ponto de entrada no cliente que pode receber o resultado da consulta. As primitivas CallEnclaveln e CallEnclaveOut podem pegar um ponteiro para uma memória temporária da memória que pode ser compartilhada entre o enclave e seu cliente (a memória temporária

Petição 870190060870, de 28/06/2019, pág. 70/143

59/102 pode ser legível, pode ser gravada, e/ou executável pelo enclave ou por seu cliente).

[00142] Com um virtualizador permitido pelo enclave, uma camada de abstração pode enviar uma solicitação CallEnclaveln para a plataforma nativa por fazer uma hypercall. A hypercall pode alterar o estado de execução para um contexto, por exemplo, um contexto de monitor de segurança, que irá salvar os registradores da CPU, restaurar um conjunto de valores de registradores da CPU do enclave anteriormente salvos (possivelmente a partir da memória do enclave), alterar a configuração da tabela de páginas para permitir acesso à memória protegida do enclave, e invocar um ponto de entrada de função dentro do enclave. De forma similar, quando uma plataforma de abstração recebe uma solicitação CallEnclaveOut, a solicitação pode ser encaminhada para a plataforma nativa por uma hypercall que irá salvar os registradores da CPU do enclave (possivelmente salvando a memória do enclave) e restaurar os registradores da CPU anteriormente salvos para um cliente do enclave, alterar a configuração da tabela de páginas para impedir acesso à memória do enclave, e transferir o controle do processador para um ponto de entrada no cliente do enclave fora do enclave.

[00143] Com um processador permitido pelo enclave, uma solicitação CallEnclaveln pode ser enviada para a plataforma nativa pela execução de uma instrução, tal como EENTER, que pode causar que a CPU restaure um conjunto de registradores da CPU do enclave (possivelmente a partir da memória do enclave) e invoque uma função (controle de transferência para um ponto de entrada) dentro do enclave. Uma primitiva CallEnclaveOut pode executar uma instrução, tal como EEXIT, que pode transferir controle para instruções fora do enclave e/ou causar que uma falha que transfere o controle para fora do enclave.

Petição 870190060870, de 28/06/2019, pág. 71/143

60/102 [00144] O contador monotônico possui vários usos. Por exemplo, um enclave pode querer restringir o quanto para trás seu estado pode ser revertido. Os contadores monotônicos podem ser uso, por exemplo, como um nonce para garantir frescor de mensagens, como discutido acima com respeito à Figura 4. Os contadores monotônicos geralmente possuem a habilidade de ser lidos e serem incrementados, mas não podem ser decrementados. Para restringir reversão ou inversão do estado de um enclave, o código dentro de um enclave pode incrementar um contador monotônico associado, e então, salvar o valor do contador junto com o estado interno do enclave. O estado e o valor do contador podem ser salvos, por exemplo, com a primitiva EnclaveSeal. Posteriormente, quando restaurando o estado do enclave, por exemplo, utilizando a primitiva EnclaveUnseal, o código dentro do enclave pode ler o valor corrente do contador monotônico e comparar o mesmo com o valor do contador com o estado não selado. Se o valor do contador com o estado não selado for menor do que o valor atual do contador, o enclave pode impedir o uso do estado não selado.

[00145] Com um virtualizador permitido pelo enclave, uma camada de abstração pode enviar uma solicitação para a plataforma nativa para ler ou incrementar um contador monotônico por fazer uma hypercall que é exposta para o enclave. Quando uma hypercall para ler ou incrementar o contador é invocada, o processador irá alterar o estado de execução para um contexto, tal como um monitor de segurança, que irá verificar a identidade do enclave fazendo a hypercall, e então, ler a partir ou incrementar, respectivamente, o contador monotônico correspondente, por exemplo, em um armazenamento não volátil tal como um chip TPN. Alternativamente, o monitor de segurança pode ler ou incrementar um contador armazenado em um servidor confiável remoto ou em um conjunto de

Petição 870190060870, de 28/06/2019, pág. 72/143

61/102 servidores confiáveis remotos, por estabelecer um canal de comunicação seguro com tal servidor e solicitar ao mesmo para ler ou incrementar um contador monotônico especificado. O servidor ou servidores confiáveis remotos podem manter o contador dentro de um enclave para isolar o mesmo do resto do código no computador hospedeiro.

[00146] Com um processador permitido pelo enclave, uma solicitação pode ser enviada para a plataforma nativa pela execução de uma instrução. Com tal processador, as primitivas de contador monotônico podem ser implementadas pela leitura ou pelo incremento de um contador nó armazenamento em memória não volátil em um chip na placa mãe do computador. Alternativamente, estas primitivas também podem ser implementadas utilizando um servidor de remoção confiável como com o virtualizador permitido pelo enclave.

[00147] A Figura 13 representa um fluxograma ilustrativo para um método 1300 para abstrair uma plataforma de enclave nativa. Uma plataforma de abstração de enclave pode receber uma solicitação a partir de um enclave ou do cliente do enclave na caixa 1302. Na caixa 1304, a plataforma de abstração pode determinar se uma plataforma nativa inclui instruções do processador do enclave, por exemplo, por determinar se a plataforma nativa conforma-se com a SGX. Se ela se conformar, as instruções do processador do enclave são executadas na caixa 1306. Na caixa 1308, a plataforma de abstração pode determinar se uma plataforma nativa inclui hypercalls do enclave, por exemplo, por determinar se a plataforma nativa conforma-se com a VSM. Se ela se conformar, a plataforma nativa faz hypercalls do enclave. Os resultados a partir da execução das instruções do enclave ou da chamada de hypercalls do enclave são organizados na caixa 1312. A organização pode incluir, por exemplo, converter os parâmetros de saída ou a manipulação de exceção das instruções do

Petição 870190060870, de 28/06/2019, pág. 73/143

62/102 processador do enclave ou as hypercalls do enclave para o formato ou protocolo da interface da camada de abstração. Os parâmetros de saída convertidos então são retornados para o solicitante original (enclave ou cliente) na caixa 1314.

IDENTIDADE DE ENCLAVE ABSTRATO [00148] A Figura 14 representa imagens ilustrativas de binário do enclave utilizadas para instanciar um enclave. Um enclave pode ser instanciado pela criação de um container seguro, AL como um container do enclave 1490, e pela cópia de partes da uma ou mais imagens do enclave para dentro do container. O container do enclave 1490 pode ter sido criado por referência à imagem primária do enclave 1410. A imagem primária pode incluir referência para outras imagens dependentes do enclave. Neste exemplo, a imagem primária 1410 inclui Dependencyl e Dependency2 como referências para as imagens dependentes do enclave 1420 e 1450, respectivamente. A imagem 1420 inclui ainda as dependências em relação às imagens 1430 e 1440, enquanto a imagem 1450 depende da imagem 1460. Uma vez que todas estas imagens (ou partes das mesmas) são copiadas para dentro do container 1490, o enclave resultante pode incluir imagens que não são de plataforma 1402, as quais podem incluir código e dados que são únicos ou específicos para o enclave instanciado, imagens da plataforma de abstração 1404, e imagens da plataforma nativa 1406.

[00149] Cada imagem de enclave, tal como a imagem primária 1410, pode incluir IDs, dependências, código, dados e uma assinatura do autor da imagem. No exemplo da imagem 1410, dois IDs 1410.1 e

1410.2 estão incluídos. Estes IDs podem ser UUIDs que especificam, por exemplo, um valor de identidade abstrata correspondendo ao valor de ImagelD, FamilylD, ou AuthorlD que, individualmente ou coletivamente, podem ser utilizados para identificar qualquer enclave

Petição 870190060870, de 28/06/2019, pág. 74/143

63/102 instanciado com esta imagem de enclave. Como representado, a imagem 1410 possui dois IDs, mas menos ou mais IDs são viáveis. O código na imagem 1410 pode ser instruções binárias executáveis pelo processado computador hospedando o container do enclave 1490. Os dados na imagem 1410 podem ser utilizados por qualquer código carregado no container 1410. A imagem 1410 também pode incluir uma assinatura Sig 1410 para garantir a integridade de qualquer um ou de todo os outros conteúdos da imagem, tais como IDs, referências de dependência, código e dados. Outras imagens 1420 a 1460 podem de forma similar conter IDs, referências de dependência, código, dados e assinaturas.

[00150] Um indicador de dependência, tal como Dependencel e Dependence2 ou imagem 1410, Dependencel e Dependence2 da imagem 1420, e Dependencel da imagem 1450, pode ser especificado de vários modos. Se as imagens 1410 a 1460 forem armazenadas em uma memória do sistema de computador, um indicador de dependência pode simplesmente ser um endereço na memória. Se as imagens do enclave forem arquivos em um sistema de arquivos, as referências podem ser nomes de arquivo. Em algumas modalidades, as referências podem ser um identificador lógico. Um identificador lógico pode ser um número único, tal como um UUID, ou pode ser outros dados, tal como uma cadeia de texto, que de outro modo identifica uma imagem de dependência. Por exemplo, uma cadeia de texto pode indicar um autor da imagem binária dependente, fonte, nome de produto, família do produto, e/ou número de versão. Um identificador lógico inclui uma localização na Rede ou na Internet, tal como uma localização onde uma cópia de um binário dependente pode ser recuperada.

[00151] Em algumas modalidades, um arquivo de imagem do enclave pode ser localizado por se consultar um indicador de

Petição 870190060870, de 28/06/2019, pág. 75/143

64/102 dependência, tal como um identificador lógico, em um registrador de imagens de enclave para encontrar um ponteiro para a versão atual ou cópia local da imagem de enclave referenciada. Em alguns casos, um serviço confiável pode ser utilizado para resolver um indicador de dependência para a identificação de uma imagem de enclave ou localização de imagem particular.

[00152] Em algumas modalidades, um indicador de dependência pode ser um identificador criptograficamente seguro, tal como um hash criptográfico da imagem binária do enclave dependente pretendido. Tal hash pode incluir todos os binários dependentes, ou somente uma parte dos mesmos. A parte de um binário dependente incluída em um indicador de dependência pode incluir valores de identidade abstrata, tais como o ID 1410.1 ou o ID 1420.2, e podem ser valores de identidade abstrata. Um serviço de resolução para um identificador criptograficamente seguro pode não precisar ser tão confiável quanto o identificador lógico porque a entidade determinando as dependências do enclave pode estar apta a verificar que a imagem dependente correta foi encontrada por se calcular o hash do próprio binário dependente.

[00153] A Figura 15 representa um fluxograma ilustrativo para um método 1400 para executar uma operação do enclave com identidade de enclave abstrata. Um valor de identidade abstrata para um enclave pode proporcionar uma base para determinar a equivalência entre dois enclaves que possuem algum aspecto em comum, mas não são exatamente idênticos. Um valor de identidade pode estar incluído em um relatório de atestação e pode ser associado com o tipo de identidade abstrata (tal como ExactHash, InstanceHash, ImagelD, FamilylD, ou AuthorlD). Dois enclaves que não são exatamente os mesmos podem possuir o mesmo valor de identidade abstrata para um tipo de identidade abstrata. Adicionalmente, código de enclave idêntico

Petição 870190060870, de 28/06/2019, pág. 76/143

65/102 instanciado nos containers seguros nas duas plataformas de enclave nativas diferentes também podem possuir o mesmo valor de identidade abstrata. O método 1500 pode ser executado, por exemplo, por uma camada da plataforma de abstração entre uma plataforma de enclave nativa e um enclave ou um cliente do enclave.

[00154] Na caixa 1502, um enclave é instanciado a partir de uma imagem de enclave, tal como a imagem primária do enclave 1410 da Figura 14. A imagem do enclave pode ser uma imagem primária incluindo código do enclave, dados, uma lista de identidades, uma lista de quaisquer imagens dependentes do enclave, e uma assinatura. Para garantir a integridade das imagens do enclave, as imagens podem ser assinadas com uma chave privada que pode corresponder ao autor das imagens do enclave. A lista de IDs de identidade do enclave na imagem do enclave pode corresponder aos tipos de identidades abstratas tais como uma ImagelD, uma FamilylD e uma AuthorlD, cada uma pretendida para identificar a imagem do enclave coletivamente junto com outras imagens relacionadas do enclave. Uma lista de imagens dependentes do enclave pode se referir a outras imagens do enclave contendo código do enclave do qual o código na imagem primária do enclave depende. Uma imagem dependente do enclave pode ou não ser criada pelo mesmo autor, e algumas imagens dependentes do enclave podem estar associadas com uma plataforma de enclave geralmente (uma plataforma de abstração ou plataforma nativa) ao invés do que particularmente associada com uma imagem primária do enclave ou com o autor da imagem primária do enclave. O enclave pode ser instanciado pela criação de um container seguro do enclave utilizando qualquer plataforma de enclave nativa, e copiando toda ou uma parte da imagem primária e quaisquer imagens dependentes do enclave para dentro do container seguro.

[00155] Na caixa 1503, uma operação do enclave é solicitada, por

Petição 870190060870, de 28/06/2019, pág. 77/143

66/102 exemplo, por um enclave ou por um cliente do enclave, junto com um tipo de identidade do enclave. O tipo de identidade pode especificar um tipo de identidade abstrata, tal como ImagelD ou AuthorlD, e estar relacionado com um enclave particular instanciado, mas não especificar o valor de AuthorlD para este enclave. O restante do método 1500 seguindo a caixa 1503 descreve operações para executar a operação (tal como atestação, selagem de dados, ou uso de um contador monotônico, etc.) com o enclave instanciado utilizando um valor de identidade derivado para este tipo de identidade do enclave instanciado. A identidade pode ser determinada utilizando um hash de um subconjunto da imagem (imagens) do enclave. Qual subconjunto da imagem (imagens) do enclave é utilizado como uma entrada para o hash pode ser baseado em parte no tipo de identidade desejado a ser utilizado na operação do enclave.

[00156] Na caixa 1504, uma parte da imagem do enclave, chamada de uma parte de identidade neste documento, é determinada baseado no tipo de identidade. A parte de identidade pode incluir todas, parte ou nenhuma das várias imagens binárias do enclave utilizadas para instanciar um enclave na caixa 1502. A parte de identidade pode incluir todo, uma parte ou nenhum do código do enclave contido na imagem do enclave. A parte de identidade também pode incluir zero, um, ou mais IDs de identidade listados em uma parte que não é de código das imagens do enclave incluídas. A parte de identidade pode ou não também incluir dados de enclave contidos nas imagens do enclave. A parte de identidade pode incluir qualquer combinação destas várias partes das imagens do enclave. Por exemplo, uma parte de identidade pode incluir todo o código, nenhum dos dados, e dois ou quatro IDs de identidade disponíveis. Na caixa opcional 1506, quais imagens dependentes do enclave são para ser incluídas na parte de identidade é determinado, e uma parte de identidade de cada imagem

Petição 870190060870, de 28/06/2019, pág. 78/143

67/102 incluída é determinada.

[00157] A parte de identidade de imagens dependentes pode ou não ser a mesma que a parte de identidade de uma imagem primária do enclave. Por exemplo todo o código e o ImagelD são incluídos na parte de identidade de uma imagem primária, enquanto nenhum código e somente FamilylD de uma imagem dependente pode ser incluído na parte de identidade da imagem dependente.

[00158] Quando o código do enclave está incluído na parte de identidade, as partes do código do enclave na parte de identidade podem ser determinadas por uma combinação do tipo de identidade com um indicador de quais dependências são para ser incluídas na parte de identidade. O tipo de identidade InstanceHash pode incluir, por exemplo, o código do enclave na imagem primária, mas nenhuma imagem dependente, enquanto o tipo de identidade ExactHash pode incluir o código do enclave em todas as imagens dependentes que não são consideradas parte de uma plataforma de enclave. Por exemplo, todas as imagens dependentes do enclave que não são assinadas com uma chave privada do autor da plataforma de enclave podem ser consideradas como não sendo parte da plataforma de enclave. Alternativamente ou em adição, a imagem primária pode incluir uma lista de quais imagens dependentes do enclave são para ser incluídas ou excluídas na parte de identidade para os tipos de identidade InstanceHash ou ExactHash.

[00159] Os IDs de identidade de enclave, os quais podem estar incluídos como metadados em uma imagem do enclave, podem ser incluídos na parte de identidade da imagem do enclave ao invés ou em adição ao código do enclave. Por exemplo, a parte de identidade para tipos de identidade ImagelD, FamilylD e AuthorlD pode incluir metadados de ID correspondentes a partir da imagem do enclave. Quando os tipos de identidade são aninhados ou em camadas, a parte

Petição 870190060870, de 28/06/2019, pág. 79/143

68/102 de identidade para tipos de nível inferior pode incluir dados do ID para tipos de nível superior. Por exemplo, a parte de identidade para ImagelD pode incluir dados de ID para ImagelD, FamilylD e AuthorlD, enquanto a parte de identidade para AuthorlD pode somente incluir dados de ID para AuthorlD.

[00160] Os tipos de identidade que incluem código do enclave, tais como InstanceHash e ExactHash, proporcionam um nível mais alto de segurança, por exemplo, para o cliente do enclave via atestação, de que algum código do enclave está executando dentro de um enclave. Entretanto, a identidade do enclave irá necessariamente alterar quando qualquer um da parte de identidade do código do enclave alterar. Por exemplo, qualquer correção de segurança ou outro defeito for corrigido em uma nova versão de uma imagem de enclave, o valor de identidade resultante baseado no novo código também irá alterar. Por proporcionar um mecanismo para algumas partes do código do enclave serem excluídas do cálculo do hash da identidade, a identidade de um enclave pode ser separada das alterações para a parte excluída do código do enclave. Por exemplo, quando o código do enclave de um autor depende do código do enclave proporcionado pela plataforma de enclave, a identidade do enclave pode ser separada das revisões para a plataforma dependente.

[00161] Na caixa 1508, um valor de identidade é determinado, o qual pode representar uma identidade do enclave instanciado na caixa 1502. Um valor de identidade pode ser determinado por se calcular um hash através da parte de identidade anteriormente determinada da imagem ou imagens do enclave (o valor de identidade é a saída de uma função hash onde a parte de identidade é a entrada para a função hash). Em algumas modalidades, a entrada para a função hash serão partes da imagem (imagens) originais do enclave, enquanto em outras modalidades, a entrada para a função hash serão partes de um

Petição 870190060870, de 28/06/2019, pág. 80/143

69/102 container do enclave após ter copiado a parte de identidade da imagem para dentro do container (e possivelmente decriptografado a parte de identidade no caso onde uma imagem original do enclave é criptografada).

[00162] Na caixa 1510, a integridade do valore de identidade resultante pode ser opcionalmente verificada pela verificação da integridade da imagem (imagens) original do enclave. A integridade de uma imagem do enclave pode ser verificada com uma chave pública correspondendo a uma chave privada utilizada para assinar a imagem do enclave. Tal par de chaves pública / privada pode ser associado, por exemplo, com o autor da imagem (imagens) do enclave, de modo que confiança no valor de identidade resultante pode ter origem na confiança do autor do enclave.

[00163] Finalmente, na caixa 1512, uma operação relacionada com o enclave instanciado pode ser executada utilizando o valor de identidade. Por exemplo: um relatório de atestação do enclave instanciado pode ser gerado ou verificado para um tipo de identidade; dados podem ser selados para ou ter a selagem retirada a partir do enclave instanciado em uma identidade; e um contador monotônico ou um tempo confiável ligado com o enclave instanciado e com o tipo de identidade podem ser utilizados.

[00164] As operações do enclave utilizando tipos de identidade de nível superior permitem interações entre grupos de possíveis instanciações de enclave. A atestação para um tipo de identidade de nível superior pode proporcionar equivalência de relatório de atestação para todos os enclaves com a mesma identidade de nível superior. Por exemplo, relatório de atestação para um tipo de identidade AuthorlD pode ser equivalente ao relatório de atestação a partir de todos os enclaves instanciados a partir de uma imagem primária contendo os mesmos metadados de AuthorlD. Os dados selados para um tipo de

Petição 870190060870, de 28/06/2019, pág. 81/143

70/102 identidade de alto-nível podem ter a selagem retirada por qualquer enclave com o mesmo valor de identidade de alto-nível. Por exemplo, os dados selados para um enclave instanciado com o tipo de identidade AuthorlD podem ter a selagem retirada por qualquer outro enclave instanciado com os mesmos metadados de AuthorlD em sua imagem primária do enclave.

EQUIVALÊNCIA DE IDENTIDADE DE ENCLAVE [00165] A Figura 16 representa um sistema ilustrativo com equivalência de identidade abstrata de enclave. Um cliente do enclave 1602 pode se comunicar com um primeiro enclave 1612 instanciado em um container seguro do enclave da primeira plataforma nativa 1616 via a plataforma de abstração 1614, e o cliente 1602 também pode ser comunicar com um segundo enclave 1622 instanciado em um container seguro do enclave da segunda plataforma nativa 1626 via a plataforma de abstração 1624. A primeira plataforma nativa 1616 pode ou não residir no mesmo computador que a segunda plataforma nativa. O cliente do enclave 1602 pode residir no mesmo computador de qualquer uma das plataformas nativas, ou pode residir em um terceiro computador separado. A primeira plataforma nativa 1616 pode não ser a mesma que a segunda plataforma nativa 1626. Por exemplo, a primeira plataforma nativa 1616 pode ser uma versão mais antiga da segunda plataforma nativa a partir do mesmo fabricante de plataforma nativa. Alternativamente, a primeira plataforma nativa 1616 e a segunda plataforma nativa 1626 podem se conformar com arquiteturas de enclave completamente diferentes, tais como VSM e SGX.

[00166] Um cliente do enclave pode de forma segura determinar que enclaves são equivalentes por comparar valores de identidade derivados a partir de relatórios de atestação. O cliente do enclave 1602 pode de forma segura identificar cada um dos enclaves por receber relatórios de atestação separados a partir do primeiro enclave

Petição 870190060870, de 28/06/2019, pág. 82/143

71/102

1612 e do segundo enclave 1622. Um valor de identidade pode estar incluído (ou ser derivado de) cada um destes relatórios de atestação. Se os valores de identidade forem os mesmos, o cliente do enclave 1602 pode ter confiança de que o primeiro enclave 1612 e o segundo enclave 1622 são equivalentes em algum sentido. Os valores de identidade a partir dos relatórios de atestação podem ser valores de identidade abstrata correspondendo a um tipo de identidade abstrata particular (tal como ExactHash, InstanceHash, ImagelD, FamilylD ou AuthorlD), ou hashs de tais valores de identidade abstratas. Neste caso, a equivalência pode ser determinada onde os enclaves não são exatamente idênticos. Dois enclaves podem não exatamente idêntico, mas ainda determinados como sendo equivalentes, por exemplo, onde imagens de enclave carregadas no container do enclave são versões diferentes da mesma funcionalidade, ou as mesmas imagens primárias com diferentes imagens dependente, ou as mesmas imagens do enclave carregadas dentro de containers de enclave de diferentes arquiteturas de enclave.

[00167] O primeiro enclave 1612 pode ser considerado equivalente, mas não idêntico ao segundo enclave 1622 para várias situações. Em um primeiro exemplo, somente um subconjunto de código inicialmente carregado dentro dos containers de enclave é o mesmo (por exemplo, equivalente para os tipos de identidade abstrata ExactHash ou InstanceHash). Em um segundo exemplo, o autor do código do enclave pode ter incluído um ID idêntico em duas imagens binárias de enclave diferentes, mesmo que, no entanto, o código nas duas imagens binárias seja diferente (por exemplo, equivalente para tipos de identidade ImagelD, FamilylD, ou AuthorlD). Em um terceiro exemplo, o código em cada enclave é totalmente o mesmo, mas é carregado (instanciado) em diferentes plataformas nativas. Neste terceiro exemplo, a primeira plataforma nativa 1616 e a segunda

Petição 870190060870, de 28/06/2019, pág. 83/143

72/102 plataforma nativa 1626 podem ser fabricadas por diferentes fabricantes e, por consequência, a confiança dos diferentes relatórios de atestação tem origem nas diferentes autoridades de certificado (veja a Figura 7, elemento 738) dos diferentes fabricantes. Um exemplo onde as duas plataformas nativas são diferentes é em uma fazenda de servidores ou na computação em nuvem onde os servidores alocados para as cargas de trabalho de processamento do primeiro e do segundo enclaves são servidores que não suportam a mesma plataforma de enclave nativa.

[00168] Em uma modalidade alternativa, o primeiro enclave pode ser o cliente do segundo enclave, de modo que as caixas 1602 e 1612 são combinadas. Determinar a equivalência de enclave nesta modalidade pode incluir determinar, dentro do primeiro enclave, que um valor de identidade a partir de um relatório de atestação do segundo enclave é o mesmo que o próprio valor de identidade do primeiro enclave (em um nível de identidade abstrata particular).

[00169] A Figura 17 representa um fluxograma ilustrativo para processamento paralelo com dois enclaves equivalentes. O processo 1700 pode ser executado, por exemplo, por um cliente de dois ou mais enclaves diferentes. Na caixa 1702, dois enclaves são instanciados em diferentes instâncias de plataforma nativa, por exemplo, como representado na Figura 16. Os enclaves podem ser instanciados por um cliente de enclave especificando uma imagem binária de enclave (tal como a imagem primária 1410 da Figura 14) via um método CreateEnclave das plataformas de abstração 1614 e 1624. A imagem binária de enclave especificada para instanciar os dois enclaves pode ser a mesma ou diferente. Um relatório de atestação para cada enclave instanciado é criado na caixa 1704. Os relatórios de atestação podem ser criados, por exemplo, na solicitação do cliente de enclave ou na solicitação dos próprios enclaves. Uma entidade desejando

Petição 870190060870, de 28/06/2019, pág. 84/143

73/102 provar equivalência dos dois enclaves, tal como o cliente de enclave, obtém cópias de ambos os relatórios de atestação. Os relatórios de atestação podem ser opcionalmente verificados na caixa 1706. Por exemplo, a integridade do relatório pode ser verificada pela verificação da assinatura de atestação com um certificado de endosso (tal como Figura 7, elemento 728) da plataforma nativa que produziu o relatório de atestação. Além disso, o certificado de endosso pode ser verificado com a chave pública (tal como Figura 7, elemento 732) do fabricante da plataforma nativa. Valores de identidade (ou de um hash da mesma) podem ser extraídos a partir década relatório de atestação na caixa 1708, e a equivalência dos dois enclaves pode ser determinada por se verificar que os valores de identidade extraídos são os mesmos para cada enclave. Estes valores de identidade podem ser valores de identidade abstrata (ou hashs das mesmas) associados com um tipo de identidade.

[00170] Uma vez que o cliente do enclave provou a equivalência de duas instanciações de enclave a partir das operações nas caixas 1708 e 1710, os dois enclaves podem ser utilizados de forma intercambiável, de acordo com o tipo de equivalência apresentado. As caixas 1712 a 1720 representam um método ilustrativo para utilizar os enclaves equivalentes para utilizar os dois enclaves equivalentes instanciados de uma maneira em processamento paralelo. Nas caixas 1712 e 1716, uma parte de um conjunto de dados de entrada, tal como parte de uma base de dados ou parte de um arquivo de imagem digital, é copiada para o primeiro e para o segundo enclaves. A parte do conjunto de dados copiada pode ser idêntica ou diferente de acordo com a tarefa de processamento em mãos. Uma operação de processamento pode ser de forma segura executada em paralelo por simultaneamente parcialmente executar a operação no primeiro enclave na caixa 1714 e parcialmente executar a operação no

Petição 870190060870, de 28/06/2019, pág. 85/143

74/102 segundo enclave na caixa 1718. A operação pode ser, por exemplo, pesquisar a base de dados ou executar uma operação de processamento de imagem. O primeiro enclave pode pesquisar a primeira metade da base de dados ou executar a operação de processamento de imagem na primeira metade de uma imagem, enquanto o segundo enclave Poe pesquisar a segunda metade da base de dados ou executar a operação de processamento de imagem da segunda metade da imagem. Finalmente, na caixa 1720, os resultados do processamento paralelo no primeiro e no segundo enclave podem ser combinados, por exemplo, pela combinação das duas metades classificadas da base de dados, ou pela colocação das duas metades de imagem juntas novamente.

[00171] A Figura 18 representa um fluxograma ilustrativo para processamento serial com dois enclaves equivalentes. Como representado na Figura 18, uma operação do enclave, tal como uma operação de base de dados ou uma operação de processamento de imagem, é feita de forma segura em duas partes seqüenciais nos dois enclaves separados. O processo 1800 pode ser executado, por exemplo, pelo cliente do enclave 1602 da Figura 16. Na caixa 1802, um primeiro enclave é criado em uma primeira plataforma de enclave nativa, e um relatório de atestação do primeiro enclave é criado na caixa 1804. Este primeiro relatório de atestação (do primeiro enclave) pode ser verificado na caixa 1806, por exemplo, como descrito acima com respeito à caixa 1706 da Figura 17. Na caixa 1808, uma operação segura é iniciada no primeiro enclave, mas não completada. O estado do primeiro enclave pode opcionalmente ser selado para ser de forma segura levado do primeiro enclave na caixa 1810. Por exemplo, o estado do primeiro enclave pode ser selado para um tipo de identidade do primeiro enclave. Uma vez que o estado do enclave tenha sido salvo, o primeiro enclave pode ser terminado (não representado).

Petição 870190060870, de 28/06/2019, pág. 86/143

75/102 [00172] Um segundo enclave é utilizado iniciando na caixa 1812. Na caixa 1812, o segundo enclave é instanciado em uma segunda plataforma nativa. Como nas Figuras 16 e 17, a segunda plataforma nativa pode ou não ser hospedada no mesmo computador que a primeira plataforma nativa, e a primeira e a segunda plataformas nativas podem ser as mesmas ou diferentes. Um relatório de atestação da segunda plataforma nativa é criado na caixa 1814, e, opcionalmente, este segundo relatório de atestação pode ser verificado na caixa 1816. Um valor de identidade a partir do primeiro e do segundo relatórios de atestação pode ser comparado na caixa 1818 para verificar a equivalência do primeiro e do segundo enclaves. Em modalidades alternativas, o segundo enclave pode ser instanciado e a equivalência verificada (caixas 1812 a 1818) antes da operação segura ser iniciada no primeiro enclave na caixa 1808. Para continuar a operação segura iniciada no primeiro enclave, o estado selado a partir do primeiro enclave pode ser copiado para o segundo enclave e ter a selagem retirada na caixa 1820. Na caixa 1822, a operação segura é completada no segundo enclave (utilizando o estado do enclave de forma segura copiado a partir do primeiro enclave, se o estado foi copiado).

SELAGEM DE DADOS DISTRIBUÍDA [00173] A Figura 19 é um diagrama de blocos de um sistema ilustrativo de selagem de dados distribuída. A selagem de dados pode ser distribuída através de vários enclaves, onde estes enclaves são hospedados em plataformas de enclave nativas separadas, e/ou em computadores separados. Como explicado acima, as primitivas de abstração EnclaveSeal e EnclaveUnseal podem selar e retirar a selagem de dados para um enclave utilizando uma chave ligada com a plataforma de enclave nativa ou com o computador físico no qual um enclave está executando. Isto pode restringir a retirada de selagem

Petição 870190060870, de 28/06/2019, pág. 87/143

76/102 para somente enclaves hospedados no mesmo computador ou para a mesma instância de plataforma de enclave nativa. A Figura 19 representa um sistema de vedação de dados distribuída, onde a selar ou retirar a selagem de dados pode ocorrer em uma plataforma nativa ou computador diferente da plataforma nativa ou computador hospedando um enclave. O sistema 1900 inclui os computadores 1910, 1930, 1950, com a rede 1902 conectando os computadores 1910 e 1930, e a rede 104 conectando os computadores 1930 e 1950. O computador 1910 hospeda o enclave fonte 1912, a partir do qual os dados a serem selados podem ter origem; o computador 1930 hospeda um enclave de selagem distribuída (DSE) 1932 para servir as solicitações de selagem e retirada de selagem distribuídas, e o computador 1950 hospeda o enclave destino 1952, onde dados anteriormente selados têm a selagem retirada. Como explicado acima com respeito à Figura 9, os enclaves 1912, 1932, 1952 podem se comunicar com as plataformas de abstração 1914, 1934, 1954, respectivamente, via um protocolo de abstração de enclave, e as plataformas 1014, 1934, 1954 podem se comunicar com as plataformas nativas 1916, 1936 e 1956, respectivamente, via um protocolo nativo. Em modalidades alternativas, um ou mais enclaves 1912, 1932, 1950 podem ser hospedados diretamente nas plataformas nativas 1961, 1936, 1956 sem uma plataforma de abstração intermediária. Os dados selados 1938 podem ser dados selados para o DSE 1932 utilizando uma chave associada com o DSE 1932 ou com sua plataforma nativa hospedeira 1936. Os dados selados 1938 podem ser armazenados em uma localização menos protegida, tal como no computador 1930 fora do container seguro do enclave do DSE 1932, por exemplo, em qualquer outro lugar no espaço de memória do computador 1930 ou em um sistema de arquivos de um disco rígido.

Petição 870190060870, de 28/06/2019, pág. 88/143

77/102 [00174] A selagem de dados distribuída pode incluir autenticação do DSE 1930 para o enclave fonte, por exemplo, pela atestação do DSE 1932 através da rede 1902. Uma vez que o enclave fonte 1912 acredita o DSE 1932, o enclave fonte 1912 pode enviar dados sensíveis através de um canal de comunicação seguro para o DSE 1932 junto com a política de selagem para selagem pelo DSE 1932. O DSE 1932 pode então selar os dados a partir do enclave 1912 nele próprio e armazenar os dados selados no armazenamento não seguro. Posteriormente, o enclave destino 1952 pode solicitar os dados anteriormente selados. Para retirar a selagem dos dados, o DSE 1932 pode autenticar o enclave destino 1952, por exemplo, pela atestação através da rede 1904, e verificar que a retirada de selagem para o enclave destino 1952 é permitida de açodo com a política de selagem proporcionada pelo enclave fonte 1912. O DSE 1932 pode retirar a selagem dos dados anteriormente selados a partir do enclave fonte 1912, e então, enviar os dados com a selagem retirada através de um canal de comunicação seguro para o enclave destino 1952. Os dados de enclave podem ser comunicados de forma segura para e a partir do DSE 1932 pela criptografia dos dados de enclave através das redes 1902 e 1904. Por exemplo, os dados de enclave enviados através da rede 1902 podem ser criptografados com uma chave gerada durante a atestação do DSE 1932 para o enclave fonte 1912, e os dados enviados através da rede 1904 podem ser criptografados com uma chave gerada durante a atestação do enclave destino 1952 para o DSE 1932. Outros canais de comunicação seguros são possíveis, tal como criptografia com uma chave pública do destino, por exemplo, uma chave pública associada com o DSE ou uma chave pública associada com o enclave destino.

[00175] As identidades de enclave utilizadas na selagem e retiradas de selagem distribuídas podem ou não ser identidade de enclave

Petição 870190060870, de 28/06/2019, pág. 89/143

78/102 abstrata. Por exemplo, em algumas modalidades com uma camada de plataforma de abstração, uma política de selagem, tal como uma especificada por um enclave fonte e imposta por um DSE, pode identificar identidades de enclave de retirada de selagem permitidas onde as identidades de enclave de retirada de selagem permitidas são, por exemplo, uma lista e identidades de enclave abstratas, ou uma lista de tipos de identidade abstrata em combinação com valores de identidade abstrata do enclave fonte. Em outras situações, uma identidade que não é abstrata pode ser utilizada. Por exemplo, em algumas modalidades, um DSE pode ser implementado com código publicamente disponível, de modo que a confiança no DSE é confiança no conhecimento de seu código, oposto à confiança no autor de seu código. Neste exemplo, a atestação de um DSE pode ser um hash sinalizado de todo o código público do DSE, e a entrada para a função hash pode não incluir valores de identidade abstrata assinados pelo autor.

[00176] Em algumas modalidades, as plataformas nativas 1916, 1936, 1956 são plataformas nativas separadas devido às mesmas serem hospedadas em diferentes computadores 1910, 1930, 1050, mesmo se as plataformas nativas 1916, 1936, 1956 forem de acordo com a mesma versão da mesma arquitetura de plataforma de enclave nativa. Em outras modalidades, as plataformas nativas 1916, 1936, 1956 podem ser de acordo com diferentes arquiteturas de plataforma ou com diferentes versões da mesma arquitetura de plataforma de enclave nativa. O uso de identidades abstratas na política de selagem pode facilitar a fonte de hospedagem e os enclaves destinos em diferentes arquiteturas de plataforma nativa.

[00177] Em outras modalidades da selagem de dados distribuída não representadas na Figura 19, podem não existir três computadores separados (tais como os computadores separados 1910, 1930,1950).

Petição 870190060870, de 28/06/2019, pág. 90/143

79/102

Por exemplo, os enclaves fonte e destino podem estar em um computador (e talvez em uma única plataforma nativa), enquanto o DSE está em um computador separado. Alternativamente, um DSE pode estar hospedado no mesmo computador que o computador hospedeiro do enclave fonte ou do computador hospedando o enclave destino. Nestas modalidades de selagem de dados distribuída, a selagem e a retirada de selagem dos dados não são total mente locais a um único computador, como é descrito acima com respeito às primitivas de abstração EnclaveSeal e EnclaveUnseal.

[00178] A selagem de dados distribuída pode ser implementada em uma API da camada de abstração, tal como pelas plataformas de abstração 1914, 1934, 1954. Por exemplo, as primitivas DistributedEnclaveSeal e DistributedEnclaveUnseal são similares às primitivas de selagem de dados locais EnclaveSeal e EnclaveUnseal discutidas acima.

DWORD

DistributedEnclaveSeal ( _ln_ SEAL1NG_POLICY sealingPoliey,

J.n jeads^ bytes _optjCdwPlaintextSize) LFC V0ID pPhintext, _In_ DWORD dwPlàintextSize.

_In_reads_bytes_opt_(dwAuthdataSize) LPCVOTD pAuthdata,

J.n~ DWORD dwAuthdaUSize, „Oüt jvrites jyte^UJdwSededtextSize) LPV01D pSealedtext,

JiK-vii DWORD dwSealedtextSize, SeKEndaveMetôity> SetOfTargetEncSaves )

[00179] DistributedEnclaveSeal estende EnclaveSeal por pegar um parâmetro adicional SetOfTargetEnclaves, o qual permite que um enclave de chamada, tal como o enclave 1910, especifique um conjunto de identidades de enclave que são autorizadas a retirar a

Petição 870190060870, de 28/06/2019, pág. 91/143

80/102 selagem dos dados proporcionados via o parâmetro pPlaintext. Se nenhuma identidade for proporcionada via SetOfTargetEnclaves, uma identidade de enclave autorizado preestabelecida pode ser assumida para ser uma identidade do enclave de selagem, por exemplo, ExactHash ou InstanceHash do enclave de selagem.

[00180] A implementação de DistributedEnclaveSeal, por exemplo, como um método da plataforma de abstração 1914 no computador do enclave fonte, pode incluir estabelecer um canal de comunicação seguro com um DSE, tal como por criptografar a mensagem através da rede 1902. A(s) chave(s) para esta criptografia pode(m), por exemplo, ser gerada(s) durante um processo de atestação, como descrito acima, ou pode ser qualquer chave pública associada com o DSE 1932.

[00181] DistributedEnclaveSeal pode ser ainda generalizado por pegar um parâmetro adicional KeyForData (não apresentado no protótipo de função DistributedEnclaveSeal acima). Em algumas modalidades, vários conjuntos de dados podem ser mantidos selados simultaneamente para um único enclave ou para uma única identidade de enclave. Neste caso, KeyForData permite a especificação de qual conjunto de dados está sendo selado. KeyForData pode ser qualquer tipo de identificador de dados, tal como uma cadeia, um número, ou um conjunto de propriedades. Em algumas modalidades, KeyForData pode ser um parâmetro de entrada para DistributedEnclaveSeal e gerado pelo enclave de selagem, eficazmente permitindo que o enclave de selagem nomeie o conjunto de dados. Em outras modalidades, KeyForData pode ser um parâmetro de saída, onde o DSE gera o identificador KeyForData à medida que os dados são selados.

Petição 870190060870, de 28/06/2019, pág. 92/143

81/102

DWORD

DisUíbutdEnclaveUnseal( in.reads.bytes.opi (dwSeriedtextStee)LPCVOIDpSeatatet,

Jto~ DWORD wSeaíedtextSize,

Jn _reads_bytes _opt_(dwAutlidataSize) LPCVOID pAüthdata, ln~ DWORD dw.AiitMaUSàe.

_Out_writes_bytes_to_(dwPlaintextSize) LPCVOID pPlaintext, _Inout_ DWORD dwPtontextSize

Key KeyForData,

Enclavddentity Identity [00182] DistributedEnclaveUnseal pode ser implementado na plataforma de abstração 1954, e operar em resposta a uma solicitação a partir de um enclave destino 1952. DistributedEnclaveUnseal pode estabelecer um canal de comunicação seguro para o DSE 1932, por exemplo, por criptografar mensagens com uma chave gerada durante a atestação do enclave destino 1952 para o DSE 1932, ou por criptografar mensagens enviadas para o enclave destino com uma chave pública do enclave destino. O DSE pode verificar uma identidade do enclave solicitante (destino) tal como por atestação, retirar a selagem dos dados selados solicitados, e de forma segura enviar os dados com a selagem retirada para o enclave solicitante. Nas modalidades onde o enclave solicitante possui vários identificadores, uma identidade particular pode ser especificada no parâmetro Identity. Nas modalidades onde vários conjuntos de dados de enclave estão armazenados para uma única identidade de enclave, o parâmetro KeyForData pode especificar qual conjunto de dados selados (para a identidade especificada) é solicitado por utilizar o mesmo valor KeyForData utilizado em DistributedEnclaveSeal quando o conjunto de dados foi selado.

Petição 870190060870, de 28/06/2019, pág. 93/143

82/102 [00183] Em algumas modalidades, as identidades de enclaves autorizados a retirar a selagem de dados podem ser especificadas (tal como no parâmetro SetOfTargetEnclaves) pelas chaves públicas dos enclaves alvo autorizados. Nesta modalidade, a atestação do enclave destino para o DSE pode não ser necessária, mas os dados com a selagem retirada somente podem então ser proporcionados como criptografados utilizando uma das chaves públicas especificadas. Assumindo que somente os enclaves desejados têm acesso às chaves privadas correspondentes para decriptação, somente os enclaves desejados terão acesso aos dados com a selagem retirada.

[00184] Em modalidades não representadas na Figura 19, as funções do enclave de selagem distribuída (DSE) 1032 podem ser elas próprias distribuídas através de vários DSEs. Por exemplo, a funcionalidade do DSE pode ser distribuída através de vários DSEs em vários computadores para redundância e tolerância a falha. Neste exemplo, qualquer DSE replicado pode estar apto a servir uma solicitação de selagem e de retirada de selagem. Observe que os dados selados 1938, uma vez que eles sejam selados / tenham a selagem retirada, podem ser armazenados de forma segura em qualquer lugar, incluindo sendo replicados através dos servidores de armazenamento da nuvem.

[00185] A selagem de dados distribuída pode permitir movimento de cargas de trabalho do enclave entre computadores. Por exemplo, os dados de enclave fonte selados por um DSE podem ser dados de estado do enclave fonte em um primeiro servidor da nuvem, os quais podem ser carregados no enclave destino em um segundo servidor da nuvem após a retirada de selagem. Isto pode ser feito de forma similar ao descrito acima com respeito à Figura 18. Uma operação segura pode iniciar a execução no enclave fonte. Posteriormente, talvez após a execução no enclave fonte ser interrompida, o estado do enclave

Petição 870190060870, de 28/06/2019, pág. 94/143

83/102 fonte pode ser selado para um DSE, e então ter a selagem retirada para um enclave destino quando o enclave destino está pronto para continuar a operação segura que foi iniciada no enclave fonte.

[00186] A Figura 20 é um fluxograma ilustrativo para selagem de e retirada de selagem de dados distribuída, como podem ser executadas por um enclave de selagem ou DSE. As caixas 2002 a 2006 correspondem à selagem de dados distribuída, enquanto as caixas 2008 a 2010 correspondem à retirada de selagem de dados distribuída. Em resposta a uma solicitação para selar um conjunto de dados de enclave se originando a partir de um enclave fonte, o enclave de selagem (ou DSE) pode atestar a si próprio para o enclave fonte, por enviar um relatório ou quota de atestação para o enclave fonte na caixa 2002. O enclave fonte pode verificar a identidade do enclave de selagem como um enclave de selagem genuíno e confiável por inspecionar um valor de identidade e assinatura no relatório de atestação do enclave de selagem. Na caixa 2004, o enclave de selagem recebe uma lista de permitidas e os dados de enclave a serem selados. Estes podem ser recebidos via um canal seguro como descrito acima com respeito à Figura 19. Na caixa opcional 2006, o enclave de selagem pode selar os dados de enclave fonte para ele próprio, por exemplo, se os dados estiverem armazenados fora do container seguro do enclave de selagem, tal como em um sistema de arquivos do computador. Para retirar a selagem dos dados para um enclave destino, o enclave destino pode atestar a si próprio para o enclave de selagem, tal como por proporcionar um relatório ou quota de atestação, na caixa 2008. Na caixa 2010, uma identidade do enclave destino pode ser verificada, tal como por inspecionar o relatório de atestação do enclave destino. Na caixa 2012, o enclave de selagem determina se o enclave destino tem permissão para retirar selagem de dados a partir do enclave fonte por verificar que uma

Petição 870190060870, de 28/06/2019, pág. 95/143

84/102 identidade autenticada do enclave destino está incluída na lista de permitidas recebida com os dados. Uma vez que a permissão tenha sido confirmada, os dados de enclave podem ter a selagem retirada se eles foram selados, e então enviados para o enclave destino via um canal seguro na caixa 2014.

ENCLAVE DE CAIXA-FORTE DE CHAVES [00187] Caixas-fortes podem ser implementadas com os enclaves. Uma caixa-forte de chaves de forma segura mantém chaves, tais como chaves de um sistema de criptografia para criptografar e decriptografar dados, para cliente da caixa-forte de chaves. Uma caixa-forte de chaves pode adicional mente executar operações com a chave, tal como criptografar e decriptografar dados, assinar dados, e derivar novas chaves a partir de uma chave existente. Uma caixa-forte de chaves, quando implementada como um enclave, pode proporcionar armazenamento muito seguro de e processamento com chaves de criptografia secretas. Adicionalmente, a atestação de software de um enclave de caixa-forte de chaves pode proporcionar altos níveis de segurança para um cliente da caixa-forte que está se comunicando com uma caixa-forte autêntica e confiável. Sistemas altamente seguros podem ser construídos em um enclave de caixaforte de chaves com uma chave bloqueada pela caixa-forte, por meio do que uma chave armazenada dentro de uma caixa-forte de chaves nunca é liberada para qualquer cliente fora da caixa-forte de chaves, e em alguns casos, a chave bloqueada pela caixa-forte pode somente sempre existir como armazenada dentro (ou possivelmente selada para) o enclave de caixa-forte de chaves.

[00188] A Figura 21 é um diagrama de blocos de um enclave de caixa-forte de chaves ilustrativo. O enclave 2122 é uma caixa-forte de chaves dentro de um container seguro do enclave da segunda plataforma de enclave nativa 2126. No exemplo da Figura 21, o cliente

Petição 870190060870, de 28/06/2019, pág. 96/143

85/102

2112 do enclave de caixa-forte de chaves 2122 também é um enclave, e hospedado dentro de um container seguro do enclave da primeira plataforma de enclave nativa 2116. Os enclaves 2112, 2122 podem interagir com suas respectivas plataformas nativas 2112, 2126 via as respectivas plataformas de abstração de enclave 2114, 2124. Em outras modalidades, uma ou ambas as plataformas de abstração 2114, 2124 podem não existir onde os enclaves 2112 e/ou 2122 interagem diretamente com as plataformas nativas 2116, 2126.

[00189] O enclave de caixa-forte de chaves 2122 pode se comunicar com seu cliente de caixa-forte 2112 via o canal de comunicações 2150. Em algumas modalidades, o canal de comunicações 2112 pode ser um canal de comunicações seguro proporcionando segurança de sigilo, integridade, e/ou frescor de mensagens enviadas através do canal de comunicação 2150. O sigilo e a integridade de tal canal de comunicações seguro pode ser estabelecida, por exemplo, com criptografia e assinaturas, como nas Figuras 2 e 3, utilizando chaves compartilhadas geradas como parte de um processo de atestação, como nas Figuras 5 e 6.

[00190] A atestação de software proporciona segurança em parte por proporcionar segurança da identidade da entidade no outro tamanho de um canal de comunicação. Por atestar o enclave de caixaforte de chaves 2122 para um cliente de caixa-forte, o cliente pode obter garantia de que o enclave de caixa-forte de chaves 2122 é quem ele diz que é antes de enviar um segredo, tal como uma chave ou outros dados de texto não criptografado, para a caixa-forte de chaves. O inverso também é verdadeiro para clientes que também são enclaves, como representado na Figura 21. Por atestar o enclave de caixa-forte 2112 para um enclave de caixa-forte de chaves 2122, a caixa-forte de chaves de chaves pode obter garantia de que o cliente é quem ele diz antes de revelar um segredo, tal como uma chave ou

Petição 870190060870, de 28/06/2019, pág. 97/143

86/102 outros dados de texto não criptografado, para o cliente.

[00191] Os sistemas de caixa-forte de chaves com chaves bloqueadas pela caixa-forte e chaves derivadas, particularmente onde chaves de criptografia são derivadas a partir de uma chave bloqueada pela caixa-forte, podem ser utilizados para construir um sistema de segurança que seja flexível e muito seguro. Uma função de derivação de chave, a qual pode ou não ser pública, pode ser utilizada para gerar várias chaves a partir de uma primeira chave. A primeira chave (um segredo raiz) pode ser bloqueada pela caixa-forte para nível mais alto de segurança, e as chaves derivadas a partir da primeira chave podem ser utilizadas para propósito de criptografia. Se uma chave derivada for comprometida, uma nova chave derivada pode ser gerada em um sistema existente sem ter que acessar ou alterar o cofre-forte de chaves mantendo a primeira chave.

[00192] Um enclave de caixa-forte de chaves (KVE) ilustrativo é um sistema de caixa-forte de chaves baseado em nuvem que proporciona armazenamento de chave, geração, derivação, distribuição, criptografia, decriptografia e assinaturas utilizando enclaves. O KVE pode ser identificado por seu hash exato (um hash do conteúdo de seu container seguro), ou por um identificador arbitrário assinado por ou associado com seu criador. No último caso, o enclave pode ser assinado com a chave privada de seu criador para evitar conflitos e brechas se segurança devido às colisões do identificador.

[00193] Um cliente da caixa-forte de chaves pode interagir com um sistema de caixa-forte de chaves utilizando as seguintes primitivas ilustrativas. Um protótipo de função StoreKey ilustrativa é:

StoreKey([iíi] Keyname, [in] KeyType, [in] KeyValue, [in] Policy) [00194] StoreKey armazena uma dada chave no cofre-forte de chaves e associa a mesma com um dado nome. O tipo de chave também é associado com a chave e restringe o que pode ser feito com

Petição 870190060870, de 28/06/2019, pág. 98/143

87/102 a chave. Por exemplo, algumas chaves somente elevem ser utilizadas para criptografia, outras para assinaturas, etc. Além disso, chaves específicas somente podem ser utilizadas com algoritmos de criptografia específicos. A política pode especificar políticas para ainda restringir o uso da chave. Por exemplo, ela pode especificar um conjunto de identidades de enclave que tem a permissão de recuperar a chave e/ou utilizar a chave. Ela também pode especificar propriedades temporais, por exemplo, que a chave deve ser destruída em alguma data, ou que a taxa de operações utilizando a chave deve ser limitada.

[00195] Um protótipo de função GenerateKey ilustrativa é:

GenerateKey([Ín] keyName, [in] keyType. [in] Pôlicy) [00196] GenerateKey gera uma nova chave de algum tipo e mantém a mesma armazenada dentro do cofre-forte de chaves, isto é, a chave nunca deixa o cofre-forte de chaves.

[00197] Um protótipo de função GetKey ilustrativo é:

GetKey ([in] KeyName, [out] KeyValue) [00198] GetKey busca uma chave armazenada dentro do cofre-forte de chaves. Estas primitivas tipicamente são implementadas através de um canal de comunicação seguro e o código que chama a primitiva tipicamente executa em um ambiente confiável. Em tal contexto, frequentemente é aceitável recuperar uma chave a partir do cofre-forte de chaves.

[00199] Um protótipo de função DeleteKey ilustrativo é: DeleteKey([in] keyName) [00200] DeleteKey deleta uma chave do cofre-forte de chaves. [00201] Um protótipo de função DeriveKey é:

DeriveKey([ín] newKeyName, [ia] KeyName, [in] kdfldentifier, [in]

AdditionalData)

Petição 870190060870, de 28/06/2019, pág. 99/143

88/102 [00202] DeriveKey utiliza a função de derivação de chave criptográfica (KDF) identificada por kdfldentifier para derivar uma nova chave baseado na chave identificada por keyName e nos dados passados em AdditionalData.

[00203] Um protótipo de função Encrypt ilustrativo é:

.Encrypt-([in] KeyName, [in] algorithm, [in] data, [out]en€ryptedData) [00204] Encrypt criptografa os dados com a chave identificada por KeyName, utilizando o algoritmo solicitado.

[00205] Um protótipo de função Decrypt ilustrativo é:

Decrypt([ia] KeyName, [in] algorithm, [in] encrytedData, [outjdata) [00206] Decrypt decriptografa os dados com a chave identificada por KeyName, utilizando o algoritmo solicitado.

[00207] Um protótipo de função Sign ilustrativo é:

Sign([in] KeyName, [in] algorithm, [in] data, [out] rignature) [00208] Sign assina os dados com a chave identificada por KeyName, utilizando o algoritmo solicitado.

[00209] Um protótipo de função VerifySignature ilustrativo é: VeritySigiiature([iii]KevNam.e. [in] algorithm, [in] signature, (out) bool signaturelsCoTiect) [00210] VerifySignature verifica a assinatura com a chave identificada por KeyName, utilizando o algoritmo solicitado.

[00211] Todas as primitivas de caixa-forte de chaves acima podem ser implementadas por se estabelecer um canal seguro com o KVE. O canal pode ser estabelecido utilizando atestação e executando uma troca de chave de Diffie-Hellman como descrito acima com respeito às Figuras 5 e 6. Após o canal de comunicação ser estabelecido, a solicitação é enviada de forma segura através do canal e a resposta é lida a partir do canal. O canal pode proporcionar garantias de sigilo e de integridade dos dados trocados.

[00212] Em outra modalidade, a primeira vez que o KVE executa,

Petição 870190060870, de 28/06/2019, pág. 100/143

89/102 ele gera um par de chaves pública / privada e ele gera uma quota para a chave pública. Então, ele grava a quota e a chave pública, enquanto mantendo a chave privada dentro do enclave. A chave pública e a quota então podem ser distribuídas para todos os sistemas / códigos que desejam utilizar o cofre-forte de chaves. Neste caso, a implementação das primitivas acima verifica a quota e confirma que ela está falando com um KVE genuíno, e então, criptografa a solicitação utilizando a chave pública do KVE. Como parte da solicitação, a implementação das primitivas pode incluir uma chave para criptografia e proteção de integridade dos resultados enviados a partir do KVE. Esta modalidade pode proporcionar um canal de comunicações bidirecional seguro sem atestação.

[00213] A Figura 22 é um fluxograma ilustrativo para algumas operações do enclave de cofre-forte de chaves. O processo 2200 inicia na caixa de entrada 2202 por de forma segura armazenar, dentro do enclave de cofre-forte de chaves, uma chave utilizada em um sistema de criptografia. A chave pode ser utilizada, por exemplo, para criptografar ou decriptog rafar dados, gerar uma assinatura criptográfica, ou pode somente ser utilizada como uma chave raiz a partir da qual derivar outras chaves. A chave pode ser armazenada de forma segura no enclave de cofre-forte de chaves, por exemplo, por armazenar a chave dentro do espaço de memória do container seguro do enclave. Em outras modalidades, a chave pode ser mantida segura fora do container seguro do enclave por selar os dados da chave para o enclave de cofre-forte de chaves, ou pode ser mantida segura por remotamente selar com um enclave de selagem distribuída como descrito com respeito às Figuras 19 e 20.

[00214] Na caixa 2204, o enclave de cofre-forte de chaves executa um processo de atestação para atestar a identidade do enclave cofreforte de chaves para o cliente do cofre-forte. Isto pode dar ao cliente

Petição 870190060870, de 28/06/2019, pág. 101/143

90/102 garantia de que o cofre-forte de chaves não é um impostor e pode ser confiável com segredos tais como uma chave ou dados a serem criptografados. A atestação do enclave de cofre-forte de chaves pode incluir enviar, para o cliente do cofre-forte, um relatório de atestação ou quota de atestação do enclave de cofre-forte de chaves. O cliente do cofre-forte de chaves pode então verificar a integridade do relatório de atestação por verificar uma assinatura no relatório de atestação com uma chave pública associada com a plataforma de enclave nativa do enclave de cofre-forte de chaves. Por exemplo, o relatório de atestação do cofre-forte de chaves 2122 pode ser gerado pela segunda plataforma nativa 2126, e o cliente do cofre-forte 2112 pode verificar a assinatura no relatório utilizando uma chave pública associada com a segunda plataforma nativa 2126. Este processo de atestação também pode gerar chaves utilizadas para um canal de comunicação seguro entre o cliente do cofre-forte e o enclave de cofre-forte de chaves, por exemplo, como apresentado nas Figuras 5 e

6. O relatório de atestação pode incluir uma identidade do enclave cofre-forte de chaves que pode ser determinado de vários modos como descrito acima, por exemplo, com respeito às Figuras 14 e 15. A identidade pode, por exemplo, ser baseada em um hash de todo o conteúdo do container seguro do enclave de cofre-forte de chaves, um hash somente de um único identificador assinado pelo autor / criador do enclave de cofre-forte de chaves, ou um hash de uma combinação de uma parte do conteúdo do container com um identificador único.

[00215] Algumas operações do enclave de cofre-forte de chaves também podem requerer garantia da identidade do cliente do cofreforte. Por exemplo, decriptografar dados ou divulgar uma chave (tal como com as primitivas Decrypt ou GetKey) pode requere tal garantia. Nestas situações, se um cliente de cofre-forte também for um enclave, a caixa opcional 2208 inclui um processo de atestação para verificar,

Petição 870190060870, de 28/06/2019, pág. 102/143

91/102 pelo enclave cofre-forte de chaves, a identidade do cliente do cofreforte. O processo de atestação da caixa 2208 pode incluir receber, no enclave cofre-forte de chaves, um relatório ou quota de atestação do cliente do cofre-forte.

[00216] Na caixa opcional 2210, um canal de comunicações seguro pode ser estabelecido entre o cofre-forte de chaves e o enclave cofreforte de chaves. A comunicação segura pode ser requerida para passar segredos entre o cliente do cofre-forte e o enclave cofre-forte de chaves, tais como chaves ou dados a serem criptografados. O processo de atestação da caixa 2004 ou 2008 pode gerar chaves que podem ser utilizadas para criar um canal de comunicação seguro entre o cliente de cofre-forte e o enclave cofre-forte de chaves, por exemplo, como apresentado nas Figuras 5 e 6. Alternativamente, qualquer chave pública conhecida de um destino de uma mensagem pode ser utilizada para enviar uma mensagem de forma segura.

[00217] Na caixa 2212, uma operação de chave, tal como uma das primitivas de cofre-forte de chaves descritas acima, pode ser executada dentro do enclave cofre-forte de chaves. Durante esta operação, os dados da chave podem ser armazenados somente no espaço de endereços do container seguro do enclave cofre-forte de chaves. Primitivas ilustrativas incluem DeriveKey, Decrypt, Sign e outras.

[00218] O processo 2200 presume que um enclave cofre-forte de chaves já conhece a chave. Observe que para algumas operações do enclave cofre-forte de chaves ou primitivas, tais como StoreKey ou GenerateKey, a ordem das operações pode ser diferente desta que é representada no processo 2200. Por exemplo, para GenerateKey, a operação de geração de chave (como na caia 2212) irá ocorrer antes da operação de armazenamento seguro da caixa 2202. Tal ordem de operação é representada na Figura 23, caixas 2302 a 2308.

Petição 870190060870, de 28/06/2019, pág. 103/143

92/102 [00219] A Figura 23 é um fluxograma ilustrativo para criar e utilizar um enclave cofre-forte de chaves com uma chave bloqueada pelo cofre-forte. Nas caixas 2302 a 2308 do processo 2300, uma nova chave é derivada dentro do enclave cofre-forte de chaves. Nas caixas 2310 a 2316, a chave recentemente derivada é utilizada para executar uma operação de decriptografia. Isto é um uso ilustrativo da chave bloqueada pelo cofre-forte, por meio do qual todas as operações de chave são executadas com o enclave cofre-forte de chave e a chave nunca é proporcionada para um cliente do cofre-forte. Além disso, a nova chave neste exemplo pode nunca existir fora do enclave cofreforte de chaves, devido à mesma ter sido criada (derivada) a partir de dentro do próprio enclave cofre-forte de chave, e nunca proporcionada para o enclave cofre-forte de chaves a partir de um cliente do cofreforte ou de qualquer lugar. Para algumas modalidades e políticas de uso de chave, uma chave bloqueada pelo cofre-forte pode ser efêmera pelo fato de que ela nunca deixa o container seguro do enclave cofreforte de chaves, mesmo após a selagem da chave para o enclave cofre-forte de chaves. Tal chave efêmera, tal como pode ocorrer com uma chave derivada utilizada para temporariamente dar segurança para um canal de comunicações, pode parar de existir em qualquer lugar quando o container do enclave cofre-forte de chaves for destruído ou terminado. Enquanto o processo da Figura 23 ilustra como uma chave bloqueada pelo cofre-forte pode ser utilizada, o processo da Figura 23 também pode ser utilizado com uma chave que não é bloqueada pelo cofre-forte, por exemplo, se a política de uso de chave permitiu que a chave retornasse para o cliente que solicitou sua criação.

[00220] Na caixa 2302, o enclave cofre-forte de chaves atesta a si próprio para o cliente do cofre-forte. Isto pode ser requerido pelo cliente devido ao fato de que o cliente irá proporcionar um segredo a

Petição 870190060870, de 28/06/2019, pág. 104/143

93/102 ser criptografado na caixa 2312. Na caixa 2304, o enclave cofre-forte de chaves pode receber, por exemplo, a partir do cliente do cofre-forte, uma indicação de uma política de uso de chave. A indicação, por exemplo, pode ser uma estrutura de dados especificando a política, ou pode ser um identificador a ser utilizado com um registro de políticas de uso de chave. A própria política de uso de chave pode indicar que esta chave nunca deve ser proporcionada para qualquer cliente de cofre-forte. Na caixa 2306, uma nova chave é derivada a partir de uma chave raiz anteriormente conhecida, por exemplo, com a primitiva DeriveKey descrita acima. Uma solicitação (não representada) para derivar a nova chave pode ser recebida pelo enclave cofre-forte de chaves a partir, por exemplo, do cliente do cofre-forte. Na caixa 2308, a chave recentemente derivada pode ser armazenada de forma segura de acordo com a política de uso de chave recebida.

[00221] O cliente do cofre-forte pode atestar a si próprio para o enclave cofre-forte de chaves na caixa 2310. Um processo de atestação pode incluir receber, no enclave cofre-forte de chaves, um relatório ou quota de atestação do cliente do cofre-forte. A política de uso de chave recebida pode restringir alguns ou todos os usos da nova chave para solicitações a partir de solicitantes que são autenticados via a atestação de software. Nas caixas 2312 a 2316, uma operação de decriptografia, tal como para a primitiva Decrypt acima, é executada utilizando a chave derivada na caixa 2306. Em outras modalidades, outras operações podem ser executadas com uma chave bloqueada pelo cofre-forte, tal como criptografia, assinatura, verificar uma assinatura e derivar outra nova chave a partir da chave derivada na caixa 2306 (derivando uma segunda chave de geração a partir da chave raiz). Na caixa 2312, uma memória temporária de dados criptografados é recebida a partir do cliente do cofre-forte. Os dados criptografados recebidos são decriptografados

Petição 870190060870, de 28/06/2019, pág. 105/143

94/102 com a chave derivada na caixa 1314, e os dados decriptografados resultantes (em uma memória temporária de dados decriptografados) são enviados para o cliente do cofre-forte via o canal de comunicações seguro na caixa 2316.

[00222] Em uma modalidade, um método para selar dados de enclave compreende:

[00223] enviar, para um enclave fonte hospedado em uma primeira plataforma de enclave nativa, um primeiro relatório de atestação de um enclave de selagem hospedado em uma segunda plataforma de enclave nativa;

[00224] receber uma lista de permitidas e dados de enclave associado a partir do enclave fonte, onde a lista de permitidas inclui uma lista de uma ou mais identidades de enclave permitidas para retirada de selagem dos dados de enclave;

[00225] armazenar de forma segura os dados de enclave e a lista de permitidas; e [00226] restringir acesso dos dados de enclave para enclaves com identidades autenticadas permitidas de acordo com a lista de permitidas.

[00227] Em uma modalidade, a primeira plataforma de enclave nativa está em um primeiro computador e a segunda plataforma de enclave nativa está hospedada em um segundo computador.

[00228] Em uma modalidade, a lista de permitidas é uma lista de tipos de identidade abstrata; e ainda compreendendo [00229] receber um relatório de atestação de fonte a partir do enclave fonte; e [00230] derivar um valor de identidade permitida a partir do relatório de atestação de fonte e um tipo de identidade abstrata na lista de permitidas.

[00231] Em uma modalidade, os dados de enclave recebidos são

Petição 870190060870, de 28/06/2019, pág. 106/143

95/102 criptografados, e ainda compreendendo:

[00232] executar um processo de atestação entre o enclave fonte e o enclave de selagem; e [00233] decriptografar os dados de enclave decriptografados com uma chave gerada durante o processo de atestação.

[00234] Em uma modalidade, armazenar os dados de enclave de forma segura inclui:

[00235] criptografar os dados de enclave com uma chave associada com o enclave de selagem para criar dados de enclave selados;

[00236] armazenar os dados de enclave selados no armazenamento persistente; e [00237] após determinar que o acesso é permitido para uma identidade autenticada, decriptografar os dados de enclave selados.

[00238] Em uma modalidade, um método para selar dados de enclave compreende:

[00239] receber, em um enclave fonte hospedado em uma primeira plataforma de enclave nativa, um primeiro relatório de atestação de um enclave de selagem hospedado em uma segunda plataforma de enclave nativa;

[00240] verificar confiança no enclave de selagem; e [00241] enviar uma lista de permitidas e os dados de enclave associados para o enclave de selagem, onde a lista de permitidas inclui uma lista de uma ou mais identidade de enclave permitidas para retirar a selagem dos dados de enclave.

[00242] Em uma modalidade, o método ainda compreende:

[00243] um processo de atestação entre o enclave de selagem e o enclave fonte;

[00244] gerar dados de enclave criptografados por criptografar os dados de enclave com uma chave gerada durante o processo de atestação; e

Petição 870190060870, de 28/06/2019, pág. 107/143

96/102 [00245] onde os dados de enclave enviados para o enclave de selagem são dados de enclave criptografados.

[00246] Em uma modalidade, a primeira plataforma de enclave nativa está em um primeiro computador e a segunda plataforma de enclave nativa está hospedada em um segundo computador.

[00247] Em uma modalidade, a lista de permitidas é uma lista de tipos de identidade abstrata; e ainda compreendendo:

[00248] enviar um relatório de atestação de fonte do enclave fonte para o enclave de selagem, onde o relatório de atestação de fonte inclui pelo menos um valor de identidade do enclave fonte correspondendo a um tipo de identidade abstrata na lista de permitidas.

[00249] Em uma modalidade, o método ainda compreende:

[00250] parcialmente completar uma operação de processamento seguro no enclave fonte; e [00251] onde os dados de enclave incluem dados de estado do enclave fonte suficientes para permitir que outra instanciação de enclave continue a operação de processamento seguro parcialmente completada.

[00252] Em uma modalidade, o sistema compreende pelo menos um processador e memória armazenando nas mesmas instruções que, quando executadas pelo sistema, causam que pelo menos:

[00253] enviar, para um enclave fonte hospedado em uma primeira plataforma de enclave nativa, um primeiro relatório de atestação de um enclave de selagem hospedado em uma segunda plataforma de enclave nativa;

[00254] receber uma lista de permitidas e dados de enclave associados a partir do enclave fonte, onde a lista de permitidas inclui uma lista de uma ou mais identidades de enclave permitidas de retirar a selagem dos dados de enclave;

Petição 870190060870, de 28/06/2019, pág. 108/143

97/102 [00255] armazenar os dados de enclave e a lista de permitidas de forma segura; e [00256] restringir acesso dos dados de enclave aos enclaves com identidades autenticadas que são permitidas de acordo com a lista de permitidas.

[00257] Em uma modalidade, a primeira plataforma de enclave nativa está em um primeiro computador e a segunda plataforma de enclave nativa está hospedada em um segundo computador.

[00258] Em uma modalidade, a lista de permitidas é uma lista de tipos de identidade abstrata, e as instruções ainda causam pelo menos:

[00259] receber um relatório de atestação da fonte do enclave fonte; e [00260] derivar valores de identidade permitida a partir do relatório de atestação de fonte e um tipo de identidade abstrata na lista de permitidas.

[00261] Em uma modalidade, os dados de enclave recebidos são criptografados, e as instruções ainda causam pelo menos:

[00262] executar um processo de atestação entre o enclave fonte e o enclave de selagem; e [00263] decriptografar os dados de enclave criptografados com uma chave gerada durante o processo de atestação.

[00264] Em uma modalidade, armazenar os dados de enclave de forma segura inclui:

[00265] criptografar os dados de enclave com uma chave associada com o enclave de selagem para criar dados de enclave selados;

[00266] armazenar os dados de enclave selados no armazenamento persistente; e [00267] após determinar que o acesso é permitido para uma identidade autenticada, decriptografar os dados de enclave selados.

Petição 870190060870, de 28/06/2019, pág. 109/143

98/102 [00268] Em uma modalidade, o sistema compreende pelo menos um processador e memória armazenando nas mesmas instruções que, quando executadas pelo sistema, causam pelo menos:

[00269] receber, em um enclave fonte hospedado em uma primeira plataforma de enclave nativa, um primeiro relatório de atestação de um enclave de selagem hospedado em uma segunda plataforma de enclave nativa;

[00270] verificar confiança no enclave de selagem; e [00271] enviar uma lista de permitidas e dados de enclave associados para o enclave de selagem, onde a lista de permitidas inclui uma lista de uma ou mais identidades de enclave permitidas para retirar a selagem dos dados de enclave.

[00272] Em uma modalidade, as instruções ainda causam pelo menos:

[00273] um processo de atestação entre o enclave de selagem e o enclave fonte;

[00274] geração de dados de enclave criptografados por criptografar os dados de enclave com uma chave gerada durante o processo de atestação; e [00275] onde os dados de enclave enviados para o enclave de selagem são os dados de enclave criptografados.

[00276] Em uma modalidade, a primeira plataforma de enclave nativa está em um primeiro computador e a segunda plataforma de enclave nativa está hospedada em um segundo computador.

[00277] Em uma modalidade, a lista de permitidas é uma lista de tipos de identidade abstrata; e onde as instruções ainda causam pelo menos:

[00278] enviar um relatório de atestação de fonte do enclave fonte para o enclave de selagem, onde o relatório de atestação de fonte inclui pelo menos um valor de identidade do enclave fonte

Petição 870190060870, de 28/06/2019, pág. 110/143

99/102 correspondendo a um tipo de identidade abstrata na lista de permitidas.

[00279] Em uma modalidade, as instruções ainda causam pelo menos:

[00280] parcialmente completar uma operação de processamento seguro no enclave fonte; e [00281] onde os dados de enclave incluem dados de estado do enclave fonte suficientes para permitir que outra instanciação de enclave continue a operação de processamento seguro parcialmente completada.

[00282] Cada um dos processos, métodos e algoritmos descritos nas seções precedentes podem ser incorporados, e totalmente ou parcialmente automatizados, por módulos de código executados por um ou mais computadores ou processadores de computador. Os módulos de código podem ser armazenados em qualquer tipo de meio não temporário legível por computador ou dispositivo de armazenamento de computador, tal como unidades de disco rígido, memória de estado sólido, disco ótico e/ou coisas parecidas. Os processos e algoritmos podem ser implementados parcialmente ou totalmente no sistema de circuitos de aplicação específica. Os resultados dos processos e etapas do processo revelados podem ser armazenados, persistentemente ou de outro modo, em qualquer tipo de armazenamento não temporário de computador tal como armazenamento volátil ou não volátil. Os vários aspectos e processos descritos acima podem ser utilizados independentemente uns dos outros, ou podem ser combinados de vários modos. É pretendido que todas as combinações e subcombinações possíveis se situem dentro do escopo desta revelação. Em adição, alguns métodos ou blocos de processo podem ser omitidos em algumas implementações. Os métodos e processos descritos neste documento também não estão

Petição 870190060870, de 28/06/2019, pág. 111/143

100/102 limitados a qualquer sequência particular, e os blocos e os estados se relacionando com os mesmos podem ser executados em outras sequências que sejam apropriadas. Por exemplo, os blocos ou estados descritos podem ser executados em uma ordem diferente desta especificamente revelada, ou vários blocos ou estados podem ser combinados em um único bloco ou estado. Os blocos ou estados ilustrativos podem ser executados em série, em paralelo ou de alguma outra maneira. Os blocos ou estados podem ser adicionados ou removidos das modalidades ilustrativas reveladas. Os sistemas e componentes ilustrativos descritos neste documento podem ser configurados de forma diferente do que descrito. Por exemplo, elementos podem ser adicionados, removidos ou reorganizados comparado com as modalidades ilustrativas reveladas.

[00283] Também será apreciado que vários itens são ilustrados como sendo armazenados na memória ou no armazenamento enquanto sendo utilizados, e que estes itens ou partes dos mesmos podem ser transferidos entre a memória e outros dispositivos de armazenamento para propósito de gerenciamento de memória e integridade de dados. Alternativamente, em outras modalidades, alguns ou todos os módulos de software e/ou sistemas podem executar na memória ou em outro dispositivo e se comunicarem com os sistemas de computação ilustrados via comunicação entre computadores. Além disso,em algumas modalidades, alguns ou todos os sistemas e/ou módulos podem ser implementados ou proporcionados de outros modos, tal como pelo menos parcialmente em firmware e/ou hardware, incluindo, mas não limitado a um ou mais circuitos integrados de aplicação específica (ASICs), circuitos integrados padrão, controladores (por exemplo, por executar instruções apropriadas, e incluindo microcontroladores e/ou controladores incorporados), arranjos de portas programáveis em

Petição 870190060870, de 28/06/2019, pág. 112/143

101/102 campo (FPGAs), dispositivo de lógica programável complexa (CPLDs), etc. Alguns ou todos os módulos, sistemas e estruturas de dados também podem ser armazenados (por exemplo, como instruções de software ou dados estruturados) em um meio legível por computador, tal como um disco rígido, uma rede ou um artigo de mídia portátil para ser lido por uma unidade apropriada ou via uma conexão apropriada. Para propósito deste relatório descritivo e das reivindicações, a frase meio de armazenamento legível por computador e variações da mesma, não incluem ondas, sinais, e/ou outras mídias de comunicação temporárias e/ou intangíveis. Os sistemas, módulos e estruturas de dados também podem ser transmitidos como sinais de dados gerados (por exemplo, como parte de uma onda portadora ou de outro sinal propagado analógico ou digital) em vários meios de transmissão legíveis por computador, incluindo meio sem uso de fios e meio com uso de fios, podem assumir várias formas (por exemplo, como parte de um sinal analógico único ou multiplexado, ou como vários pacotes ou quadros digitais discretos). Tais produtos de programa de computador também podem assumir outras formas em outras modalidades. Por consequência, a presente revelação pode ser praticada com outras configurações de sistema de computador.

[00284] A linguagem condicional utilizada neste documento, tal como, entre outras, pode, podería, podia, poder, por exemplo, dentre outras, a não ser que especificamente declarado de outro modo, ou de outro modo entendido dentro do contexto como utilizado, é geralmente pretendida para querer dizer que algumas modalidades incluem, enquanto outras modalidades não incluem, alguns aspectos, elementos e/ou etapas. Assim, tal linguagem condicional geralmente não é pretendida para implicar que aspectos, elementos e/ou etapas sejam de qualquer modo requeridos para uma ou mais modalidades ou que uma ou mais modalidades necessariamente incluem lógica

Petição 870190060870, de 28/06/2019, pág. 113/143

102/102 para decidir, com ou sem entrada ou solicitação do autor, se estes aspectos, elementos e/ou etapas estão incluídos ou são para ser executados em qualquer modalidade particular. Os termos compreendendo, incluindo, possuindo, dentre outros, são sinônimos e são utilizados inclusivamente, de um modo ilimitado, e não excluem elementos, aspectos, atos, operações, dentre outros, adicionais. Além disso, o termo ou é utilizado em seu sentido inclusivo (e não em seu sentido exclusivo) de modo que quando utilizado, por exemplo, para conectar uma lista de elementos, o termo ou significa um, alguns ou todos os elementos na lista.

[00285] Apesar de algumas modalidades ilustrativas terem sido descritas, estas modalidades foram apresentadas a título somente de exemplo e não são pretendidas para limitar o escopo da invenção revelado neste documento. Assim, nada na descrição precedente é pretendido para implicar que qualquer aspecto, característica, etapa, módulo ou bloco particular seja necessário ou indispensável. Na verdade, os novos métodos e sistemas descritos neste documento podem ser incorporados de várias outras formas; além disso, várias omissões, substituições e modificações na forma dos métodos e sistemas descritos neste documento podem ser feitas sem afastamento do espírito das invenções reveladas neste documento. As reivindicações acompanhantes e seus equivalentes são pretendidos para cobrir tais formas ou modificações como se situariam dentro do escopo e do espírito de algumas das invenções reveladas neste documento.

Claims (15)

1. REIVINDICAÇÕES

   1. Método para selar dados de enclave, caracterizado pelo fato de que compreende:

   enviar, para um enclave fonte hospedado em uma primeira plataforma de enclave nativa, um primeiro relatório de atestação de um enclave de selagem hospedado em uma segunda plataforma de enclave nativa;

   receber uma lista de permitidas e dados de enclave associados a partir do enclave fonte, em que a lista de permitidas inclui uma lista de uma ou mais identidades de enclave permitidas para retirar a selagem dos dados de enclave;

   armazenar de forma segura os dados de enclave e a lista de permitidas; e restringir acesso dos dados de enclave aos enclaves com identidades autenticadas que são permitidas de acordo com a lista de permitidas.
2. 2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que:

   a primeira plataforma de enclave nativa está em um primeiro computador e a segunda plataforma de enclave nativa está hospedada em um segundo computador.
3. 3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a lista de permitidas é uma lista de tipos de identidade abstrata e ainda compreendendo:

   receber um relatório de atestação de fonte do enclave fonte; e derivar um valor de identidade permitida a partir do relatório de atestação de fonte e um tipo de identidade abstrata na lista de permitidas.
4. 4. Método, de acordo com a reivindicação 1, caracterizado

   Petição 870190060870, de 28/06/2019, pág. 115/143

   2/5 pelo fato de que os dados de enclave recebidos são criptografados, e ainda compreendendo:

   executar um processo de atestação entre o enclave fonte e o enclave de selagem; e decriptografar os dados de enclave criptografados com uma chave gerada durante o processo de atestação.
5. 5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que armazenar os dados de enclave de forma segura inclui:

   criptografar os dados de enclave com uma chave associada com o enclave de selagem para criar dados de enclave selados;

   armazenar os dados de enclave selados no armazenamento persistente; e após determinar que o acesso é permitido para uma identidade autenticada, decriptografar os dados de enclave selados.
6. 6. Sistema, caracterizado pelo fato de que compreende pelo menos um processador e memória armazenando nas mesmas instruções que, quando executadas pelo sistema, causam pelo menos:

   envio, para um enclave fonte hospedado em uma primeira plataforma de enclave nativa, um primeiro relatório de atestação de um enclave de selagem hospedado em uma segunda plataforma de enclave nativa;

   recebimento de uma lista de permitidas e de dados de enclave associados a partir do enclave fonte, em que a lista de permitidas inclui uma lista de uma ou mais identidades de enclave permitidas de retirar a selagem dos dados de enclave;

   armazenamento dos dados de enclave e da lista de permitidas de forma segura; e restrição do acesso dos dados de enclave aos enclaves com identidades autenticadas que são permitidas de acordo com a

   Petição 870190060870, de 28/06/2019, pág. 116/143

   3/5 lista de permitidas.
7. 7. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de que:

   a primeira plataforma de enclave nativa está em um primeiro computador e a segunda plataforma de enclave nativa está hospedada em um segundo computador.
8. 8. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de que a lista de permitidas é uma lista de tipos de identidade abstrata, e as instruções ainda causam pelo menos:

   recebimento de um relatório de atestação de fonte do enclave fonte; e derivação de valores de uma identidade permitida a partir do relatório de atestação de fonte e um tipo de identidade abstrata na lista de permitidas.
9. 9. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de que os dados de enclave recebidos são criptografados, e as instruções ainda causam pelo menos:

   execução de um processo de atestação entre o enclave fonte e o enclave de selagem; e decriptografia dos dados de enclave criptografados com uma chave gerada durante o processo de atestação.
10. 10. Sistema, de acordo com a reivindicação 6, caracterizado pelo fato de que armazenar os dados de enclave de forma segura inclui:

    criptografar os dados de enclave com uma chave associada com o enclave de selagem para criar dados de enclave selados;

    armazenar os dados de enclave selados no armazenamento persistente; e após determinar que o acesso é permitido para uma identidade autenticada, decriptografar os dados de enclave selados.

    Petição 870190060870, de 28/06/2019, pág. 117/143

    4/5
11. 11. Sistema, caracterizado pelo fato de que compreende pelo menos um processador e uma memória armazenando na mesma instruções que, quando executadas pelo sistema, causam pelo menos:

    recebimento, em um enclave fonte hospedado em uma primeira plataforma de enclave nativa, um primeiro relatório de atestação de um enclave de selagem hospedado em uma segunda plataforma de enclave nativa;

    verificação de confiança no enclave de selagem; e envio de uma lista de permitidas e de dados de enclave associados para o enclave de selagem, em que a lista de permitidas inclui uma lista de uma ou mais identidades de enclave permitidas de retirar a selagem dos dados de enclave.
12. 12. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que as instruções ainda causam pelo menos:

    um processo de atestação entre o enclave de selagem e o enclave fonte;

    geração de dados de enclave criptografados pela criptografia dos dados de enclave com uma chave gerada durante o processo de atestação; e em que os dados de enclave enviados para o enclave de selagem são dados de enclave criptografados.
13. 13. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que:

    a primeira plataforma de enclave nativa está em um primeiro computador e a segunda plataforma de enclave nativa está hospedada em um segundo computador.
14. 14. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que a lista de permitidas é uma lista de tipos de identidade abstrata;

    Petição 870190060870, de 28/06/2019, pág. 118/143

    5/5 e em que as instruções ainda causam pelo menos:

    envio de um relatório de atestação de fonte do enclave fonte para o enclave de selagem, em que o relatório de atestação de fonte inclui pelo menos um valor de identidade do enclave fonte correspondendo a um tipo de identidade abstrata na lista de permitidas.
15. 15. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que as instruções ainda causam pelo menos:

    parcialmente completar uma operação de processamento seguro no enclave fonte; e em que os dados de enclave incluem dados de estado do enclave fonte suficientes para permitir que outra instanciação de enclave continue a operação de processamento seguro parcialmente completada.