Proposition d’authentification

Dans cette section, nous allons décrire les mécanismes d'authentification qui sont utilisés dans les architectures centralisées: IMS, puis nous proposerons des mécanismes pour le pair à pair.

3.3.1. Aspect sécurité IMS

La norme IMS propose une architecture de sécurité qui utilise trois protocoles de sécurité en fonction de la connexion à sécuriser (Figure 3.3.1-1):

o IMS Authentication Key Agreement (AKA) [NiAT02] entre l'équipement utilisateur (UE) et IMS réseau via le P-CSCF

o IP Sécurité (IPSec) [KeAt98] entre UE et P-CSCF o Diameter [CLZA03] entre HSS et I/S-CSCF

L'architecture IMS de sécurité est complexe car elle nécessite les trois protocoles. C’est pourquoi elle est généralement simplifiée dans les environnements de tests, ce qui conduit à des vulnérabilités que nous présentons par la suite. L’analyse de ces vulnérabilités permet d’illustrer notre propos sur la sécurité mais dans la mesure où la sécurité implantée ne reflète par un réel système IMS, il est difficile d’utiliser l’expérimentation pour faire de l’analyse. Nous avons alors procédé par formulation (en comparer ses signalsations) comme nous le verrons en fin de chapitre.

Figure 3.3.1-1: Vue globale de la sécurité dans d'IMS

Dans le plan de sécurité de l’IMS, il y a P/I/ S-CSCF et UPSF (User Profile Server Function, ou appelé HSS). P/I/ S-CSCF sont utilisés dans les procédures de sécurité IMS pour l'authentification entre l'équipement utilisateur et le cœur de réseau, pour accorder ou non l’autorisation de générer une nouvelle clé.

Figure 3.3.1-2: Architecture de sécurité d’IMS

La Figure 3.3.1-2 représente l'architecture de sécurité IMS avec un accès de transport IP pour se connecter à un réseau Multimedia IP (MM IP). L'IMS est indépendant du réseau de transport. L’élément noté GE (Generic Entities) dans le module Transport IP générique, est équivalent à des entités de transport 3GPP. L’équipement utilisateur (User Equipment) peut être soit un ISIM (IMS Subscriber Identity Module) ou un UA (User Agent) (client ayant une adresse IP). L’utilisateur ISIM-UE peut être connecté directement à Home NGN (numéro 1). Quant à l’utilisateur de type UA, il se connecte directement à un équipement P-CSCF (numéro 2) dans les réseaux NGN visités ou via le domaine du transport IP générique. Le module IMS Subscriber Identity (ISIM) qui est présent sur les téléphones portables utilise une clé pré-partagée. Lorsque ce module n’existe pas (cas des PC) il est possible d’utiliser un autre mécanisme tel que MD5.

Comme décrit précédemment à propos de l’architecture de sécurité IMS, quand l'équipement utilisateur souhaite accéder à un réseau géré par IMS, il doit effectuer

une authentification mutuelle qui est appelé AKA (Authentication and Key Agreement). IMS fournit des services d'authentification, la confidentialité et l'intégrité pour le chemin de signalisation SIP entre l'utilisateur et le réseau IMS (Figure 3.3.1-3). SIP utilise le mécanisme HTTP Digest pour l'authentification. Les paramètres AKA qui sont utilisés sont décrits dans la RFC 3310 [NiAT02].

Figure 3.3.1-3: Accès sécurisé d’un utilisateur terminal à IMS

Figure 3.3.1-4: Enregistrement IMS avec authentification AKA La Figure 3.3.1-4 présente le mécanisme d’AKA :

 L’application ISIM et le réseau partagent un secret à long terme (K).

 L’algorithme AKA est intégré sur un dispositif de puce appelée Universal Integrated Circuit Card (UICC).

 Le réseau produit un vecteur d'authentification basé sur K et un numéro de séquence SQN. Le vecteur d'authentification contient:

o Un défi aléatoire (RAND)

o un jeton d'authentification (AUTN)

o La réponse d'authentification attendue (XRES)

o Les deux clés de session: une clé d'intégrité (IK) et une clé de chiffrement (CK)

o Le vecteur d'authentification est téléchargé à partir du HSS à la S- CSCF lorsque le premier message Register est reçu par le S-CSCF. o Le S-CSCF crée une demande d'authentification contenant RAND,

AUTN, IK, et CK, et l'envoie à l'utilisateur dans le SIP 401 (Unauthorized).

o L'utilisateur vérifie avec l’ISIM que l’AUTN est correcte. Si l’AUTN est correcte, le réseau a été authentifié. L'utilisateur produit alors une réponse d'authentification en utilisant K et RAND, et envoie le résultat (RES) à la S-CSCF dans un message REGISTRE seconde.

o Le S-CSCF compare RES avec XRES. Si elles correspondent, l'authentification est réussie.

Après ces étapes, deux clés de session sont obtenues (IK et CK). L'équipement utilisateur et le P-CSCF utilisent ces clés de session pour sécuriser la communication par la création de deux paires de canaux d'IPSec, à travers lesquelles le trafic est transmis sous forme cryptée et l'intégrité protégée. Une fois que les SA (Security Associations) sont établies, le P-CSCF permettra d'identifier toutes les requêtes SIP à venir au travers de l’association SA comme appartenant à l'utilisateur authentifié [NiAT02].

3.3.2. Aspect securité de P2P SIP centralisé

Dans le cadre de la sécurité P2P SIP centralisée, plusieurs mécanismes de sécurité peuvent être appliqués. Ceux-ci dépendent du niveau de sécurité requis que nous définissons en trois degrés.

Le premier niveau est le plus simple qui suppose que tous les pairs se font confiance. A partir du moment où le pair fait partie du réseau il est sûr (un mécanisme d’accès préalable peut être effectué, tel une connexion à la box sécurisée par mot de passe.) Le mécanisme met en place un contact direct comme indiqué dans Figure 3.3.2-1.

Figure 3.3.2-1: Confiance mutuelle

Dans la deuxième solution, où les utilisateurs ne se font pas confiance, nous pouvons utiliser la solution de la clé pré-partagée avec le serveur d'authentification pour négocier la génération de clé de session en envoyant la demande de ticket crypté par clé pré-partagée entre les deux utilisateurs (Bob et Alice). L’échange de la clé entre le serveur d’authentification et chaque utilisateur se fait au début du déploiement. Si sa demande de ticket est vérifiée, le serveur d'authentification répond un ticket qui est également chiffré avec la clé pré-partagée, comme indiqué dans la Figure 3.3.2-2. Ils peuvent utiliser ce ticket pour générer une clé de session avec un temps d'expiration. Il s'agit d'un concept similaire à celui proposé par Kerberos.

Figure 3.3.2-2: Génération d’une clé de session

Figure 3.3.2-3: Utilisation d’une clé pré-partagée

Le troisième mécanisme est mis en œuvre à l'aide de clé pré-partagée entre le serveur et l’utilisateur comme le montre la Figure 3.3.2-3. Bob envoie le message qui est signé par sa clé pré-partagée à Alice. Alice vérifie la signature du message en l’envoyant au serveur d'authentification. Alice répond à Bob, si la signature du message est vérifiée sinon si la vérification a échoué elle laisse tomber son message. En fonction du niveau d'efficacité de la protection souhaité, de nombreux types d'architectures de sécurité peuvent être intégrés. Des mécanismes peuvent être définis tels qu’un serveur AAA centralisé, un serveur pour générer des tickets de session pour les clients, l'authentification par serveur de proximité les signatures par les pairs et la cryptographie par clés public/privé. Il pourrait également être utilisé un mécanisme par protocole défi/réponse protocole d’authentification mutuelle. Cependant, l’augmentation du niveau de protection peut conduire à diminuer les performances du système. Cela devrait être pris en considération avant de décider d'appliquer un mécanisme de sécurité. C’est pourquoi nous nous sommes attachés dans ce travail à évaluer le coût des architectures.

Afin d’évaluer précisément le coût d’une solution nous avons dans une première démarche expérimenté les solutions proposées.