Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)

Este artigo apresenta uma nova arquitetura de capacidades implementada em FPGA que permite a criação de um sistema operacional de tempo real seguro sem TCB de software em tempo de execução, isolando completamente subsistemas e periféricos não confiáveis sem exigir alterações de hardware.

O essencial

Imagine que o seu dispositivo embarcado (como um roteador inteligente, um sensor industrial ou um carro conectado) é uma casa muito segura.

Nesta casa, existem três tipos de potenciais ladrões:

1. O Inquilino (Aplicação): O software que você instalou para fazer algo útil.
2. O Zelador (Sistema Operacional): O programa que gerencia a casa, abre portas e distribui chaves.
3. O Encanador (Periféricos/Hardware): Dispositivos externos que fazem o trabalho pesado, como a placa de rede ou o disco rígido.

O Problema: "Confie em Alguém"

Até hoje, a segurança dessas casas funcionava assim: "Confie no Zelador". O Zelador (o Kernel do sistema operacional) tinha todas as chaves mestras. Se o Zelador fosse corrompido (por um vírus ou um erro), o ladrão ganhava acesso a tudo: aos seus dados, à sua rede e até podia controlar o encanador para roubar coisas.

Além disso, se o Encanador (o hardware) fosse mal-intencionado, ele podia tentar entrar na casa sem permissão, e o Zelador muitas vezes não conseguia impedir isso.

A maioria das defesas atuais protege contra o Inquilino ou contra o Encanador, mas raramente contra os três ao mesmo tempo. E o pior: elas exigem que você confie cegamente no Zelador.

A Solução: "Não Confie em Ninguém" (Trust Nothing)

Os autores deste paper, Eric e Sven, criaram uma nova abordagem chamada Skadi (o sistema operacional) e Bredi (o hardware). A filosofia deles é simples: Ninguém é confiável.

Eles usaram uma metáfora de "Chaves Mágicas" (chamadas de Capacidades).

1. A Casa de Compartimentos (Subsistemas)

Em vez de ter um Zelador gigante que controla tudo, a casa foi dividida em pequenos compartimentos isolados.

• O sistema de som não sabe onde fica a cozinha.
• O sistema de luz não sabe onde fica o cofre.
• Cada um tem sua própria chave para sua própria sala.

Se o sistema de som for hackeado, o hacker fica preso ali. Ele não consegue pular para a sala da luz ou para o cofre, porque não tem a chave mágica para entrar.

2. As Chaves Mágicas (Capacidades)

No mundo antigo, você usava um endereço (como "Rua das Flores, nº 10") para entrar em um lugar. Se alguém soubesse esse endereço, podia entrar.
No mundo do Bredi, você não usa endereços. Você usa Chaves Mágicas.

• Essa chave não é apenas um número; ela é um "token" que diz: "Você pode entrar nesta sala, mas apenas para ler, e apenas por 5 minutos".
• Se você tentar usar essa chave em outra sala, ela não funciona.
• Se você tentar forjar uma chave, o sistema percebe porque a chave tem um código secreto que ninguém consegue adivinhar.

3. O Zelador Desaparece (Sem TCB de Software)

A grande inovação é que, depois que a casa é construída, o Zelador some.

• No início, um "Arquiteto" (o Loader) organiza as chaves e abre as portas para os compartimentos.
• Assim que a casa está pronta, o Arquiteto se vai e destrói suas próprias chaves mestras.
• Agora, não existe mais nenhum "Zelador" rodando na memória que possa ser hackeado. Se um hacker entrar em um compartimento, ele não consegue controlar o resto da casa porque não há um "cérebro central" vulnerável.

4. O Encanador Controlado

E se o Encanador (o hardware de rede) for mal-intencionado?
No sistema antigo, o Encanador podia ler qualquer coisa que o Zelador permitisse. No Bredi, o Encanador só recebe uma Chave Mágica temporária para um pedaço específico de memória (ex: "Apenas para escrever este pacote de dados aqui").
Se o Encanador tentar ler a memória do cofre, a chave simplesmente não funciona. O hardware em si impede o roubo, sem precisar de um software confiável para vigiar.

O Resultado: Segurança e Velocidade

Você pode pensar: "Tantas chaves e compartimentos devem deixar a casa lenta, certo?"

• Em tarefas de cálculo puro: O sistema é tão rápido quanto os sistemas inseguros atuais.
• Em tarefas de rede (enviar dados): Há um pequeno atraso (cerca de 3 a 4 vezes mais lento que o padrão), mas ainda é rápido o suficiente para a maioria das aplicações do mundo real.

Por que isso é importante?

Hoje, nossos dispositivos estão cheios de falhas. Se um hacker pega um erro no seu aplicativo, ele pode assumir o controle do seu carro ou da sua rede doméstica.

O trabalho Skadi e Bredi prova que é possível construir dispositivos onde:

1. Um erro no aplicativo não quebra o sistema todo.
2. Um vírus no sistema operacional não existe (porque ele não roda).
3. Um hardware malicioso não consegue roubar dados.

É como transformar uma casa com uma única porta trancada por um zelador (que pode ser subornado) em uma fortaleza com dezenas de portas, onde cada chave só abre uma porta específica, e o zelador já saiu de casa para sempre.

Resumo em uma frase: Eles criaram um sistema onde a segurança é construída nos alicerces (hardware) e nas regras de acesso (chaves), eliminando a necessidade de confiar em qualquer software que esteja rodando no momento, tornando dispositivos embarcados muito mais seguros contra hackers, erros e hardware defeituoso.

Resumo técnico

Título: Trust Nothing: RTOS Security without Run-Time Software TCB (Versão Estendida)

Autores: Eric Ackermann e Sven Bugiel (CISPA Helmholtz Center for Information Security)

1. O Problema

Os dispositivos embarcados enfrentam um cenário de ameaças em expansão, onde vulnerabilidades podem surgir em três vetores principais:

1. Software de Aplicação: Bugs em firmware e aplicações.
2. Kernel do Sistema Operacional: Falhas no núcleo do OS (ex: Zephyr, Linux).
3. Periféricos de Hardware: Dispositivos com Acesso Direto à Memória (DMA) que podem ser comprometidos ou agir como "cavalos de Troia" (ex: ataques Thunderclap).

Limitações das Defesas Atuais:

• As arquiteturas de segurança existentes geralmente protegem contra apenas dois desses vetores simultaneamente.
• Sistemas baseados em MMU (Unidade de Gerenciamento de Memória) exigem que o kernel seja confiável para configurar a proteção, mantendo um TCB (Trusted Computing Base) de software em tempo de execução.
• Arquiteturas de capacidades modernas (como CHERI) muitas vezes excluem dispositivos do modelo de ameaça ou exigem drivers confiáveis, falhando em proteger contra DMA malicioso sem mudanças de hardware nos periféricos.
• Não existe, até o momento, uma arquitetura que garanta segurança simultaneamente contra software de aplicação não confiável, kernels comprometidos e dispositivos periféricos maliciosos, sem depender de um TCB de software em tempo de execução.

2. Metodologia e Arquitetura Proposta

Os autores propõem uma solução baseada em Co-design Hardware-Software, combinando uma nova arquitetura de capacidades chamada Northcape com uma implementação de hardware e um sistema operacional.

A. Arquitetura Northcape (Hardware)

Baseia-se no conceito de capacidades de objeto, mas com inovações críticas:

• Controle de Acesso no Barramento do Sistema: A verificação de capacidades ocorre no Northbridge (ponte norte), não apenas na CPU. Isso permite proteger tanto o processador quanto dispositivos DMA.
• Tokens de Capacidade: Em vez de endereços físicos, o sistema usa tokens de 64 bits contendo um identificador, um nonce (nãoça) aleatório e um deslocamento (offset).
• Tabela de Metadados de Capacidade (CMT): O hardware resolve os tokens consultando uma tabela na memória principal que define limites, permissões e restrições.
• Tipos de Capacidades:
  • Diretas: Donas do segmento de memória.
  • Indiretas: Subconjuntos de capacidades diretas (proteção de sub-objetos).
  • Lock-holder: Garantem acesso exclusivo, bloqueando outras capacidades sobrepostas.
• Restrições de ID de Subsistema: Uma inovação chave que vincula uma capacidade a um ID específico de subsistema. Se um dispositivo ou outro subsistema tentar usar o token sem o ID correto, o acesso é negado, prevenindo ataques de adivinhação e uso indevido.

B. Implementação de Hardware: Bredi SoC

• Base: CPU RISC-V cva6 (64-bit) em FPGA.
• Componentes Chave:
  • AXI MMU: Enforça restrições de acesso para dispositivos DMA, traduzindo tokens para endereços físicos.
  • Capability Resolver: Lógica de hardware para resolver tokens recursivamente (para capacidades indiretas e travadas).
  • NTLB (Northcape TLB): Cache de duas camadas (L1 e L2) para acelerar a tradução de capacidades, minimizando a latência.
  • Módulo de Operações: Implementa instruções de hardware para criar, derivar, travar e revogar capacidades.
• Tratamento de Interrupções:
  • ISRs Não Confiáveis: As Rotinas de Serviço de Interrupção (ISRs) são tratadas como subsistemas não confiáveis.
  • Empilhamento de Registradores: O CPU possui um segundo conjunto de registradores para o regime de interrupção, impedindo vazamento de estado do subsistema interrompido para a ISR.
  • Interrupções Não Mascaráveis (NMI): Garantem a disponibilidade de serviços críticos mesmo se um atacante tentar desabilitar interrupções.

C. Sistema Operacional: Skadi RTOS

• Base: Modificação do RTOS Zephyr.
• Filosofia: "Trust Nothing" (Não confie em nada).
• Sem Kernel Privilegiado: Todas as funcionalidades do kernel (agendador, alocação de memória, drivers, ISRs) são decompostas em subsistemas mutuamente isolados.
• Sem TCB de Software em Tempo de Execução:
  • Existe apenas um Loader (Skadi Loader) privilegiado durante o boot.
  • O Loader aloca capacidades, configura restrições de ID e, ao final do boot, destrói a si mesmo e a capacidade raiz, tornando impossível recuperar privilégios.
  • Após o boot, apenas subsistemas não privilegiados (ID > 0) existem.
• Chamadas de Subsistema (Subsystem Calls): Mecanismo de troca de controle atômico que altera o fluxo de controle e o ID do subsistema ativo simultaneamente, garantindo isolamento mútuo sem intermediários confiáveis.

3. Principais Contribuições

1. Primeira Implementação Completa de Northcape: Bredi é a primeira implementação de hardware funcional de uma arquitetura de capacidades que protege contra software e dispositivos não confiáveis simultaneamente.
2. RTOS sem TCB em Tempo de Execução: O Skadi demonstra que é possível construir um sistema operacional de tempo real onde nenhum componente de software em execução é confiável por padrão.
3. Proteção de DMA sem Mudanças no Periférico: O sistema protege dispositivos DMA maliciosos usando o AXI MMU e tokens de capacidade, sem exigir alterações no hardware dos periféricos (drivers podem ser não confiáveis).
4. Garantias de Tempo Real (Soft Real-Time): O sistema mantém garantias de disponibilidade através de interrupções não mascaráveis e agendamento cooperativo/voluntário, mesmo na presença de atacantes.
5. Compatibilidade com Zephyr: O Skadi mantém compatibilidade com a API e o modelo de construção do Zephyr, facilitando a portabilidade de componentes existentes.

4. Resultados e Avaliação

Os protótipos foram implementados em uma placa FPGA (Digilent Genesys 2) e avaliados em termos de segurança, área de chip e desempenho.

• Segurança: O sistema fornece isolamento espacial e temporal rigoroso. A combinação de tokens não forjáveis, restrições de ID de subsistema e isolamento de registradores impede que um subsistema comprometido acesse dados de outros ou do kernel.
• Desempenho (Computação):
  • Em benchmarks de computação pura (Coremark, Stream), o Skadi tem desempenho indistinguível do Zephyr inseguro e comparável ao Linux, devido à alta taxa de acerto no TLB de capacidades (NTLB L1).
• Desempenho (E/S e Rede):
  • Há uma sobrecarga perceptível em cenários limitados por E/S (ex: ping, TCP throughput), com latência aumentando em cerca de 3x a 4x em comparação ao Zephyr padrão.
  • Isso é atribuído à granularidade fina da compartimentalização (muitas chamadas de subsistema).
  • No entanto, os autores argumentam que os valores absolutos ainda são práticos para a maioria dos dispositivos embarcados.
• Tempo Real:
  • O sistema responde a interrupções em frações de milissegundos (~68 µs de latência média), demonstrando viabilidade para sistemas de tempo real suave.
  • A sobrecarga no agendamento é de 3x a 10x, mas aceitável para o ganho de segurança.
• Área de Chip:
  • A implementação adicionou uma sobrecarga de área significativa (principalmente devido ao L2 NTLB e ao resolvedor), mas ainda é considerada viável para FPGAs e ASICs modernos.

5. Significado e Conclusão

O trabalho "Trust Nothing" representa um avanço fundamental na segurança de sistemas embarcados. Ao eliminar a necessidade de um kernel confiável e proteger contra dispositivos DMA maliciosos sem exigir hardware personalizado nos periféricos, ele oferece uma base para o "Security-by-Design" em dispositivos críticos (como infraestrutura de rede 5G, IoT industrial e veículos autônomos).

A principal lição é que é possível trocar uma pequena fração de desempenho em E/S por uma segurança radicalmente superior, onde a falha de qualquer componente de software ou hardware não compromete a integridade ou confidencialidade do sistema como um todo. O projeto planeja liberar o código-fonte (Skadi e Bredi) sob licença Open Source, incentivando futuras otimizações e adoção.