Manuel Siemens IOT2050

Préface

Ce document contient des informations sur l'utilisation des fonctionnalités de démarrage sécurisé (Secure Boot) pour l'IOT2050.

Il s'adresse aussi bien au personnel de programmation et de test qui met en service l'appareil et le connecte à d'autres unités (systèmes d'automatisation, dispositifs de programmation), qu'au personnel de service et de maintenance qui installe des modules complémentaires ou effectue des analyses de pannes/erreurs.

Connaissances de base requises

La compréhension de ce manuel nécessite des connaissances en ordinateurs personnels, systèmes d'exploitation et programmation. Des connaissances générales dans le domaine de l'ingénierie du contrôle d'automatisation sont recommandées.

Champ d'application de ce document

Ce manuel s'applique aux appareils IOT2050 de la famille d'appareils SIMATIC IOT2000.

• 6ES7647-0BA00-1YA2 (FS04)
• 6ES7647-0BA01-1YA2
• 6ES7647-0BB00-1YA2

Conventions

Les termes génériques suivants sont utilisés dans cette documentation :

Figures

Ce manuel contient des figures des appareils décrits. L'appareil fourni peut différer de certains détails par rapport aux figures. Dans certaines figures, un appareil est utilisé pour représenter tous les appareils.

Informations de sécurité

Siemens propose des produits et des solutions dotés de fonctions de sécurité industrielle qui supportent le fonctionnement sécurisé des installations, systèmes, machines et réseaux.

Afin de protéger les installations, systèmes, machines et réseaux contre les cybermenaces, il est nécessaire de mettre en œuvre – et de maintenir en continu – un concept de sécurité industrielle holistique et à la pointe de la technologie. Les produits et solutions de Siemens constituent un élément de ce concept.

Les clients sont responsables de la prévention des accès non autorisés à leurs installations, systèmes, machines et réseaux. Ces systèmes, machines et composants ne doivent être connectés à un réseau d'entreprise ou à Internet que si et dans la mesure où une telle connexion est nécessaire et seulement lorsque des mesures de sécurité appropriées (par exemple, pare-feu et/ou segmentation de réseau) sont en place.

Pour des informations supplémentaires sur les mesures de sécurité industrielle pouvant être mises en œuvre, veuillez visiter (https://www.siemens.com/industrialsecurity).

Les produits et solutions de Siemens font l'objet d'un développement continu pour les rendre plus sécurisés. Siemens recommande fortement que les mises à jour de produits soient appliquées dès qu'elles sont disponibles et que les dernières versions de produits soient utilisées. L'utilisation de versions de produits qui ne sont plus supportées, et le fait de ne pas appliquer les dernières mises à jour peuvent augmenter l'exposition des clients aux cybermenaces.

Pour rester informé des mises à jour de produits, abonnez-vous au flux RSS Siemens Industrial Security en visitant (https://www.siemens.com/cert).

Introduction

Les fonctionnalités Secure Boot sur IOT2050 sont développées pour aider à garantir que l'IOT2050 démarre en utilisant uniquement des micrologiciels et des logiciels approuvés par Siemens ou par vous. Lorsque l'appareil démarre, le micrologiciel vérifie la signature de chaque élément du logiciel de démarrage. Si les signatures sont valides, l'appareil démarre et le micrologiciel cède le contrôle au système d'exploitation.

La protection de l'intégrité est obtenue par la signature numérique : la clé cryptographique signe d'abord le binaire sous protection, puis l'IOT2050 valide le binaire avec la même clé pendant la phase de démarrage. Si la validation est réussie, cela signifie que le binaire est intact et peut démarrer. Sinon, le binaire est suspect et l'appareil ne peut pas démarrer.

Remarque
Secure Boot est uniquement pour les variantes IOT2050 PG2 et ultérieures (par exemple IOT2050 M.2).

Chaîne de confiance

L'IOT2050 utilise une paire de clés RSA comme clé cryptographique, ce qui est également l'algorithme cryptographique le plus courant pour la signature numérique dans l'industrie.

Une paire de clés RSA possède deux clés, une clé publique et une clé privée. Dans le scénario de signature numérique, la clé privée signe le binaire, tandis que l'appareil valide le binaire avec la clé publique. La clé privée doit être conservée en toute sécurité. Au contraire, la clé publique peut être distribuée librement.

La clé privée signe les éléments suivants :

• Le micrologiciel, y compris U-Boot, TF-A et OPTee
• Le chargeur de système d'exploitation EFI Boot Guard
• Le noyau Linux, et tout autre binaire UEFI faisant partie de la chaîne de démarrage

Pour valider la signature binaire, Siemens fournit un outil pour programmer le hachage de la clé publique dans la zone OTP (One Time Programming) de l'IOT2050.

Chaîne de confiance : Pendant le démarrage, le premier chargeur de démarrage, par exemple SEBoot, valide l'u-boot avec le hachage de la clé publique stocké dans la zone OTP de l'IOT2050. Ensuite, l'u-boot valide l'EFI Boot Guard qui à son tour valide le noyau Linux ainsi que les blobs de l'arbre de périphériques.

Racine de confiance : La racine de confiance fait référence au hachage de la clé publique stocké dans la zone OTP de l'appareil et au SEBoot.

Remarque
Le SEBoot est validé par rapport au hachage de la clé publique Siemens par le chargeur de démarrage ROM.

Remarque
Gardez la clé privée en toute sécurité
Une fois qu'une clé privée est compromise, un pirate informatique pourrait signer son u-boot ou son noyau malveillant que Secure Boot ne pourrait pas distinguer des versions légitimes, ce qui pourrait mettre l'appareil en danger.

Siemens propose trois emplacements de clés dans la zone OTP. Lorsque la clé utilisée est compromise, vous pouvez passer à la clé suivante dans les emplacements pour invalider la clé compromise. Trois emplacements garantissent que vous avez deux opportunités de sauver le démarrage sécurisé (Secure Boot) d'une fuite de clé.

Infrastructure Secure Boot

Zone OTP

OTP (One Time Programmable - Programmable une seule fois)
Siemens vous ouvre la zone OTP étendue pour la mise en œuvre de Secure Boot. L'accès à cette zone OTP est géré par le SEBoot. Trois parties principales sont stockées dans l'OTP :

• Hachages de clé publique
• Bit d'activation de Secure Boot
• Version sécurisée

Hachages de clé publique
Il y a trois emplacements pour stocker les hachages de clé publique. Vous pouvez choisir le nombre de hachages de clé publique à programmer (un, deux ou trois).

Siemens vous recommande d'utiliser au moins deux clés. Au cas où une clé serait compromise, vous pouvez utiliser une autre clé.

1. MPK : la première clé pour la signature des micrologiciels et images personnalisés.
2. SMPK : la deuxième clé pour la signature des micrologiciels et images personnalisés. Si la première clé est compromise, l'utilisateur peut passer à l'utilisation de cette clé.
3. BMPK : la troisième clé pour la signature des micrologiciels et images personnalisés. Si la deuxième clé est également compromise, l'utilisateur peut passer à l'utilisation de cette clé.

Bit d'activation de Secure Boot
Le bit d'activation de Secure Boot indique si Secure Boot est activé ou désactivé. Ce bit est programmable via le même outil de provisionnement de clés. Une fois ce bit programmé, le SEBoot validera le chargeur de démarrage de l'étape suivante par rapport aux clés OTP programmées.
Vous pouvez choisir de programmer ce bit avec les hachages de clé publique, ou séparément après la programmation des clés.

Remarque
Si Secure Boot sur l'IOT2050 est activé, vous ne pouvez pas le désactiver.

Le bit d'activation de Secure Boot ne contrôle le SEBoot que pour vérifier le chargeur de démarrage immédiatement suivant, qui est la combinaison de TF-A, OPTee et u-boot SPL dans la plupart des cas.

Vous pouvez toujours désactiver la validation d'image dans SPL pour rompre la chaîne de validation ultérieure, même si le bit d'activation de Secure Boot est activé.

Version sécurisée
Après avoir implémenté Secure Boot sur l'IOT2050, la version sécurisée peut détecter et prévenir les attaques de régression (Downgrade Attack).

La version sécurisée est également signée par la clé privée. Une fois qu'un micrologiciel de version sécurisée plus récente est détecté et validé, un compteur non volatil (NV) sur l'appareil est mis à jour avec le numéro de version plus récent. Lorsque l'appareil est attaqué par un ancien micrologiciel défectueux ayant une version sécurisée inférieure, le SEBoot détectera et rejettera l'attaque de régression.

Le compteur NV est également implémenté dans la zone OTP étendue. La version sécurisée varie de 0 à 127, ce qui signifie que vous pouvez avoir jusqu'à 127 versions de sécurité pour corriger les bogues de sécurité.

SEBoot

SEBoot est le chargeur de démarrage de première étape juste après le RBL (ROM Boot Loader), par exemple le CPU. Il est signé avec la clé racine Siemens et est validé par le RBL. Pendant le démarrage, la tâche principale du SEBoot est de valider l'image de l'étape ultérieure qui est signée avec la clé client. SEBoot empêche également les attaques de régression en comparant la version sécurisée de l'image et celle définie dans l'OTP.

Remarque
Pour l'IOT2050, le SEBoot doit être le chargeur de démarrage de première étape. Sinon, l'appareil refuse de démarrer.

Exemple de démarrage sécurisé pour IOT2050

Implémentation de l'exemple de démarrage sécurisé pour IOT2050

En fonction de l'infrastructure fournie, vous pouvez implémenter le démarrage sécurisé pour IOT2050 de plusieurs manières.

Prérequis

• une machine Linux est prête
• le dépôt meta-iot2050 est cloné
• Deux supports de stockage, carte SD ou clé USB, conviennent
• Une image de construction, elle peut être stockée sur une carte SD ou une clé USB

Procédures

1. Générez les paires de clés RSA.
   Remarque
   Siemens recommande d'utiliser au moins deux jeux de clés, par exemple MPK et SMPK.
   openssl req -x509 -newkey rsa: 4096 -keyout custMpk.pem -nodes outform pem -out custMpk.crt -sha256 -days 3650
openssl req -x509 -newkey rsa: 4096 -keyout custSmpk.pem -nodes outform pem -out custSmpk.crt -sha256 -days 3650
# only if you want to have the third key
# openssl req -x509 -newkey rsa: 4096 -keyout custBmpk.pem -nodes outform pem -out custBmpk.crt -sha256 -days 3650
2. Supprimez les jeux de clés de démonstration existants dans <path-meta-iot2050>/recipes-bsp/secureboot-otp-provisioning/files/keys.
   rm -rf <path-meta-iot2050>/recipes-bsp/secure-boot-otpprovisioning/files/keys/*
   Remarque
   Conservez les clés privées en toute sécurité. Ne commettez pas vos clés dans le dépôt git.
3. Copiez les fichiers *.pem et *.crt générés vers <path-meta-iot2050>/recipes-bsp/secure-boot-otpprovisioning/files/keys
   cp *.pem <path-meta-iot2050>/recipes-bsp/secure-boot-otpprovisioning/files/keys/
cp *.crt <path-meta-iot2050>/recipes-bsp/secure-boot-otpprovisioning/files/keys/
4. Construisez le firmware et l'image OS signés :
   cd <path-meta-iot2050>
./kas-container build kas-iot2050-boot-pg2.yml: kas/opt/secureboot.yml: kas/opt/otpcmd/key-provision.yml
./kas-container build kas-iot2050-swupdate.yml: kas/opt/secureboot.yml
   Remarque
   Avant de construire les images signées, assurez-vous que le certificat de la clé de signature est valide. Renouvelez le certificat s'il est expiré.
   • Le firmware signé généré se trouve à l'emplacement <path-metaiot2050>/build/tmp/deploy/images/iot2050/iot2050-pg2-imageboot.bin
   • L'image OS signée générée se trouve à l'emplacement <path-metaiot2050>/build/tmp/deploy/images/iot2050/iot2050-image-swu-example-iot2050debian-iot2050.wic.img.
5. Insérez un support de stockage dans la machine de construction et copiez-y le fichier iot2050-pg2-imageboot.bin généré.
6. Insérez le support de stockage de l'étape 5 dans l'IOT2050 et démarrez l'IOT2050 avec l'image de démarrage que vous avez préparée.
7. Connectez la machine de construction et l'IOT2050 avec un câble UART, entrez dans le shell et exécutez les commandes suivantes pour programmer la flash.
   iot2050-firmware-update -f iot2050-pg2-image-boot.bin
8. Éteignez l'IOT2050 et retirez l'image d'exemple.
9. Allumez l'IOT2050 et entrez "yes" (oui) pour programmer les clés dans l'OTP lorsque le message d'invite apparaît.
   Remarque
   Une fois le démarrage sécurisé activé, vous ne pouvez plus programmer de nouvelle clé dans l'OTP, même si un emplacement vide existe dans l'OTP.
   Remarque
   Une fois le démarrage sécurisé activé, pour améliorer la sécurité, la console u-boot est désactivée.
10. Insérez un autre support de stockage dans la machine de construction et créez le support de démarrage avec l'image OS signée à l'aide de la commande suivante.
    dd if=<path-meta-iot2050>/build/tmp/deploy/images/iot2050/iot2050image-swu-example-iot2050-debian-iot2050.wic.img \ of=/dev/<device-name> bs=100M oflag=direct status=progress
11. Insérez le support de démarrage avec l'image OS signée et démarrez l'IOT2050.
    Résultat : L'image du firmware et l'image OS sont toutes deux signées et validées par l'ensemble de clés généré.

Vérifier l'implémentation de l'exemple

L'implémentation de l'exemple est basée sur la configuration du firmware et de l'image d'exemple fournie dans <path-meta-iot2050>.

L'image du firmware signée comprend :

• SEBoot
• TF-A signé
• OPTee signé
• U-Boot signé
• Données de programmation OTP

L'image OS signée contient une image PE de noyau signée, qui comprend le noyau, les blobs d'arbre de périphériques, le paramètre de ligne de commande du noyau et un ramdisk. Le système de fichiers comprend :

• La partition système EFI contient le chargeur de démarrage EFI Boot Guard
• Les partitions de démarrage contiennent les images PE de noyau signées
• Système de fichiers racine monté comme /usr
• Système de fichiers en lecture/écriture monté comme /var
• Système de fichiers en lecture/écriture monté comme /home

Séquence de démarrage
Toutes les validations d'image mentionnées utilisent le même jeu de clés que celui programmé dans la zone OTP.

1. Après la mise sous tension de l'appareil, le SEBoot valide l'image combinée de TF-A, OPTee et U-Boot SPL.
2. U-Boot SPL valide U-Boot proper, puis U-Boot proper valide l'EFI Boot Guard.
3. EFI Boot Guard valide l'image PE du noyau.
   Les étapes 1 et 2 utilisent principalement le démarrage vérifié et le certificat X.509, et l'étape 3 utilise principalement le démarrage sécurisé UEFI.

Jeux de clés et clés utilisés dans l'implémentation de l'exemple

• Les jeux de clés pour la programmation OTP : <path-metaiot2050>/recipes-bsp/secureboot-otp-provisioning/files/keys.
  Ces clés sont destinées à être programmées dans la zone OTP.
• Le jeu de clés pour la signature et la validation de U-Boot (à la fois U-Boot SPL et U-Boot proper) :
  <path-meta-iot2050>/recipes-bsp/u-boot/files/keys
  Ce sont des liens symboliques vers les clés OTP.
• Le jeu de clés pour la signature et la validation dans le démarrage sécurisé UEFI, c'est-à-dire EFI Boot Guard et le noyau :
  <path-meta-iot2050>/recipes-devtools/secure-bootsecrets/files
  Ce sont également des liens symboliques vers les clés OTP.

Dans l'implémentation de l'exemple, un même jeu de clés est utilisé pour signer et valider toutes les chaînes de démarrage. Cependant, vous pouvez utiliser différentes clés pour différentes étapes de validation, à condition que :

• La clé utilisée par SEBoot pour valider l'image combinée TFA/OPTee/U-Boot SPL doit être identique à la clé OTP actuellement utilisée.
• Avec le binaire de l'image, la clé utilisée pour valider le binaire de l'image de l'étape suivante doit être validée par rapport à la clé de l'étape précédente. Et lorsque le binaire de l'image de l'étape actuelle est validé et démarré, la validation du binaire de l'image de l'étape suivante par rapport à la clé validée commence.

Exemple de noyau

L'implémentation de référence comporte sept partitions.

Remarque
Comme /usr est monté en lecture seule et validé, /usr ne peut être mis à jour qu'avec SWUpdate. Les commandes, telles que apt install et upgrade, ne sont pas autorisées.

Sujets avancés sur le démarrage sécurisé

Approvisionnement des clés
L'implémentation d'exemple utilise deux ensembles de clés par défaut. Vous pouvez l'ajuster selon vos besoins. Par exemple, si vous avez besoin de trois ensembles de clés, créez la troisième clé et placez-la dans le répertoire meta-iot2050.
cd <path-meta-iot2050>
./kas-container build kas-iot2050-boot-pg2.yml: kas/opt/secureboot.yml: kas/opt/otpcmd/key-provision-3keys.yml

Traitement des incidents : clé divulguée
Lorsque la clé en cours d'utilisation est divulguée, vous pouvez passer à l'ensemble de clés suivant comme suit :

1. Copiez ou liez la nouvelle clé vers<path-meta-iot2050>/recipes-bsp/u-boot/files/keys/custMpk...
2. Construisez le nouveau micrologiciel signé avec la clé ainsi que les données otpcmd de commutation de clé.
   cd <path-meta-iot2050>
./kas-container build kas-iot2050-boot-pg2.yml: kas/opt/secureboot.yml: kas/opt/otpcmd/key-switch.yml

Méthode TUI
Lorsque la clé en cours d'utilisation est divulguée, vous pouvez également passer à l'ensemble de clés suivant avec TUI.
cd <path-meta-iot2050>
./kas-container menu

1. Définissez Firmware image for PG2 devices (Image du micrologiciel pour les appareils PG2) comme Image type (Type d'image)
2. Cochez Secure Boot and OTP provisioning (Démarrage sécurisé et approvisionnement OTP) dans Image features (Fonctionnalités de l'image)
3. Sélectionnez OTP provisioning command type (Type de commande d'approvisionnement OTP)
4. Vérifiez votre sélection dans generated.config.yaml.

Traitement des incidents : version sécurisée
Dans l'implémentation d'exemple, vous pouvez définir la version sécurisée comme suit.

1. Exécutez la commande suivante.
   cd <path-meta-iot2050>
./kas-container menu
2. Définissez Firmware image for PG2 devices (Image du micrologiciel pour les appareils PG2) comme Image type (Type d'image), et définissez Secure Boot (Démarrage sécurisé) comme Image features (Fonctionnalités de l'image).
3. Définissez une valeur plus élevée pour Use specific firmware secure version (Utiliser une version sécurisée de micrologiciel spécifique) sous Build options (Options de compilation).
   Vous devez définir une valeur supérieure à l'ancienne valeur lorsque vous devez incrémenter la version sécurisée pour corriger un bogue de sécurité. Par exemple : si la version sécurisée actuellement utilisée est 3, vous devez utiliser 4 comme nouvelle version sécurisée.
4. Naviguez vers Save & Build (Sauvegarder et compiler) et appuyez sur Enter (Entrée).

Remarque
Seul SEBoot vérifie la version sécurisée pour valider l'image conteneur tispl. En remplaçant l'image conteneur tispl, une nouvelle chaîne de démarrage sécurisé pourrait être établie pour le reste. Cette chaîne de démarrage sécurisé peut empêcher les attaques par rétrogradation pour ces autres images.

Politique de sécurité de SEBoot
SEBoot définit trois politiques de sécurité pour différents états sécurisés :

¹ Vous pouvez définir l'appareil sur la politique souple comme une dernière vérification pour s'assurer que tout fonctionne comme prévu avant d'activer le démarrage sécurisé.

Remarque
L'état sécurisé par défaut de SEBoot est "aucune".

Système d'avis d'avertissement

Ce manuel contient des avis que vous devez respecter afin d'assurer votre sécurité personnelle et de prévenir les dommages matériels. Les avis concernant votre sécurité personnelle sont mis en évidence dans le manuel par un symbole d'alerte de sécurité ; les avis ne concernant que les dommages matériels n'ont pas de symbole d'alerte de sécurité. Ces avis présentés ci-dessous sont classés selon le degré de danger.

indique qu'un décès ou des blessures corporelles graves surviendront si les précautions appropriées ne sont pas prises.

indique qu'un décès ou des blessures corporelles graves peuvent survenir si les précautions appropriées ne sont pas prises.

indique que des blessures corporelles mineures peuvent survenir si les précautions appropriées ne sont pas prises.

AVIS :
indique que des dommages matériels peuvent survenir si les précautions appropriées ne sont pas prises.

Si plusieurs degrés de danger sont présents, l'avis d'avertissement représentant le degré de danger le plus élevé sera utilisé. Un avis avertissant de blessures aux personnes avec un symbole d'alerte de sécurité peut également inclure un avertissement relatif aux dommages matériels.

Personnel qualifié
Le produit/système décrit dans cette documentation ne doit être utilisé que par du **personnel qualifié** pour la tâche spécifique, conformément à la documentation pertinente, en particulier ses avis d'avertissement et ses instructions de sécurité. Le personnel qualifié est celui qui, en fonction de sa formation et de son expérience, est capable d'identifier les risques et d'éviter les dangers potentiels lors de l'utilisation de ces produits/systèmes.

Références

• Industrial Cybersecurity - Siemens Global
• CERT Services - Siemens Global

Télécharger le manuel

Ici, vous pouvez télécharger la version PDF complète du manuel. Elle peut contenir des instructions de sécurité supplémentaires, des informations de garantie, des règles de la FCC, etc.

Télécharger Manuel Siemens IOT2050

Les langues disponibles