Segurança DDS do jeito mais difícil (ware) - SGX Parte 3:Serviços DDS reforçados

Esta é a Parte 3 em seis - série de blogs sobre este tópico. Se você é novo nesta série, leia os blogs anteriores aqui .

Na Parte 2 desta série, expliquei como criar um endpoint protegido usando RTI Connext DDS Micro + Security, SCONE e Intel SGX. Embora seja interessante, ainda não examinamos uma solução prática com SGX integrado. Na Parte 1, sugeri que DDS + SGX é mais provável de aparecer em uma sala de servidor do que como um ponto de extremidade Industrial Internet of Things (IIoT) mais tradicional. Nesta parte, veremos soluções mais práticas para uma aplicação DDS reforçada com SGX através das lentes dos serviços DDS.

Muitos serviços DDS são os principais alvos para o fortalecimento da segurança. Freqüentemente, eles assinam mais tópicos e, em uma solução DDS segura, têm mais acesso a chaves efêmeras. Essas chaves são armazenadas por necessidade na memória do aplicativo. Com habilidade e determinação, um usuário ou invasor privilegiado pode extraí-los, ou talvez mais efetivamente, pode coletar os dados da memória do sistema logo após as proteções DDS serem removidas - ou até mesmo alterar os dados pouco antes de as proteções serem adicionadas. Afinal, por que se preocupar com a criptografia quando os dados já estão em texto simples?

Figura 1:Superfície de ataque em ambientes DDS



Se você está acompanhando esta série, deve se lembrar que, na Parte 1, eu apresentei uma arquitetura em que pacotes protegidos por DDS poderiam chegar no fio e ser passados ​​para um espaço protegido por SGX antes que a proteção DDS fosse removida. Uma vez dentro do aplicativo, o SGX protege os dados e a proteção DDS pode ser removida. Como a CPU pode ver os dados em texto simples, não há necessidade de operações exóticas em dados criptografados. Isso oferece uma vantagem distinta sobre outros métodos de proteção, como criptografia homomórfica.

Esse design permite que um aplicativo pegue os dados criptografados durante a transmissão, mova-os para um espaço protegido antes de remover a criptografia, opere nos dados e adicione proteção à transmissão. Se pudermos construir um desses aplicativos, poderemos construir muitos. Além disso, como o DDS fornece proteção no fio, podemos ter uma rede heterogênea quando os aplicativos não SGX podem se comunicar com os aplicativos SGX; alguns desses aplicativos podem ser serviços DDS.

Para ilustrar isso, vamos dar uma olhada no RTI Routing Service. A especificação de segurança DDS do Object Management Group® (OMG®) requer que o código do aplicativo Routing Service opere em dados protegidos, mesmo que momentaneamente. Além disso, o Routing Service possui todas as chaves efêmeras de cada endpoint a partir do qual ele se comunicou. Algumas arquiteturas exigem que o serviço de roteamento apareça na borda da rede, aumentando o risco de ataque. Como tal, é um alvo de alto valor para um usuário mal-intencionado.

Figura 2:O serviço de roteamento RTI fornece um espaço protegido para aplicativos em execução em ambientes SGX



Embora ainda não tenhamos explorado isso, o SCONE tem suporte integrado e transparente para armazenamentos de arquivos criptografados, bem como atestados. Com armazenamentos de arquivos integrados, podemos expandir a funcionalidade de nosso aplicativo. No exemplo do Routing Service, agora podemos armazenar as chaves privadas usadas para identidade em um espaço protegido disponível apenas para o aplicativo; nenhum usuário root + tem acesso a eles.

Para levar a ideia adiante, agora podemos armazenar quaisquer dados em disco de forma protegida.

Figura 3:O serviço de roteamento DDS e RTI é protegido em ambientes SCONE



Por exemplo, podemos armazenar comunicações DDS para reprodução autorizada. O SCONE oferece suporte a comunicações TLS nativas (e transparentes) com outros contêineres SCONE autorizados, como o SQLite.

Com essas ferramentas, podemos construir uma infraestrutura onde todos os dados estão protegidos o tempo todo, mesmo contra um administrador de sistema ou invasor mal-intencionado. Obviamente, um aplicativo precisa se medir de maneira confiável antes de ser confiável para acessar serviços confiáveis, incluindo suas lojas e conexões de rede. Essa é a função do serviço de atestado.

O serviço de atestado, em poucas palavras, é um método remoto de verificar se o aplicativo não foi modificado, é original e está sendo executado em uma CPU SGX original. Essencialmente, o serviço de atestado é um sistema mais confiável que verifica se um sistema menos confiável tem - e pode ser executado com segurança - um aplicativo confiável. Originalmente, esse serviço era fornecido exclusivamente pela Intel, mas as coisas estão mudando.

O atestado remoto pode parecer um problema para muitos sistemas fechados, principalmente se o atestado for fornecido pela Intel. No entanto, não é tão difícil quanto se poderia imaginar, pois um atestado de um aplicativo precisa ocorrer apenas uma vez e sobrevive a uma reinicialização. O processo verifica a CPU e o aplicativo por meio de instruções ISA que possuem garantias de integridade criptográfica. Esses valores podem ser selados em disco e reutilizados conforme necessário. Essa reutilização pode incluir um aplicativo que prova para a CPU que não foi modificado, uma CPU que prova a um sistema remoto que é genuíno ou um aplicativo que prova a outro aplicativo que não foi modificado. Esses recursos são particularmente úteis em um sistema distribuído para garantir que o aplicativo parceiro remoto de um determinado aplicativo seja confiável.

Como temos usado o SCONE como nossa estrutura SGX, é útil destacar que o SCONE fornece um serviço de atestado. Este serviço pode ser gerenciado localmente em seu sistema se você for o titular da licença SCONE Enterprise. O SCONE tem um serviço de atestado global para usuários não empresariais e exploraremos o atestado com esse serviço global posteriormente nesta série.

Em meu próximo blog, explorarei o custo da segurança em ambientes DDS-SGX.