BRPI0501783B1 - sistema e processo para inicialização de sistema operacional protegido usando validação de estado - Google Patents

Abstract

"sistema e processo para inicialização de sistema operacional protegido usando validação de estado". descreve-se um mecanismo para inicialização de sistema operacional protegido, que impede componentes invasores de serem carregados com o sistema operacional e, assim, impede a divulgação da chave do sistema sob circunstâncias inadequadas. após uma parte do procedimento de partida da máquina ter ocorrido, o carregador do sistema operacional é executado, o carregador é validado, e a existência de um estado de máquina correta é verificada e/ou criada. após o carregador ter sido verificado, como sendo um carregador legítimo, e o estado da máquina, no qual ela está rodando, é verificado como sendo correto, o comportamento futuro do carregador é conhecido para proteção contra o carregamento de componentes invasores, que podem provocar a divulgação da chave do sistema. com o comportamento do carregador sendo conhecido como seguro para a chave do sistema, o validador pode deslacrar a chave do sistema e fornecê-la ao carregador.

Description

"SISTEMA E PROCESSO PARA INICIALIZAÇÃO DE SISTEMA OPERACIONAL PROTEGIDO USANDO VALIDAÇÃO DE ESTADO" CAMPO DA INVENÇÃO A presente invenção refere-se, de uma maneira geral, ao campo da computação. De modo particular, a invenção fornece um mecanismo para assegura que um sistema proceda de um estado seguro conhecido, e esse mecanismo possa ser usado para inicializar um sistema, de modo a fornecer garantia suficiente de comportamento correto do sistema. Essa garantia de comportamento correto, por sua vez, pode impedir que uma ou mais chaves sejam distribuídas sob circunstâncias inadequadas .

ANTECEDENTES DA INVENÇÃO A segurança do computador depende, muitas vezes, dele ser capaz de prever o comportamento dos componentes de software. Em geral, a segurança de um sistema pode emanar da premissa de que um programa conhecido, cujo comportamento é compreendido, o qual proceda de um bom estado conhecido, a-tue de uma maneira previsível. Em oposição a isto, a obstrução à segurança, que pode envolver a obtenção de um sistema de computador para se comportar de maneira fora das expectativas de seu projetista, pode ser geralmente realizada, por substituição ou alteração de um programa conhecido, ou sua execução em um estado, onde seu comportamento não seja conhecido. Assim, um aspecto do fornecimento de segurança para um ambiente computacional inclui a verificação de se um programa conhecido está sendo usado, e que ele é procedente de um bom estado conhecido.

Uma área, onde a capacidade de previsão do compor-tamento é particularmente importante, é no carregamento de um sistema operacional e de seus componentes. Embora o sistema operacional em si possa ser projetado para fornecer um certo nível de confiança com relação a seu comportamento, o tempo, antes de tal sistema operacional ser carregado, é um tempo em que o sistema é particularmente vulnerável a ataques, visto que a infra-estrutura que protege o sistema operacional contra ataques pode não ter sido ainda estabelecida (ou pode estar no processo de ser estabelecida). Assim, a garantia de que o sistema operacional seja carregado de uma maneira previsível é importante para proteção do sistema o-peracíonal contra certas classes de ataques.

Um tipo de violação de segurança, que pode emanar do carregamento não-seguro de um sistema operacional, se refere â proteção da chave (ou chaves) que permitem certa funcionalidade restrita. Para fins de exemplo, mas não de limitação, os sistemas operacionais WINDOWS da MICROSOFT empregam uma chave de sistema, ou "SYSKEY", que é usada para proteger vários processos, por tornar o correto desempenho desses processos dependentes da disponibilidade da SISKEY. Por exemplo, a chave necessária para descriptografar informações privadas que são armazenadas pelo sistema operacional no formato criptografado, pode ser derivada da SYSKEY.

De modo convencional, as chaves necessárias para realizar operações restritas são protegidas pelo procedimento de logon (entrada em sessão). De modo característico, o usuário precisa se autenticar corretamente (p. ex. , pelo fornecimento das credenciais corretas de logon, tal como uma combinação de nome de usuário/ senha), antes de iniciar o uso do sistema. O uso das chaves é habilitado somente, se o usuário se autenticar corretamente, e o sistema somente irá permitir que o usuário faça um número limitado de tentativas (p. ex. , três), antes de concluir que o usuário deixou de efetuar corretamente o logon. (Este tipo de limite no número de tentativas para logon impede que usuários desautorizados habilitem o uso da funcionalidade protegida, através do uso de um ataque de força bruta para descobrir a senha, no caso, digamos, de um computador laptop roubado). Porém, o uso do procedimento de logon para proteger o acesso às chaves presume que o carregador do sistema operacional carregou corre-tamente o sistema operacional com o programa de logon correto, e que o uso das chaves não tenha sido de outro modo habilitado por código invasor que possa estar rodando. Se um carregador invasor for usado, ao invés disto, e o carregador invasor fizer com que um programa de logon invasor seja carregado com o sistema operacional, então o uso de chaves pode ser habilitado, ou as chaves podem ser mesmo divulgadas, sem que as credenciais corretas tenham sido inseridas. Visto que o carregamento do sistema operacional propicia uma oportunidade para uma violação de segurança, a proteção das chaves em uma situação destas requer que o carregamento do sistema operacional ocorra em circunstâncias onde ele possa ser verificado para ocorrer de forma correta.

Um problema que ocorre com a verificação da segurança de um processo de carregamento do sistema operacional é que carregamentos legítimos do sistema operacional podem envolver muitos programas distintos {p. ex., existem numerosas "ROMs opcionais" distintas, que são programas pré-SO que rodam durante um procedimento de inicialização do sistema), e existem numerosos procedimentos distintos que podem ser realizados fazendo parte de um carregamento de sistema operacional . Assim, existe um número praticamente incontável de estados de máquina legítimos distintos durante um carregamento, e a identificação de todos esses estados e a verificação de que a máquina se encontra em um bom estado conhecido pode comprovar ser uma tarefa inviável. Porém, nem todas as partes do procedimento de carregamento possuem implicações de segurança. Pode ser mais eficiente deixar o carregamento evoluir sem qualquer tentativa de avaliar sua segurança, mas, a seguir, definir o ambiente para um bom estado conhecido, antes de iniciar qualquer procedimento que possa afetar uma função relativa à segurança, tal como a distribuição de chaves. De maneira mais genérica, um sistema arbitrário pode ser permitido rodar por algum tempo sem qualquer tipo de avaliação de segurança, desde que o sistema possa ser definido para um bom estado conhecido, antes de permitir quaisquer ações que tenham implicações de segurança para o-correr.

Com vistas ao anterior, existe a necessidade de um mecanismo que solucione as deficiências da técnica anterior.

SUMÁRIO DA INVENÇÃO A presente invenção proporciona o carregamento de um sistema operacional em circunstâncias onde o carregamento possa ser verificado como sendo corretamente executado. Quando uma máquina é iniciada, o procedimento inicial de partida (p. ex., BIOS, ROMs opcionais, registro de inicialização principal, setor de inicialização etc.) é realizado. Após esses procedimentos iniciais serem realizados, o carregador do sistema operacional é iniciado, e pode realizar várias tarefas preliminares. Após o carregador de o sistema operacional ser iniciado e tiver realizado essas tarefas preliminares, uma validação do carregador do sistema operacional é realizada. A validação compreende a realização de testes de validade no carregador em si, ou em uma parte do carregador (p. ex., somas de verificação, ou outros testes que são destinados â avaliação da identidade e exatidão do carregador), bem como avaliação do estado atual da máquina (ou forçar a máquina a estar de acordo com um bom estado conhecido). Se o carregador (ou parte relevante) for conhecido como estando correto, e o estado da máquina é aquele, em que o carregador foi previamente verificado como tendo um comportamento correto, então o comportamento do carregador pode ser previsto. Assim, pode ser assegurado que um carregador correto operando sob um estado de máquina correto não irá carregar um componente que faça com que dados, que habilitem funções protegidas (p. ex. , chaves criptográficas, tal como a chave do sistema), sejam distribuídos em circunstâncias inadequadas.

De preferência, a validação é realizada por um va-lidador que roda em um ambiente de alta garantia. Um ambiente de alta garantia é aquele, no qual é possível fornecer um grau relativamente alto de garantia, onde os processos nele realizados rodem da maneira para eles prevista. Assim, a garantia para que o validador opere corretamente deriva do fato do validador ser verificado por um processo que roda o ambiente de alta garantia, (p. ex. , por verificação de uma assinatura de seu binário), e da confiança subjacente de que os processos no ambiente de alta garantia sejam realizados de forma correta. (Ou, pelo menos, existe um nível de garantia de que o ambiente de alta garantia não irá interferir, ou permitir interferência, com a operação correta de um processo que opere dentro desse ambiente; deve-se ter ainda uma base de confiança distinta, de que o programa, que implemente um processo dentro do ambiente de alta garantia, irá rodar corretamente da maneira dele esperada). Um ambiente de alta garantia pode fornecer armazenamento lacrado, que é uma unidade de armazenamento onde dados podem ser lacrados a um objeto.específico (p. ex., a um programa específico), e que o controle do ambiente de alta garantia ocorra de tal modo, que os dados lacrados não sejam liberados para qualquer objeto, além daquele ao qual os dados são lacrados (conforme verificado pelo ambiente de alta garantia). O validador pode usar este armazenamento lacrado para lacrar uma chave {p. ex., a SYSKEY) para si próprio, e pode se recusar a desla-crar a chave, exceto para o objeto correto, e quando as circunstâncias (p. ex., o estado da máquina) forem satisfatórias, de acordo com determinado padrão.

Outros aspectos da invenção são abaixo descritos.

BREVE DESCRIÇÃO DOS DESENHOS O sumário anterior, bem como a descrição detalhada a seguir das modalidades preferidas, são mais bem entendidos, quando lidos em conjunto com os desenhos apensos. A fim de ilustrar a invenção, ela é mostrada nas construções exem-plificantes dos desenhos; porém, a invenção não é limitada aos processos e instrumentalidades específicas divulgadas. Nos desenhos: a Fig. 1 é um diagrama de blocos de um ambiente computacional exemplificante, onde aspectos da invenção podem ser implementados; a Fig. 2 é um diagrama de blocos de um sistema que emprega um processo, cuja operação correta é dependente de uma chave do sistema; a Fig. 3 é um diagrama de blocos de um sistema se arquivos criptografados que protege dados criptografados contra descriptografia desautorizada, por tornar a descrip-tografia dependente de uma chave do sistema; a Fig. 4 e um fluxograma de um processo de inicialização exemplificante com validação, de acordo com aspectos da invenção; a Fig. 5 é um diagrama de blocos de um validador exemplificante, de acordo com aspectos da invenção; e a Fig. 6 é um fluxograma de um processo exemplifi-cante para proteger uma chave do sistema, de acordo com aspectos da invenção. DESCRIÇÃO DETALHADA DE MODALIDADES ILUSTRATIVAS Panorama Geral Diversos processos, que podem ocorrer sob um sistema operacional, são dependentes de uma ou mais chaves para sua correta operação. 0 acesso às chaves pode ser controlado por um programa de autenticação, tal como um programa de lo-gon, que se recusa a habilitar o uso da(s) chave(s) , a não ser que o usuário forneça credenciais corretas, tais como uma combinação de nome de usuário/ senha. Assim, pela recusa do programa de logon em habilitar o uso de chaves na ausência de credenciais corretas, diversos processos (p. ex.,descriptografia de arquivos criptografados) podem ser disparados {ou inteiramente impedidos) para usuários que não conheçam a senha. Embora o programa de logon possa ser eficaz era permitir acesso às chaves, um carregador de sistema operacional pode ser enganado ao carregar um componente diferente, que irá distribuir as chaves fora das regras de autenticação impostas pelo programa de logon. Assim, quando chaves forem distribuídas desta maneira, a proteção das chaves requer a proteção do processo de carregamento do sistema operacional. A presente invenção fornece mecanismos, que podem ser usados para proteger o processo de carregamento. Arranjo Computacional Exemplificante A Fig. 1 mostra um ambiente computacional exempli-ficante, onde aspectos da invenção podem ser implementados. 0 ambiente do sistema computacional 100 é somente um exemplo de um ambiente computacional adequado, e não tem a intenção de sugerir qualquer limitação quanto ao escopo de uso ou funcionalidade da invenção. 0 ambiente computacional 100 também não deve ser interpretado, como tendo qualquer dependência ou exigência relativa a qualquer componente ou uma combinação de componentes ilustrados no ambiente operacional exemplificante 100. A invenção é operacional com uma pluralidade de ambientes ou configurações de sistema computacional para uso geral ou específico. Exemplos de sistemas, ambientes, e/ou configurações computacionais bastante conhecidos, que podem ser apropriados para uso com a invenção, incluem, mas não são limitados a, computadores pessoais, computadores de servidor, dispositivos portáteis ou laptop, sistemas multipro-cessadores, sistemas baseados em microprocessadores, receptores de TV digital universal, eletrônicos programãveis por consumidor, PCs de rede, minicomputadores, computadores de grande porte, sistemas embutidos, ambientes computacionais distribuídos que incluem qualquer um dos sistemas ou dispositivos acima, e semelhantes. A invenção pode ser descrita no contexto geral de instruções executáveis por computador, tais como módulos de programa sendo executados por um computador. De maneira geral, módulos de programa incluem rotinas, programas, objetos, componentes, estruturas de dados etc., que realizam tarefas específicas ou implementam tipos de dados abstratos específicos. A invenção pode ser também praticada em ambientes computacionais distribuídos, onde tarefas são realizadas por dispositivos de processamento remotos que são ligados através de uma rede de comunicação ou outra mídia para transmissão de dados. Em um ambiente computacional distribuído, módulos de programa e outros dados podem ser localizados em mídias de armazenamento em computador local e remoto, incluindo dispositivos armazenadores de memória.

Com referência à fig. 1, um sistema exemplificante para implementação da invenção inclui um dispositivo computacional para uso geral na forma de um computador 110. Componentes do computador 110 podem incluir, mas não são limitados a, uma unidade de processamento 120, uma memória de sistema 130, e um barramento de sistema 121 que interliga vários componentes de sistema, incluindo a memória de sistema, à unidade de processamento 120. A unidade de processamento 120 pode representar uma pluralidade de unidades lógicas de processamento, tais como aquelas suportadas em um processador de execução múltipla. O barramento de sistema 121 pode ser qualquer um de diversos tipos de estruturas de barramento, incluindo um barramento de memória ou controlador de memória, um barramento periférico, e um barramento local usando qualquer uma de uma variedade de arquiteturas de barramento. Para fins de exemplo, e não de limitação, essas arquiteturas incluem barramento de Industry Standard Ar-chítecture (ISA), barramento de Micro Channel Architecture (MCA), barramento de Enhanced ISA (EISA), barramento local da Electronics Standards Association (VESA), e barramento de Peripheral Component Interconnect (PCI) (também conhecido como barramento de Mezzanine). O barramento de sistema 121 pode ser também implementado como uma conexão ponto a ponto, "switching fabric", ou semelhantes, dentre os dispositivos de comunicação. 0 computador 110 inclui tipicamente uma variedade de mídias legíveis por computador. Mídias legíveis por computador podem ser quaisquer mídias disponíveis que possam ser acessadas por computador 110 e incluem mídias voláteis e não-volãteis, mídias removíveis e não-removíveis. Para fins de exemplo, e não de limitação, mídias legíveis por computador podem compreender mídias de armazenamento em computador e mídias de comunicação. Mídias de armazenamento em computador incluem mídias voláteis e não-voláteís, removíveis e não-removíveis, implementadas em qualquer processo ou tecnologia para armazenamento de informações, tais como instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados. Mídias de armazenamento em computador incluem, mas não são limitadas a, RAM, ROM, EEPROM, memória flash ou outra tecnologia de memória, CDROM, discos versáteis digitais (DVD) ou outro armazenamento em disco õ-tico, cassetes magnéticos, fita magnética, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outra mídia que possa ser usada para armazenar as informações desejadas e que possa ser acessada pelo computador 110. Mídias de comunicação incorporam tipicamente instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados em um sinal modulado de dados, tal como uma onda portadora ou outro dispositivo de transporte, e incluem quaisquer mídias para fornecimento de informações. A expressão "sinal modulado de dados" significa um sinal que possui uma ou mais de suas caracte- rísticas definidas ou alteradas, de forma a codificar informações no sinal. Para fins de exemplo, e não de limitação, mídias de comunicação incluem mídias com fio, tais como conexão direta com fio ou de rede com fio, e mídias sem fio, tais como acústicas, RF, infravermelhas, ou outras mídias sem fio. Combinações de qualquer um dos acima devem ser também incluídas no escopo das mídias legíveis por computador. A memória de sistema 130 inclui mídias de armazenamento em computador na forma de memória volátil e/ou não-volátil, tal como memória somente de leitura (ROM) 131 e memória de acesso aleatório (RAM) 132. Um sistema básico de entrada/ saída 133 (BIOS), contendo as rotinas básicas que ajudam a transferir informações entre elementos dentro do computador 110, tal como durante a partida, é tipicamente armazenado na ROM 131. A RAM 132 contém tipicamente dados e/ou módulos de programa que são imediatamente acessíveis e/ou sendo atualmente operados pela unidade de processamento 120. Para fins de exemplo, e não de limitação, a fig. 1 ilustra o sistema operacional 134, programas de aplicativo 135, outros módulos de programa 136, e dados de programa 137, 0 computador 110 pode ainda incluir outras mídias de armazenamento em computador removíveis/ não-removíveis, voláteis/ não-volateis. Somente para fins de exemplo, a fig. 1 ilustra uma unidade de disco rígido 141 que lê ou grava em mídias magnéticas não-removíveis, não-voláteis, uma unidade de disco magnético 151 que lê ou grava em um disco magnético removível, não-volãtil 152, e uma unidade de disco ótico 155 que lê ou grava em um disco ótico removível, não-volãtil 156, tal como um CDROM ou outras mídias óticas. Outras mídias de armazenamento em computador removíveis/ não-removíveis, voláteis/ não-volãteis, que podem ser usadas no ambiente operacional exemplificante, incluem, mas não são limitadas a, cassetes de fita magnética, cartões de memória flash, discos versáteis digitais, fita de vídeo digital, RAM em estado sólido, ROM em estado sólido, e semelhantes. A unidade de disco rígido 141 é tipicamente conectada ao barra-mento de sistema 121 através de uma interface de memória não-removível, tal como interface 140, e a unidade de disco magnético 151 e a unidade de disco ótico 155 são tipicamente conectadas ao barramento de sistema 121 por uma interface de memória removível, tal como a interface 150.

As unidades e suas mídias de armazenamento em computador associadas, acima discutidas e ilustradas na fig. 1, fornecem armazenamento de instruções legíveis por computador, estruturas de dados, módulos de programa e outros dados para o computador 110. Na fig. 1, por exemplo, a unidade de disco rígido 141 é ilustrada como armazenando o sistema operacional 144, programas de aplicativo 145, outros módulos de programa 146, e dados de programa 147. Observe que estes componentes podem ser iguais ou diferentes do sistema operacional 134, programas de aplicativo 135, outros módulos de programa 136, e dados de programa 137. O sistema operacional 144, programas de aplicativo 145, outros módulos de programa 146, e dados de programa 147 são indicados aqui por números diferentes para ilustrar que, no mínimo, eles são cópias distintas. Um usuário pode inserir comandos e informações no computador 20 através de dispositivos de entrada, tais como um teclado 162 e dispositivo apontador 161, normalmente chamado de mouse, trackball ou almofada de toque. Outros dispositivos de entrada (não mostrados) podem incluir um microfone, joystick, game pad, antena parabólica, scanner, ou semelhantes. Esses e outros dispositivos de entrada são muitas vezes conectados na unidade de processamento 120 através de uma interface para entrada de usuário 160 que é acoplada ao barramento de sistema, mas podem ser conectados através de outras estruturas de barramento e interface, tais como uma porta paralela, porta de jogos ou um barramento serial universal (USB) . Um monitor 191 ou outro tipo de dispositivo mostrador é também conectado ao barramento de sistema 121 através de uma interface, tal como uma interface de vídeo 190. Além do monitor, os computadores podem ainda incluir outros dispositivos de saída periférica, tais como alto-falantes 197 e impressora 196, que podem ser conectados através de uma interface periférica de saída 195. O computador 110 pode operar em um ambiente de rede usando conexões lógicas para um ou mais computadores remotos, tal como computador remoto 180. O computador remoto 180 pode ser um computador pessoal, um servidor, um roteador, um PC de rede, um dispositivo de mesmo nível ou outro nó de rede comum, e tipicamente inclui muitos ou todos os elementos acima descritos com relação ao computador 110, embora somente um dispositivo de armazenamento em memória 181 tenha sido ilustrado na fig. 1. As conexões lógicas ilustradas na fig. 1 incluem uma rede local (LAN) 171 e uma rede de área ampla (WAN) 173, mas podem também incluir outras redes. Esses ambientes de rede são normalmente encontrados em escritórios, redes de computador dentro de empresas, intranet e na Internet.

Quando usado em um ambiente de rede LAN, o computador 110 é conectado na LAN 171 através de uma interface ou adaptador de rede 170. Quando usado em um ambiente de rede WAN, o computador 110 inclui tipicamente um modem 172 ou outros meios para estabelecer comunicações através da WAN 173, tal como a Internet. 0 modem 172, que pode ser interno ou externo, pode ser conectado ao barramento de sistema 121 através da interface de entrada de usuário 160, ou outro mecanismo apropriado. Em um ambiente de rede, módulos de programa ilustrados com relação ao computador 110, ou partes deste, podem ser armazenados no dispositivo armazenador de memória remota. Para fins de exemplo, e não de limitação, a fig. 1 ilustra programas de aplicativo remotos 185, como residentes no dispositivo de memória 181. Deverá ser apreciado que as conexões de rede mostradas são exemplifícantes e outros meios para estabelecimento de um laço de comunicações entre os computadores podem ser usados. Açao Protegida por Chaves Um ambiente computacional pode empregar uma chave, da qual certos processos, que ocorram dentro do ambiente, dependam para sua operação correta. A chave do sistema, ou "SYSKEY" usada pelos sistemas operacionais WINDOWS da MICROSOFT é um exemplo de uma chave destas, mas não é um exemplo limitador. Em uma modalidade preferida, uma chave, da qual um processo dependa, é uma chave única, criptografica-mente aleatória por plataforma, isto é, existindo duas máquinas, é provável que as duas máquinas tenham chaves distintas. Assim, um processo, que dependa dessas chaves, é improvável de ser portãvel de uma plataforma para outra, pelo menos na medida em que mecanismos eficazes sejam empregados para garantir que uma chave de plataforma não esteja disponível fora daquela plataforma. A Fig. 2 mostra um sistema exemplificante, no qual um processo roda em função de uma chave. O processo 202 é dependente da chave 204, a fim de operar corretamente. Deve ser observado que o processo 202 não é limitado à noção tradicional de um processo, isto é, uma unidade de execução que pode ser controlada por um sistema operacional e atribuída a um espaço de endereço, mas ao invés disto se refere, de maneira mais genérica, a qualquer operação ou série de operações que podem ser realizadas em um computador. Deve ser ainda observado que, embora esse exemplo mostre o processo que é dependente de uma chave criptográfica, o termo "processo", conforme aqui usado, não é limitado a processos que realizam operações criptográficas.

Como mostrado na fig. 2, se a chave 204 for disponibilizada como uma entrada ao processo 202, então o processo 202 opera corretamente. Por outro lado, se a chave 204 não estiver disponível como uma entrada ao processo 202, então o processo 202 não opera corretamente. Um mecanismo de proteção por chave 106 controla o acesso à chave 204, isto é, o mecanismo 206 alimenta, ou não alimenta, o processo 202 com a chave 204, dependendo de se condições de segurança relevantes tenham sido atingidas. Por exemplo, um usuário pode precisar se conectar e fornecer uma senha correta, antes que o mecanismo 206 habilite o uso da chave 204.

Deve ser observado, que a negação da chave 204 para impedir o processo 202 de operar corretamente, é algumas vezes o resultado desejado. Por exemplo, a criptografia/ descriptografia de arquivos é um exemplo de um processo 202 que é protegido pela chave 204. A correta descriptografia de um arquivo pode ser dependente do acesso à chave 2 04 . Se o usuário não puder obter acesso e se autenticar corretamente, então pode ser desejável que a descriptografia de um arquivo não seja processada, visto que a incapacidade de um usuário em obter acesso pode indicar que o computador está sendo operado por uma outra pessoa que não seu usuário pretendido (p. ex. , no caso de um laptop roubado) . Assim, o mecanismo de proteção por chave 206 pode estabelecer acesso à chave 204, em função das principais condições de segurança serem satisfeitas, e pode usar a negação da chave 204 em disparar processos que necessitem ser disparados, quando aquelas condições de segurança não forem satisfeitas. A capacidade de um mecanismo 206 em disparar processos desta maneira é dependente daqueles processos necessitando da chave 204 para sua correta operação, visto que esta dependência é que habilita o ato de negação da chave 204 em disparar o processo. A Fig. 3 mostra um exemplo específico {mas não limitador) de um processo, que é dependente da chave 204. No exemplo da Êig. 3, o processo exemplificante é um Sistema de Arquivos Criptografados {EFS} 3 02 que armazena arquivos no formato criptografado, e também descriptografa os arquivos criptografados. Deve ser observado que uma finalidade dessa criptografia de arquivos é proteger dados em um computador laptop para não serem recuperados por um ladrão, no caso do laptop ser roubado. Quando um arquivo 304 for gerado para armazenamento, o arquivo é alimentado ao EFS 302. O EFS 302 então criptografa o arquivo 304, e transforma o arquivo 304 em arquivo criptografado 306, que é armazenado no disco rígido 141. Quando uma requisição for feita para recuperar o arquivo criptografado 306, o EFS 302 recupera o arquivo criptografado 306 e o descriptografa para gerar o arquivo descriptografado 308. {Na prática, a substância do arquivo descriptografado 308 é igual àquela do arquivo original 304, embora, para fins de clareza, a fig. 3 mostre estas duas instâncias do arquivo em separado: o arquivo 304 é o arquivo original, e o arquivo descriptografado 308 é o mesmo arquivo, após ele ter sido criptografado, armazenado, recuperado, e descriptografado pelo EFS 302) .

Deverá ser observado que uma entrada para o EFS 302 é a chave de conteúdo 310. A chave de conteúdo 310 é, de preferência, uma chave simétrica que funciona como uma entrada para um processo criptográfico. A chave de conteúdo 310 é usada para criptografar o arquivo 304, a fim de criar o arquivo criptografado 306, sendo também usada para descriptograf ar o arquivo criptografado 306, a fim de criar o arquivo descriptografado 308. Pode ser apreciado que o armazenamento da chave 310 em algum local facilmente recuperável pode tornar rapidamente ineficaz a capacidade do EFS 302 para proteger os dados. Se a chave de conteúdo estiver facilmente disponível em um disco rígido, ou se ela for facilmente derivãvel de algum recurso conhecido do laptop (p. ex. , o número de série do processador), então não fará nenhuma diferença, se os arquivos estiverem armazenados no formato criptografado, visto que um ladrão pode encontrar facilmente a chave e descriptografã-los. Assim, é desejável proteger a chave, derivando-a de alguma maneira que somente possa ser feita com a cooperação do dono verdadeiro. Uma maneira de proteger a chave é usar um módulo gerador de chaves 312, que receba a chave 204 como entrada, e derive a chave de conteúdo 310 em função da chave 304. Assim, na medida em que a chave 2 04 seja apenas fornecida em circunstâncias adequada-mente seguras, é igualmente verdadeiro que a chave de conteúdo 310 será somente derivãvel em circunstâncias apropriadas. Em outras palavras, ao tornar a derivação da chave de conteúdo 310 dependente da disponibilidade da chave 204, qualquer proteção que for oferecida à chave 204 pode ser estendida à chave de conteúdo 310. Por exemplo, se o fornecimento da chave 204 exigir que o usuário obtenha acesso, através do fornecimento de uma senha correta, então pode ser assegurado que a chave de conteúdo 310 não será disponibilizada, a não ser que o usuário obtenha um acesso correto.

Assim, a proteção da chave 204 contra circunstâncias de ser fornecida de maneira incorreta é importante, visto que outros processos podem depender da chave 204 ser liberada, somente quando o correto contexto de segurança (p. ex. , um usuário legitimado, conectado, que oferece a senha correta) estiver presente. Conforme abaixo descrito, uma maneira para fazer com que uma máquina distribua a chave 204, de forma que possa resultar em mau uso, é inicializar a máquina em um ambiente inseguro, no qual componentes violadores do sistema operacional possam substituir os componentes corretos (onde se presume que os componentes corretos sejam capazes de proteger a chave 204) . Assim, mecanismos são abaixo descritos, os quais asseguram que uma máquina seja i-nicializada em um ambiente (seguro) conhecido, antes da chave 204 poder ser distribuída.

Processo de Inicialização com Validação de Estado A Fíg. 4 apresenta uma sequência típica de eventos que são usados em um procedimento de inicialização.

Inicialmente, a máquina é ligada. Uma máquina típica é configurada para iniciar a execução de instruções em um determinado endereço fixo, no momento em que ela é ligada. As instruções tipicamente contidas nesse endereço são conhecidas como uma "BIOS" 402, ou "Sistema Básico de Entrada/ Saída". Ao término da execução da BIOS 402, a BIOS 402 inicia a execução de pequenos programas denominados "ROMs opcionais" 404. ROMs opcionais são programas que realizam funções prematuras muito básicas de inicialização, tal como a definição da senha de hardware para a máquina, ou seleção de qual dos diversos sistemas operacionais deve ser inicía-lizado. Após as ROMs opcionais 404 rodarem, a máquina é instruída a carregar o Registro de Inicialização Principal (MBR) 406. O MBR 406 ê um programa executável. De modo característico, o MBR 406 reside no primeiro setor do disco rígido de um computador, e começa pesquisando qual partição usar para posterior inicialização na tabela de partição. {Por exemplo, um disco pode ser particionado para uso com diferentes sistemas operacionais, e cada sistema operacional pode requerer um procedimento de inicialização distinto). Após a partição correta ter sido pesquisada, o MBR 406 transfere o controle ao setor de inicialização 408 associado àquela partição. Então, o setor de inicialização inicia o processo de carregamento do carregador do sistema operacional 410, que irá finalmente carregar o sistema operacional. Deve ser observado que o MBR 4 06 é mostrado na fig. 4 meramente para indicar como um componente destes irá se adequar a um processo de inicialização exemplificante, e a invenção não é limitada a procedimentos de inicialização, que usam o MBR 406.

Durante o momento em que o carregador 410 do sistema operacional estiver rodando, o carregador e estado da máquina são validados (450). ("Máquina", neste contexto, pode se referir a uma máquina física, ou a uma máquina virtual) . A validação e realizada por um componente de software confiável que opera em um ambiente de alta garantia (uma modalidade que é melhor descrita abaixo) e, assim, existe um certo grau de garantia/ confiança de que a validação do carregador 410 está sendo feita corretamente. Em essência, através da validação dos aspectos relevantes do estado da maquina, enquanto o carregador 410 do sistema operacional pos- suir controle sobre a máquina, e através da validação do carregador 410, é possível proporcionar um certo grau de garantia, de que versões ilegítimas ou violadoras de componentes do sistema operacional (p. ex., a camada de abstração de hardware, o núcleo, acionadores etc, (416)) não sejam mais tarde carregadas, até o momento em que o programa de logon 418 esteja rodando. A prevenção, de que componentes violadores sejam carregados até o momento em que o programa de logon 418 esteja rodando, é importante, porque uma das primeiras coisas que o sistema operacional irá fazer, após ele ser carregado, é rodar um programa de logon 418 que permita o acesso à chave 204, e se componentes violadores puderem ser carregados, então esses componentes podem fazer com que o programa de logon 418 se comporte de uma maneira errada, podendo resultar na distribuição da chave 204 sob circunstâncias inadequadas, comprometendo assim a segurança de todos os componentes que dependem da proteção da chave 204, conforme acima descrito. Assim, a proteção da chave 204 pode ser alcançada, exercendo-se um controle rígido sobre o estado da máquina, desde o momento em que o carregador 410 do sistema operacional estiver rodando, até o programa de logon ter sido concluído. A validação 450 ocorre durante o momento, em que o carregador 410 do sistema operacional está rodando. A validação inclui validação do carregador e do estado da máquina, e pode ainda incluir a configuração do estado da máquina em um bom estado conhecido. A idéia básica por detrás da validação e configuração do estado da máquina é colocar a mãquí- na em um estado, onde, se o carregador rodar enquanto a máquina estiver naquele estado, o carregador não carregue quaisquer componentes violadores ou se comporte, de outra forma, de maneira que resulte em violações de segurança. A validação 450 assegura que o código do carregador seja, na realidade, o código que foi previamente verificado como tendo um comportamento correto, e também assegura que a máquina esteja em um estado, no qual esse código conhecido irá se comportar de maneira correta (quer por verificação de que a máquina jã se encontra naquele estado, ou por colocação da máquina naquele estado) . Deverá ser apreciado que esta técnica é capaz de alavancar o estado (seguro) existente da máquina, para garantir que estados futuros da máquina sejam também seguros, e esta alavancagem é disponibilizada pelo fato de que o comportamento do carregador 410 do sistema operacional não é apenas conhecido e entendido, mas também rigidamente delimitado. Com base nesta observação, deverá ser apreciado que a validação 450 não deve ocorrer de forma muito antecipada (p. ex. , no momento em que as ROMs opcionais 404, ou MBR 4 06, forem executadas) , visto que a ampla variedade de códigos provenientes de numerosas fontes distintas, e a vasta amplitude de estados em que a máquina pode ser colocada em decorrência da execução desse código, torna difícil, se não impossível, determinar o comportamento da máquina durante a execução de todos estes módulos de código distintos. Assim, é preferível a não preocupação com quais estados a máquina se encontra antes da execução do carregador 410, desde que a máquina possa ser colocada em um estado legítimo, no momento em que o carregador 410 estiver rodando.

Em uma modalidade preferida, a execução do carregador 410 é dividida em dois estágios: estágio 1 (412) e es- tágio 2 (414). De preferência, antes do estágio 2 ser iniciado, o código que implementa o estágio 2 é validado (450), e o código confiável que realiza a validação 450, salta então para o estágio 2 em um ponto de entrada bem definido. (0 "código confiável", que realiza a validação, é o programa acima mencionado que roda em um ambiente de alta garantia. Deverá ser entendido pelas pessoas versadas na técnica que o termo "confiável" não implica em uma condição infalível absoluta, mas significa simplesmente que existe uma certa base para supor que o código irá realizar sua tarefa corretamente. Visto que o comportamento de um programa pode ser afetado pelo ambiente, no qual ele roda, a execução do código confiável em um ambiente de alta garantia significa que o código confiável irá operar corretamente: (1) o código confiável pode ser confiável, para realizar corretamente sua função em um ambiente que esteja de acordo com certas expectativas, e (2) o ambiente de alta garantia pode ser confiável, para fornecer corretamente um ambiente que esteja de acordo com essas expectativas). 0 estágio 2 pode então validar (de acordo com um certo padrão preferido) quaisquer informações que ele tenha recebido do estágio 1. A linha divisória entre o estágio 1 e o estágio 2 reflete o fato de que podem existir alguns aspectos de um procedimento de inicialização, que podem ser realizados sem qualquer verificação de segurança, e sem ter quaisquer consequências para uma de- terminada tarefa relativa ã segurança (tal como a distribuição da chave 204), desde que o estado e programas relevantes possam ser validados em algum instante de tempo, antes dos eventos poderem ser colocados em movimento, o que pode fazer com que tal tarefa relativa à segurança não seja realizada corretamente. Além disto, pode haver problemas com a tentativa de validar o estado em um momento muito prematuro no processo de inicialização: o caminho de execução atual, que um procedimento legítimo de inicialização pode assumir, é bastante variável, assim que se torna difícil definir a diferença entre estados válidos ou inválidos de máquina sob tais circunstâncias variáveis. Pode fazer sentido permitir simplesmente que o carregamento avance por qualquer um desses estados variáveis, sem tentar determinar, se qualquer estado que a máquina assuma, é válido. Assim, o estágio 1 representa a parte do carregamento que avança sem qualquer validação. Ao final do estágio 1, o carregador e o estado da máquina são validados, e o estágio 2 é iniciado. A presunção de uma linha divisória destas é que processos podem rodar sem quaisquer restrições de segurança, até um determinado ponto, em cujo ponto todos os fatores relevantes sobre a máquina são validados e a máquina é colocada em um bom estado conhecido, o qual anula essencialmente o efeito de quaisquer ações anteriores, que possam ter colocado a máquina em um estado que seja inaceitável de um ponto de vista da segurança. 0 ponto exato no processo de carregamento, onde a linha divisória entre o estágio 1 e o estágio 2 é traçada, é altamente específico às circunstâncias (p. ex., Como se parece o código do carregador? Que tarefas precisam ser feitas, como parte integrante do carregamento?) , e representa uma espécie de negociação: Por um lado, a linha divisória deve ser tarde o suficiente para que, para ações futuras, a quantidade de variação no comportamento legítimo do carregamento seja pequena o suficiente, para que o comportamento legítimo possa ser distinguido de forma viável do comportamento ilegítimo. (Como acima observado, no procedimento de carregamento prematuro, o grande número de ROMs opcionais e outras variáveis tornam o número de possíveis caminhos de execução tão grande que é difícil distinguir comportamentos legítimos de comportamentos ilegítimos). Por outro lado, a linha divisória deve ser antecipada o suficiente, para que ela preceda quaisquer eventos (p. ex. , o carregamento do programa de logon) que possam ter efeito sobre a segurança, tal como fazer com que chaves sejam distribuídas de forma inadequada. Em geral, a linha divisória entre o estágio 1 e o estágio 2 permite a execução de um sistema arbitrário em um estado "bruto" (ou "aberto", ou "inválido") por um determinado tempo, e a seguir inicia todos os componentes que sejam necessários para verificar o comportamento (p. ex. , um ambiente de alta garantia) , e a seguir usa tais componentes para validar o estado atual da máquina (ou forçar a máquina para um bom estado conhecido), em cujo instante o processo de realizar algo que pode mais tarde afetar a segurança (p. ex., a distribuição de chaves) pode ser permitido prosseguir.

Validação 450 A validação 450 é, na essência, o ato de verificar se o carregador 410 do sistema operacional (ou, de modo especial, em uma modalidade preferida, a verificação de se o estágio 2 do carregador) é um programa confiável conhecido, e de garantir de que a máquina, na qual ele está rodando, está em um bom estado conhecido. Assim, a validação possui duas partes: (1) exame do programa carregador (ou estagio 2 do programa carregador) para garantir que ele seja o programa confiável conhecido que ele parece ser, e (2) troca do estado da máquina relevante para um bom estado conhecido, no qual o carregador é conhecido por se comportar corretamente. A premissa da realização de (1) e (2) é que um programa conhecido, operando em estado da máquina conhecido, se comporte de uma maneira conhecida. A primeira parte da validação, a saber, exame do carregador, pode ser realizada de uma variedade de maneiras. No exemplo mais simples, pode haver uma comprovação ("hash"} do programa conhecido (que pode ser criptografícamente assinado para criar uma assinatura digital, ou armazenado de uma maneira não não-falsificãvel), com o qual o programa atual que está rodando pode ser comparado. O problema com a comprovação ao longo de todo o programa é que diferentes instâncias de um programa legítimo podem ter imagens ligeiramente diferentes, assim que uma comprovação que seja computada de uma maneira que requeira identidade completa entre o programa conhecido e a instância sendo rodada do programa, pode ser muito restritiva. De preferência, a validação é realizada de uma maneira que assegure que o programa se] a aquele suposto ser, mas que não seja muito restritivo, p. ex., o processo de validação pode comparar comprovações de componentes de programa que sejam conhecidas como fixas, e pode realizar outros testes em componentes de programa que possam se alterar ao longo do tempo. 0 componente que realiza a validação deve ser adequado aos detalhes do programa que está sendo validado; a invenção não é limitada a qualquer técnica específica para validação de um programa. A segunda parte da validação, a saber, verificação/ definição do estado da máquina, é de preferência realizada, através da definição de todas as "fontes" relevantes de estado para valores conhecidos. De modo característico, o estado relevante, que pode afetar um sistema operacional, é proveniente de três fontes: a CPU, o "chípset", e a memória. Assim, estes itens podem ser colocados em um bom estado conhecido no momento da validação, p. ex., a CPU pode ser colocada em um estado conhecido, p. ex. , anel 0, com o contador de programa apontado para um local conhecido, todos os registros de dados posicionados em zero, e toda a memória, diferente da memória, na qual o programa de carregador está armazenado, sendo posicionada em zero. Se o carregador tiver sido verificado, como se comportando de maneira correta, quando ele rodar com a máquina neste estado, então a combinação de exame do carregador e colocação da máquina no bom estado conhecido deve assegurar um correto comportamento, até o momento em que o programa de logon 418 estiver rodando. Conforme acima discutido, um dos benefícios (embora não o único benefício) do correto comportamento até a execução do programa de logon 418 é que componentes invasores não se- jam carregados, o que iria fazer com que a chave 204 fosse distribuída sob circunstâncias inadequadas.

Deve ser observado que, a fim de que o processo de validação proteja o carregamento do sistema operacional contra componentes invasores, deve haver garantia suficiente de que o processo de validação em si esteja sendo corretamente realizado. A exatidão do processo de validação pode ser assegurada pela incorporação do validador como um agente confiável que roda em um ambiente computacional de alta garantia. Por exemplo, pode haver um pequeno sistema operacional que realize um número limitado de funções, mas que forneça um alto grau de garantia, de que tal sistema operacional se comporte de acordo com suas especificações. Esse sistema operacional pode ser executado em conjunto com outros sistemas operacionais em uma máquina exclusiva, e o isolamento de um sistema operacional de alta garantia desses, de outros ambientes (menos seguros) no sistema, pode ser aplicado por um componente supervisor, tal como um hipervisor ou monitor de máquina virtual. {Em uma modalidade, um hipervisor aplica partições, que são ambientes que o hipervisor mantém em um certo estado de isolamento mútuo entre si, e onde um sistema operacional pode rodar) . Além disto, o componente de alta garantia pode ter acesso exclusivo a uma raiz de confiança, tal como um módulo de hardware, que aplica, e protege fortemente, chaves criptográficas por plataforma. O validador pode ser um programa (ou "agente")/ que rode em um ambiente de alta garantia destes, o qual forneça garantia de que, na medida em que o ambiente de alta garantia em si possa ser con- fiável com resistente a ataques, o validador não estará sujeito a ataques externos do ambiente de alta garantia, que fará com que ele se comporte de forma incorreta. Além disto, conforme acima observado, o ambiente de alta garantia pode fornecer armazenamento lacrado (isto é, a capacidade para armazenar um certo dado e para liberar esse dado somente ao objeto específico, ao qual o dado tenha sido lacrado), e o validador pode usar esse armazenamento lacrado para armazenar quaisquer chaves que devam ser distribuídas. Deve ser observado que o validador pode ser parte integrante do ambiente de alta garantia, mas pode ser também um componente distinto que rode no ambiente de alta garantia. A Fig. 5 apresenta um exemplo de um validador 550, que realiza a validação de acordo com o procedimento acima descrito. O validador 550 possui a capacidade de avaliar o carregador 410 quanto à exatidão e/ou conformidade com um determinado grupo de padrões conhecidos. Além disto, o validador 550 possui a capacidade para avaliar e/ou afetar o estado da máquina 502. Usando a combinação dessas capacidades, o validador 550 pode assegurar que o carregador 410 irã se comportar corretamente, ao assegurar que o carregador 410 seja o carregador, que é suposto estar rodando, e ao assegurar que a máquina, na qual ele está rodando, se encontre em um estado, no qual o carregador 410 é conhecido por se comportar corretamente.

De modo estrutural, o validador 550 pode compreender dois componentes: uma parte geral 504 e uma parte de carregador específico 506. A "parte geral" 504 compreende um código que é comum a uma ampla variedade de validadores (ou a todos os validadores) . A parte de carregador específico 506 é um código que se refere especificamente a validação de um carregador específico 410, isto é, o código que compreende como uma instância correta de carregador 410 (ou estágio 2 do carregador 410) se parecería, e que realiza testes para assegurar que o carregador 410 está de acordo com esta compreensão. Assim, a parte de carregador específico 506 pode ser combinada com a parte geral 504 para formar um validador completo. O validador 550 ê o componente que decide final -mente, se a chave 204 deverá ser fornecida ao carregador (o qual irá então, mais tarde, fornecê-la ao sistema operacional, para uso por parte do sistema operacional, de acordo com a maneira permitida por um programa de logon, conforme acima descrito) . O validador 550 pode proteger a chave 204, lacrando a chave 204 para o validador 550 em uma unidade de armazenamento lacrada 508. A unidade de armazenamento lacrada 508 pode ser um recurso de um ambiente computacional de alta garantia. A unidade de armazenamento lacrada 508 pode permitir que componentes rodando em um ambiente de alta garantia lacrem dados arbitrários para si próprios, de forma que nenhum outro componente possa recuperar os dados. Por exemplo, a parte de carregador específico 506 do validador 550 pode lacrar a chave 2 04 para si própria. A unidade de armazenamento lacrada 508 irá impedir que todo elemento diferente da parte de carregador especifico 506 deslacre a chave 204. Assim, a chave 204 é protegida, porque ela somen- te pode ser obtida a partir da parte de carregador específico 506, e a parte de carregador específico 506 irã apenas distribuir a chave 204 a um carregador que a parte de carregador específico 506 acredite que não irá fazer com que a chave 204 seja distribuída de modo inadequado. Em outra modalidade, a chave é lacrada com base em uma combinação de componentes que inclui o validador e o estágio 2 do carregador 410. Nessa modalidade, a parte de carregador específico do validador 506 pode ser eliminada, porque o mecanismo de armazenamento lacrado em si assegura essencialmente a presença de um carregador do estágio 2 correto, antes da chave poder ser deslacrada, visto que o binário para um carregador de estágio 2 correto conhecido faz parte da métrica pertencente ao lacre.

Processo Exemplificante de Proteção da SY5KEY A Fig. 6 apresenta um processo exemplificante de proteção de uma chave, de acordo com os aspectos acima descritos da invenção. Em algum ponto após a máquina ser iniciada, um carregador de sistema operacional é executado (602). Durante a execução do carregador de sistema operacional, o carregador e o estado da máquina são validados (604), assegurando assim que o carregador irã se comportar de uma maneira previsível, pelos motivos acima descritos. Após o carregador e o estado da máquina terem sido validados, o carregador é usado para carregar o sistema operacional, enquanto que impedindo que componentes violadores sejam carregados (606). (Conforme acima discutido, a validação do carregador e do estado da máquina significa que o comportamento futuro do carregador é conhecido por não resultar no carregamento de componentes violadores). Após o sistema operacional ser carregado, o programa de logon é executado, o que permite acesso à chave.

Outras Modalidades Exemplificantes Deve ser observado que os mecanismos da presente invenção podem ser usados, não apenas para realizar um carregamento de sistema operacional, mas geralmente para permitir que um sistema realize uma determinada função em um estado bruto (não validado) , enquanto que necessitando de validação para prosseguir com certas funções. Por exemplo, um computador pode realizar algumas funções, que podem ser realizadas sem qualquer espécie de validação (p. ex. , o computador pode atuar como um rádio), mas a validação pode precisar ser realizada, antes do computador poder realizar funções mais sensíveis (p. ex., leitura de arquivos a partir do disco rígido) . Em geral, uma máquina pode ser considerada, como um aparelho e um PC genérico, e que a parte do aparelho não necessita de validação/ logon, mas a parte do PC genérico necessita de validação/ logon.

Além disto, o validador não é limitado à liberação/ não-liberação de um grupo específico de chaves ao programa de logon, mas pode ser configurado de modo mais genérico para liberar grupos específicos de chaves a pilhas específicas de software, p. ex., existe uma pilha de softwares que pode obter uma primeira chave, mas o validador pode liberar uma segunda chave somente a uma pilha de softwares "mais intensamente validada".

Além disto, as chaves não precisam ser necessariamente liberadas por um procedimento de logon, mas podem ser fornecidas através de procedimentos de validação arbitrários. Por exemplo, um binário de tocador de DVD pode obter, digamos, as chaves de função do DVD, após o validador ter determinado que o tocador é o binário correto, mas sem necessitar de um logon.

Além disto, alguns programas podem operar de alguma forma sem validação, mas, a seguir, necessitar de um tipo de validação, antes de obter a permissão para exposição à certa funcionalidade. Por exemplo, um aplicativo de telefonia pode iniciar sem a necessidade de logon, mas pode necessitar de logon, antes das chaves poderem ser distribuídas, o que irá permitir a operação das funções criptográficas do aplicativo.

Observa-se que os exemplos anteriores foram apresentados somente para fins de explicação e não devem ser, de forma alguma, considerados como limitadores da presente invenção. Embora a invenção tenha sido descrita com referência a várias modalidades, entende-se que as palavras, que tenham sido aqui usadas, são palavras de descrição e ilustração, ao invés de palavras limitadoras. Além disto, embora a invenção tenha sido aqui descrita com referência a meios, materiais e modalidades específicos, a invenção não pretende ser limitada aos detalhes aqui divulgados; ao invés disso, a invenção se estende a todas as estruturas, processos e usos funcionalmente equivalentes, que estejam dentro do escopo das reivindicações anexas. As pessoas versadas na técnica, tendo se beneficiado dos ensinamentos deste relatório descritivo, podem efetuar numerosas modificações com relação a este, e mudanças podem ser feitas sem se afastar do escopo e espírito da invenção em seus aspectos.

REIVINDICAÇÕES

Claims (30)

1. Mídia legível por computador, codificada com instruções executáveis por computador para realizar um processo, CARACTERIZADA pelo fato de compreender: partida de um carregador de sistema operacional; validação da identidade ou exatidão do dito carregador; garantia de que uma máquina, na qual o dito carregador do sistema operacional roda, se encontra em um estado conhecido; e se a identidade ou exatidão do dito carregador for validada, e se a dita máquina, na qual o dito sistema operacional roda, se encontra em um estado conhecido, então: provisão de uma chave ao dito carregador; e permissão para que o dito carregador carregue um sistema operacional.

2. Midia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA adicionalmente pelo fato do processo compreender: execução de um programa de logon (entrada em sessão) que controle o acesso para a dita chave.

3. Midia legível por computador, de acordo com a reivindicação 2, CARACTERIZADA pelo fato do dito programa de logon garantir que um usuário forneça credenciais, como uma condição para que o dito programa de logon conceda acesso à dita chave.

4. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato da dita chave ser usável para descriptografar uma partição criptografada do sistema operacional.

5. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato do dito ato de validar a identidade ou exatidão do dito carregador, e do dito ato de assegurar que uma máquina esteja em um estado conhecido, serem realizados após todos os seguintes itens terem executado: um sistema básico de entrada/ saída; uma ROM opcional; um registro de inicialização principal; e um setor de inicialização.

6. Mídia legível por computador, de acordo com a reivindicação 5, CARACTERIZADA pelo fato do dito ato de validar a identidade ou exatidão do dito carregador, e do dito ato de assegurar que uma máquina esteja em um estado conhecido, serem realizados após uma parte do dito carregador de sistema operacional ser executada.

7. Mídia legível por computador, de acordo com a reivindicação 6, CARACTERIZADA pelo fato do dito ato de validação ser realizado, após todo, ou substancialmente todo, o sistema operacional ser iniciado, ou após um certo número de partições ser iniciado, cada uma das ditas partições compreendendo um ambiente, em que um certo grau de isolamento de outras partições é mantido por um hipervisor.

8. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato da dita chave ser lacrada a um validador, que realiza o dito ato de validação e o dito ato de garantia, e em que o processo ainda compreende : deslacre da dita chave por parte do dito validador.

9. Mídia legível por computador, de acordo com a reivindicação 8, CARACTERIZADA pelo fato da dita chave ser lacrada pelo menos ao dito validador, e do dito validador validar pelo menos uma parte do dito carregador.

10. Mídia legível por computador, de acordo com a reivindicação 8, CARACTERIZADA pelo fato da dita chave ser lacrada ao dito validador, e a pelo menos uma parte do dito carregador.

11. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato da dita máquina compreender uma máquina física.

12. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato da dita máquina compreender uma máquina virtual.

13. Mídia legível por computador, de acordo com a reivindicação 12, CARACTERIZADA pelo fato da dita chave ser revelada somente, se uma arquitetura do dita máquina virtual não for alterada ou for validada.

14. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato do ato de assegurar que uma máquina se encontra em um estado conhecido compreende: avaliação de um estado atual da dita máquina e comparação do dito estado atual com o dito estado conhecido.

15. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato do ato de assegurar que uma máquina se encontra em um estado conhecido compreende: definição de um estado atual da dita máquina, como sendo compatível com o dito estado conhecido.

16. Mídia legível por computador, de acordo com a reivindicação 1, CARACTERIZADA pelo fato do dito carregador ser um sistema operacional completo, ou uma instância completa de um sistema operacional.

17. Sistema para execução de uma inicialização de um sistema operacional sob circunstâncias que fornecem garantias quanto à confiabilidade da inicialização, o sistema sendo CARACTERIZADO pelo fato de compreender: um validador que avalia a exatidão ou identidade de um carregador de sistema operacional que irá carregar o sistema operacional, e que ainda avalia um estado de uma máquina, na qual o dito carregador de sistema operacional irá operar, o qual permite ou impede o carregador de sistema operacional de prosseguir com o carregamento do sistema operacional, dependendo do fato da exatidão ou identidade do carregador de sistema operacional ser ou não verificada, e que coloca a dita máquina em um estado conhecido, antes de permitir o prosseguimento do dito carregador de sistema operacional .

18. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de uma chave ser lacrada ao dito validador, e em que o dito validador deslacra a dita chave e fornece a dita chave ao dito carregador de sistema operacio- nal, se o dito carregador de sistema operacional for permitido prosseguir.

19. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato do dito validador avaliar a exatidão ou identidade do carregador de sistema operacional, e avaliar o estado da máquina, após o carregador de sistema operacional ter iniciado a operação, mas antes do carregador de sistema operacional ter inicializado um núcleo ou um aciona-dor de dispositivo.

20. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato do dito validador compreender: uma parte geral que é comum a uma classe de vali- dadores; e uma parte específica que é específica ao dito carregador de sistema operacional, e que é substituível por uma parte distinta, no caso do dito validador estar sendo usado para validar um diferente carregador de sistema operacional.

21. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato da dita máquina compreender uma máquina física.

22. Sistema, de acordo com a reivindicação 17, CARACTERIZADO pelo fato da dita máquina compreender uma máquina virtual.

23. Processo de inicialização de um sistema operacional, CARACTERIZADO pelo fato de compreender: execução de um sistema básico de entrada/ saída, uma ROM opcional, um registro de inicialização principal, e um setor de inicialização; iniciação de um carregador de sistema operacional; validação do dito carregador de sistema operacional; validação de um estado de uma máquina, na qual o dito carregador de sistema operacional executa; se o dito carregador de sistema operacional e o dito estado da dita máquina forem determinados como sendo válidos, então permissão para que o dito carregador de sistema operacional carregue um sistema operacional.

24. Processo, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de uma chave, que é necessária para realizar corretamente pelo menos uma função subordinada ao dito sistema operacional, ser lacrada a um validador que realiza os ditos atos de validação de um carregador de sistema operacional e validação de um estado da máquina, e em que o processo ainda compreende: se o carregador de sistema operacional e o estado da máquina forem válidos, então deslacre da dita chave e fornecimento da dita chave ao dito carregador de sistema operacional.

25. Processo, de acordo com a reivindicação 23, CARACTERIZADO adicionalmente pelo fato de compreender: após o dito sistema operacional ter sido carregado, execução de um programa de logon que permite acesso à dita chave.

26. Processo, de acordo com a reivindicação 23, CARACTERIZADO pelo fato do dito programa de logon ainda permitir ou impedir que componentes do dito sistema operacional usem a dita chave, dependendo do fato de um usuário concluir com sucesso um procedimento de autenticação.

27. Processo, de acordo com a reivindicação 23, CARACTERIZADO pelo fato dos ditos atos de validação do dito carregador de sistema operacional e validação do dito estado da máquina serem realizados, após o dito carregador de sistema operacional ter realizado pelo menos uma ação.

28. Processo, de acordo com a reivindicação 27, CARACTERIZADO pelo fato dos ditos atos de validação do dito carregador de sistema operacional e de validação do dito estado da máquina serem realizados em um instante de tempo, antes da restauração do estado da máquina, irá impedir o carregador de funcionar corretamente para carregar o dito sistema operacional.

29. Processo, de acordo com a reivindicação 23, CARACTERIZADO pelo fato da dita máquina compreender uma máquina física.

30. Processo, de acordo com a reivindicação 23, CARACTERIZADO pelo fato da dita máquina compreender uma máquina virtual.