APRENDER. PRATICAR. EVOLUIR.Secure Boot é uma política de carregamento
Secure Boot avalia conteúdo de arranque segundo uma política da plataforma. Nas bases UEFI descritas pela Microsoft, db contém identidades ou hashes permitidos e dbx identifica conteúdo revogado. Se o mesmo hash estiver nas duas, a revogação tem precedência. O plano de recuperação não pode assumir que um bootloader antigo continuará permitido apenas porque está guardado e assinado. Mantém inventário de firmware, bootloader, chaves e imagens de recuperação, com versões e dependências entre atualizações. A documentação consultada inclui o aviso de atualização dos certificados Microsoft de 2011, com expirações a começar em 2026; datas e aplicabilidade devem ser confirmadas para a plataforma concreta. Num projeto fictício de renovação de servidores, ensaia a atualização das bases e o arranque da imagem de recuperação antes de retirar confiança antiga. Define quem pode alterar a política e como se recupera uma máquina que já não arranca pelo caminho normal. Não alteres PK, KEK ou dbx apenas para eliminar um erro sem compreender o âmbito. A assinatura aceite não prova ausência de vulnerabilidades no componente. Combina prevenção de alterações indevidas com deteção e recuperação, seguindo a abordagem de resiliência de firmware do NIST. Esta aula descreve o mecanismo; o laboratório local não altera firmware nem executa Secure Boot.
Measured Boot conserva uma história que precisa de interpretação
Medir componentes permite avaliar o percurso observado, mas não demonstra que foram impedidos de executar. Distingue a política de carregamento do registo das medições. Um PCR acumula informação através de operações de extensão; o modelo didático começa com 32 bytes zero e calcula SHA-256 sobre o valor anterior concatenado com o hash do evento. Alterar, retirar ou reordenar eventos muda o resultado nos casos exercitados. A sequência e a representação dos dados são parte do contrato de reprodução, não detalhes que se podem normalizar livremente depois. O event log fornece informação para interpretar e reproduzir medições. Uma reprodução que coincide com o digest recebido comprova uma relação entre esses dados, mas não decide que o firmware é aprovado. É necessária comparação com referências autorizadas e uma origem confiável para o digest. O laboratório executa hashing real em Python, mas usa strings sintéticas, não estruturas TCG de eventos nem PCR físicos. Mostra que uma atualização pode produzir um log internamente coerente e continuar fora da referência permitida. Na operação, a equipa de plataforma deve explicar a mudança de medição, e a equipa responsável pela política deve autorizar a referência adequada. Copiar automaticamente o valor observado para a allowlist elimina essa separação.
Atestação: origem, frescura e decisão de acesso
A arquitetura RATS distingue quem produz evidência, quem a avalia e quem utiliza o resultado para decidir acesso. O verificador combina evidência, referências e política; a relying party aplica a sua política ao resultado recebido. Uma quote que valida com uma chave pública enviada pelo próprio dispositivo não estabelece, por si só, que essa chave pertence ao alvo autorizado. A inscrição e a cadeia de confiança precisam de ligar a identidade de attestation ao equipamento ou ambiente esperado. Um desafio recente ajuda a limitar replay quando está ligado de forma autenticada à evidência e à transação pendente. O modelo local verifica identificador, desafio, reprodução do log e referência. Depois constrói um dicionário falso com valores coerentes e observa que também é aceite. Esse resultado é intencional: não existe assinatura nem TPM, pelo que os testes de campos não provam autenticidade. A demonstração ensina uma lacuna, não implementa um verificador de produção. Mesmo evidência autêntica descreve um estado num momento; software e política podem mudar depois. Define frescura admissível, reavaliação e autorização da operação funcional. Não atribuas permissões de pagamentos apenas porque o arranque foi considerado aceitável. Conserva limites de âmbito e de tempo no resultado entregue a APS e ao dono do serviço.
Atualizar firmware sem perder acesso aos segredos
Um objeto protegido por política PCR pode deixar de ser utilizável depois de uma mudança legítima de firmware. A aprovação do pacote pelo fornecedor e a aprovação empresarial do novo estado são relações diferentes. No caso de estudo, vinte de cem servidores recebem firmware B, mas a política só aceita A. A perda de unsealing não é corrigida por editar o event log nem por presumir que toda a atualização assinada preserva as condições anteriores. Suspende a expansão enquanto se valida o novo estado, a referência autorizada e a via de recuperação. Antes da janela, identifica que segredos dependem do TPM, quem pode autorizar mudança de política e que procedimento devolve o serviço sem divulgar material sensível. Testa um canário representativo, incluindo arranque, libertação do segredo e operação funcional. Um rollback só serve se for compatível e continuar permitido pela plataforma; firmware ou bootloaders revogados podem impedir essa saída. Limpar o TPM também não é uma operação neutra. Pode afetar acesso a chaves e a dados dependentes, pelo que exige inventário e recuperação confirmada. Regista explicitamente o que o laboratório não demonstrou: não houve sealing, unsealing, limpeza de TPM nem atualização de firmware real. Os exercícios orientam a preparação de um ensaio autorizado em hardware adequado.
HSM: proteger material não decide quem o pode usar
Um HSM pode manter uma chave não exportável e ainda assim executar operações pedidas por um cliente comprometido que conserva autorização. Separar exportação de utilização ajuda a desenhar a resposta. O incidente pode exigir limitar credenciais, operações e aplicações autorizadas, além de avaliar a chave. Os atributos concretos dependem do produto e da ferramenta; a referência CloudHSM consultada para KMU não é uma promessa universal sobre todos os HSM. A política deve explicitar quem cria, utiliza, administra, recupera e retira cada chave, com separação de funções quando o risco o exige. A disponibilidade também tem contratos diferentes. Redundância no cluster não substitui um restauro ensaiado, e a existência de um backup não prova que a aplicação consegue voltar a funcionar. Confirma utilizadores, acesso, objetos necessários, operação criptográfica e tempos de recuperação num ambiente apropriado. Se o fornecedor apresentar uma alegação FIPS, relaciona o módulo efetivo, versão, ambiente e modo com o certificado de validação e a security policy. Um algoritmo com nome aprovado ou um teste de assinatura bem-sucedido não valida o produto inteiro. O laboratório deste bloco usa chaves temporárias de software e não executa CloudHSM, quorum, recuperação empresarial ou validação CMVP. Usa as perguntas para preparar critérios de aceitação desses mecanismos.
Definir a fronteira de hardware e fechar o handover
Uma VM com vTPM ou um enclave com resultado favorável não fornece automaticamente prova sobre todo o datacenter. Identifica a raiz em que a evidência assenta, os componentes medidos e a dependência do hipervisor, fornecedor ou serviço de attestation. Um nome comercial não demonstra isolamento físico nem independência de todos esses componentes. Da mesma forma, código identificado corretamente pode continuar a conter uma falha de autorização. A referência aprovada precisa de revisão quando se descobre que a versão permitida já não satisfaz os requisitos de segurança. Fecha o percurso com um exercício de aceitação: escolhe uma classe de máquinas, descreve a ameaça, identifica o controlo preventivo, a deteção e a recuperação, e indica qual evidência pertence a cada um. Pede casos positivos, alterações não autorizadas, evidência antiga e recuperação depois de uma atualização legítima. Regista quem atualiza referências, quem responde à perda de acesso a segredos e quem pode autorizar exceções. As duas execuções locais de 77 verificações demonstram comportamento dos fixtures; a falsificação aceite pelo modelo impede interpretá-las como prova de TPM. O resumo é exigir origem confiável, política atual, âmbito conhecido e recuperação ensaiada para cada garantia. A revisão independente e os ensaios de hardware continuam necessários para utilização empresarial.
Depois de atualizar firmware, um PCR diferente pode impedir unsealing mesmo quando o pacote foi assinado pelo fornecedor.
Armadilhas comuns
Medição como bloqueio; log coerente como estado aprovado; nonce sem autenticação; HSM não exportável como autorização de negócio; limpar TPM sem recuperação.
Tópicos relacionados: Certificados e confiança · Engenharia e controlos do host · Resiliência e dependências
Cada garantia precisa de uma origem confiável, âmbito conhecido, política atual e recuperação ensaiada.
Referência: TPM 2.0 Library Part 1 Architecture · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17