Virtualização de recursos

A principal função do TBS é compartilhar eficientemente certos recursos limitados do TPM: chaves, autorização e sessões de transporte.

Quando uma instância de um desses recursos é criada, o TBS cria uma instância virtual do recurso e retorna um identificador para essa instância virtual no fluxo de comando de resultado (em vez da instância de identificador real retornada pelo TPM). O TBS mantém um mapeamento entre o identificador virtual e o identificador real internamente. Se o TPM ficar sem espaço para armazenar mais recursos de um determinado tipo, as instâncias existentes do recurso serão salvas seletivamente e removidas até que o TPM possa armazenar o novo recurso. Quando os recursos antigos são necessários novamente, o TBS carrega os contextos salvos (salvando e removendo outros recursos, se necessário) antes de enviar o comando.

Toda a virtualização no TBS é realizada em nome de um contexto específico. Cada contexto só tem permissão para acessar recursos virtuais criados especificamente em seu nome, bem como os recursos físicos no TPM que correspondem a esses recursos virtuais. Por padrão, o número total de todos os recursos virtualizados é limitado a 500. Esse número pode ser alterado criando ou modificando um DWORD valor do Registro chamado MaxResources em HKEY_LOCAL_MACHINE\Software\Microsoft\Tpm. O uso de recursos TBS em tempo real pode ser observado usando a ferramenta Monitor de desempenho para controlar o número de recursos TBS. Esta restrição tornou-se obsoleta com o Windows 8 e o Windows Server 2012.

Recursos TPM limitados que não são virtualizados pelo TBS (como contadores e armazenamento NV) devem ser compartilhados cooperativamente entre pilhas de software.

Limites de recursos

O TPM permite que os chamadores consultem seus recursos para determinar quanto espaço está disponível para determinados tipos de recursos. Alguns desses limites de recursos, como a quantidade de espaço disponível para chaves, sessões de autorização e sessões de transporte, são efetivamente estendidos pelo TBS por meio da virtualização. As limitações de TBS, que são controladas pela configuração de registro MaxResources, geralmente são muito maiores do que as limitações reais do hardware TPM subjacente. Nenhum mecanismo é fornecido para consultar as limitações do TBS separadamente dos limites de hardware do TPM. Esta limitação TBS tornou-se obsoleta com o Windows 8 e Windows Server 2012.

Chaves

O TBS virtualiza identificadores de chave para que as chaves possam ser descarregadas de forma transparente do TPM quando não estiverem sendo usadas e carregadas de volta no TPM quando forem necessárias. Quando uma chave é criada, o TBS associa um identificador virtual à chave carregada. O mesmo identificador virtual é usado para o tempo de vida do recurso. Os identificadores de chave virtual só são válidos no contexto que os criou, e os recursos associados não são preservados além da vida do contexto.

• Criando chaves com TPM_LoadKey2

  Se uma chave for criada usando o comando TPM_LoadKey2, TPM2_CreatePrimary, TPM2_Load ou TPM2_LoadExternal, o TBS substituirá o identificador no fluxo de bytes de retorno por um identificador de chave virtual de sua escolha. Como resultado, o TBS garante que cada identificador virtual seja exclusivo. Se o TBS detetar uma colisão (um evento extremamente improvável), o TBS descarrega a chave do TPM e informa o software de chamada. O software pode então reenviar a operação. Esse processo pode ser repetido até que o TBS obtenha um identificador de chave exclusivo.

• Limpar chaves

  O TBS invalida o identificador de chave virtual quando recebe uma mensagem TPM_FlushSpecific ou TPM2_FlushContext para esse identificador virtual do contexto do cliente. Se a chave estiver fisicamente presente no TPM quando a mensagem de liberação for recebida, o TBS liberará a chave do TPM naquele momento.

• Remoção temporária de chaves

  Ao remover uma chave do TPM para abrir espaço para um novo item, o TBS executa um comando TPM_SaveContext ou TPM2_ContextSave na chave antes de eliminá-la.

• Restaurando chaves

  Quando um comando que faz referência a uma chave carregada é enviado ao TBS, ele garante que a chave esteja fisicamente presente no TPM. Se a chave não estiver presente, o TBS a restaurará com uma chamada para TPM_LoadContext ou TPM2_ContextLoad. Se uma chave não puder ser restaurada para o TPM, o TBS retornará TPM_E_INVALID_KEYHANDLE como o resultado do TPM.

O TBS substitui cada identificador virtual associado a uma chave em um fluxo de comando pelo identificador físico da chave carregada no TPM. Se um comando for enviado com um identificador virtual que não é reconhecido pelo TBS no contexto do chamador, o TBS formata um fluxo de erro para o chamador com TPM_E_INVALID_KEYHANDLE.

Sessões de Autorização

As sessões de autorização são criadas chamando TPM_OIAP, TPM_OSAP ou TPM_DSAP. Em cada caso, o fluxo de bytes de retorno contém o identificador TPM físico da sessão de autorização recém-criada. O TBS substitui isso por um identificador virtual. Quando a sessão de autorização é posteriormente referenciada, o TBS substitui o identificador virtual no fluxo de comandos pelo identificador físico da sessão de autorização. O TBS garante que o tempo de vida da sessão de autorização virtual corresponda ao da sessão de autorização física. Se um cliente tentar usar um identificador virtual expirado, o TBS formata um fluxo de erro com erro TPM_INVALIDAUTHHANDLE.

Os slots de sessão são limitados e o TBS pode ficar sem slots externos nos quais salvar contextos de sessão de autorização. Se isso acontecer, o TBS escolhe uma sessão de autorização para invalidar para que o novo contexto possa ser salvo com êxito. Um aplicativo que tenta usar o contexto antigo precisará recriar a sessão de autorização.

O TBS invalida a sessão de autorização virtual quando ocorre qualquer um dos seguintes casos:

• O sinalizador de uso contínuo associado à sessão de autorização no fluxo de comando retornado do TPM é FALSE.

• Um comando que usa uma sessão de autorização falha.

• É executado um comando que invalida a sessão de autorização associada ao comando (como TPM_CreateWrapKey).

• Uma chave associada a uma sessão OSAP ou DSAP é removida do TPM com uma chamada para TPM_FlushSpecific ou TPM2_FlushContext (sem considerar se esse comando se originou com o TBS ou com software de nível superior).

  O TBS ressincronizará automaticamente as sessões de autorização após a execução bem-sucedida de determinados comandos não determinísticos para garantir que o estado TBS permaneça consistente com o estado TPM. Os comandos afetados são:

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

Em cada um dos seguintes casos, a sessão de autorização no TPM é liberada automaticamente pelo TPM:

• Criando sessões de autorização

  Os identificadores de sessão de autorização virtual são válidos apenas no contexto que os criou, e os recursos associados não são preservados além da vida do contexto associado.

• Sessões de autorização de compensação

  O TBS invalida a sessão de autorização virtual se receber um comando TPM_FlushSpecific ou TPM2_FlushContext para o identificador virtual do contexto do cliente. Se a sessão de autorização estiver fisicamente presente no TPM quando o comando flush for recebido, o TBS liberará a sessão física do TPM imediatamente.

• Removendo temporariamente sessões de autorização

  Ao remover uma sessão de autorização do TPM para abrir espaço para uma nova entidade, o TBS executa TPM_SaveContext ou TPM2_ContextSave nessa sessão de autorização.

• Restaurando sessões de autorização

  Quando um comando TPM autorizado é enviado ao TBS, o TBS garante que todas as sessões de autorização virtual referidas no comando estejam fisicamente presentes no TPM. Se alguma das sessões de autorização não estiver presente, o TBS as restaurará com uma chamada para TPM_LoadContext ou TPM2_ContextLoad. Se uma sessão de autorização não puder ser restaurada no TPM, o TBS retornará TPM_E_INVALID_HANDLE como o resultado do TPM.

O TBS substitui cada identificador virtual associado a uma sessão de autorização em um fluxo de comando pelo identificador físico da sessão de autorização carregado no TPM.

Se um comando for enviado com um identificador virtual que não é reconhecido pelo TBS no contexto do chamador, o TBS formata um fluxo de erro para o chamador com o erro TPM_E_INVALID_HANDLE.

Sessões de Transporte

As sessões de transporte são um mecanismo fornecido pelo TPM que permite que uma pilha de software criptografe dados em um comando à medida que ele passa entre o software e o TPM. Isso impede que um adversário intercete os dados à medida que eles passam sobre o barramento de hardware.

Infelizmente, esse mecanismo também impede que o TBS examine os dados de carga útil. Na maioria dos casos, isso não é um problema porque o TBS apenas modifica identificadores, não dados de carga útil. No entanto, no caso de TPM_LoadContext por exemplo, o identificador de recurso retornado é coberto pela criptografia. Portanto, o TBS impede tentativas de executar uma operação de TPM_LoadContext coberta por uma sessão de transporte.

O TBS bloqueia os seguintes comandos na sessão de transporte:

• TPM_EstablishTransport
• TPM_ExecuteTransport
• TPM_Terminate_Handle
• TPM_LoadKey
• TPM_EvictKey
• TPM_SaveKeyContext
• TPM_LoadKeyContext
• TPM_SaveAuthContext
• TPM_LoadAuthContext
• TPM_SaveContext
• TPM_LoadContext
• TPM_FlushSpecific

Quando qualquer um desses comandos é coberto por uma sessão de transporte, o TBS retorna TPM_E_EMBEDDED_COMMAND_UNSUPPORTED como o resultado do TPM.

Os identificadores de sessão de transporte são virtualizados de maneira semelhante aos identificadores de chave e identificadores de autorização. Há um número limitado de slots de contexto de sessão de transporte salvos disponíveis no TPM.

O TBS invalida a sessão de transporte virtual se ocorrer qualquer um dos seguintes casos:

• O sinalizador de uso contínuo associado à sessão de transporte no fluxo de comando de retorno do TPM é FALSE.

  Como nas sessões de autorização acima, o TBS ressincronizará automaticamente as sessões de transporte após a execução bem-sucedida de certos comandos não determinísticos para garantir que o estado TBS permaneça consistente com o estado TPM. Os comandos afetados são:

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

Em cada um destes casos, a sessão de transporte no TPM será liberada automaticamente pelo TPM:

• Criando sessões de transporte

  O TBS cria um identificador virtual para cada sessão de transporte criada por um cliente. Os identificadores de transporte virtual só são válidos no contexto que os criou, e os recursos associados não são preservados além da vida do contexto associado.

• Compensação de sessões de transporte

  O TBS invalida a sessão de transporte virtual se receber um comando TPM_FlushSpecific para o identificador virtual do contexto do cliente. Se a sessão de transporte estiver fisicamente presente no TPM quando o comando flush for recebido, o TBS liberará a sessão física do TPM imediatamente.

• Remoção temporária de sessões de transporte

  Ao remover uma sessão de transporte do TPM para abrir espaço para uma nova entidade, o TBS executa TPM_SaveContext nessa sessão de transporte.

• Restaurando sessões de transporte

  Quando um comando TPM_ExecuteTransport é enviado ao TBS, o TBS garante que a sessão de transporte referida no comando esteja fisicamente presente no TPM. Se a sessão de transporte não estiver presente, o TBS a restaurará com uma chamada para TPM_LoadContext.

O TBS substitui o identificador virtual associado à sessão de transporte em um fluxo de comando pelo identificador físico da sessão de transporte carregado no TPM. Se um comando for enviado com um identificador virtual que não é reconhecido pelo TBS no contexto do chamador, o TBS formata um fluxo de erro para o chamador usando TPM_E_INVALID_HANDLE.

Sessões Exclusivas de Transporte

Sessões exclusivas de transporte encapsulado são uma maneira de o software de nível superior determinar se algum outro software acessou o TPM durante uma cadeia de comandos. Eles não impedem que outros softwares acessem o TPM, apenas dão ao criador da sessão de transporte um meio de determinar que algum outro acesso ocorreu. O TBS não faz nada específico para dificultar sessões exclusivas de transporte, mas é um pouco incompatível com elas. O TBS tenta duplicar o comportamento natural do TPM por ser transparente, por isso não favorece comandos de contextos que estabelecem uma sessão de transporte exclusiva. Por exemplo, se o cliente B enviar um comando quando o cliente A estiver em uma sessão de transporte exclusiva, ele invalidará a sessão de transporte exclusiva do cliente A.

Os comandos iniciados pelo TBS também podem encerrar a sessão de transporte exclusiva. Isso acontece quando o cliente A está em uma sessão de transporte exclusiva e um comando executado pelo cliente A chama um recurso que não está fisicamente presente no TPM. Essa situação aciona o gerenciador de virtualização TBS para executar um comando TPM_LoadContext para fornecer esse recurso, que encerra a sessão de transporte exclusiva do cliente A.