Windows Mobile, Développement et Sécurité

Aspect Sécuritaire

Introduction : Risques et enjeux pour les opérateurs mobiles

A l'heure actuelle, le monde PC et tout particulièrement Windows est canabalisé par les virus. Les entreprises dépensent des fortunes colossales pour se prémunir d'éventuels problemes et les particuliers sont focalisés sur ce probleme lorsqu'ils utilisent Internet.

Les Smartphone ne sont toujours pas assez répandu pour que l'on puisse rapporter des problemes conséquent en matiere de virus. Pour autant ils en existent comme Skull.L sur la plateforme Symbian (cf: http://www.pcinpact.com/actu/news/SkullL_le_faux_antivirus_Symbian_qui_crane.htm). Dès lors, il s'agit pour les opérateurs mobiles de se prémunir de ce genre de probleme. Un utilisateur doit pouvoir entierement confiance en son terminal mobile.

Parts de marché des éditeurs de solutions d'antivirus dans le monde (Source IDC)

Parts de marché des éditeurs de solutions d'antivirus dans le monde
En 2001
Symantec
32,4%
Network Associates
26,4%
Trend Micro
14,2%
Computer Associates
4,9%
Sophos
2,5%
Sybari Software
1,8%
Panda Software
1,7%
F-Secure
1,3%

Source : http://solutions.journaldunet.com/dossiers/indicateurs/securite/antivirus_monde.shtml

Windows mobile dispose d'un systeme de certification d'application qui vient se soustraire à l'utilisateur en permettant ou non l'installation et l'execution d'une application. Cette sécurité s'appuie sur sa reconnaissance de la source des fichiers destinés à etre installés ou executé par le biais de la certification de données.

Le chiffrement de données

Présentation

Source : http://bobbyseb.free.fr/theme_2.html

La cryptologie moderne est née en 1976 avec l?introduction par deux chercheurs de l?Université de Stanford, Whitfield Diffie et Martin Hellman, du concept de clé publique.

Le terme « cryptage » est un anglicisme, tiré de l'anglais « encryption ». En français, on doit employer le mot chiffrement. L'Académie française précise que le mot est à bannir et ne figure pas dans son dictionnaire même si on peut le trouver dans des usuels. Toutefois, « crypter » est souvent employé, surtout au passif, dans le cadre de la télévision payante (on « crypte » des chaînes).

Le principe émet que seule l?opération de déchiffrement doit être protégée par une clé gardée secrète. Le chiffrement peut parfaitement être exécuté à l?aide d?une clé connue publiquement, à condition, bien sûr, qu?il soit virtuellement impossible d?en déduire la valeur de la clé secrète. On parle alors de « cryptographie asymétrique ».

Principe

Source : http://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#Principe

La cryptographie asymétrique, ou cryptographie à clé publique est fondée sur l'existence de fonctions à sens unique ? c'est-à-dire qu'il est simple d'appliquer cette fonction à un message, mais extrêmement difficile de retrouver ce message à partir du moment où on l'a transformé.

En réalité, on utilise en cryptographie asymétrique des fonctions à sens unique et à brèche secrète. Une telle fonction est difficile à inverser, à moins de posséder une information particulière, tenue secrète, nommée clé privée.

À partir d'une telle fonction, voici comment se déroulent les choses : Alice souhaite pouvoir recevoir des messages chiffrés de n'importe qui. Elle génère alors une valeur à partir d'une fonction à sens unique et à brèche secrète à l'aide d'un algorithme de chiffrement asymétrique (liste ici), par exemple RSA.

Elle la diffuse, mais garde secrète l'information permettant d'inverser cette fonction. On parle de clé publique pour celle qu'on diffuse (sans avoir à se préoccuper de sa sécurité) et de clé privée pour l'information secrète (qui doit rester la propriété exclusive d'Alice).

1e étape : Alice génère deux clés. La clé publique (verte) qu'elle envoie à Bob et la clé privée (rouge) qu'elle conserve précieusement sans la divulguer à quiconque.

2e et 3e étapes : Bob chiffre le message avec la clé publique d'Alice et envoie le texte chiffré. Alice déchiffre le message grâce à sa clé privée.

La certification d'application

Source : http://www.commentcamarche.net/crypto/certificat.php3

Introduction à la notion de certificats

Les algorithmes de chiffrement asymétrique sont basés sur le partage entre les différents utilisateurs d'une clé publique. Généralement le partage de cette clé se fait au travers d'un annuaire électronique (généralement au format LDAP) ou bien d'un site web.

Toutefois ce mode de partage a une grande lacune : rien ne garantit que la clé est bien celle de l'utilisateur a qui elle est associée. En effet un pirate peut corrompre la clé publique présente dans l'annuaire en la remplaçant par sa clé publique. Ainsi, le pirate sera en mesure de déchiffrer tous les messages ayant été chiffrés avec la clé présente dans l'annuaire.

Ainsi un certificat permet d'associer une clé publique à une entité (une personne, une machine, ...) afin d'en assurer la validité. Le certificat est en quelque sorte la carte d'identité de la clé publique, délivré par un organisme appelé autorité de certification (souvent notée CA pour Certification Authority).

L'autorité de certification est chargée de délivrer les certificats, de leur assigner une date de validité (équivalent à la date limite de péremption des produits alimentaires), ainsi que de révoquer éventuellement des certificats avant cette date en cas de compromission de la clé (ou du propriétaire).

Structure d'un certificat

Les certificats sont des petits fichiers divisés en deux parties :

La structure des certificats est normalisée par le standard X.509 de l'UIT (plus exactement X.509v3), qui définit les informations contenues dans le certificat :

L'ensemble de ces informations (informations + clé publique du demandeur) est signé par l'autorité de certification, cela signifie qu'une fonction de hachage crée une empreinte de ces informations, puis ce condensé est chiffré à l'aide de la clé privée de l'autorité de certification; la clé publique ayant été préalablement largement diffusée afin de permettre aux utilisateurs de vérifier la signature avec la clé publique de l'autorité de certification.

Lorsqu'un utilisateur désire communiquer avec une autre personne, il lui suffit de se procurer le certificat du destinataire. Ce certificat contient le nom du destinataire, ainsi que sa clé publique et est signé par l'autorité de certification. Il est donc possible de vérifier la validité du message en appliquant d'une part la fonction de hachage aux informations contenues dans le certificat, en déchiffrant d'autre part la signature de l'autorité de certification avec la clé publique de cette dernière et en comparant ces deux résultats.

On distingue différents types de certificats selon le niveau de signature :

Conclusion

On retiendra par exemple les étapes entre la volonté d'une société de certifier des correctifs pour ses logiciels et l'installation des correctifs chez le client. Elles sont les suivantes :

Tout d'abord la société doit contacter une autorité d'enregistrement. Cette dernière va se charger de générer la paire clef privée-clef publique et de collecter des informations probantes sur la société.

Elle va ensuite envoyer les informations de la société vérifiées ainsi que la clef publique à une autorité de certification. Celle-ci va générer un certificat contenant les informations de la société ainsi que sa clef publique. On pourra vérifier la validité de ce certificat, avec la clef publique de l'autorité de certification largement répandue, par le fait que les informations auront été hashées puis signées avec la clef privée de l'autorité de certification.

La société se voit ensuite remettre son certificat. Elle peut donc remettre ses correctifs à ses clients. Chaque fichier est hashé puis le résultat du hashage est signé avec la clef privée de la société : on appelle cela l'empreinte d'un fichier.

Le client peut vérifier la validité des correctifs en effectuant la même fonction de hashage sur les fichiers reçus d'une part et en déchiffrant l'empreinte d'autre part. S'ils sont similaires, le fichier est de source sûre.

La certification d'application sur Windows Mobile

Source : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/smartphone_security.asp

Présentation

La sécurité des applications sur Windows Mobile consiste à protéger l'intégrité des terminaux des utilisateurs en empechant d'installé une application provenant d'une source inconnue.

Cette politique est basée sur la signature d'application. Un opérateur mobile choisit une politique de sécurité avant de répandre un terminal mobile sur le marché. Cependant, l'utilisateur peut généralement changer à souhait la politique de sécurité de son terminal.

Les terminaux basés sur Windows Mobile implementent une sécurité dite de périmetre, qui empeche d'installer une application provenant d'une source inconnue, et une sécurité d'execution qui empeche d'executer ce meme type d'application.

Par exemple, vous avez seulement besoin d'installer une sonnerie ou une gestionnaire d'écran alors qu'une application executable necessite d'être installée puis executée. Par conséquent, si vous créer un contenu qui ne necessite que d'etre installé, vous ne vous soucierez que de la politique de sécurité dite de périmetre, sinon il faudra aussi pensé à la politique d'execution.

Le systeme d'exploitation Windows Mobile dispose de trois magasins de certificats :

  1. ceux concernant les executions en mode non privilégié
  2. ceux concernant les executions en mode privilégié
  3. ceux concernant l'installation de contenu sur le terminal

Un magasion de certificats contient la portion publique des certificats numériques installés sur le terminal. La version publique d'un certificat peut être utilisée pour vérifier la signature numérique d'une application, mais il ne peut pas être utilisé pour signer une application.

Quel mode d'exécution utilisé

La plupart des applications ont seulement besoin d'un acces d'execution en mode non privilégié : les jeux ou les applications bureautiques par exemple. Cependant, si une application doit realiser une des contraintes suivantes, elle pourrait avoir besoin de s'executer en mode privilégié ce qui signifie qu'elle doit être signée avec un certificat avec un accès d'execution en mode privilégié :

Le modèle de sécurité d'application a été conçu pour être « flexible » du fait du nombre élévé de requetes en matiere de sécurité des opérateurs mobiles. Le concept d'application privilégiée ou non privilégiée correspond au niveau d'accès requis d'une application :

Les politiques de sécurité envisageables pour un opérateur

Pour l'installation d'application (la sécurité de périmetre), la politique de l'opérateur est simple:

Depuis Smartphone 2003, il existe un mode additionnel demandant à l'utilisateur de confirmer l'installation ou non.

Concernant l'execution d'une application (la sécurité d'execution), l'opérateur mobile doir faire le bon choix pour autoriser une application ou un composant à s'executer en mode privilégié ou non-privilégié. Le tableau suivant montre le type de certificat avec lequel notre application doit être signé pour s'executer :

Policy Execution mode Execution mode
  Unprivileged Privileged
Unrestricted None None
Standard None Operator privileged certificate required
Restricted Mobile2Market unprivileged certificate required Operator privileged certificate required

Les terminaux Windows Mobile supportent aussi un mode avec message de sollicitation. L'opérateur peut en effet déléguer à l'utilisateur le choix d'executer une application non-signée si elle ne demande pas de ressources dites « privilégiées ». Les politiques d'execution sont alors les suivantes :

Policy Execution mode Execution mode
  Unprivileged Privileged
Unrestricted None None
Standard Mobile2Market unprivileged certificate required (also Prompt mode) Mobile2Market or Operator privileged certificate required
Restricted Mobile2Market unprivileged certificate required Mobile2Market or Operator privileged certificate required

Concernant l'opérateur Orange, on peut noter le choix de la politique de sécurité suivante :

Currently Announced
Windows Mobile-based Smartphone Operators
Policy
Execution Mode
Mobile Operator
(Regional Availability)
Device
(Platform Version)
Application Security Configuration
Unprivileged
Privileged
AT&T Wireless (U.S.)
KPN (Netherlands)
Sierra Wireless Voq Professional Phone (Windows Mobile 2003 software for Smartphone)
Standard (prompt)
Mobile2Market
unprivileged root certificate
Mobile2Market
privileged root certificate
Orange (Europe)
SPV1 (Windows Mobile 2002 software for Smartphone)
Restricted
Mobile2Market
unprivileged root certificate
Orange
privileged root certificate
Orange (Europe)
SPV2 (Windows Mobile 2003 software for Smartphone)
Standard (prompt)
Mobile2Market
unprivileged root certificate
Orange
privileged root certificate

On constate que pour Smartphone 2003, Orange a choisi de déléguer à l'utilisateur le choix d'installer et d'execution des applications ou composants non signés ne faisant pas appel à des ressources privilégiées.

Veuillez trouver sur le lien suivant la liste des clefs registres dont l'accès necessite un accès privilégié ainsi que la liste des APIs dites « privilégiées » : Cliquer ici

Conclusion

On peut donc constater que l'opérateur possède une grande part de responsabilité pour ce qui concerne la sécurité de son parc de terminaux mobiles Windows Mobile. Il est celui qui fixe la politique à suivre en matière d'installation et d'execution d'application selon leur provenance et leurs prérequis au point de vue du niveau d'accès.

Pour autant, la plupart des opérateurs, en particulier Orange, mettent à disposition des « développeurs » ou plutôt des utilisateurs désireux d'installer des applications non-signées ou signées avec un certificat racine non présent dans le terminal.