:: News .:. Documents .:. Forum .:. Downloads .:. Bibliographie .:. Liens .:. Contact  :: 


Home
  :. News
  .: Documents
    .: Notions
    .: Protocoles
    .: Sécurité
    .: Architecture
    .: Prog
    .: Systèmes
  :. Forum
  .: Downloads
  :. Bibliographie
  .: Liens
  :. Contact

Chat

  Nickname:


irc: #guill.net

Forum



 
WAP : Le protocole WTLS  
 

 

WTLS : Wireless Transport Layer Secure

La couche sécurité vient s'intégrer juste au-dessus de la couche transport de telle sorte qu'elle est située au niveau le plus bas possible, ce qui permet d'assurer grâce à des normes établies, une sécurité meilleure que si elle avait été seulement au niveau applicatif. Le protocole WTLS permet de respecter trois des quatre contraintes principales lorsqu'on parle de sécurité liée aux réseaux :
1 - la confidentialité : elle assure aux deux parties en présence (mécanisme client serveur) qu'elles sont les seules à avoir accès aux informations échangées. Ceci est assuré par un mécanisme d'encryption des données.
2 - l'intégrité des données : cela permet de s'assurer que les données n'ont pas été altérées par l'une ou l'autre des parties. On utilise pour cela des algorithmes de hashage pour s'assurer de la validité des données. Il y a une réémission si un changement d'empreinte est détecté d'un coté ou de l'autre
3 - l'authentification (coté serveur) : l'authentification a pour but de prouver qu'un tiers est bien celui qu'il prétend être. Des certificats permettent d'authentifier les serveurs.
Seul le principe de non-répudiation n'est pas géré par la couche sécurité : celle ci aurait pour but de faire preuve juridique qu'une transaction a bien eu lieu. Ce mécanisme est souvent associé à une signature numérique.

On peut penser que les mécanismes de sécurité mis en Suvre nécessitent de grosse puissance de calcul, mais il n'en est rien. WTLS a été pensé de manière à s'adapter aux capacités des réseaux et mobiles GSM, c'est à dire faible taux de transfert, interactions lentes, capacités de calcul et de mémoire limitées et restriction gouvernementale en matière de chiffrement.

Détails

La couche sécurité est construite de façon modulaire, c'est à dire qu'elle dépend du niveau de sécurité demandé pour une application donnée. La couche WTLS permet d'avoir une interface pour l'administration des connexions sécurisées. Ce modèle respecte les spécificités définies par TLS 1.0. Les mécanismes mis en Suvre dans cette partie ne seront pas abordés dans les détails, certains étant plus proche de l'algorithmique ou de la cryptographie.

La couche WTLS permet à un client d'établir une connexion sécurisée avec un serveur et de fixer les options de sécurités prises en compte. L'établissement de la connexion sécurisée s'effectue en plusieurs étapes et le client aussi bien que le serveur peut annuler la communication à tout moment. La négociation inclut les paramètres de sécurité, l'échange de clés et l'authentification.

Dans une session pleinement sécurisée, on retrouve un mécanisme similaire à la figure ci dessous :

Routine d'établissement de connexion :

L'ensemble des primitives de la couche WTLS est donné par la figure ci-dessous

Nom Type de primitive Description
Sec-Unit-Data Transport Echange d'informations
Sec-Create Service Création de connexion
Sec-Exchange Service Echange de clé
Sec-Commit Service Passage en mode sécurisé
Sec-Terminate Service Mettre fin au mode sécurisé
Sec-Exception Service Avertir d'une exception
Sec-Create-Request Service Demande d'initialisation de la part du serveur

Chacune de ces primitives peut être générée par le client ou le serveur selon le respect de certaines conditions prédéfinies. Suivant les primitives utilisées, l'état de la connexion client-serveur va passer par plusieurs étapes chacune correspondant à un niveau de sécurisation plus ou moins élevé.

Pour réaliser toutes ces opérations, la couche WTLS est en fait subdivisée en deux autres couches. L'une est appelée la couche enregistrement, chargée de transmettre les données, ventuellement les compresser, d'appliquer un code d'authentification, de chiffrer et de faire les opérations inverses pour le déchiffrage. L'autre couche est en fait le protocole d'accord permettant aux deux éléments en présence de se mettre d'accord sur la sécurité mise en jeu.

Couche enregistrement :

Paramètres définissant la connexion :

Nom Description
connection end Type de terminal, client ou serveur
bulk cypher algorithm Algorithme utilisé pour le chiffrement. Ce paramètre précise des informations relatives au chiffrement
MAC algorithm Algorithme utilisé pour l'authentification. Ce paramètre précise des informations relatives à l'authentification
compression algorithm Type de compression utilisée
master secret Clé secrète de 20 octets utilisée pendant les échanges
client random 16 octets aléatoires fournis par le client
server random 16 octets aléatoires fournis par le serveur
sequence number mode Définit la façon dont les séquences d'octets sont échangées
key refresh Temps au bout duquel une nouvelle clé secrète est générée

Une fois que ces paramètres de sécurité ont été changés et que les clés ont été tablies, les états de connexion peuvent être initialisés en leur faisant passer certaines étapes. Pour que la connexion soit maintenue, les méthodes mises en Suvre doivent respecter les paramètres de sécurité définis au-dessus, notamment le temps maximal avant une réémission de la clé.

Couche de négociation de connexion :

Pour négocier une connexion sécurisée, un protocole d'accord appelé handshake est nécessaire.

Le protocole Handshake met en Suvre les fonctions suivantes :
· Echange de messages de bienvenue pour un accord entre les deux parties sur les algorithmes utilisés.
· Echange de valeurs aléatoires.
· Echange des paramètres de chiffrement pour permettre au lient et au serveur de se mettre d'accord sur une " pré clé de chiffrement "
· Echange des certificats et des informations chiffrées pour permettre au client et au serveur de s'authentifier
· Génération de la clé secrète à partir de la " pré clé secrète " et change de données aléatoires
· Proposer des mécanismes de sécurité pour la couche enregistrement
· Permettre au client ou au serveur de vérifier que l'autre extrémité à bien calculer les mêmes paramètres de sécurité et que la négociation s'est bien déroulée sans tentatives d'accès malveillant (hacker).

Il est possible de modéliser le mécanisme de négociation par la figure suivante :

Les paramètres définis dans ce protocole sont donnés sur la figure suivante :

Nom Description
session identifier Séquence d'octet choisie par le serveur pour identifier la session en cours
protocol version Version du protocole WTLS
peer certificate Certificat utilisé (peut être nul)
compression method Type d'algorithme utilisé pour compersser les données à chiffrer
cypher spec Spécifie l'algorithme utilisé pour le hashage et l'authentification
master secret Clé secrète de 20 octets
sequence number Séquence d'octets échangés
key refresh
Temps avant recalcul de clé
is resumable
Précise si la connexion peut être reprise

Ces indicateurs sont utilisés pour créer des paramètres de connexion sécurisée eux-mêmes utilisés pour le chiffrement des données protégées. Des sous protocoles avec des méthodes prédéfinies permettent, au sein même du protocole d'accord de modifier certains paramètres de négociation alors même que la connexion est déjà établie.

 




Sondage

Quel est votre connexion à Internet aujourd'hui ?
 
RTC 56Kbps
ADSL simple de 128 à 2048 Kbps
ADSL + Téléphonie (+TV) de 128 à 2048 Kbps
ADSL simple jusqu'à 20Mbps
ADSL + Téléphonie (+TV) jusqu'à 20Mbps
Autres (RNIS, Satellites bi-directionnel...)
Total :
2884

Recherche


Docs
   Pflogsumm (Analyseur de log mail pour Postfix)
   Proftpd (Mise en service d'un serveur FTP avec proftpd sous Linux)
   Openldap (Mise en service d'un serveur LDAP sous Linux)
   Gestion des périphériques en c++ builder (Communication RS232 en C++ Builder)
   Les sockets windows (Windows Sockets : un cours accéléré)

guill.net©1999-2018