Comprendre le magasin de clés de sécurité

Objectif : Explorer les fichiers situés dans le magasin de clés de sécurité ROS 2.

Niveau du didacticiel : Avancé

Durée : 15 minutes

Arrière-plan

Le package sros2 peut être utilisé pour créer des clés, des certificats et des politiques nécessaires pour activer la sécurité ROS 2. Cependant, la configuration de la sécurité est extrêmement flexible. Une compréhension de base du magasin de clés de sécurité ROS 2 permettra l’intégration avec une PKI (infrastructure de clé publique) existante et la gestion des éléments clés sensibles conformément aux politiques organisationnelles.

Emplacements des artefacts de sécurité

Avec la sécurité des communications activée dans le didacticiel précédent, examinons les fichiers qui ont été créés lorsque la sécurité a été activée. Ce sont les fichiers qui rendent le cryptage possible.

Les utilitaires sros2 (ros2 security ...) séparent les fichiers en clés publiques, privées et enclavées.

ROS utilise le répertoire défini par la variable d’environnement ROS_SECURITY_KEYSTORE comme keystore. Pour ce tutoriel, nous utilisons le répertoire ~/sros2_demo/demo_keystore.

Matériel de clé publique

Vous trouverez trois certificats de chiffrement dans le répertoire public à ~/sros2_demo/demo_keys/public ; cependant, les certificats d’identité et d’autorisations ne sont en fait qu’un lien vers le certificat de l’autorité de certification (CA).

Dans une infrastructure à clé publique, l”autorité de certification agit comme une ancre de confiance : elle valide les identités et les autorisations des participants. Pour ROS, cela signifie tous les nœuds qui participent au graphe ROS (qui peut s’étendre à toute une flotte de robots individuels). En plaçant le certificat de l’autorité de certification (ca.cert.pem) à l’emplacement approprié sur le robot, tous les nœuds ROS peuvent établir une confiance mutuelle avec d’autres nœuds utilisant la même autorité de certification.

Bien que dans nos didacticiels, nous créons une autorité de certification à la volée, dans un système de production, cela doit être fait selon un plan de sécurité prédéfini. Généralement, l’autorité de certification d’un système de production est créée hors ligne et placée sur le robot lors de la configuration initiale. Il peut être unique pour chaque robot, ou partagé par une flotte de robots tous destinés à se faire confiance.

DDS (et ROS, par extension) prend en charge la séparation des chaînes de confiance d’identité et d’autorisation, de sorte que chaque fonction a sa propre autorité de certification. Dans la plupart des cas, un plan de sécurité du système ROS ne nécessite pas de séparation entre ces tâches, de sorte que les utilitaires de sécurité génèrent une seule autorité de certification qui est utilisée à la fois pour l’identité et les autorisations.

Utilisez openssl pour afficher ce certificat x509 et l’afficher sous forme de texte :

cd ~/sros2_demo/demo_keys/public
openssl x509 -in ca.cert.pem -text -noout

La sortie doit ressembler à ce qui suit : :

Certificate:
  Data:
      Version: 3 (0x2)
      Serial Number:
          02:8e:9a:24:ea:10:55:cb:e6:ea:e8:7a:c0:5f:58:6d:37:42:78:aa
      Signature Algorithm: ecdsa-with-SHA256
      Issuer: CN = sros2testCA
      Validity
          Not Before: Jun  1 16:57:37 2021 GMT
          Not After : May 31 16:57:37 2031 GMT
      Subject: CN = sros2testCA
      Subject Public Key Info:
          Public Key Algorithm: id-ecPublicKey
              Public-Key: (256 bit)
              pub:
                  04:71:e9:37:d7:32:ba:b8:a0:97:66:da:9f:e3:c4:
                  08:4f:7a:13:59:24:c6:cf:6a:f7:95:c5:cd:82:c0:
                  7f:7f:e3:90:dd:7b:0f:77:d1:ee:0e:af:68:7c:76:
                  a9:ca:60:d7:1e:2c:01:d7:bc:7e:e3:86:2a:9f:38:
                  dc:ed:39:c5:32
              ASN1 OID: prime256v1
              NIST CURVE: P-256
      X509v3 extensions:
          X509v3 Basic Constraints: critical
              CA:TRUE, pathlen:1
  Signature Algorithm: ecdsa-with-SHA256
       30:45:02:21:00:d4:fc:d8:45:ff:a4:51:49:98:4c:f0:c4:3f:
       e0:e7:33:19:8e:31:3c:d0:43:e7:e9:8f:36:f0:90:18:ed:d7:
       7d:02:20:30:84:f7:04:33:87:bb:4f:d3:8b:95:61:48:df:83:
       4b:e5:92:b3:e6:ee:3c:d5:cf:30:43:09:04:71:bd:dd:7c
Quelques points à noter à propos de ce certificat CA :

  • Le nom du sujet du certificat sros2testCA est la valeur par défaut fournie par les utilitaires sros2.

  • Ce certificat est valable dix ans à compter de sa création

  • Comme tous les certificats, celui-ci contient une clé publique utilisée pour le chiffrement à clé publique-privée

  • En tant qu’autorité de certification racine, il s’agit d’un certificat auto-signé ; c’est-à-dire qu’il est signé à l’aide de sa propre clé privée.

Comme il s’agit d’un certificat public, il peut être librement copié selon les besoins pour établir la confiance dans l’ensemble de votre système ROS.

Matériel de clé privée

Les éléments de clé privée peuvent être trouvés dans le répertoire keystore ~/sros2_demo/demo_keys/private. Semblable au répertoire public, celui-ci contient une clé d’autorité de certification ca.key.pem et des liens symboliques vers celle-ci à utiliser à la fois comme clé privée d’identité et de permission de l’autorité de certification.

Avertissement

Protégez cette clé privée et créez-en une sauvegarde sécurisée !

Il s’agit de la clé privée associée à l’autorité de certification publique qui sert de point d’ancrage pour toute la sécurité de votre système ROS. Vous l’utiliserez pour modifier les politiques de chiffrement du graphe ROS et pour ajouter de nouveaux participants ROS. En fonction des besoins de sécurité de votre robot, la clé peut être protégée par des autorisations d’accès et verrouillée sur un autre compte, ou elle peut être entièrement déplacée du robot vers un autre système ou appareil. Si le fichier est perdu, vous ne pourrez pas modifier les autorisations d’accès et ajouter de nouveaux participants au système. De même, tout utilisateur ou processus ayant accès au fichier a la possibilité de modifier les politiques système et les participants.

Ce fichier n’est requis que pour configurer le robot, mais n’est pas nécessaire pour que le robot fonctionne. Il peut être stocké en toute sécurité hors ligne dans un autre système ou sur un support amovible.

Les utilitaires sros2 utilisent la cryptographie à courbe elliptique plutôt que RSA pour une sécurité améliorée et une taille de clé réduite. Utilisez la commande suivante pour afficher les détails de cette clé privée de courbe elliptique :

cd ~/sros2_demo/demo_keys/private
openssl ec -in ca.key.pem -text -noout

Votre sortie devrait ressembler à ce qui suit : :

read EC key
Private-Key: (256 bit)
priv:
    93:da:76:b9:e3:91:ab:e9:42:76:f2:38:f1:9d:94:
    90:5e:b5:96:7b:7f:71:ee:13:1b:d4:a0:f9:48:fb:
    ae:77
pub:
    04:71:e9:37:d7:32:ba:b8:a0:97:66:da:9f:e3:c4:
    08:4f:7a:13:59:24:c6:cf:6a:f7:95:c5:cd:82:c0:
    7f:7f:e3:90:dd:7b:0f:77:d1:ee:0e:af:68:7c:76:
    a9:ca:60:d7:1e:2c:01:d7:bc:7e:e3:86:2a:9f:38:
    dc:ed:39:c5:32
ASN1 OID: prime256v1
NIST CURVE: P-256

En plus de la clé privée elle-même, notez que la clé publique est répertoriée et qu’elle correspond à la clé publique répertoriée dans l’autorité de certification ca.cert.pem.

Politique de gouvernance de domaine

Recherchez la politique de gouvernance du domaine dans le répertoire enclave du magasin de clés, ~/sros2_demo/demo_keys/enclaves. Le répertoire enclave contient le document de politique de gouvernance XML governance.xml, ainsi qu’une copie du document qui a été signé par l’autorité de certification des autorisations en tant que governance.p7s.

Le fichier governance.p7s contient des paramètres à l’échelle du domaine tels que la façon de gérer les participants non authentifiés, de crypter ou non la découverte et les règles par défaut pour l’accès aux rubriques.

Utilisez la commande suivante pour valider la signature S/MIME du fichier de gouvernance :

openssl smime -verify -in governance.p7s -CAfile ../public/permissions_ca.cert.pem

Cette commande imprimera le document XML et la dernière ligne sera Verification réussie pour montrer que le document a été correctement signé par l’autorité de certification des autorisations.

Enclaves de sécurité

Les processus sécurisés (généralement des nœuds ROS) s’exécutent dans une enclave de sécurité. Dans le cas le plus simple, tous les processus peuvent être regroupés dans la même enclave, et tous les processus utiliseront alors la même politique de sécurité. Cependant, pour appliquer différentes politiques à différents processus, les processus peuvent utiliser différentes enclaves de sécurité lors du démarrage. Pour plus de détails sur les enclaves de sécurité, consultez le document de conception. L’enclave de sécurité est spécifiée en utilisant l’argument ROS --enclave lors de l’exécution d’un nœud.

Chaque enclave de sécurité nécessite six fichiers pour activer la sécurité. Chaque fichier doit être nommé comme défini ci-dessous et comme indiqué dans la norme de sécurité DDS . Afin d’éviter d’avoir plusieurs copies des mêmes fichiers, les utilitaires sros2 créent des liens pour chaque enclave vers la politique de gouvernance unique, l’AC d’Identité et l’AC de Permissions décrites ci-dessus.

Voir les six fichiers suivants dans l’enclave listener. Trois sont spécifiques à cette enclave, tandis que trois sont génériques à ce système ROS :

  • key.pem, la clé privée utilisée pour chiffrer et déchiffrer dans cette enclave

  • cert.pem, le certificat public pour cette enclave ; ce certificat a été signé par l’Identity CA

  • permissions.p7s, les permissions pour cette enclave ; ce fichier a été signé avec le Permissions CA

  • governance.p7s, un lien vers le fichier de politique de sécurité signé pour ce domaine

  • identity_ca.cert.pem, un lien vers l’Identity CA pour ce domaine

  • permissions_ca.cert.pem, un lien vers l’autorité de certification des autorisations pour ce domaine

La clé de chiffrement privée key.pem doit être protégée conformément à votre plan de sécurité. Cette clé chiffre, déchiffre et valide les communications au sein de cette enclave spécifique. En cas de perte ou de vol de la clé, révoquez la clé et créez une nouvelle identité pour cette enclave.

Le fichier permissions.xml a également été créé dans ce répertoire et peut être utilisé pour recréer le fichier des permissions signées. Cependant, ce fichier n’est pas requis pour activer la sécurité car DDS utilise à la place la version signée du fichier.

Fais le quiz!

Voyez si vous pouvez répondre à ces questions sur le magasin de clés de sécurité ROS. Commencez par une nouvelle session de terminal et activez la sécurité avec le keystore créé dans le tutoriel précédent :

export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keys
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce

cd ~/sros2_demo/demo_keys/enclaves/talker_listener/listener

Faites une copie de sauvegarde de permissions.p7s avant de commencer.

Ouvrez permissions.p7s dans un éditeur de texte. Apportez une modification négligeable au contenu XML (par exemple, ajoutez un espace ou une ligne vide) et enregistrez le fichier. Lancez le nœud d’écoute :

ros2 run demo_nodes_cpp listener --ros-args --enclave /talker_listener/listener

Qu’attendez-vous qu’il se passe ?

Pouvez-vous lancer le nœud de locuteur ?

ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker

Quelle est la différence entre lancer le listener et lancer le talker ?

Quelle commande vous permet de vérifier si la signature du fichier permissions.p7s modifié est valide ?

Restaurez votre fichier permissions.p7s d’origine correctement signé avant de passer au didacticiel suivant.