2.4 Comparaison entre la pile WAP et la pile TCP/IP

De même qu'il est possible de faire un parallélisme entre le modèle OSI et la pile TCP/IP, on peut également le faire pour la pile WAP. En effet, celle-ci est conforme au modèle multicouches défini par le modèle OSI. WAP a été créé sur la base de la pile IP, intégrant la sécurité définie par la norme TLS.

2.5 Sécurité sur le WAP

Dans les transactions électroniques qui peuvent s'effectuer, deux techniques de cryptage sont utilisées pour garantir la sécurité :
· La cryptographie à clé secrète : cette technique dite également symétrique ou à clé partagée. Elle permet d'assurer les fonctions de confidentialité et d'intégrité
· La cryptographie à clé publique dans la phase de négociation qui, elle, permet d'assurer (couplée avec des certificats) les quatre points clés : confidentialité, intégrité, authentification et non répudiation.

Pendant la transaction, la clé secrète est utilisée. Elle est connue uniquement des deux parties de la connexion et a été générée de façon aléatoire. Cette clé sert à la fois à chiffrer et à déchiffrer les données. Seule la connaissance de cette clé permet de retrouver les messages en clair. La longueur de cette clé est comprise entre 40 et 128 bits. Pour que cette clé soit échangée sans risque entre les deux parties, il est important que l'échange ait lieu de manière extrèmement sécurisé.

Pour assurer cette confidentialité et intégrité, la cryptographie à clé publique intervient dans la phase d'initialisation. Le mécanisme est le suivant :
· Chaque partie possède une paire de clé : publique et privée. La clé privée n'est connue que par son propriétaire alors que la clé publique peut être connue de n'importe qui sans précautions particulières. Celle ci peut être demandée directement à son propriétaire ou bien à un organisme de certification possédant cette clé.
· On appelle ce mécanisme asymétrique car un message codé avec la clé privée ne peut être récupéré qu'avec la clé publique et inversement. Ainsi, si on code avec la clé privée, dans ce cas, tous ceux qui possèdent la clé publique pourront décoder le message. A l'inverse, si on code avec la clé publique, dans ce cas, seul le propriétaire de la clé privée sera capable de décoder le message. C'est ce mécanisme qui est utilisé pour l'échange de la clé secrète.

Cette méthode très efficace est de plus en plus utilisée. Cependant, dans le cas du WAP, elle ne peut être exploitée que dans la phase d'initialisation car elle nécessite l'emploi de clés de taille relativement importantes (512 ou 1024 bits) ce qui n'est pas compatible avec l'utilisation des réseaux sans fils. En effet, la bande passante étant surchargée, il est important de ne pas l'alourdir encore plus.
Dans cette phase, on peut aussi utiliser les certificats d'authentification pour authentifier les parties en présence et vérifier les signatures numériques.

Comparaison WTLS et SSL

Comme il a été vu dans le détail de la couche WTLS, la sécurité du WAP a été copiée sur SSL

SSL

Le protocole SSL, bien connu des internautes, est actuellement la référence pour sécuriser une transmission sur Internet.

Fonctionnement :
1- le navigateur fait une demande de transaction sécurisée au serveur
2- le serveur lui envoie son certificat d'authentification délivré par un organisme officiel. Ce certificat comporte une clé publique.
3- Le navigateur s'assure tout d'abord que le certificat délivré est valide puis il envoie au serveur une clé secrète codée issue de la clé publique ( de 56 ou 128 bits). Seul le serveur sera donc capable de décoder cette clé secrète car il détient la clé privée. Cette clé secrète ainsi créée sera utilisée par l'algorithme de Bulk (cryptographie symétrique) pour encoder les messages.
4- Le serveur et le client possède maintenant une clé secrète partagée et les échanges sont faits par l'intermédiaire de cette clé. Pour assurer l'intégrité des données, on utilise un algorithme de hash.
On voit bien que ce mécanisme permet d'assurer la confidentialité (mécanisme de chiffrement), l'intégrité (algorithme de hash) et l'authentification (certificats). Cependant seule l'authentification du serveur est implémentée et la non-répudiation n'est pas prise en compte.

WTLS

Quand on pense à sécurité on imagine des transmissions fiables mais ceci n'est pas garanti dans le cas du WAP, en effet, la bande passante est faible et la qualité des transmissions n'est pas garantie. Pour s'adapter au mieux à ces contraintes, WTLS définit un nombre d'entêtes moins important que SSL et la compression y est plus élevée. Dans le but d'augmenter encore plus la sécurité, WTLS définit en plus la possibilité de réactualiser la clé secrète sans passer par la phase de négociation pénalisante en terme de bande passante. Des solutions utilisant le protocole WTLS existent et permettent aux entreprises de profiter de WTLS dans leurs applications et d'intégrer des systèmes PKI (Public Key Infrastructure) pour la gestion des certificats d'authentification.
Dans sa version actuelle 1.1, WAP permet les options de sécurité suivante :
· Confidentialité
· Intégrité
· Authentification du serveur

L'échange sécurisé nécessite un terminal mobile supportant WTLS, un serveur Web supportant SSL et une passerelle WAP (ou un serveur) supportant WTLS et SSL. Lors de l'échange sécurisé entre la passerelle WAP et un serveur Web, les données sont codées en utilisant le protocole SSL. Le serveur WAP a pour but de faire la conversion entre les formats WTLS et SSL. Ce point de liaison est critique car les données au format SSL doivent être décodées avant d'être ré encodées au format WTLS. Il est donc important que ce serveur soit astreint à des règles de sécurité particulières, tant au niveau logiciel que matériel.
Les données échangées entre le terminal et la passerelle sont alors codées au format WTLS.

Contraintes

Actuellement, la sécurité de bout en bout pour une transaction électronique n'est pas garantie, en effet ni SSL ni WTLS ne gèrent l'authentification du client. Ce problème sera résolu à partir de la version 1.2 du protocole WAP. L'idée de cette version est de pouvoir récupérer à partir du terminal des informations relatives à son propriétaire.
La solution retenue est l'utilisation d'un module embarqué sur le terminal, le WIM (WAP Identity Module). Le module WIM permet au protocole WTLS (ou à d'autres fonctions de la couche application) de sauvegarder et de récupérer à partir du portable des informations relatives au client, comme l'intégration de clés publiques et privées au sein de WIM. En effet le langage WMLScript, enrichi de la bibliothèque " crypto " permet d'interagir avec le module WIM. Le terminal peut alors être utilisé par exemple comme périphérique de signature numérique. Ce module prend tout son intérêt par son indépendance avec le type de terminal mobile. Il permet aux développeurs de mettre en place des solutions pleinement sécurisées.
Pour le cas du téléphone portable, on imagine très bien pouvoir intégrer ce module à l'intérieur même de la carte SIM (Subscriber Identity Module). Des solutions proposant cette méthode existent déjà. Elles peuvent être à base de Java Card mais d'autres supports peuvent également être mis en Suvre pour supporter ce module WIM, parmi lesquels on retrouve les smart cards (dotées de microprocesseurs), les cartes SIM, ou bien encore les cartes EMV (Europay Mastercard Visa) et SET(Secure Electronic Transaction)

2.6 Complément sur le WAP

Cette section a pour but de clarifier certaines notions abordées, des protocoles WAP très utilisés : WCMP et Push

PUSH

Il est facile de comprendre la différence entre le push et le pull, ne serait ce que par leur signification anglaise. Dans le pull, le client retire vers lui l'information qui l'intéresse, alors que dans le push c'est le serveur qui est l'initiateur du message.

En fait ce schéma est un peu simpliste car, comme le serveur initiateur et le mobile ne sont absolument pas sur le même réseau, il est nécessaire d'employer une passerelle :

Comme la passerelle push est le lien entre le réseau Internet et le réseau sans fil, elle doit être capable de contrôler les fonctions suivantes :
· Identification et authentification de l'initiateur du push
· L'analyse et la détection d'erreur dans le contenu
· Résolution d'adresse
· Encodage conforme aux contraintes du réseau sans fil
· Conversion de protocole

Bien entendu toutes les communications se font par l'intermédiaire du protocole HTTP (même s'il est prévu d'autres support à l'avenir).

Au contraire, pour tout ce qui touche aux transmissions sans fil de la passerelle push jusqu'au mobile, les communications se font par le support de la couche WSP qui définit tous les mécanismes de fonctionnement nécessaires au push. Pour mieux cerner la façon de faire du push, l'exemple suivant présente un morceau de code XML avec une carte WML:

WCMP

WCMP est l'équivalent d'ICMP sous le protocole IP, il sert à rendre compte des erreurs qui peuvent avoir lieu au cours d'une connexion. Ce mode est utilisé par WDP au niveau des noeuds d'interconnexion ou des passerelles pour signaler les erreurs survenues. Tout comme WDP, WCMP n'est utilisé que dans les environnements qui ne supportent pas IP (car dans ce cas, ICMP est utilisé)

L'entête WCMP est simple puisqu'elle ne comprend que 3 champs :
- Type : indique le type de message
- Code : définit le format du champ données
- Données : peuvent être des reports d'erreurs ou d'informations

Les types compris entre 0 et 127 correspondent à des types d'erreurs, alors que ceux compris entre 128 et 191 correspondent à des messages d'informations. Globalement, on retrouve, pour le type d'erreurs qu'ICMP un ajout de 50 sur le champ type.