IBM Cloud Docs
Cryptographie à sécurité quantique dans TLS

Cryptographie à sécurité quantique dans TLS

Vous pouvez utiliser une connexion TLS post-quantique pour envoyer des demandes à un Nœud final de service IBM® Key Protect for IBM Cloud®.

Qu'est-ce que la cryptographie à sécurité quantique ?

La cryptographie à sécurité quantique, également connue sous le nom de cryptographie post-quantique, est une nouvelle génération du système cryptographique à clé publique qui fait l'objet d'une évaluation par le NIST. Ces nouveaux algorithmes cryptographiques quantiques reposent sur des problèmes mathématiques complexes que, d'après les recherches actuelles, même les grands ordinateurs quantiques ne peuvent pas résoudre.

Lorsque ces algorithmes cryptographiques quantiques sont utilisés pour la communication TLS, la sécurité de l'échange de clés publiques entre le client et le serveur est censée avoir des niveaux de sécurité plus élevés que les algorithmes RSA et ECC actuels. Cependant, le NIST n'a pas normalisé les algorithmes et, jusque-là, Key Protect a adopté une méthode hybride qui combine les algorithmes à sécurité quantique et les algorithmes ECC actuels pour protéger les données en transit.

Pourquoi Quantum Safe TLS est-il important ?

Au fur et à mesure que l'informatique quantique évolue et progresse, un grand ordinateur quantique sera capable d'exécuter l'algorithme "algorithme "SHOR qui peut casser les algorithmes de communication TLS actuels (RSA/ECC) en quelques minutes minutes. Bien que les grands ordinateurs quantiques ne soient pas disponibles aujourd'hui, toutes les données TLS en transit qui ont été fouillées et stockées peuvent être violées lorsque ces grands ordinateurs quantiques sont mis à disposition. Les données ont une longue durée de vie. Il est donc essentiel que Key Protectprenne en charge les algorithmes cryptographiques à sécurité quantique pour sécuriser les communications TLS.

Pour préserver la résilience de vos données en transit, Key Protect a introduit la possibilité d'utiliser une connexion TLS post-quantique garantissant la sécurisation de vos données lors du processus d'échange de clés.

Quelles sont les considérations relatives à la cryptographie à sécurité quantique ?

Avant de configurer votre service pour envoyer des demandes à Key Protect via un nœud final de service post-quantique Key Protect, gardez à l'esprit les considérations suivantes :

  • Le National Institute for Standards and Technology (NIST) est en train de normaliser les algorithmes de sécurité quantique. Le NIST évalue actuellement les approches candidates à la cryptographie quantique sûre et ne devrait pas achever le processus de normalisation et ne devrait pas achever le processus de normalisation avant 2023 qu'après 2023. Key Protect utilise l' algorithme Kyber, qui est l'un des candidats du troisième tour en cours d'évaluation. Si les recherches du NIST révèlent que l'algorithme Kyber n'est pas à sécurité quantique, le mécanisme d'échange de clés est toujours protégé par les algorithmes TLS classiques lors de l'utilisation de l'algorithme Kyber en mode hybride.

  • Les résultats de performance peuvent différer de ceux des algorithmes de clés classiques. L'algorithme de sécurité quantique utilise une taille de clé plus grande que les algorithmes à clé publique classiques Les exigences de bande passante du réseau sont donc plus élevées. Les performances de l'algorithme de sécurité quantique peuvent également être affectées par le profil réseau, la vitesse de l'unité centrale et les taux d'appel de l'API.

  • Quantum Safe TLS protège uniquement les données en transit, pas les données au repos. Les algorithmes de sécurité post-quantique utilisés par Key Protect protègent vos données contre les violations lorsqu'elles sont envoyées à un nœud final de service Key Protect. Les clés racine importées (y compris leur contenu associé) sont chiffrées par les clés de session TLS. Le chiffrement des données au repos utilise des clés symétriques et les clés symétriques AES 256 sont à l'abri des attaques informatiques quantiques de grande envergure.

  • Key Protect prend uniquement en charge Quantum Safe TLS pour les plateformes Linux. Key Protect fournira à l'avenir une prise en charge de Quantum Safe TLS à d'autres systèmes d'exploitation.

  • Quantum Safe TLS est pris en charge uniquement via le kit de développement de logiciels (SDK) Key Protect. La prise en charge TLS post-quantique (Quantum safe TLS) sera ajoutée à l(interface de ligne de commande Key Protect (CLI) à l'avenir. Pour en savoir plus sur l'accès au kit de développement de logiciels (SDK) Key Protect, consultez Configuration du SDK.

Utilisation de Quantum Safe TLS avec Key Protect

Vous pouvez choisir entre des modes de connexion TLS post-quantiques hybrides et non hybrides lors de l'envoi de demandes à Key Protect.

Mode Quantum Safe et mode hybride

Key Protect prend en charge deux modes de protection de vos clés lors d'une connexion TLS : le mode Quantum Safe et le mode hybride.

  • Mode hybride : Le mode hybride utilise une combinaison d'un algorithme post-quantique et d'algorithmes classiques d'échange de clés pour protéger vos données pendant le transit. Lorsque vous émettez une demande à l'aide de ce mode, l'algorithme elliptique classique et l'algorithme de sécurité post-quantique sont utilisés dans un mécanisme d'échange de clés pour protéger vos données par cryptographie lors de leur transmission vers le du service Key Protect.

    Le mode hybride prend en charge l'algorithme hybride Kyber avec les ensembles de paramètres suivants (taille des clés) :

    • p256_kyber512 : combine kyber512 avec ECDH à l'aide de la courbe p_256. Fournit la sécurité L1.
    • p384_kyber768 : combine kyber768 avec ECDH à l'aide de la courbe p_384. Fournit la sécurité L3.
    • p521_kyber1024 : combine kyber1024 avec ECDH à l'aide de la courbe p_521. Fournit la sécurité L5.

L'algorithme hybride est utilisé conformément aux directives de la communauté de projet Open Quantum Safe (OQS). Pour plus d'informations sur l'algorithme et les tailles de clés associées, voir tailles de clés associées, voir Prototypage de l'échange de clés post-quantique et hybride.

  • **Mode post-quantique (Quantum Safe) **: Le mode de sécurité post-quantique utilise un algorithme post-quantique pour protéger vos données en transit. Lorsque vous émettez une demande à l'aide de ce mode, l'algorithme post-quantique est utilisé dans un mécanisme d'échange de clés pour protéger vos données par cryptographie lors de leur transmission vers le du service Key Protect.

    Le mode Quantum Safe prend en charge l'algorithme Kyber avec les ensembles de paramètres suivants (taille des clés) :

    • kyber512
    • kyber768
    • kyber1024

L'algorithme Kyber est utilisé conformément aux directives de IBM Cloud. Pour en savoir plus sur l'algorithme et ses tailles de clés associées, voir CRYSTAUX-Kyber.

Nœuds finaux compatibles Quantum Safe

IBM® Key Protect for IBM Cloud® comportent des nœuds finaux compatibles avec Quantum Safe pour 2 régions : US-South et EU-GB. Consultez le tableau suivant pour déterminer quels nœuds finaux compatibles Quantum Safe utiliser lors de l'envoi de demandes au service IBM® Key Protect for IBM Cloud®.

Région Nœuds finaux publics
Dallas qsc.us-south.kms.cloud.ibm.com
Londres qsc.eu-gb.kms.cloud.ibm.com
Francfort qsc.eu-de.kms.cloud.ibm.com
Liste des points de terminaison privés sécurisés quantiques pour interagir avec Key Protect Sur le réseau privé d'IBM Cloud
Région Nœuds finaux privés
Dallas private-qsc.us-south.kms.cloud.ibm.com
Londres private-qsc.eu-gb.kms.cloud.ibm.com
Francfort private-qsc.eu-de.kms.cloud.ibm.com

Les nœuds finaux de service Key Protect classiques ne sont pas compatibles avec Quantum Safe.

Configuration de Quantum Safe TLS avec Key Protect via le SDK

Prérequis

Avant de configurer votre application pour utiliser le SDK, procédez comme suit :

  1. Télécharger le script Le script Open Quantum Safe Software Stack(OQSSA). Ce script va générer et installer toutes les dépendances nécessaires (liboqs, opensslet libcurl) dans votre dossier de répertoire HOME ($HOME/opt/oqssa/).

  2. Assurez-vous que les packages dépendants requis pour la génération d'OQSSA sont installés. Vous devez disposer des droits sudo pour installer les packages de dépendance.

    • Dépendances Debian (Ubuntu) : libtool automake autoconf cmake (3.5 or above) make openssl libssl-dev build-essential git wget golang (1.14 or above) patch perl diffutils

    Si vous utilisez une distribution Debian, copiez le fragment de code suivant dans un fichier et exécutez-le pour vérifier que tous les packages nécessaires ont été installés :

    echo "Starting prerequisites verification"
    CMAKE_VER_REQUIRED="3.*"
    packages="libtool automake autoconf cmake make openssl libssl-dev git wget build-essential golang patch perl diffutils"
    for REQUIRED_PKG in $packages
    do
        PKG_STATUS=$(dpkg-query -W --showformat='${Version},${Status}\n' $REQUIRED_PKG|grep "install ok installed")
        if [ "" = "$PKG_STATUS" ]
        then
          echo "$REQUIRED_PKG is NOT installed"
          #sudo apt-get -y install $REQUIRED_PKG
        else
          PKG_VER=$(echo $PKG_STATUS| cut -d',' -f 1)
          if [ "cmake" == $REQUIRED_PKG ]  && ! [[ $PKG_VER =~ $CMAKE_VER_REQUIRED ]]
          then
            echo "$REQUIRED_PKG Version is: $PKG_VER. OQSSA requires cmake 3.5 and above."
          fi
        fi
    done
    echo "Prerequisites verification completed"
    
    • Dépendances RHEL (Centos/Fedora) : libtool automake autoconf cmake (3.5 or above) make openssl ncurses-devel gcc-c++ glibc-locale-source glibc-langpack-enopenssl-devel git wget golang (1.14 or above) patch perl diffutils 'Developement Tools'

    Si vous utilisez une distribution RHEL, copiez le fragment de code suivant dans un fichier et exécutez-le pour vérifier que tous les packages nécessaires ont été installés :

    echo "Starting prerequisites verification"
    CMAKE_VER_REQUIRED="3.*"
    packages="git libtool automake autoconf cmake make openssl  ncurses-devel gcc-c++ openssl-devel wget glibc-locale-source glibc-langpack-en sudo golang patch perl diffutils"
    for REQUIRED_PKG in $packages
    do
        PKG_STATUS=$(rpm -q --qf '%{VERSION},%{INSTALLTIME}\n' $REQUIRED_PKG)
        if [[ "$PKG_STATUS" == *"not installed"* ]];
        then
        echo "$REQUIRED_PKG is NOT installed"
        #sudo yum -y install $REQUIRED_PKG
        else
          PKG_VER=$(echo $PKG_STATUS| cut -d',' -f 1)
          if [ "cmake" == $REQUIRED_PKG ]  && ! [[ $PKG_VER =~ $CMAKE_VER_REQUIRED ]]
          then
            echo "$REQUIRED_PKG Version is: $PKG_VER. OQSSA requires cmake 3.5 and above."
          fi
        fi
    done
    PKG_STATUS=$(yum grouplist Dev* |grep "Development Tools")
    if [ "" = "$PKG_STATUS" ]
    then
        echo "Developement Tools is NOT installed"
    fi
    echo "Prerequisites verification completed"
    
  3. Une fois les packages prérequis installés et vérifiés, exécutez le script pour générer et installer OQSSA :

    bash build-oqssa.sh
    
  4. Exécutez la commande suivante pour définir le chemin de la bibliothèque Quantum :

    export LD_LIBRARY_PATH=$HOME/opt/oqssa/lib:$LD_LIBRARY_PATH
    

Configuration du SDK Key Protect avec votre application

Une fois les prérequis installés, procédez comme suit pour configurer le SDKKey Protect avec votre application:

  1. Accédez au dossier dans lequel réside le client go en exécutant la commande suivante :

        cd $HOME/keyprotect-go-client
    
  2. Définissez l'algorithme Kyber lors de l'initialisation de Client Key Protect dans votre code d'application. Si vous n'indiquez pas d'algorithme, votre application utilise par défaut l'algorithme p384_kyber768. Utilisez le code suivant comme exemple de configuration d'algorithme :

    qscConfig := kp.ClientQSCConfig{
        AlgorithmID: kp.KP_QSC_ALGO_p384_KYBER768,
    }
    
  3. Compilez le SDK Key Protect en exécutant la commande suivante :

    LD_LIBRARY_PATH=$HOME/opt/oqssa/lib PKG_CONFIG_PATH=$HOME/opt/oqssa/lib/pkgconfig go build –-tags quantum
    

Utilisation de nœuds finaux Quantum Safe Key Protect via CURL

Prérequis

Avant d'envoyer une demande curl à un nœud final post-quantique Key Protect, procédez comme suit :

  1. Télécharger le script Le script Open Quantum Safe Software Stack(OQSSA). Ce script va générer et installer toutes les dépendances nécessaires (liboqs, opensslet libcurl) dans votre dossier de répertoire HOME ($HOME/opt/oqssa/).

  2. Assurez-vous que les packages dépendants requis pour la génération d'OQSSA sont installés. Vous devez disposer des droits sudo pour installer les packages de dépendance.

    • Dépendances Debian (Ubuntu) : libtool automake autoconf cmake (3.5 or above) make openssl libssl-dev build-essential git wget golang (1.14 or above) patch perl diffutils

    Si vous utilisez une distribution Debian, copiez le fragment de code suivant dans un fichier et exécutez-le pour vérifier que tous les packages nécessaires ont été installés :

    echo "Starting prerequisites verification"
    CMAKE_VER_REQUIRED="3.*"
    packages="libtool automake autoconf cmake make openssl libssl-dev git wget build-essential golang patch perl diffutils"
    for REQUIRED_PKG in $packages
    do
        PKG_STATUS=$(dpkg-query -W --showformat='${Version},${Status}\n' $REQUIRED_PKG|grep "install ok installed")
        if [ "" = "$PKG_STATUS" ]
        then
          echo "$REQUIRED_PKG is NOT installed"
          #sudo apt-get -y install $REQUIRED_PKG
        else
          PKG_VER=$(echo $PKG_STATUS| cut -d',' -f 1)
          if [ "cmake" == $REQUIRED_PKG ]  && ! [[ $PKG_VER =~ $CMAKE_VER_REQUIRED ]]
          then
            echo "$REQUIRED_PKG Version is: $PKG_VER. OQSSA requires cmake 3.5 and above."
          fi
        fi
    done
    echo "Prerequisites verification completed"
    
    • Dépendances RHEL (Centos/Fedora) : libtool automake autoconf cmake (3.5 or above) make openssl ncurses-devel gcc-c++ glibc-locale-source glibc-langpack-enopenssl-devel git wget golang (1.14 or above) patch perl diffutils 'Developement Tools''

    Si vous utilisez une distribution RHEL, copiez le fragment de code suivant dans un fichier et exécutez-le pour vérifier que tous les packages nécessaires ont été installés :

    echo "Starting prerequisites verification"
    CMAKE_VER_REQUIRED="3.*"
    packages="git libtool automake autoconf cmake make openssl  ncurses-devel gcc-c++ openssl-devel wget glibc-locale-source glibc-langpack-en sudo golang patch perl diffutils"
    for REQUIRED_PKG in $packages
    do
        PKG_STATUS=$(rpm -q --qf '%{VERSION},%{INSTALLTIME}\n' $REQUIRED_PKG)
        if [[ "$PKG_STATUS" == *"not installed"* ]];
        then
        echo "$REQUIRED_PKG is NOT installed"
        #sudo yum -y install $REQUIRED_PKG
        else
          PKG_VER=$(echo $PKG_STATUS| cut -d',' -f 1)
          if [ "cmake" == $REQUIRED_PKG ]  && ! [[ $PKG_VER =~ $CMAKE_VER_REQUIRED ]]
          then
            echo "$REQUIRED_PKG Version is: $PKG_VER. OQSSA requires cmake 3.5 and above."
          fi
        fi
    done
    PKG_STATUS=$(yum grouplist Dev* |grep "Development Tools")
    if [ "" = "$PKG_STATUS" ]
    then
        echo "Developement Tools is NOT installed"
    fi
    echo "Prerequisites verification completed"
    
  3. Une fois les packages prérequis installés et vérifiés, exécutez le script pour générer et installer OQSSA :

    bash build-oqssa.sh
    

Demande CURL à un nœud final compatible Quantum Safe

Lors d'un appel vers le nœud final post-quantique via curl vous devrez utiliser des méthodes spécifiques pour vous assurer que la demande est traitée avec succès soit traitée avec succès. Le tableau suivant contient la liste des indicateurs requis pour effectuer une demande curl Quantum Safe.

Décrit les drapeaux nécessaires pour effectuer des requêtes curl vers le service Key Protect
Indicateur Description
-tlsv1.3 Cet indicateur force la connexion de curl à un serveur TLS v1.3.
--curves Cet indicateur précise quel algorithme post-quantique doit être utilisé dans le
Mécanisme d'échange de clés TLSv1.3. Si vous n'indiquez pas d'algorithme, l'indicateur par défaut est l'algorithme p384_kyber768.

Vous pouvez utiliser l'exemple de demande suivant pour extraire une liste de clés pour votre instance Key Protect via un nœud final post-quantique.

$ curl --tlsv1.3 --curves <qsc_algorithm> -X GET \
    "https://qsc.<region>.kms.cloud.ibm.com/api/v2/keys" \
    -H "accept: application/vnd.ibm.kms.key+json" \
    -H "authorization: Bearer <IAM_token>" \
    -H "bluemix-instance: <instance_ID>"

Remplacez les variables de votre demande conformément au tableau suivant :

Décrit les variables nécessaires pour effectuer une demande de liste de clés par l'intermédiaire d'un point de terminaison à sécurité quantique.
Variables Description
qsc_algorithm Obligatoire. Algorithme Kyber dans la taille de clé qui sera utilisée pour protéger vos données en transit.

Algorithme + tailles de clé acceptables : kyber512, kyber768, kyber1024, p256_kyber512, p384_kyber768 et p521_kyber1024.
région Obligatoire. Abréviation de la région, telle que us-south ou eu-gb, qui représente la zone géographique où réside votre instance Key Protect.

For more information, see Points d'aboutissement des services régionaux.
IAM_token Obligatoire. Votre jeton d'accès IBM Cloud. Incluez le contenu complet du jeton IAM, y compris la valeur Bearer, dans la demande cURL.

For more information, see Récupération d'un jeton d'accès.
instance_ID Obligatoire. Identificateur unique affecté à votre instance de service Key Protect.

For more information, see Récupération d'un identifiant d'instance.