Création d'un système Windows CE sécurisé

Maricia Alforque
Microsoft Corporation
Mise à jour Octobre 2000

Concerne :
     Microsoft Windows CE version 3.0

Résumé : cet article donne une présentation de haut niveau des différentes options disponibles dans Windows CE 3.0 pour assurer la sécurité des systèmes et des applications. Il suppose une bonne connaissance des technologies de sécurité Microsoft de base et des interfaces de programmation (API) Win32.

Sommaire

Introduction
Création d'un environnement sécurisé
Utilisation de l'interface SSPI pour la gestion des fournisseurs de sécurité (SSP)
Utilisation de SSL pour les communications réseau sécurisées
Cryptage des données à l'aide de CryptoAPI
Isolement des données sensibles dans une carte à puce
Identification des systèmes de façon unique
Utilisation du mode noyau protégé
Utilisation de l'authentification numérique dans le chargeur d'initialisation à distance
Pour plus d'informations

Introduction

Les services de sécurité constituent une partie essentielle d'un système d'exploitation évolué. Les infrastructures réseau, les pratiques d'administration système et l'expérience des utilisateurs finaux dépendent de la gestion, de la souplesse et de la mise en application des services de sécurité. Microsoft® Windows® CE 3.0 étend l'entreprise dans un monde de plus en plus connecté en réseau, sans remettre en cause la sécurité, car il offre un ensemble intégré de services de sécurité doté des fonctions suivantes :

• modèle d'environnement sécurisé ;
  
  
• interface SSPI (Security Support Provider Interface) ;
  
  
• prise en charge de Windows NT® LAN Manager ;
  
  
• prise en charge de Secure Sockets Layer (SSL) ;
  
  
• cryptographie ;
  
  
• infrastructure de cartes à puce qui prend en charge la CryptoAPI ;
  
  
• identifiant unique de système ;
  
  
• configuration de noyau protégé ;
  
  
• authentification numérique dans le chargeur d'initialisation à distance.

Création d'un environnement sécurisé

Les systèmes Windows CE envoient, reçoivent et traitent des informations qui doivent être protégées contre les applications qui ne sont peut-être pas sûres. Alors, comment protéger votre système ? Vous pouvez créer un système d'exploitation (OS) sécurisé qui empêche le chargement de modules inconnus, restreint l'accès aux API système et empêche l'accès en écriture à des parties du registre système.

Pour créer un environnement sécurisé, vous devez implémenter deux fonctions :

•  OEMCertifyModuleInit
  
  
• OEMCertifyModule

Avant que le noyau ne charge une application, la fonction OEMCertifyModule vérifie la signature de cette dernière pour protéger votre système contre les applications inconnues. Cela garantit que la plate-forme Windows CE charge une application uniquement si elle contient une signature numérique. La fonction OEMCertifyModule renvoie une des trois options suivantes :

1. Totalement sûre pour exécuter n'importe quelle opération.
   
   
2. Sûre pour être exécutée, mais avec restriction d'appel de certaines fonctions.
   
   
3. Non sûre et, par conséquent, non autorisée à être exécutée.

Le tableau suivant décrit les deux fonctions.

Fonction	Description	Valeur renvoyée
OEMCertifyModuleInit	Autorise le chargeur OS à notifier l'OEM qu'un nouveau module est en cours de chargement. Cela permet à l'OEM de décider de vérifier ou non si le module est sûr.	TRUE ou FALSE
OEMCertifyModule	Permet au chargeur OS de transmettre le code du module (par exemple, DLL, EXE et OCX) à l'OEM pour qu'il vérifie que ce module peut être exécuté sur le système en toute securité.	OEM_CERTIFY_TRUST OEM_CERTIFY_RUN OEM_CERTIFY_FALSE

Le tableau suivant décrit les valeurs renvoyées par la fonction OEMCertifyModule.

Valeur renvoyée	Description
OEM_CERTIFY_TRUST	Application sûre pour exécuter n'importe quelle opération.
OEM_CERTIFY_RUN	Application sûre pour être exécutée, mais avec restriction d'appel de fonctions privilégiées.
OEM_CERTIFY_FALSE	Non sûre et, par conséquent, non autorisée à être exécutée.

Une fonction OEMCertifyModule peut exécuter n'importe quel type de contrôle sur le module en cours de chargement, tel que le contrôle de redondance cyclique ou le contrôle de certificat. Lorsqu'une bibliothèque de liens dynamiques (DLL) charge des données dans l'espace d'adressage d'un EXE, le niveau de confiance de l'EXE détermine le niveau d'accès final. Par exemple, lorsqu'un EXE avec le niveau de confiance OEM_CERTIFY_RUN tente de charger une DLL qui a un niveau de confiance inférieur (OEM_CERTIFY_TRUST), le niveau de confiance final de la DLL est OEM_CERTIFY_RUN. Par ailleurs, si l'EXE tente de charger une DLL qui a un niveau de confiance supérieur, le chargement échoue.

Le tableau suivant montre les différentes combinaisons de niveau de confiance EXE et DLL.

Confiance EXE	Confiance DLL	Confiance finale DLL
OEM_CERTIFY_RUN	OEM_CERTIFY_RUN	OEM_CERTIFY_RUN
OEM_CERTIFY_RUN	OEM_CERTIFY_TRUST	OEM_CERTIFY_RUN
OEM_CERTIFY_TRUST	OEM_CERTIFY_RUN	Échec du chargement de la DLL
OEM_CERTIFY_TRUST	OEM_CERTIFY_TRUST	OEM_CERTIFY_TRUST

Remarque   Les OEM doivent signer numériquement tous les pilotes tiers, sinon le chargement des pilotes échoue. Tous les pilotes doivent être sécurisés lors de l'implémentation de ce modèle de sécurité.

L'implémentation la plus simple du modèle de sécurité utilise la fonction OEMCertifyModule pour renvoyer OEM_CERTIFY_RUN pour toutes les applications. Cela permet l'exécution des applications qui ne font pas partie de la section MODULES ROM de l'image, mais avec une restriction d'appel de fonctions privilégiées. Ainsi, vous n'avez pas à spécifier au moment de l'exécution quelles applications sont sûres ou pas. Si OEM_CERTIFY_FALSE est renvoyé à la place, les applications de la RAM ne pourront pas être exécutées. Dans tous les cas, les fichiers OS de la section MODULES ROM de l'image s'exécuteront toujours avec l'ensemble des privilèges.

Pour créer une signature numérique, vous pouvez utiliser Signfile.exe, qui est inclus dans Platform Builder 3.0. Signfile.exe est un outil permettant de signer un fichier exécutable avec une clé privée qui utilise l'algorithme SHA (Secure Hash Algorithm) pour calculer le hachage cryptographique. Vous trouverez un exemple de code Signfile.exe dans le CD du produit Platform Builder 3.0 (Public\Common\Oak\Tool\Signfile).

Pour vérifier la signature au moment du chargement, vous pouvez utiliser les fonctions Loadauth.lib fournies dans le répertoire spécifique du processeur de Platform Builder, dans \Public\Common\Oak\Lib. Pour plus de détails sur l'utilisation des fonctions Loadauth.lib, reportez-vous à la documentation de Platform Builder 3.0.

Vous pouvez également écrire votre propre schéma de vérification de signature au lieu d'utiliser les outils Platform Builder.

Le code suivant montre un exemple d'implémentation des fonctions OEMCertifyModuleInit et OEMCertifyModule à l'aide des fonctions Loadauth.lib :

/* La clé publique de signature BLOB */
const unsigned char g_bSignPublicKeyBlob[] = {
0x06,0x02,0x00,0x00,0x00,0x24,0x00,0x00,0x52,0x53,0x41,0x31,0x00,0x02,
0x00,0x00,0x01,0x00,0x01,0x00,0xb1,0x00,0x93,0x7c,0x18,0x63,0xce,0xf3,
0x23,0xe3,0x57,0x74,0x13,0x54,0x17,0x2c,0xdb,0xf6,0x56,0x77,0xb3,0x8d,
0x34,0x6c,0x41,0x3d,0x4e,0xbb,0xc1,0xaf,0x3d,0x17,0xb6,0x0e,0x70,0x72,
0x43,0x12,0x1d,0xb1,0x2a,0x57,0x05,0x27,0x58,0x63,0xef,0xb7,0x3b,0x71,
0xee,0xe4,0xcd,0x14,0xbe,0xf7,0x32,0xec,0xa2,0xae,0xbf,0x9a,0x6b,0x75
};
// Déclarations pour le contrôle de signature des RAM 
// exécutables au moment du chargement
typedef BOOL (* OEMLoadInit_t)(LPWSTR lpszName);
typedef DWORD (* OEMLoadModule_t)(LPBYTE lpData, DWORD cbData);

extern OEMLoadInit_t pOEMLoadInit;
extern OEMLoadModule_t pOEMLoadModule;
extern BOOL InitPubKey(const BYTE *KeyBlob, DWORD cbKeyBlob);

// Routines des bibliothèques Loadauth 
extern BOOL CertifyModuleInit(void);
extern BOOL CertifyModule(PBYTE pbBlock, DWORD cbBlock);
extern BOOL CertifyModuleFinal(PBYTE *ppbSignData,
 PDWORD pcbSignData);

// Appelé une fois pour chaque module exécutable RAM
// pour initialiser le contrôle de signature
static BOOL OEMCertifyInit(LPWSTR lpszName)
{
 return CertifyModuleInit();
}

// Appelé une ou plusieurs fois après OemLoadInit
static DWORD OEMCertifyModule(LPBYTE lpData, DWORD cbData)
{
 if (cbData)
 {
 // traite les octets du module
 return CertifyModule(lpData, cbData);
 }
 else
 {
 // appel final
 DWORD dwTrustLevel = OEM_CERTIFY_FALSE;
 LPBYTE pSignedData;
 DWORD cbSignedData;
 BOOL fRet = CertifyModuleFinal(&pSignedData,
 &cbSignedData);
 if (fRet)
 {
 // le fichier a une signature valide
 // le niveau de confiance devrait être 
 // renvoyé sous forme de données signées
 if (cbSignedData < sizeof(CHAR))
 dwTrustLevel = OEM_CERTIFY_RUN;
 else
 switch (*pSignedData)
 {
 case 'T' :
 dwTrustLevel = OEM_CERTIFY_TRUST;
 break;
 case 'R' :
 dwTrustLevel = OEM_CERTIFY_RUN;
 break;
 default:
 dwTrustLevel = OEM_CERTIFY_FALSE;
 break;
 }
 }
 #ifdef DEBUG
 if (!fRet)
 lpWriteDebugStringFunc(TEXT("OEMCertifyModule:échec du contrôle
 de signature.\r\n"));
 #endif

 // retourne un des niveaux OEM_CERTIFY 
 return dwTrustLevel;
 }
}

void OEMInit()
{
 ...
 ...
 //
 // Définit les raccordements de vérification de signature du module.
 //
 pOEMLoadInit = OEMCertifyInit;
 pOEMLoadModule = OEMCertifyModule;
 //
 // Initialise la clé publique de vérification de signature.
 //
 InitPubKey(g_bSignPublicKeyBlob,sizeof(g_bSignPublicKeyBlob));
 
 // 
 // Autres étapes d'initialisation OEM
 //
 ...
}

Remarque   Le nom des fonctions OEMCertifyModuleInit et OEMCertifyModule est arbitraire ; vous pouvez utiliser n'importe quel nom. Cependant, il est important d'initialiser les deux pointeurs noyau, pOEMLoadInit et pOEMLoadModule, de la fonction OEMInit sur ces fonctions nommées.

API restreintes

Outre les fonctions OEM, les API CeGetCurrentTrust et CeGetCallerTrust permettent à une DLL de demander le niveau de confiance d'une application appelante. Vous pouvez utiliser ces fonctions pour vérifier les niveaux de confiance des applications.

Les modules non sûrs ne peuvent pas appeler les API suivantes :

• SetInterruptEvent
  
  
• SetSystemMemoryDivision
  
  
• CESetThreadPriority
  
  
• CeSetThreadQuantum
  
  
• ForcePageout
  
  
• VirtualCopy
  
  
• LockPages
  
  
• UnlockPages
  
  
• SetProcPermissions
  
  
• SetKMode
  
  
• ReadProcessMemory
  
  
• WriteProcessMemory
  
  
• SetCleanRebootFlag
  
  
• PowerOffSystem
  
  
• DebugActiveProcess

La restriction s'applique également aux indicateurs de débogage DEBUG_ONLY_THIS_PROCESS et DEBUG_PROCESS de l'API CreateProcess .

L'architecture de registre sécurisée de Windows CE 3.0 permet uniquement aux "applications sûres" (OEM_CERTIFY_TRUST) que vous avez identifiées de modifier les clés et les valeurs des registres protégés.

Dans Windows CE 3.0, les clés de registre suivantes et leurs sous-clés sont protégées contre les applications non sûres :

• HKEY_LOCAL_MACHINE\Comm
  
  
• HKEY_LOCAL_MACHINE\Drivers
  
  
• HKEY_LOCAL_MACHINE\HARDWARE
  
  
• HKEY_LOCAL_MACHINE\SYSTEM
  
  
• HKEY_LOCAL_MACHINE\Init
  
  
• HKEY_LOCAL_MACHINE\WDMDrivers

De plus, la valeur ERROR_ACCESS_DENIED est renvoyée pour les applications non sûres qui tentent d'utiliser les fonctions de registre suivantes :

• RegSetValueEx
  
  
• RegCreateKeyEx
  
  
• RegDeleteKey
  
  
• RegDeleteValue

Comme le reste du registre n'est pas protégé, les OEM doivent placer toutes les informations importantes dans une des clés protégées.

Remarque   Toutes les applications ont un accès en lecture seule à toutes les clés et valeurs du registre.

Utilisation de l'interface SSPI pour la gestion des fournisseurs de sécurité (SSP)

L'interface SSPI (Security Support Provider Interface), qui est disponible par l'intermédiaire du module Secur32.dll, est une API courante bien définie qui permet d'obtenir des services de sécurité intégrés pour l'authentification, l'intégrité des messages et la confidentialité des données. Elle fournit une couche d'abstraction entre les protocoles de niveau applications et les protocoles de sécurité. Comme le mode d'identification ou d'authentification des utilisateurs et le mode de cryptage des données pendant leur transfert à travers un réseau varie selon les applications, Windows CE SSPI offre un moyen d'accéder aux DLL contenant des schémas d'authentification et de données cryptographiques différents. Ces DLL sont appelées des SSP (Security Support Providers).

L'illustration suivante montre la relation entre les DLL SSP et SSPI Secur32.dll, Winsock et WinInet.

Figure 1. Relation entre les DLL SSP et SSPI Secur32.dll, Winsock etWinInet

La SSPI met un ou plusieurs SSP, également appelés progiciels de sécurité, à disposition des applications. Un progiciel de sécurité mappe différentes fonctions SSPI sur une implémentation du protocole de sécurité spécifique de ce progiciel. Les OEM peuvent également écrire leurs propres progiciels de sécurité et les ajouter ensuite au registre.

Les SSP suivants sont disponibles dans Windows CE 3.0 :

• Schannel Cryptographic Provider
  
  
• Windows NT LAN Manager SSP

Fonctions SSPI

SSPI permet aux développeurs d'applications d'utiliser un des SSP sans connaître en détail les protocoles de sécurité.

Les tableaux suivants montrent les fonctions SSPI prises en charge par Windows CE 3.0.

Les fonctions de gestion des autorisations fournissent l'accès aux autorisations d'un principal. Un principal est une entité reconnue par le système d'exploitation, qui peut être un utilisateur ou un processus. Un principal utilise les autorisations pour établir l'identité d'un utilisateur ou d'une application.

Fonction	Description
AcquireCredentialsHandle	Permet à une application d'acquérir un descripteur pour les autorisations.
FreeCredentialsHandle	Libère un descripteur d'autorisation et toutes les ressources associées.
QueryCredentialsAttributes	Récupère les attributs d'une autorisation.

Les fonctions de gestion de contexte permettent aux applications de créer et d'utiliser un contexte de sécurité. Un contexte de sécurité se compose des données de sécurité propres à une connection et contient des informations telles qu'une clé de session et la durée de la session. Le client et le serveur doivent coopérer pour créer un contexte de sécurité.

Fonction	Description
InitializeSecurityContext	Initie un contexte de sécurité en générant un jeton qui peut être transmis à un serveur ou à un homologue éloigné.
AcceptSecurityContext	Établit un contexte de sécurité en utilisant un redirecteur pour valider les autorisations.
DeleteSecurityContext	Libère un contexte de sécurité et supprime les structures de données locales qui lui sont associées.
QueryContextAttributes	Récupère les attributs du contexte de sécurité.
ApplyControlToken	Applique un message de sécurité supplémentaire à un contrôle de sécurité existant.
FreeContextBuffer	Libère la mémoire tampon allouée par le fournisseur de sécurité.

Les fonctions de support de messages utilisent un contexte de sécurité pour assurer l'intégrité des messages et la confidentialité lors des échanges de messages sur la connection sécurisée. L'intégrité repose sur la signature des messages et la vérification des signatures, et la confidentialité sur le cryptage et le décryptage des messages.

Fonction	Description
MakeSignature	Génère une somme de contrôle cryptographique du message et inclut des données de séquencement pour éviter la perte ou l'insertion de message. Cette fonction permet également à l'application de choisir entre plusieurs algorithmes cryptographiques.
VerifySignature	Vérifie la signature du message.

Les fonctions de gestion de progiciels fournissent des services aux divers progiciels de sécurité pris en charge.

Fonction	Description
EnumerateSecurityPackages	Liste les progiciels de sécurité disponibles et leurs fonctions.
QuerySecurityPackageInfo	Récupère les informations relatives au progiciel spécifié.

Authentification utilisateur et sécurité DCOM

Dans les applications client-serveur, Windows CE 3.0 utilise le fournisseur de sécurité Windows NT LAN Manager (NTLMSSP.dll) pour l'authentification utilisateur. Les applications clientes fournissent le nom d'utilisateur, le nom de domaine et le mot de passe au NTLMSSP, et les applications serveur et client échangent des jetons pour terminer l'authentification.

Les applications serveur fonctionnant sous Windows CE peuvent également avoir recours au progiciel de sécurité Windows NT LAN Manager. Par exemple, le modèle DCOM (Distributed Component Object Model) utilise le protocole Windows NT LAN Manager pour établir les autorisations des utilisateurs, si l'indicateur RPC_C_AUTHN_WINNT est sélectionné.

Bien que l'authentification dans Windows CE soit similaire à celle de Windows NT, il existe des différences marquées. Dans Windows NT, l'authentification peut avoir lieu dans chaque cas suivant : le client se connecte au serveur, le client appelle ou le client et le serveur échangent des données ; l'authentification peut également être désactivée. Windows NT prend en charge l'emprunt d'identité, qui permet à un objet d'acquérir les autorisations d'un utilisateur ou d'un client authentifié, contrairement à Windows CE. Dans Windows CE, l'authentification est effectuée au niveau de la connection uniquement (RPC_C_AUTH_LEVEL_CONNECT). À ce niveau, DCOM exécute un contrôle d'authentification la première fois qu'un client appelle le serveur et, si le client passe le contrôle, aucune authentification n'a lieu pour les appels suivants. Sur Windows CE, un objet DCOM peut appeler avec n'importe quel niveau d'authentification, mais les appels entrants n'arriveront jamais avec un niveau d'authentification supérieur à CONNECT. En outre, l'authentification Windows CE peut être désactivée (RPC_C_AUTHN_LEVEL_NONE).

Après une authentification réussie, le contrôle d'accès est exécuté en fonction d'une liste d'accès qui identifie les "principaux" autorisés à lancer des classes sur le système. La liste est créée à partir des paramètres du registre DefaultAccessPermissions ou fournie par programme à partir de l'objet DCOMAccessControl lors de l'initialisation du serveur.

L'authentification s'effectue normalement lorsqu'un client Windows CE est connecté par un réseau à un contrôleur de domaine Windows NT, qui gère les autorisations de sécurité. Cependant, dans un environnement mobile, lorsqu'un contrôleur de domaine Windows NT n'est pas toujours disponible ou lorsque le réseau ne fonctionne pas sous Windows NT, vous pouvez créer une base de données locale de noms d'utilisateur et de mots de passe destinée au progiciel de sécurité Windows NT LAN Manager pour la vérification des autorisations. Windows CE fournit les API suivantes pour créer et gérer cette base de données :

• NTLMEnumUser renvoie le nom d'utilisateur enregistré pour tout index spécifique de la base de données.
  
  
• NTLMSetUserInfo crée un utilisateur dans la base de données (s'il n'en existe aucun) et modifie les informations de cette entrée.
  
  
• NTLMDeleterUser supprime un utilisateur de la base de données.

Utilisation de SSL pour les communications réseau sécurisées

Pour les communications réseau sécurisées, Windows CE prend également en charge les protocoles de sécurité SSL versions 2.0 et 3.0, qui sont disponibles par l'intermédiaire de WinInet ou directement à partir de WinSock. Ces applications utilisent des sockets sécurisés pour envoyer et recevoir les données codées via les lignes de communication.

L'implémentation de sockets sécurisés s'appuie sur l'authentification pour déterminer si un hôte éloigné est fiable. Les hôtes éloignés établissent leur fiabilité en obtenant un certificat auprès d'une autorité de certification (AC). Celle-ci peut à son tour avoir une certification d'une autorité supérieure, et ainsi de suite, créant ainsi une chaîne de confiance. Pour savoir si un certificat est fiable, une application doit déterminer l'identité de la CA racine, puis s'assure qu'il est digne de confiance.

Windows CE 3.0 SSL gère une base d'AC fiables, qui est indépendante du magasin de certificats CryptoAPI 2.0. Lorsqu'une application tente d'établir une connection sécurisée, Windows CE 3.0 extrait le certificat racine de la chaîne de certification et le vérifie par rapport à la base de données AC. Il délivre le certificat serveur à l'application au moyen d'une fonction de rappel de validation de certificat, accompagné des résultats de la comparaison avec la base de données AC.

C'est aux applications qu'incombe l'ultime responsabilité de vérifier qu'un certificat est acceptable. Elles peuvent en accepter ou en rejeter. Si un certificat est rejeté, la connection n'est pas réalisée. Un certificat doit répondre, au minimum, à deux exigences : il est actuel et l'identité qu'il contient correspond à l'identité de l'entité à laquelle vous vous connectez. Une liste de CA racine est incluse dans la base de données Channel CA. Il est à noter que ces certificats racine expirent et qu'une mise à jour périodique peut s'avérer nécessaire. Il est également possible d'actualiser la base de données en éditant le registre.

Les autorités de certification racine suivantes sont incluses dans la base de données Windows CE 3.0 Channel  CA :

• VeriSign/RSA Secure Server
  
  
• VeriSign Class 1 Public Primary CA
  
  
• VeriSign Class 2 Public Primary CA
  
  
• VeriSign Class 3 Public Primary CA
  
  
• GTE Cybertrust ROOT
  
  
• Thawte Personal Basic CA
  
  
• Thawte Personal Freemail CA
  
  
• Thawte Personal Premium CA
  
  
• Microsoft Root Authority
  
  
• Root SGC Authority
  
  
• Entrust.net Secure Server CA
  
  
• Entrust.net Premium Secure Server CA

Cryptage des données à l'aide de CryptoAPI

CryptoAPI fournit des services qui permettent aux développeurs d'applications d'ajouter des schémas de cryptage/décryptage de données, d'authentifier à l'aide de certificats numériques et de coder/décoder ASN.1 dans leurs applications Win32. Les développeurs peuvent utiliser les fonctions de CryptoAPI sans connaître en détail l'implémentation sous-jacente. CryptoAPI fonctionne avec plusieurs fournisseurs de services cryptographiques (CSP) qui exécutent les fonctions cryptographiques proprement dites, telles que le cryptage, le décryptage, le stockage et la sécurité des clés.

Les trois éléments du système cryptographique Microsoft sont le système d'exploitation, l'application et le CSP. Les applications communiquent avec le système d'exploitation par l'intermédiaire de la couche CryptoAPI, et le système d'exploitation communique avec les CSP via l'interface de fournisseurs de services cryptographiques (CSPI). La figure suivante illustre ce principe.

Figure 2. Les applications communiquent avec le système d'exploitation par l'intermédiaire de la couche CryptoAPI, et le système d'exploitation communique avec les CSP via l'interface de fournisseurs de services cryptographiques (CSPI).

Les CSP sont des modules indépendants, généralement une DLL, qui exécutent toutes les opérations cryptographiques. En principe l'idéal, les CSP sont écrits pour être indépendants d'une application particulière afin que n'importe quelle application puisse s'exécuter avec plusieurs CSP. En réalité, certaines applications ont des exigences spécifiques qui nécessitent un CSP personnalisé. Les OEM peuvent écrire leur propre progiciel CSP et l'ajouter au registre.

Le tableau suivant décrit les deux CSP prédéfinis inclus dans Windows CE 3.0.

CSP	Description
Fournisseur de base RSA	Prend en charge la signature numérique et le cryptage de données. Il est considéré comme un outil cryptographique à usage général.
Fournisseur étendu RSA	Prend en charge le cryptage de clés 128 bits. Il assure une sécurité renforcée grâce à des clés plus longues et à des algorithmes supplémentaires.

Les applications peuvent utiliser les fonctions CryptoAPI pour :

• générer et échanger des clés ;
  
  
• crypter et décrypter des données ;
  
  
• coder et décoder des certificats ;
  
  
• gérer et sécuriser des certificats ;
  
  
• créer et vérifier des signatures numériques, et calculer du hachage.

Les fonctionnalités fournies par CryptoAPI 1.0 dans Windows CE 3.0 sont très similaires à celles de Windows 2000 et Windows NT ; cependant, seule un sous-ensemble de CryptoAPI 2.0 est pris en charge. Les fonctionnalités suivantes disponibles dans CryptoAPI 2.0 sont prises en charge dans Windows CE 3.0 : le codage et le décodage de certificats numériques conformément à la norme X.509 et la gestion de certificats. Les fonctionnalités suivantes ne sont pas prises en charge : les outils de gestion des listes de révocation de certificat et des listes de certificats fiables, les fonctions de messagerie de bas niveau et les fonctions de messagerie simplifiées.

Coredll.lib exporte les fonctions CryptoAPI 1.0 et Crypto32.lib les fonctions CryptoAPI 2.0 ; toutes ces fonctions sont définies dans le fichier d'en-tête Wincrypt.h.

Isolement des données sensibles dans une carte à puce

Vous pouvez ajouter une couche de sécurité à un système Windows CE en utilisant des cartes à puce pour stocker les informations d'authentification, ou un mécanisme de signature numérique. Vous pouvez écrire un fournisseur CryptoAPI personnalisé qui exploite la capacité d'une carte à puce pour stocker les informations en toute sécurité.

Le sous-système de cartes à puce Windows CE prend en charge CryptoAPI par l'intermédiaire de fournisseurs de services de cartes à puce (SCSP), qui sont des DLL autorisant l'accès à des services spécifiques. Le sous-système asssure un lien entre le lecteur de cartes à puce et les applications. Windows CE ne fournit pas de SCSP ; en général, le vendeur de cartes à puce fournit les SCSP appropriés. Cependant, les interfaces décrites dans le tableau suivant sont disponibles dans Windows CE.

Composant du sous-système	Fichier	Description
Gestionnaire de ressources	Scard.dll	Utilise les API Win32 pour gérer l'accès à plusieurs lecteurs et cartes à puce.
Bibliothèque d'aide du gestionnaire de ressources	Winscard.dll	Expose les services PC/SC pour l'utilisation des cartes à puce et des lecteurs de cartes à puce.
Bibliothèque d'aide du lecteur de cartes à puce	Smclib.lib	Fournit des routines de support pour pilote de carte à puce et un support additionnel de protocole T=0 et T=1 pour des pilotes spécifiques.
Exemples de pilotes de lecteurs de cartes à puce	Pscr.dll bulltlp3.dll stcusb.dll	Pilote de lecteur SwapSmart PC. Pilote de lecteur série. Pilote de lecteur USB.

Un système de carte à puce standard se compose d'applications, d'un sous-système qui traite les communications entre les lecteurs de cartes à puce et les applications, de lecteurs et de la carte à puce. Le schéma suivant illustre l'architecture d'un système de carte à puce Windows CE.

Figure 3. Architecture d'un système de carte à puce Windows CE

L'implémentation d'une partie de la fonctionnalité fournisseurs de services CryptoAPI de cartes à puce dans un matériel distinct garantit la sécurité des clés et des opérations cryptographiques, care :

• elle assure un stockage résistant aux falsifications pour la protection des clés privées et autres formes d'informations personnelles ;
  
  
• elle isole des autres parties du système les calculs à sécurité élevée qui impliquent l'authentification, les signatures numériques et les échanges de clés ;
  
  
• elle permet la portabilité des autorisations et autres informations personnelles.

Dans une organisation qui utilise des cartes à puce, les utilisateurs n'ont pas à se rappeler tous les mots de passe (uniquement un code personnel) et peuvent utiliser le même certificat à d'autres fins de sécurité commme la signature numérique d'un courrier électronique.

Identification des systèmes de façon unique

Les OEM peuvent fournir une balise d'identification unique pour un système Windows CE, accessible par une application. Par exemple, vous pouvez avoir besoin d'identifier chaque téléphone cellulaire qui utilise votre image OS à des fins de facturation et de sécurité.

Windows CE utilise la structure DEVICE_ID pour stocker le numéro d'identification unique du système. Le contrôle d'entrée/sortie IOCTL_HAL_GET_DEVICEID de la couche d'adaptation OEM renvoie le DEVICE_ID en cours affecté au système Windows CE. Pour plus d'informations, reportez-vous à "Fourniture d'informations sur les plates-formes pour les applications" (en anglais) dans la section Développement du système d'exploitation (en anglais) de la documentation Platform Builder.

Utilisation du mode noyau protégé

L'utilisation du mode plein noyau, lors de l'exécution des tâches, laisse l'ensemble du système vulnérable, car Windows CE ignore les fonctions de sécurité. En mode plein noyau, les applications peuvent accéder à toute mémoire physique du système. Ce dernier reste ouvert aux applications malveillantes qui recherchent des informations privilégiées et des codes de cryptage, ou à celles qui suppriment des fichiers.

Bien que l'exploitation en mode plein noyau augmente les performances, elle peut ne pas être acceptable dans un environnement ouvert non protégé. Vous pouvez désactiver le mode plein noyau ; mettez à 1 le second bit des ROMFLAGS dans le fichier Config.bib. Selon le paramétrage des autres indicateurs, la valeur de ROMFLAGS peut varier.

Utilisation de l'authentification numérique dans le chargeur d'unitialisation à distance

Le chargeur d'initialisation à distance est un programme stocké dans la ROM qui sert à mettre à jour le fichier image OS (Nk.bin) à l'aide de la mémoire flash ou d'un serveur éloigné. Pour assurer l'intégrité de l'image OS qui est téléchargée, vous pouvez utiliser le cryptage numérique afin de signer et des vérifier les fichiers image OS. Le chargeur utilise la CryptoAPI Microsoft pour authentifier les données à l'aide de l'algorithme de hachage asymétrique (CALG_SHA), qui produit une valeur de hachage de 160 bits.

Platform Builder 3.0 fournit les outils suivants pour l'authentification numérique :

• makekey.exe, qui crée une paire de clés publique/privée ;
  
  
• mksigs.exe, qui signe les fichiers image OS ;
  
  
• addsigs.exe, qui ajoute les signatures au fichier manifeste.

Pendant la procédure de téléchargement de l'image OS, le chargeur d'initialisation à distance extrait les signatures du fichier manifeste et vérifie l'authenticité de chaque fichier image OS. Si l'authentification échoue, le téléchargement s'arrête, et l'utilisateur en est informé.

Pour plus d'informations

Pour plus de détails sur SSPI, SSL (Secure Sockets Layer), CryptoAPI et les cartes à puce, reportez-vous à la documentation du développeur de logiciels CE .

Pour plus de détails sur la sécurité au niveau du noyau (modèle sécurisé et mode noyau), le libellé de système et le chargeur d'initialisation à distance, reportez-vous à Windows CE Platform Builder 3.0 .

Consultez également le MSDN Online Windows Embedded Developer Center (en anglais) à l'adresse http://msdn.microsoft.com/embedded.

Les informations de cet article décrivent notre technologie actuelle en matière de sécurité pour les systèmes et les applications Windows CE 3.0. Si vous pensez que la présentation et le niveau de détail était utiles ou si vous avez d'autres commentaires qui nous aideraient à vous fournir un contenu plus adapté, veuillez les envoyer à l'adresse ceuafdbk@microsoft.com.

Dernière mise à jour le lundi 12 mars 2001

• Les technologies de développement pour Windows CE sur MSDN