Manufaturação industrial
Internet das coisas industrial | Materiais industriais | Manutenção e reparo de equipamentos | Programação industrial |
home  MfgRobots >> Manufaturação industrial >  >> Industrial Internet of Things >> Tecnologia da Internet das Coisas

DDS Security the Hard (ware) Way - SGX:Parte 2 (Micro + Security + SCONE)

Esta é a Parte 2 em seis - série de blogs sobre este tópico. Se você perdeu a visão geral da Parte 1, leia aqui.

O desenvolvimento para Software Guard Extensions (SGX) foi originalmente projetado pela Intel® para ser um processo de refatoração. Cada aplicativo seria projetado desde o início ou reprojetado para particionar segredos e código de gerenciamento de segredos de outro código e, em seguida, compilado com o kit de desenvolvimento de software SGX (SDK) para proteger a partição de código sensível. Isso se alinha com o objetivo da Intel de reduzir a base de computação confiável (TCB) para a menor área possível.

Com os aplicativos existentes, no entanto, esse é um processo e tanto. Nos testes, a Intel e a United States Airforce Academy refatoraram um visualizador de PDF de código aberto em um estudo de acesso inicial. A refatoração incluiu a adição de controle de acesso a qualquer parte de um documento (redação digital) e um aplicativo de videoconferência (VTC) de código aberto (criptografia de fio para tela). O processo levou dois homens-ano para concluir os dois projetos.

Como refatorar / recompilar é um trabalho pesado e, pior, nem sempre possível devido ao acesso ao código, vários outros projetos surgiram para criar contêineres / LibOSes protegidos por SGX e compiladores cruzados. Grafeno e SCONE são bons exemplos de projetos que estão publicamente disponíveis para realizar essas tarefas. Eu examinei o Graphene e o SCONE, e ambos têm prós / contras para os resultados finais de uma construção bem-sucedida. No entanto, o SCONE já pode compilar de forma cruzada os plug-ins RTI Connext® DDS Micro e RTI Connext DDS Security com apenas ajustes para construir scripts e / ou criar alterações triviais na biblioteca musl.

Além disso, o SCONE produz um aplicativo vinculado estaticamente que pode ser executado em um Ubuntu 16.04 vanilla com o driver SGX (e CPU compatível) instalado.

O grafeno requer a implementação de pelo menos uma nova chamada de sistema (getifaddrs) ou alterações no DDS para evitar a chamada, bem como várias alterações em outras chamadas DDS frequentemente feitas no Connext DDS Micro com sistemas operacionais mais limitados (ou seja, nanosleep). O grafeno também deve ser executado como um contêiner docker. Como resultado, esse primeiro foco é a implementação de um aplicativo Connext DDS Micro seguro com SCONE. Falaremos mais sobre o grafeno posteriormente nesta série de blog.

Um dos projetos SCONE consiste em um compilador cruzado que gera um binário executável que envolve o aplicativo em um ambiente protegido por SGX. Este compilador cruzado se vincula estaticamente ao musl em vez de ao GLibC. Como resultado, iremos compilar estaticamente todos os componentes necessários para construir nosso aplicativo, incluindo OpenSSL e Connext DDS Micro.

Para acompanhar, você precisará do RTI DDS Connext Micro 3.0 (incluindo a fonte compilável), da fonte openssl 1.0.2r e do SCONE. Os produtos RTI Connext DDS estão disponíveis (com acesso licenciado) entrando em contato com a RTI; OpelSSL está disponível em https://www.openssl.org/source/; e o SCONE é acessado por meio de imagens com curadoria do SCONE no dockerhub. Esses contêineres SCONE são privados e você deve obter acesso entrando em contato com SCONE via [email protected].

Meu sistema host é compatível com SGX e executa o Ubuntu 16.04 LTS. Você pode acompanhar sem um sistema SGX. Se você tem um sistema SGX - e deseja usar SGX - você deve instalar o driver Intel SGX em https://github.com/intel/linux-sgx-driver. Se você está lendo este blog, presume-se que você saiba como usar docker, docker hub e Linux (ou esteja disposto a aprender).

Para começar, coloquei o RTI DDS Connext Micro 3.0 e o OpenSSL 1.0.2r em meu diretório inicial. Descompactei-os no diretório inicial e acabei com dois diretórios:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Todos os comandos a seguir são específicos para esses diretórios. Faça login no docker e certifique-se de estar em seu diretório inicial. Execute os comandos a seguir para iniciar o contêiner no modo interativo. Se você estiver acompanhando sem SGX, omita o --device =/ dev / isgx do comando.

cd ~
docker run -it --device =/ dev / isgx -v "$ PWD":/ home
sconecuratedimages / crosscompilers:ubuntu


Eu descobri que o contêiner é um pouco leve em algumas ferramentas necessárias (e algumas convenientes). Para remediar isso, instale as ferramentas diretamente.

atualização do apt
apt install -y make default-jre cmake nano menos
apt install -y perl --reinstall

A seguir, vamos compilar o OpenSSL. A reinstalação anterior do perl cuidou de alguns módulos ausentes no script de configuração. Para fazer, testar e instalar o OpenSSL em seu contêiner, execute os seguintes comandos. Esteja avisado de que o teste levará algum tempo para ser concluído. Para um benchmark aproximado, demorou 45 minutos para executar os seguintes comandos em um i5 NUC.

cd /home/openssl-1.0.2r
./config
make
fazer teste
make install
export OPENSSLHOME =/ usr / local / ssl

ln -s /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libcryptoz.a
ln -s /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libsslz.a

Os soft links no final do comando ajudarão com o Makefile no exemplo que usaremos. Sim, é um pouco hacky (o que você espera do segurança?), Mas funciona.

A seguir, vamos compilar o RTI DDS Micro 3.0. Execute os seguintes comandos.

cp /opt/scone/cross-compiler/x86_64-linux-musl/lib/libpthread.a /opt/scone/cross-compiler/x86_64-linux-musl/lib/libnsl.a

PATH =$ PATH:/opt/scone/cross-compiler/libexec/gcc/x86_64-linux-musl/7.3.0/
export RTIMEHOME =/ home / rti_connext_dds_micro-3.0.0
export RTIMEARCH =sgxLinux_x64gcc

cd /home/rti_connext_dds_micro-3.0.0/

./resource/scripts/rtime-make -DRTI_NO_SHARED_LIB:bool =true -DOPENSSLHOME =/ usr / local / ssl --delete --target self --name $ RTIMEARCH -G "Unix Makefiles" --build - liberação de configuração

Neste ponto, devemos ter bibliotecas do OpenSSL e RTI DDS Micro (incluindo segurança) vinculadas ao musl em vez de ao GLibC.

Vamos passar para um aplicativo de teste. Execute os seguintes comandos.

cd / home /
cd rti_connext_dds_micro-3.0.0 / example / unix / C /
cd HelloWorld_dpde_secure
rm -rf objs
make

Se tudo tiver corrido bem, teremos um editor e um assinante no seguinte diretório:/home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Vamos executá-lo para ver o que temos.

SCONE_VERSION =1 SCONE_HEAP =87108864 ./objs/sgxLinux_x64gcc/HelloWorld_publisher

A saída deve ser semelhante a:

export SCONE_QUEUES =1
export SCONE_SLOTS =256
export SCONE_SIGPIPE =0
export SCONE_MMAP32BIT =0
export SCONE_SSPINS =100
export SCONE_SSLEEP =4000
export SCONE_KERNEL =0
export SCONE_HEAP =87108864
export SCONE_STACK =81920
export SCONE_CONFIG =/ home / jason / sgx-musl.conf
export SCONE_ESPINS =10000
export SCONE_MODE =hw
export SCONE_SGXBOUNDS =no
export SCONE_VARYS =no
exportar SCONE_ALLOW_DLOPEN =não
export SCONE_MPROTECT =no
Revisão:4be39d5943d5c15e11fa17055b859de4a25c0288 (quinta-feira, 23 de agosto, 14:14:04 2018 +0200)
Branch:cf-java-fix (dirty)
Configurar opções:--enable-shared --enable-debug --prefix =/ home / christof / GIT / subtree-scone / built / cross-compiler / x86_64-linux-musl

Hash de enclave:14fa1810e1d35799ba9910243cab89660b7146f96babb97a32caef9c06b3c9a2

[1555446711.154091000] ERROR:ModuleID =0 Errcode =17 X =1 E =0 T =1
osapi / posixThread.c:96 / OSAPI_Thread_get_policy:sysrc =38
# Identity CA,:file:security / ca / ​​ca.pem
# Permissões CA,:arquivo:security / ca / ​​ca.pem
# PEER certificate:file:security / ca / ​​certs / publisher.pem
# PEER key:file:security / ca / ​​certs / publisher_key.pem
# Governança XML:arquivo:security / xml / governança.p7s
# permissões XML:arquivo:security / xml / permissions_publisher.p7s

[1555446711.159431000] ERRO:ModuleID =0 Errcode =17 X =0 E =1 T =1
/ :- 1 / :

[1555446711.159704000] ERRO:ModuleID =0 Errcode =17 X =0 E =1 T =1
/ :- 1 / :

[1555446711.197874000] ERRO:ModuleID =0 Errcode =17 X =0 E =1 T =1
/ :- 1 / :
Olá Mundo! (0)

Olá, mundo! (1)
Olá, mundo! (2)
Olá, mundo! (3)
Olá, mundo! (4)

Não tenha medo do

[1] [2] 下一页

Tecnologia da Internet das Coisas

  1. Segurança DDS do jeito mais difícil (ware) - SGX Parte 3:Serviços DDS reforçados
  2. O caminho para a segurança industrial da IoT
  3. Lidando com as vulnerabilidades de segurança da IoT industrial
  4. Protegendo a IoT contra ataques cibernéticos
  5. Protegendo o vetor de ameaça IoT
  6. Hiperconvergência e computação na borda:Parte 3
  7. O desafio de segurança apresentado pela Internet das Coisas:Parte 2
  8. O desafio de segurança apresentado pela Internet das Coisas:Parte 1
  9. Protegendo a IoT Industrial:Adotando uma abordagem de próxima geração - Parte 2
  10. A segurança potencializa o verdadeiro potencial da IoT