Fabrication industrielle
Internet des objets industriel | Matériaux industriels | Entretien et réparation d'équipement | Programmation industrielle |
home  MfgRobots >> Fabrication industrielle >  >> Industrial Internet of Things >> Technologie de l'Internet des objets

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

Ceci est la partie 2 d'un six -série de blogs sur ce sujet. Si vous avez manqué l'aperçu de la partie 1, veuillez le lire ici.

Le développement des extensions Software Guard (SGX) a été initialement conçu par Intel® pour être un processus de refactorisation. Chaque application serait conçue à partir de zéro ou repensée pour partitionner les secrets et le code de gestion des secrets d'un autre code, puis compilée avec le kit de développement logiciel (SDK) SGX pour protéger la partition de code sensible. Cela correspondait à l'objectif d'Intel de réduire la base informatique de confiance (TCB) à la plus petite zone possible.

Avec les applications existantes, cependant, c'est tout un processus. Lors des tests, Intel et la United States Airforce Academy ont remanié une visionneuse PDF open source dans une étude d'accès anticipé. La refactorisation comprenait l'ajout d'un contrôle d'accès à n'importe quelle partie d'un document (rédaction numérique) et une application open source de vidéoconférence (VTC) (cryptage filaire à écran). Le processus a pris deux années-homme pour mener à bien les deux projets.

Comme la refactorisation/recompilation est à la fois lourde et, pire, pas toujours possible en raison de l'accès au code, un certain nombre d'autres projets se sont présentés pour créer des conteneurs/LibOS protégés par SGX et des compilateurs croisés. Le graphène et SCONE sont de bons exemples de projets accessibles au public pour accomplir ces tâches. J'ai examiné à la fois le graphène et le SCONE, et les deux ont des avantages / inconvénients pour les résultats finaux d'une construction réussie. Cependant, SCONE peut déjà compiler de manière croisée les plugins RTI Connext® DDS Micro et RTI Connext DDS Security avec uniquement des ajustements pour créer des scripts et/ou créer des modifications triviales de la bibliothèque Musl.

De plus, SCONE produit une application liée de manière statique qui est exécutable sur un Ubuntu 16.04 vanille avec le pilote SGX (et un processeur compatible) installé.

Le graphène nécessite la mise en œuvre d'au moins un nouvel appel système (getifaddrs) ou des modifications de DDS pour éviter l'appel, ainsi que plusieurs modifications d'autres appels DDS souvent effectués dans Connext DDS Micro avec des systèmes d'exploitation plus limités (c'est-à-dire nanosleep). Le graphène doit également être exécuté en tant que conteneur docker. En conséquence, ce premier objectif est de mettre en œuvre une application sécurisée Connext DDS Micro avec SCONE. Nous parlerons davantage du graphène plus tard dans cette série de blogs.

L'un des projets SCONE consiste en un compilateur croisé qui génère un binaire exécutable qui encapsule l'application dans un environnement protégé par SGX. Ce compilateur croisé se lie statiquement à musl plutôt qu'à GLibC. En conséquence, nous compilerons statiquement tous les composants nécessaires à la construction de notre application, y compris OpenSSL et Connext DDS Micro.

Pour suivre, vous aurez besoin de RTI DDS Connext Micro 3.0 (y compris la source constructible), de la source openssl 1.0.2r et de SCONE. Les produits RTI Connext DDS sont disponibles (avec accès sous licence) en contactant RTI; OpelSSL est disponible sur https://www.openssl.org/source/; et SCONE est accessible via des images organisées par SCONE sur dockerhub. Ces conteneurs SCONE sont privés et vous devez y accéder en contactant SCONE via [email protected].

Mon système hôte est compatible SGX et exécute Ubuntu 16.04 LTS. Vous pouvez suivre sans système SGX. Si vous disposez d'un système SGX et que vous souhaitez utiliser SGX, vous devez installer le pilote Intel SGX à partir de https://github.com/intel/linux-sgx-driver. Si vous lisez ce blog, il est supposé que vous savez utiliser docker, docker hub et Linux (ou que vous êtes prêt à apprendre).

Pour commencer, j'ai mis à la fois le RTI DDS Connext Micro 3.0 et OpenSSL 1.0.2r dans mon répertoire personnel. Je les ai décompressés dans le répertoire personnel et je me retrouve avec deux répertoires :

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Toutes les commandes suivantes sont spécifiques à ces répertoires. Connectez-vous à docker et assurez-vous que vous êtes dans votre répertoire personnel. Exécutez les commandes suivantes pour démarrer le conteneur en mode interactif. Si vous suivez sans SGX, omettez le --device=/dev/isgx de la commande.

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

J'ai trouvé que le conteneur est un peu léger sur certains outils nécessaires (et pratiques). Pour y remédier, installez directement les outils.

apt mise à jour
apt install -y make default-jre cmake nano less
apt install -y perl --reinstall

Ensuite, compilons OpenSSL. La réinstallation précédente de perl a corrigé certains modules manquants dans le script de configuration. Pour créer, tester et installer OpenSSL sur votre conteneur, exécutez les commandes suivantes. Soyez prévenu que le test prendra un certain temps. Pour un benchmark approximatif, il a fallu 45 minutes pour exécuter les commandes suivantes sur un i5 NUC.

cd /home/openssl-1.0.2r
./config
faire
faire un test
faire l'installation
exporter 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

Les liens symboliques à la fin de la commande aideront avec le Makefile dans l'exemple que nous utiliserons. Oui, c'est un peu bidouille (qu'attends-tu du gars de la sécurité ?), mais ça marche.

Ensuite, compilons RTI DDS Micro 3.0. Exécutez les commandes suivantes.

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

CHEMIN=$CHEMIN:/opt/scone/cross-compiler/libexec/gcc/x86_64-linux-musl/7.3.0/
exporter RTIMEHOME=/home/rti_connext_dds_micro-3.0.0
exporter 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 -- config Release

À ce stade, nous devrions avoir des bibliothèques d'OpenSSL et de RTI DDS Micro (y compris la sécurité) liées à musl plutôt qu'à GLibC.

Passons à une application de test. Exécutez les commandes suivantes.

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

Si tout s'est bien passé, nous aurons à la fois un éditeur et un abonné dans le répertoire suivant :/home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Exécutons-le pour voir ce que nous avons.

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

La sortie devrait ressembler à quelque chose comme :

exporter SCONE_QUEUES=1
exporter SCONE_SLOTS=256
exporter SCONE_SIGPIPE=0
exporter SCONE_MMAP32BIT=0
exporter SCONE_SSPINS=100
exporter SCONE_SSLEEP=4000
exporter SCONE_KERNEL=0
exporter SCONE_HEAP=87108864
exporter SCONE_STACK=81920
exporter SCONE_CONFIG=/home/jason/sgx-musl.conf
exporter SCONE_ESPINS=10000
exporter SCONE_MODE=hw
exporter SCONE_SGXBOUNDS=no
exporter SCONE_VARYS=no
exporter SCONE_ALLOW_DLOPEN=non
exporter SCONE_MPROTECT=no
Révision :4be39d5943d5c15e11fa17055b859de4a25c0288 (jeu 23 août 14:14:04 2018 +0200)
Branche :cf-java-fix (sale)
Options de configuration :--enable-shared --enable-debug --prefix=/home/christof/GIT/subtree-scone/built/cross-compiler/x86_64-linux-musl

Hachage d'enclave :14fa1810e1d35799ba9910243cab89660b7146f96babb97a32caef9c06b3c9a2

[1555446711.154091000]ERREUR :ModuleID=0 Errcode=17 X=1 E=0 T=1
osapi/posixThread.c:96/OSAPI_Thread_get_policy :sysrc=38
# Identité CA, :file:security/ca/ca.pem
# Autorisations CA, :file:security/ca/ca.pem
# certificat PEER :file:security/ca/certs/publisher.pem
# clé PEER :file:security/ca/certs/publisher_key.pem
# Gouvernance XML :file:security/xml/governance.p7s
# autorisations XML :file:security/xml/permissions_publisher.p7s

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

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

[1555446711.197874000]ERREUR :ModuleID=0 Errcode=17 X=0 E=1 T=1
/ :-1/ :
Bonjour le monde! (0)

Bonjour tout le monde ! (1)
Bonjour tout le monde ! (2)
Bonjou

[1] [2] 下一页

Technologie de l'Internet des objets

  1. La route vers la sécurité industrielle de l'IoT
  2. S'attaquer aux vulnérabilités de sécurité de l'IoT industriel
  3. Sécuriser l'IoT contre les cyberattaques
  4. Sécurisation du vecteur de menace IoT
  5. Hyperconvergence et calcul à la périphérie :partie 3
  6. Le défi de sécurité posé par l'Internet des objets :2e partie
  7. Le défi de sécurité posé par l'Internet des objets :1ère partie
  8. Sécuriser l'IoT industriel :adopter une approche de nouvelle génération – Partie 2
  9. La sécurité renforce le véritable potentiel de l'IoT