Aller au contenu principal

Documentation de conformité à l'interception ANSSI R226

Objectif du document : Ce document fournit les spécifications techniques requises pour l'autorisation ANSSI R226 en vertu des articles R226-3 et R226-7 du Code pénal français pour le réseau central OmniCSCF IMS (Fonctions de contrôle de session d'appel).

Classification : Documentation de conformité réglementaire

Autorité cible : Agence nationale de la sécurité des systèmes d'information (ANSSI)

Réglementation : R226 - Protection de la vie privée des correspondances et interception légale

1. SPÉCIFICATIONS TECHNIQUES DÉTAILLÉES​

1.1 Identification du système​

Nom du produit : Réseau central OmniCSCF IMS
Type de produit : Système multimédia IP (IMS)
Fonction principale : Contrôle de session d'appel VoIP/VoLTE et livraison de services multimédias
Modèle de déploiement : Infrastructure de télécommunications sur site

Composants du réseau :

  • P-CSCF (Fonction de contrôle de session d'appel proxy)
  • E-CSCF (Fonction de contrôle de session d'appel d'urgence)
  • I-CSCF (Fonction de contrôle de session d'appel interrogative)
  • S-CSCF (Fonction de contrôle de session d'appel de service)

Ce système gère l'enregistrement, l'authentification, le routage de session et le contrôle des appels pour les réseaux de système multimédia IP (IMS). Les capacités d'interception détaillées et les caractéristiques de cryptage sont décrites dans les sections ci-dessous.

1.2 Capacités d'interception​

1.2.1 Capture d'enregistrement et d'acquisition de session​

Capture d'enregistrement SIP :

Le système CSCF traite tous les enregistrements SIP et maintient un état d'enregistrement complet :

  • Identifiants d'utilisateur :

  • Métadonnées d'enregistrement :

    • URI de contact (adresse réseau UE réelle)
    • En-tête de chemin (route de retour via P-CSCF)
    • En-tête Service-Route (route vers S-CSCF)
    • Chaîne User-Agent (identification du type d'appareil)
    • Horodatage d'expiration de l'enregistrement
    • Adresse IP source et port
    • Protocole de transport (TCP/UDP/TLS)
    • Vecteurs d'authentification (RAND, AUTN, XRES, CK, IK du HSS)

  • Informations sur la localisation du réseau :

    • En-tête P-Access-Network-Info (antenne relais, zone de localisation)
    • P-Visited-Network-ID (identification du réseau en itinérance)
    • Adresse IP reçue (source réelle)
    • Adresse P-CSCF (point d'entrée du réseau)

Capture de session d'appel :

Le S-CSCF maintient un état de dialogue SIP complet pour tous les appels actifs :

  • Identifiants de session :

    • Call-ID (identifiant de session unique)
    • URIs et tags From/To
    • Ensembles de routes pour les deux parties
    • Original-Dialog-ID (pour le suivi des interactions avec le serveur d'application)

  • Métadonnées de session :

    • Identité de l'appelant (en-tête From, P-Asserted-Identity)
    • Partie appelée (en-tête To, Request-URI)
    • Horodatage d'établissement de session
    • Horodatage de terminaison de session
    • État du dialogue (Précoce/Confirmé/Supprimé)
    • Numéros CSeq (séquençage des transactions)

  • Informations sur les médias :

    • SDP (Session Description Protocol) dans les corps de message SIP
    • Adresses des serveurs multimédias (OmniTAS)
    • Informations sur les codecs (formats audio/vidéo)
    • Points de terminaison de flux multimédia
    • Allocations de ports RTP/RTCP

Identification des appels d'urgence :

Le composant E-CSCF identifie et route les appels d'urgence :

  • Détection de numéro d'urgence (112, 911, etc.)
  • Capture de l'IMEI (Identité d'équipement mobile international)
  • Cartographie de l'IMEI vers le MSISDN (pour rappel)
  • Informations de localisation provenant de l'UE ou du réseau
  • Support du protocole HELD (HTTP-Enabled Location Delivery)
  • Destination de routage d'urgence (PSAP/AS d'urgence)

1.2.2 Stockage et traitement des données​

IMPORTANT : État en mémoire uniquement

Les composants CSCF (P-CSCF, E-CSCF, I-CSCF, S-CSCF) maintiennent toutes les données d'état en mémoire uniquement. Il n'y a aucun stockage de base de données persistant des données d'enregistrement ou de session d'appel. Tous les liaisons d'enregistrement, l'état du dialogue et les associations de sécurité IPsec sont stockés en mémoire et sont perdus lors du redémarrage du système.

Données d'enregistrement actives (en mémoire) :

Le système CSCF maintient un état en temps réel uniquement :

État d'enregistrement P-CSCF :

  • Données d'association de sécurité IPsec (paires SPI, ports, paramètres de cryptage)
  • Liaisons de contact UE et adresses réseau
  • Points de terminaison et état de tunnel IPsec
  • Périodes de validité d'enregistrement

État d'enregistrement S-CSCF :

  • Identités publiques (IMPU) et état d'enregistrement actuel
  • Liaisons de contact avec en-têtes de chemin, User-Agent, adresses reçues
  • Mappages d'identité privée (IMPI) vers identité publique
  • Profils d'utilisateur du HSS (mis en cache lors de l'enregistrement)

État de session active (en mémoire) :

Le S-CSCF maintient un état d'appel actif uniquement :

  • Identifiants d'appel (Call-ID), identités des participants (tags From/To)
  • Ensembles de routes et adresses de contact
  • État de session (Précoce/Confirmé/Terminé)
  • Informations de timing de session

Pas de CDR ni de suivi historique :

Les composants CSCF ne génèrent ni ne stockent :

  • Enregistrements de détails d'appel (CDRs)
  • Enregistrements d'appels historiques
  • Enregistrements d'enregistrement historiques
  • Suivi d'événements à long terme

Génération de CDR et suivi historique : Tous les enregistrements de détails d'appel, les données de facturation et le suivi d'appels historiques sont gérés par le TAS (Serveur d'application de téléphonie - OmniTAS), et non par les composants CSCF.

Journalisation des messages SIP/Diameter :

Les CSCF peuvent générer des journaux d'événements en temps réel à des fins opérationnelles :

  • Journalisation des messages SIP : Journalisation optionnelle des messages SIP (INVITE, REGISTER, etc.)
  • Journalisation des messages Diameter : Journalisation optionnelle des transactions Diameter (Cx, Rx, Ro)
  • Événements système : Changements de configuration, erreurs, pannes

Ces journaux sont des journaux opérationnels transitoires, pas des enregistrements d'appels persistants. La conservation des journaux est configurable et généralement à court terme (heures à jours) uniquement à des fins de débogage.

1.2.3 Capacités d'analyse​

Surveillance en temps réel :

Le panneau de contrôle web Phoenix LiveView fournit :

  • Surveillance des enregistrements :

    • Voir tous les utilisateurs enregistrés avec pagination
    • Recherche par IMPU, contact, IMPI
    • Détails d'enregistrement (contact, chemin, user-agent, expiration)
    • Capacité de désenregistrement forcé

  • Surveillance des dialogues :

    • Vue des sessions d'appel actives
    • Call-ID, URIs From/To, état, durée
    • Capacité de terminaison d'appel (envoyer BYE)
    • Actualisation automatique toutes les 5 secondes

  • État du système :

    • État des pairs Diameter (connectivité HSS, PCRF, OCS)
    • État de la passerelle frontend
    • Métriques de capacité du système
    • Capacité de tunnel IPsec (P-CSCF)

Remarque sur les données historiques :

Les composants CSCF ne maintiennent pas de données historiques. Pour les enregistrements d'appels historiques, les CDR et l'analyse des modèles de communication, les autorités d'interception légale doivent coordonner avec OmniTAS (Serveur d'application de téléphonie), qui gère toute la génération de CDR et le suivi d'appels à long terme.

Visibilité du déclenchement de services en temps réel :

Le S-CSCF traite les Critères de Filtrage Initiaux (iFC) en temps réel :

  • L'évaluation des iFC détermine quels serveurs d'application sont déclenchés pour chaque appel
  • Visibilité en temps réel sur les services invoqués
  • Décisions de routage des serveurs d'application visibles dans le flux de messages SIP

État du réseau :

  • État de connectivité HSS (interface Diameter Cx)
  • Distribution de sélection S-CSCF (I-CSCF)
  • Modèles de routage d'appels
  • Temps de réponse des serveurs d'application
  • Performance des transactions Diameter

1.3 Capacités de contre-mesure​

1.3.1 Mécanismes de protection de la vie privée​

Confidentialité des communications :

  • Tunnels IPsec : Tunnels ESP (Encapsulating Security Payload) entre l'UE et le P-CSCF

    • Cryptage : AES-CBC, AES-GCM
    • Authentification : HMAC-SHA1, HMAC-SHA256
    • Dérivation de clé à partir de IMS AKA (CK/IK du HSS)
    • Associations de sécurité par UE

  • Support TLS/TLS :

    • Support SIP sur TLS (SIPS)
    • Diameter sur TLS (connexions HSS, PCRF, OCS)
    • Authentification basée sur des certificats
    • Confidentialité parfaite à l'avance (PFS) via ECDHE/DHE

  • En-têtes de confidentialité SIP :

    • P-Asserted-Identity (ID d'appelant authentifié)
    • En-tête de confidentialité (demande de suppression de l'ID d'appelant)
    • Support de session anonyme

Contrôle d'accès :

  • Authentification et contrôle d'accès de l'interface web
  • Interface BINRPC pour le panneau de contrôle (port 2046)
  • Contrôles d'accès au registre et séparation des rôles
  • Authentification SIP (AKA via HSS)
  • Authentification des pairs Diameter

Journalisation d'audit :

  • Journalisation complète des messages SIP et Diameter
  • Événements d'enregistrement/désenregistrement
  • Événements d'établissement et de terminaison d'appel
  • Actions administratives via l'interface web
  • Changements de configuration
  • Succès/échec de l'authentification

1.3.2 Fonctionnalités de protection des données​

Sécurité d'accès :

  • Contrôle d'accès basé sur les rôles (RBAC)
  • Comptes de surveillance en lecture seule
  • Contrôles d'authentification et d'autorisation

Renforcement du système :

  • Ports réseau exposés minimaux (5060 SIP, 3868 Diameter, 8086 Web UI)
  • Vérification de la validité des messages SIP
  • Prévention des boucles Max-Forwards
  • Limitation de débit et protection contre les inondations
  • Limites de taille de message
  • Isolation des processus de travail

1.4 Points d'intégration de l'interception légale​

1.5.1 Architecture d'interception légale ETSI​

Le système CSCF fournit une base pour l'interception légale conforme à l'ETSI. Bien que les interfaces X1/X2/X3 natives ne soient pas intégrées, tous les points d'accès aux données nécessaires existent pour l'intégration avec des systèmes externes de Fonction de Médiation d'Interception Légale (LIMF).

Interfaces LI standard ETSI :

Interface X1 - Fonction d'administration :

  • Objectif : Provisionnement de mandat et de cibles par les forces de l'ordre
  • Direction : LEMF → LIMF (bidirectionnel)
  • Fonctions :
    • Activer/désactiver l'interception pour les cibles (IMPUs, IMSIs, MSISDNs)
    • Définir la durée et la période de validité de l'interception
    • Configurer les critères de filtrage (identités, fenêtres temporelles)
    • Récupérer l'état de l'interception
  • Intégration avec CSCF :
    • LIMF maintient une base de données de mandats (liste de cibles - externe au CSCF)
    • LIMF surveille l'état en temps réel du CSCF et les journaux de messages pour les sessions correspondantes
    • LIMF filtre en fonction des critères fournis par X1

Interface X2 - Livraison d'IRI (Informations relatives à l'interception) :

  • Objectif : Livrer des métadonnées de session aux forces de l'ordre
  • Direction : LIMF → LEMF (unidirectionnel)
  • Format de données : XML/ASN.1 conforme à ETSI TS 102 232
  • Contenu du CSCF :
    • Identifiants de session (Call-ID, tags de dialogue)
    • Partie appelante (URI From, P-Asserted-Identity, IMPU, IMSI, MSISDN)
    • Partie appelée (URI To, Request-URI, IMPU, IMSI, MSISDN)
    • Horodatages d'enregistrement
    • Horodatages de mise en place/teardown de session
    • Localisation réseau (P-Access-Network-Info, antenne relais, zone de localisation)
    • Adresses P-CSCF/S-CSCF (identification des éléments du réseau)
    • User-Agent (type d'appareil)
    • Informations sur l'itinérance (P-Visited-Network-ID)

Interface X3 - Livraison CC (Contenu de la communication) :

  • Objectif : Livrer le contenu de communication réel
  • Direction : LIMF → LEMF (unidirectionnel)
  • Format de données : Conforme à ETSI TS 102 232
  • Contenu du CSCF :
    • Corps de messages SIP (descriptions de session SDP)
    • Adresses des serveurs multimédias (pour l'interception RTP)
    • Informations sur les codecs
    • Messages instantanés SIP MESSAGE (contenu du corps)
    • Données d'application (si routées via CSCF)

Remarque : Pour les flux RTP audio/vidéo, le LIMF doit également s'intégrer avec les serveurs multimédias (OmniTAS) pour capturer le contenu multimédia réel. Le CSCF fournit des informations de configuration de session (SDP) montrant où les médias circulent.

1.5.2 Sources de données CSCF pour l'interception légale​

1. Accès aux données d'enregistrement :

Données d'enregistrement P-CSCF :

  • IMPU (identité publique)
  • URI de contact (adresse réseau UE)
  • IP et port reçus
  • En-tête de chemin
  • Expiration de l'enregistrement
  • Informations SPI et port IPsec
  • Chaîne User-Agent

Données d'enregistrement S-CSCF :

  • Identités publiques (IMPU), état de barring, état d'enregistrement
  • Liaisons de contact avec en-têtes de chemin, User-Agent, adresses reçues
  • Mappages d'identité privée (IMPI) vers identité publique
  • Profils d'utilisateur du HSS (format XML incluant les détails de l'abonné)

Méthodes d'accès :

  • Interfaces d'accès aux données en lecture seule
  • Interface de surveillance de l'interface web
  • Journalisation d'événements en temps réel

2. Données de session active :

Données de dialogue S-CSCF :

  • Call-ID (identifiant de session unique)
  • URIs et tags From/To
  • Numéros CSeq de l'appelant et du destinataire
  • Ensembles de routes pour les deux parties
  • Adresses de contact
  • État du dialogue (Précoce, Confirmé, Supprimé)
  • Horodatage de début
  • Valeurs de timeout

Méthodes d'accès :

  • Surveillance de l'état de dialogue en temps réel
  • Requête par identifiants de session ou identifiants de partie
  • Capacités d'exportation pour analyse judiciaire

3. Journalisation des messages SIP :

Capture de journaux :

  • Tous les messages SIP peuvent être journalisés (REGISTER, INVITE, MESSAGE, etc.)
  • Niveaux de journalisation configurables
  • Journalisation structurée avec horodatages
  • Journalisation Syslog ou basée sur des fichiers

Analyse des journaux :

  • Analyse des en-têtes SIP pour extraction d'identité
  • Extraction de SDP pour informations multimédias
  • Suivi des séquences de messages (CSeq)
  • Corrélation des requêtes et des réponses

Exemple d'entrée de journal :

INFO: INVITE sip:+33687654321@ims.mnc001.mcc001.3gppnetwork.org SIP/2.0
From: <sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org>;tag=abc123
To: <sip:+33687654321@ims.mnc001.mcc001.3gppnetwork.org>
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@ims.mnc001.mcc001.3gppnetwork.org
P-Asserted-Identity: <sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org>
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=208011234567890
Content-Type: application/sdp

v=0
o=- 1234567890 1234567890 IN IP4 192.168.1.100
s=-
c=IN IP4 10.20.30.40
t=0 0
m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

4. Journalisation des messages Diameter :

Messages Cx (Communication HSS) :

  • UAR/UAA : Autorisation utilisateur (contient IMPU, IMPI)
  • LIR/LIA : Informations de localisation (contient IMPU, S-CSCF de service)
  • MAR/MAA : Authentification (contient IMPI, vecteurs d'authentification)
  • SAR/SAA : Attribution de serveur (contient IMPU, IMPI, XML de profil utilisateur)

Données Diameter disponibles :

  • IMSI (à partir du profil utilisateur)
  • MSISDN (à partir du profil utilisateur)
  • IMPUs associés (plusieurs identités par abonné)
  • Profil utilisateur (services, barring, état d'itinérance)

Exemple de journal :

Diameter Cx SAA reçu du HSS :
User-Name: user@ims.mnc001.mcc001.3gppnetwork.org
Public-Identity: sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org
Server-Name: sip:scscf.ims.mnc001.mcc001.3gppnetwork.org
Result-Code: 2001 (Succès)
User-Data: <XML profil utilisateur avec IMSI, MSISDN, iFC>

5. Données d'appel d'urgence (E-CSCF) :

Cartographie IMEI vers MSISDN :

  • P-CSCF crée une cartographie lorsque l'UE s'enregistre avec l'IMEI
  • TTL (Time-To-Live) de 24 heures
  • Utilisé pour le rappel d'urgence
  • Synchronisé entre les nœuds de cluster P-CSCF

Conservation des données :

  • Mappages IMEI vers MSISDN conservés pendant 24 heures
  • Disponibles pour la corrélation de rappel d'urgence
  • Accessibles via des interfaces de surveillance

Journaux d'appels d'urgence :

  • Détection de numéro d'urgence (112, 911, etc.)
  • Extraction de l'IMEI à partir du contact ou des en-têtes P
  • Informations de localisation (provenant de HELD ou P-Access-Network-Info)
  • Routage PSAP (Point d'Accès de Sécurité Publique)
  • Routage E-CSCF vers AS d'urgence

1.5.3 Capacités d'intégration pour LIMF​

Le système fournit plusieurs méthodes d'intégration pour les systèmes de Fonction de Médiation d'Interception Légale (LIMF) :

  1. Accès aux données d'enregistrement et de session :

    • Accès en temps réel aux données d'enregistrement (identités, emplacements, informations sur l'appareil)
    • Surveillance des sessions actives (état des appels, participants, timing)
    • Capacités de requête historique

  2. Journalisation des événements :

    • Journalisation des messages SIP avec niveaux de détail configurables
    • Journalisation des messages Diameter pour les interactions HSS
    • Journaux d'événements structurés avec horodatages

  3. Surveillance en temps réel :

    • Surveillance en direct de l'état d'enregistrement
    • Suivi des sessions d'appel actives
    • Détection d'appels d'urgence et informations de routage

Les méthodes d'intégration prennent en charge à la fois les architectures basées sur le polling et celles basées sur les événements pour la connectivité LIMF.

1.5.4 Mappage des données CSCF vers les interfaces LI​

Mappage des données CSCF vers IRI (X2) :

Source de données CSCFChamp IRIExemple de données
IMPU (en-têtes SIP/état en mémoire)Partie Asip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org
IMPI (en-têtes SIP/état en mémoire)ID d'authentificationuser@ims.mnc001.mcc001.3gppnetwork.org
IMSI (profil utilisateur HSS)ID d'abonné208011234567890
MSISDN (profil utilisateur HSS)Numéro de téléphone+33612345678
Call-ID (en-têtes SIP/état de dialogue)ID de sessionf81d4fae-7dec-11d0-a765-00a0c91e6bf6@...
From/To (en-têtes SIP)Partie A/Partie Bsip:+33612345678@... / sip:+33687654321@...
Horodatage d'enregistrement (en mémoire)Heure de l'événement2025-11-29T10:30:00Z
P-Access-Network-Info (en-tête SIP)Localisation3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=208011234567890
IP reçue (contact SIP)Adresse IP UE10.20.30.40:5060
Adresse P-CSCF (routage SIP)Élément de réseau10.4.12.165:5060
Adresse S-CSCF (routage SIP)Élément de réseau10.4.11.45:5060

Mappage des données CSCF vers CC (X3) :

Source de données CSCFChamp CCExemple de données
Corps de MESSAGE SIPContenu du message instantané"Bonjour, comment ça va ?"
SDP dans INVITEInformations de session multimédiaPoints de terminaison RTP, codecs
Adresse du serveur multimédiaCible d'interception RTP10.50.60.70:49170

Remarque : Pour le contenu audio/vidéo réel (RTP), le LIMF doit coordonner avec les serveurs multimédias (OmniTAS) pour capturer les flux RTP. Le CSCF fournit uniquement des informations de configuration de session.

1.5 Interface de surveillance basée sur le web​

Le système inclut un panneau de contrôle basé sur le web pour la surveillance en temps réel et l'accès administratif :

Capacités de surveillance :

  • État d'enregistrement en temps réel (abonnés actifs, emplacements, informations sur l'appareil)
  • Surveillance des sessions d'appel actives (participants, état des appels, timing)
  • Recherche et filtrage par identité (IMPU, IMPI, IMSI, MSISDN)
  • État et capacité des tunnels IPsec
  • Capacités d'exportation pour analyse judiciaire

Sécurité :

  • Accès crypté HTTPS/TLS
  • Authentification requise
  • Journalisation d'audit de toutes les actions administratives
  • Modes d'accès en lecture seule pour le personnel de surveillance

2. CAPACITÉS DE CRYPTAGE ET DE CRYPTANALYSE​

2.1 Aperçu des capacités cryptographiques​

L'OmniCSCF met en œuvre plusieurs couches de protection cryptographique pour le signalement et les données d'abonné. Cette section documente toutes les capacités cryptographiques requises par l'ANSSI.

2.2 Cryptage de tunnel IPsec ESP (UE vers P-CSCF)​

2.2.1 Mise en œuvre du protocole IPsec​

Mode IPsec pris en charge :

  • ESP (Encapsulating Security Payload) - Protocole IP 50
  • Mode transport (pas de mode tunnel)
  • Protège le signalement SIP entre l'UE et le P-CSCF

Algorithmes de cryptage pris en charge :

Le système avec IPsec du noyau prend en charge :

  • AES-CBC (Advanced Encryption Standard - Cipher Block Chaining) :

    • AES-128-CBC (clé de 128 bits)
    • AES-192-CBC (clé de 192 bits)
    • AES-256-CBC (clé de 256 bits) - Recommandé

  • AES-GCM (Advanced Encryption Standard - Galois/Counter Mode) :

    • AES-128-GCM (clé de 128 bits avec AEAD)
    • AES-256-GCM (clé de 256 bits avec AEAD) - Recommandé

  • 3DES-CBC (Triple DES - Cipher Block Chaining) :

    • Clé effective de 168 bits (déprécié, compatibilité héritée)

  • Cryptage NULL :

    • Pas de confidentialité (authentification uniquement)
    • Utilisé uniquement pour le débogage ou des scénarios de conformité spécifiques

Algorithmes d'authentification pris en charge :

  • HMAC-SHA1 (Hash-based Message Authentication Code - SHA-1) :

    • Sortie de 160 bits
    • Compatibilité héritée

  • HMAC-SHA256 (HMAC - SHA-256) :

    • Sortie de 256 bits
    • Recommandé

  • HMAC-SHA384 (HMAC - SHA-384) :

    • Sortie de 384 bits

  • HMAC-SHA512 (HMAC - SHA-512) :

    • Sortie de 512 bits

  • HMAC-MD5 :

    • Sortie de 128 bits
    • Déprécié, uniquement pour compatibilité héritée

Dérivation de clé :

Les clés IPsec (CK - Cipher Key, IK - Integrity Key) sont dérivées de l'authentification IMS AKA :

  1. L'UE effectue l'authentification AKA avec S-CSCF/HSS
  2. HSS génère CK (128 bits) et IK (128 bits)
  3. S-CSCF livre CK/IK au P-CSCF via une interface interne
  4. P-CSCF utilise CK/IK pour établir des associations de sécurité IPsec avec l'UE
  5. CK utilisé pour le cryptage ESP
  6. IK utilisé pour l'authentification ESP

Paramètres d'association de sécurité :

  • Durée de vie : Liée à l'expiration de l'enregistrement SIP (typiquement 599 secondes)
  • Protection contre la répétition : Activée (fenêtre anti-replay)
  • Numéros de séquence : 32 bits ou 64 bits (ESN - Numéros de séquence étendus)
  • Confidentialité parfaite à l'avance : Non applicable (clés provenant de AKA, pas de Diffie-Hellman)

Mise en œuvre :

La capacité IPsec du P-CSCF :

  • S'interface avec la pile IPsec du noyau Linux (cadre XFRM)
  • Configure les politiques de sécurité et les associations via l'API du noyau
  • Allocation et gestion de SPI (Security Parameter Index)
  • Allocation de ports pour le trafic protégé

2.2.2 Capacités de configuration IPsec​

Sélection de suite de chiffrement :

Le P-CSCF peut être configuré pour préférer des suites de chiffrement spécifiques :

Préférées (sécurité forte) :

  • ESP avec AES-256-GCM et HMAC-SHA256
  • ESP avec AES-256-CBC et HMAC-SHA256

Prises en charge (compatibilité) :

  • ESP avec AES-128-CBC et HMAC-SHA1
  • ESP avec 3DES-CBC et HMAC-SHA1 (héritage)

Gestion des clés :

  • IKE (Internet Key Exchange) n'est PAS utilisé
  • Clés fournies via IMS AKA (CK/IK du HSS)
  • Configuration manuelle des associations de sécurité via XFRM du noyau
  • Destruction automatique de SA à l'expiration de l'enregistrement

Cycle de vie du tunnel :

  1. L'UE s'enregistre → Authentification AKA → CK/IK générés
  2. P-CSCF reçoit CK/IK de S-CSCF
  3. P-CSCF alloue une paire de SPI (SPI client, SPI serveur)
  4. P-CSCF alloue une paire de ports (port client, port serveur)
  5. P-CSCF configure les SA IPsec du noyau en utilisant CK/IK
  6. P-CSCF envoie les paramètres IPsec à l'UE dans 200 OK (en-tête Security-Server)
  7. L'UE configure les SA IPsec avec les mêmes paramètres
  8. Tout le trafic SIP suivant circule à travers les tunnels ESP
  9. À l'expiration de l'enregistrement ou à la désinscription : SA supprimées, ressources libérées

2.3 Cryptage TLS (SIP et Diameter)​

2.3.1 TLS pour SIP (SIPS)​

Versions TLS prises en charge :

  • TLS 1.2 (RFC 5246) - Pris en charge
  • TLS 1.3 (RFC 8446) - Pris en charge (si support du noyau/bibliothèque)
  • TLS 1.0/1.1 - Déprécié (désactivé par défaut)
  • SSL 2.0/3.0 - NON PRIS EN CHARGE (vulnérabilités connues)

Mise en œuvre de TLS :

le système utilise OpenSSL ou LibreSSL :

  • Bibliothèques TLS standard de l'industrie
  • Implémentations validées cryptographiquement
  • Mises à jour de sécurit�� régulières

Suites de chiffrement prises en charge :

TLS 1.3 (Préféré) :

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
  • TLS_CHACHA20_POLY1305_SHA256

TLS 1.2 (Pris en charge) :

  • ECDHE-RSA-AES256-GCM-SHA384 (Confidentialité parfaite à l'avance)
  • ECDHE-RSA-AES128-GCM-SHA256 (Confidentialité parfaite à l'avance)
  • ECDHE-ECDSA-AES256-GCM-SHA384 (Confidentialité parfaite à l'avance)
  • DHE-RSA-AES256-GCM-SHA384 (Confidentialité parfaite à l'avance)
  • DHE-RSA-AES128-GCM-SHA256 (Confidentialité parfaite à l'avance)

Chiffres faibles désactivés :

  • Pas de RC4
  • Pas de MD5
  • Pas de cryptage NULL
  • Pas de chiffres de grade EXPORT
  • Pas de DES/3DES (déprécié)

Support des certificats :

  • Certificats X.509 (format standard)
  • Clés RSA : minimum 2048 bits, recommandé 4096 bits
  • Clés ECDSA : courbes P-256, P-384, P-521 prises en charge
  • Validation de chaîne de certificats
  • Vérification de CRL (Liste de révocation de certificats) (optionnel)
  • OCSP (Protocole d'état de certificat en ligne) (optionnel)

Fonctionnalités TLS :

  • Confidentialité parfaite à l'avance (PFS) : Via échange de clés ECDHE/DHE
  • Indication de nom de serveur (SNI) : Prise en charge
  • Reprise de session TLS : Prise en charge (optimisation des performances)
  • Authentification par certificat client : Prise en charge (TLS mutuel)

SIP sur TLS (SIPS) :

  • Transport : TCP avec cryptage TLS
  • Port : 5061 (port SIPS standard)
  • Utilisé pour la communication inter-CSCF (optionnel)
  • Utilisé pour les connexions de réseau de confiance

2.3.2 TLS pour Diameter​

Capacités Diameter :

Le système prend en charge :

  • Diameter sur SCTP (préféré pour la fiabilité)
  • Diameter sur TCP avec TLS
  • Port : 3868 (port Diameter standard)

Cas d'utilisation :

  • Interface Cx : S-CSCF/I-CSCF vers HSS (données d'abonné, authentification)
  • Interface Rx : P-CSCF vers PCRF (politique QoS)
  • Interface Ro : S-CSCF vers OCS (facturation en ligne - si activé)

Configuration TLS pour Diameter :

Les mêmes suites de chiffrement que SIP

  • TLS 1.2/1.3
  • Échange de clés ECDHE/DHE (PFS)
  • Cryptage AES-GCM
  • Authentification SHA256/SHA384

Authentification basée sur des certificats :

  • Les pairs Diameter s'authentifient via des certificats TLS
  • TLS mutuel (certificats à la fois client et serveur)
  • Validation FQDN (Nom de domaine entièrement qualifié) dans les certificats
  • Validation de la chaîne CA de confiance

2.4 Cryptographie d'authentification​

2.4.1 Fonctions cryptographiques IMS AKA​

Algorithme 3GPP AKA (MILENAGE) :

Utilisé pour générer des vecteurs d'authentification (RAND, AUTN, XRES, CK, IK) :

Fonctions cryptographiques :

  • f1 : Fonction d'authentification de message (calculer MAC-A et MAC-S)
  • f2 : Fonction de réponse (calculer RES à partir de RAND et K)
  • f3 : Dérivation de clé de chiffrement (calculer CK)
  • f4 : Dérivation de clé d'intégrité (calculer IK)
  • f5 : Fonction de clé d'anonymat (calculer AK pour la confidentialité IMSI)

Matériel de clé :

  • K : Clé d'abonné permanente de 128 bits (stockée dans ISIM et HSS)
  • OPc : Clé variante de l'opérateur (dérivée de K et OP)
  • RAND : Défi aléatoire de 128 bits
  • SQN : Numéro de séquence de 48 bits (protection contre la répétition)

Séquence AKA :

  1. HSS génère RAND (aléatoire cryptographiquement)
  2. HSS calcule MAC-A = f1(K, RAND, SQN, AMF)
  3. HSS calcule AUTN = (SQN ⊕ AK) || AMF || MAC-A
  4. HSS calcule XRES = f2(K, RAND)
  5. HSS calcule CK = f3(K, RAND)
  6. HSS calcule IK = f4(K, RAND)
  7. HSS envoie {RAND, AUTN, XRES, CK, IK} à S-CSCF
  8. S-CSCF défie l'UE avec RAND et AUTN
  9. L'UE calcule RES = f2(K, RAND) en utilisant ISIM
  10. L'UE envoie RES à S-CSCF
  11. S-CSCF compare RES avec XRES (validation de l'authentification)

Propriétés de sécurité :

  • Authentification mutuelle : L'UE vérifie HSS via AUTN, HSS vérifie l'UE via RES
  • Fraîcheur de clé : RAND est aléatoire, SQN empêche la répétition
  • Dérivation de clé : CK et IK dérivées du secret partagé K

2.4.2 Authentification par hachage HTTP Digest​

Pour l'authentification non-IMS (si utilisée) :

Algorithme : MD5 (RFC 2617)

  • Fonction de hachage : MD5 (sortie de 128 bits)
  • Challenge-Réponse : Basé sur nonce
  • Protection contre la répétition : Nonce avec horodatage

Remarque : HTTP Digest avec MD5 est considéré comme faible. IMS AKA est fortement préféré.

2.5 Hachage et intégrité​

2.5.1 Fonctions de hachage disponibles​

le système peut utiliser (via OpenSSL/crypto du noyau) :

  • SHA-256 : sortie de 256 bits, recommandé
  • SHA-384 : sortie de 384 bits
  • SHA-512 : sortie de 512 bits
  • SHA-1 : sortie de 160 bits, déprécié pour une utilisation sécuritaire
  • MD5 : sortie de 128 bits, déprécié pour une utilisation sécuritaire

Utilisation :

  • Constructions HMAC pour IPsec/TLS
  • Vérification de l'intégrité des données
  • Génération de nonce
  • Détection de doublons (hachage Call-ID)

2.5.2 Intégrité des messages​

Intégrité des messages SIP :

  • IPsec ESP : HMAC-SHA256 pour SIP authentifié sur IPsec
  • TLS : Authentification des messages via TLS MAC
  • Digest SIP : Intégrité de l'en-tête d'authentification

Intégrité des messages Diameter :

  • TLS : Diameter sur TLS fournit une authentification des messages
  • HMAC : Les messages Diameter peuvent inclure des AVPs HMAC pour l'intégrité

2.6 Génération de nombres aléatoires​

Génération de nombres aléatoires cryptographiquement sécurisée :

le système repose sur :

  • Linux kernel /dev/urandom : PRNG (Générateur de nombres pseudo-aléatoires cryptographiquement sécurisé)
  • OpenSSL RAND_bytes() : CSPRNG (Générateur de nombres pseudo-aléatoires cryptographiquement sécurisé)

Utilisation :

  • Allocation de SPI (valeur de départ aléatoire)
  • Génération de Call-ID
  • Génération de paramètres de branche
  • Génération de nonce pour l'authentification
  • Génération d'ID de session

2.7 Gestion des clés​

2.7.1 Gestion des certificats TLS​

Stockage des certificats :

  • Stockage dans le système de fichiers avec des permissions restreintes (0600)
  • Situé dans : /etc/system/tls/
  • Format PEM pour les certificats et les clés

Génération de certificats :

# Générer une clé privée RSA de 4096 bits
openssl genrsa -out system-key.pem 4096

# Générer CSR (Demande de signature de certificat)
openssl req -new -key system-key.pem -out system.csr \
  -subj "/C=FR/ST=IDF/L=Paris/O=Omnitouch/CN=scscf.ims.mnc001.mcc001.3gppnetwork.org"

# Certificat auto-signé (développement/test)
openssl x509 -req -days 365 -in system.csr \
  -signkey system-key.pem -out system-cert.pem

# Production : Soumettre CSR à une CA de confiance

Rotation des certificats :

  • Renouvellement annuel de certificat recommandé
  • Redémarrage de service en douceur pour charger les nouveaux certificats
  • Aucun temps d'arrêt requis

2.7.2 Gestion des clés IPsec​

Dérivation de clé :

  • CK (Clé de chiffrement) et IK (Clé d'intégrité) provenant de IMS AKA
  • Clés de 128 bits du HSS
  • Livrées de manière sécurisée via Diameter Cx (sur TLS)

Durée de vie des clés :

  • Liée à l'expiration de l'enregistrement SIP (typiquement 599 secondes)
  • Renouvellement de clé à l'actualisation de l'enregistrement
  • Destruction automatique de clé à la désinscription

Stockage des clés :

  • Éphémère (en mémoire uniquement pendant l'enregistrement actif)
  • Installé dans la pile IPsec du noyau
  • Pas de stockage de clé persistant
  • Clés rejetées lorsque SA supprimée

2.8 Résistance à la cryptanalyse​

2.8.1 Sélection d'algorithmes​

Défense contre la cryptanalyse :

  • Pas d'algorithmes personnalisés : Uniquement des algorithmes standard de l'industrie, examinés par les pairs
  • Tailles de clé fortes : AES-256, RSA-4096, SHA-256
  • Cryptage authentifié : AES-GCM (AEAD - Cryptage authentifié avec données associées)
  • Confidentialité parfaite à l'avance : ECDHE/DHE dans TLS
  • Mises à jour régulières : Patches de sécurité OpenSSL/LibreSSL appliqués

Algorithmes dépréciés désactivés :

  • MD5 (collisions de hachage)
  • RC4 (faiblesses du chiffre de flux)
  • DES/3DES (petite taille de bloc, longueur de clé)
  • SSL 2.0/3.0 (vulnérabilités de protocole)
  • TLS 1.0/1.1 (attaques BEAST, POODLE)

2.8.2 Atténuation des attaques par canaux auxiliaires​

Résistance aux attaques par temporisation :

  • Comparaison en temps constant pour les réponses d'authentification
  • Pas de fuites de temporisation dans les opérations cryptographiques (via OpenSSL)

Protection de la mémoire :

  • Isolation de la pile IPsec du noyau
  • Isolation de la mémoire des processus
  • Pas de swap pour les données sensibles (si configuré)

2.9 Conformité et normes​

Conformité aux normes cryptographiques :

  • NIST SP 800-52 : Directives TLS
  • NIST SP 800-131A : Transitions d'algorithmes cryptographiques
  • RFC 7525 : Recommandations TLS
  • ETSI TS 133 203 : Sécurité d'accès 3GPP (IMS AKA)
  • ETSI TS 133 210 : Sécurité de couche réseau IP (IPsec)
  • 3GPP TS 33.203 : Sécurité d'accès pour IMS
  • 3GPP TS 33.210 : Sécurité de domaine réseau

Réglementations françaises en matière de cryptographie :

  • Pas de cryptographie restreinte à l'exportation (tous les algorithmes standard)
  • Moyens cryptographiques standard (pas de portes dérobées gouvernementales)
  • Certification de produit cryptographique ANSSI (si nécessaire)