DDS Security the Hard (ware) Way - SGX:Parte 1 (Visão geral)

Parte 1 de uma peça múltipla Série

A proteção de ambientes de IoT industriais de missão crítica requer segurança que pode ser dimensionada da borda à nuvem, entre sistemas e fornecedores. Como autor principal do padrão de segurança OMG DDS, a RTI desempenhou um papel importante na definição dos requisitos - e ambientes - necessários para proteger os ambientes distribuídos. Os plug-ins de segurança DDS fornecem mecanismos de segurança robustos e centrados em dados para dados durante a transmissão. O RTI Connext DDS Secure é a estrutura de conectividade confiável e comprovada que protege os sistemas por meio de segurança flexível e refinada para desempenho e eficiência ideais, do dispositivo à nuvem.

Reconhecemos, no entanto, que a segurança é uma questão complexa. Embora a RTI tenha criado segurança de alto nível na estrutura do software Connext DDS, nossa equipe de pesquisa está procurando outras áreas para conduzir uma segurança mais robusta à IIoT. Com isso em mente, temos o prazer de compartilhar com você alguns dos trabalhos da RTI Research, à medida que exploram abordagens novas e inovadoras para a segurança.

Nesta série de blog, nosso especialista em segurança Jason Upchurch olha além do software para mecanismos de hardware que fornecem segurança em um sistema não confiável, onde um aplicativo crítico processa seus dados. Com o espírito de expandir os limites da segurança, ele explora o Intel SGX® no contexto do RTI Connext® DDS Micro e dos plug-ins de segurança.

Então vamos começar.

O que é SGX e por que isso é importante?

SGX, ou Software Guard Extensions, é uma extensão do Intel ISA (Instruction Set Architecture) que fornece um TEE (Trusted Execution Environment) para executar aplicativos que contêm dados confidenciais. Embora seja verdade que o Intel ISA não domina a IoT industrial (IIoT), ele tem participação de mercado na sala de servidores, que costuma ser incorporada em várias arquiteturas IIoT. Mais especificamente, esses aplicativos de processamento de dados da sala do servidor têm mais probabilidade de ser alvos de alto valor de usuários mal-intencionados, pois podem ter mais acesso aos dados protegidos do que os terminais IIoT tradicionais. Portanto, o SGX poderia muito bem ajudar a proteger a IIoT, ou pelo menos parte dela. Vamos explorar por que SGX é importante para usuários DDS e outros desenvolvedores de aplicativos que exigem ambientes de alta segurança.

Figura 1:Connext DDS Secure Inside SGX Space

A segurança over-the-Wire pode não ser suficiente

Para começar, vamos dar uma olhada no clássico exemplo acadêmico de Alice e Bob de compartilhar um segredo. A história começa com Alice e Bob se encontrando pessoalmente, prossegue com uma Eva desonesta interceptando mensagens na transmissão e termina com um método comprovado para compartilhar segredos. Esta é a base para uma comunicação segura, mesmo que Eva intercepte todas as mensagens. Tendo executado várias das maiores investigações de intrusões do mundo, posso dizer com segurança que nunca vi "Eve" interceptar mensagens criptografadas na transmissão e coletar segredos. Também posso dizer com certeza que “Eva” quase sempre consegue os segredos que procura. Essas afirmações aparentemente contraditórias podem ser verdadeiras porque a criptografia de rede é robusta e, portanto, raramente o alvo de ataque.

Para examinar a questão, vejamos o cenário, onde Eva se senta entre Alice e Bob e pode ouvir e até mesmo manipular mensagens à vontade. O cenário pressupõe que Alice e Bob confiem um no outro com os segredos que estão compartilhando; no entanto, essa suposição prova ser muito falha na prática. O diagrama do livro na Figura 2 na verdade ilustra o problema, visto que Alice aparentemente se comunica com Bob à distância, sem qualquer tecnologia.

Figura 2:Comunicação entre Alice e Bob no livro didático



A realidade da situação é que algum tipo de dispositivo é usado para permitir que Alice e Bob se comuniquem, e é aí que nossa suposição leva a melhor. Na segurança de computadores, existe um conceito conhecido como Trusted Computing Base (TCB). Em seus termos mais simples, TCB são todos os componentes (individualmente e como um sistema), incluindo software, que você deve confiar para proteger algum tipo de processamento. Em nosso cenário clássico de Alice e Bob, estamos tentando proteger o compartilhamento de segredos à distância. É verdade que Alice presume que confia em Bob para compartilhar segredos com ele, mas ela também está confiando em seu ambiente de computação (e no dela). Em um cenário do mundo real, este é um conjunto de centenas de componentes de vários fabricantes que (a) provavelmente estão executando um sistema operacional com milhões de linhas de código; (b) está cheio de aplicativos codificados por pessoas que você não conhece; e (c) provavelmente conectado a uma rede pública que permite que os invasores e o acesso livre de malware de propagação automática ataquem o sistema à vontade. Esses sistemas estão longe de ser confiáveis, para dizer o mínimo.

... a situação é análoga a construir uma porta de aço com fechaduras elaboradas em uma casa com paredes de papel.

É fonte de humor cínico para muitos na comunidade de segurança de computador quando algum esquema de criptografia novo e melhor é recomendado para criptografar a comunicação por fio. Afinal, os segredos podem ser extraídos com pouco esforço da origem ou destino, totalmente em claro, sem se preocupar com a criptografia. Sempre pensei que a situação é análoga a construir uma porta de aço com fechaduras elaboradas em uma casa com paredes de papel.

Então, o que deve ser feito? A abordagem atual na indústria é amplamente centrada em encontrar os componentes mínimos viáveis ​​(hardware e software) necessários para realizar uma tarefa crítica, certificar e / ou medir cada componente e isolá-los de outros componentes no sistema. Em um nível muito básico, essa abordagem reduz o TCB e verifica se nenhum componente dentro do TCB foi adicionado ou modificado.



Segurança no terminal (e todos os pontos intermediários)

É útil notar que, embora não seja trivial, chegamos ao ponto na computação em que é possível construir um ambiente de computação seguro. O problema é que a demanda atual do mercado é por um ambiente de computação rico, o que está em conflito com um ambiente seguro. Mesmo na IIoT, a demanda por ambientes de computação ricos nem sempre é pela vasta funcionalidade que eles oferecem, mas porque são populares e têm um bom suporte, portanto, muito mais baratos de desenvolver e manter. Portanto, o grande problema do TCB encontra seu caminho em dispositivos que poderiam ser protegidos com outra abordagem. Em resposta ao problema, a indústria passou a arquitetar sistemas que fornecem um sistema operacional avançado e um Trusted Execution Environment (TEE) (de alguma forma) separado em um único dispositivo.

A maioria dos projetos de TEE tem essencialmente dois sistemas operacionais executados em paralelo em um único dispositivo. O rico sistema operacional lida com tarefas comuns e o sistema operacional seguro lida com tarefas confidenciais. O design TEE permite alternar entre os dois. A mudança é freqüentemente suportada por hardware e aplicada. Mecanismos de confiança comuns - como a raiz do carregamento da cadeia de confiança - são usados ​​no lado seguro para garantir que nenhum código não autorizado seja introduzido.

SGX é bem diferente. Mesmo um TCB do lado seguro pode ser bastante grande. A raiz de confiança apenas garante que um programa não seja alterado durante o carregamento. Como tal, sua segurança depende de técnicas de validação de software para cada programa carregado (incluindo o sistema operacional mínimo), tanto quanto de seu processo de inicialização confiável. A Intel decidiu minimizar radicalmente o TCB. A superfície de ataque em um processador habilitado para SGX é a CPU e o aplicativo. Não há sistema operacional, firmware, hipervisor, outro hardware ou BIOS que precise ser confiável em um ambiente SGX. O único software em que se deve confiar é o próprio aplicativo. SGX fornece um método para garantir o carregamento confiável desse aplicativo da mesma maneira que uma inicialização confiável normal, exceto que a cadeia de confiança tem apenas 3 links de comprimento (atestado de raiz, CPU, aplicativo) em vez das longas cadeias em um sistema seguro tradicional sistema de inicialização.

Figura 3:Superfície de ataque em um ambiente SGX



Tenho experimentado com Intel SGX e DDS + Security. Meu objetivo é executar um aplicativo DDS em uma área protegida de um Ubuntu 16.04 vanilla com SGX habilitado. A ideia é que a comunicação com fio protegido DDS chegue no sistema operacional Ubuntu e, em seguida, seja passada para o espaço protegido por SGX. A proteção DDS seria removida dentro do espaço protegido. Em seguida, os dados podem ser

[1] [2] 下一页