Les fonctionnalités de sécurité sous Windows CE .NET

Marcus Ash et
Mukkul Dasgupta
Microsoft Corporation

S'applique à :
Microsoft® Windows® CE .NET
Sécurité

Résumé : La sécurité devient une préoccupation de plus en plus essentielle dans le monde des périphériques connectés intelligents. Cet article traite des différents mécanismes et fonctionnalités de sécurité à la disposition des fabriquants d'équipement et des développeurs leur permettant d'élaborer des applications et des équipements Microsoft Windows CE .NET parfaitement sécurisés. Les sections qui suivent couvrent la sécurité du système d'exploitation Windows CE .NET, la cryptographie, l'authentification, les cartes à puce et les technologies de clé publique. Nous aborderons également les points faibles les plus courants en matière de sécurité et vous fournirons des conseils et les meilleures méthodes vous permettant de contourner ces faiblesses. Cet article contient également des liens vers des pages en anglais.

Sommaire

Création d'un environnement fiable
Sécurisation de votre réseau de communication
Sécurisation de votre réseau sans fil
Utilisation de l'authentification
Utilisation du Gestionnaire d'informations d'identification
Utilisation de SSL pour sécuriser les communications sur le réseau
Cryptage des données via CryptoAPI
Utilisation de l'API Protected Store
Génération de données aléatoires sécurisée
Stockage des données sensibles sur une carte à puce
Techniques de codage sécurisées
Autres ressources

Création d'un environnement fiable

Les périphériques Microsoft® Windows® CE envoient, reçoivent et traitent des informations devant être protégées contre toute application susceptible d'être instable. Pour protéger votre équipement, vous pouvez mettre en place des mesures de sécurité qui empêchent le chargement de modules inconnus par le système, limitent l'accès aux API système et empêchent l'accès en écriture à certaines zones du registre système. Lors de la certification d'applications, vous avez la possibilité de désigner un module comme étant de confiance ou non. Le noyau peut utiliser ces informations pour empêcher le chargement d'applications non autorisées ou limiter leur accès au système.

Pour créer un environnement fiable, implémentez les fonctions suivantes :

• OEMCertifyModuleInit
• OEMCertifyModule

Avant tout chargement d'une application par le noyau, la fonction OEMCertifyModule vérifie la signature de l'application afin de protéger votre système contre les applications inconnues. Ainsi, la plate-forme Windows CE .NET chargera une application uniquement si elle contient une signature numérique valide. Le tableau ci-dessous décrit en détail ces deux fonctions.

Le tableau suivant décrit les valeurs de retour de la fonction OEMCertifyModule.

Une fonction OEMCertifyModule peut exécuter n'importe quel contrôle sur le module chargé. Elle peut, par exemple, lancer un contrôle de redondance cyclique ou une vérification du certificat. Lorsqu'une bibliothèque de liens dynamiques (DLL) est chargée dans l'espace d'adressage d'un fichier .exe, le niveau de confiance du fichier .exe détermine le niveau d'accès final. Par exemple, lorsqu'un fichier .exe avec le niveau de confiance OEM_CERTIFY_RUN tente de charger une DLL avec un niveau de confiance supérieur (OEM_CERTIFY_TRUST), le niveau de confiance final de la DLL sera OEM_CERTIFY_RUN. Toutefois, si le fichier .exe tente de charger une DLL avec un niveau de confiance inférieur, le chargement de la DLL échouera.

Le tableau ci-dessous illustre les différentes combinaisons de niveaux de confiance entre un fichier .exe et une DLL.

Remarque Lorsque vous implémentez le modèle de sécurité approuvé, le chargement des pilotes jugés non fiables échoue. L'OEM doit vérifier que tous les pilotes tiers sont fiables.

L'implémentation du modèle approuvé la plus simple utilise la fonction OEMCertifyModule pour renvoyer OEM_CERTIFY_RUN à toutes les applications. Les applications hors de la zone ROM MODULES de l'image peuvent ainsi être exécutées, sans pour autant être autorisées à lancer des appels de fonction privilégiés. En utilisant l'implémentation OEMCertifyModule lors de l'exécution, vous n'avez plus à spécifier les applications de confiance. Si OEM_CERTIFY_FALSE est renvoyé, les applications en mémoire vive ne pourront pas être exécutées. Quelle que soit l'implémentation du modèle approuvé choisie, à savoir OEMCertifyModuleInit ou OEMCertifyModule, les fichiers du système d'exploitation résidant dans la zone ROM MODULES de l'image seront toujours exécutés avec des privilèges complets.

Voir aussi

• OEMCertifyModuleInit
• OEMCertifyModule

Création d'une signature

Pour créer une signature numérique à partir d'un fichier, exécutez le fichier via une fonction de hachage, puis signez le hachage résultant avec une clé privée. Une méthode très simple de création d'une signature numérique à partir d'un fichier consiste à utiliser Signfile.exe, inclus dans Microsoft Platform Builder. L'outil Signfile.exe permet de signer un fichier exécutable avec une clé privée fournie par un fournisseur de services cryptographiques (FSC).

Signfile.exe utilise l'algorithme de hachage SHA (Secure Hashing Algorithm) pour calculer le hachage cryptographique. SHA génère un hachage de 20 octets à partir d'une chaîne d'octets de taille arbitraire. Signfile.exe remplit le hachage comme spécifié par le standard PKCS1 (Public-Key Cryptography Standard) et le crypte en utilisant l'algorithme de clé publique RSA. Le module de la clé peut avoir une longueur comprise entre 512 et 1 024 bits. La signature résultante a la même taille que le module. Par exemple, la signature d'une clé de 1 024 bits aura une taille de 128 octets. Signfile.exe utilise ensuite les fonctions Microsoft Windows NT® ImageAddCertificate et ImageGetDigestStream pour incorporer la signature dans un fichier exécutable portable (PE).

La liste suivante énumère le contenu de la mémoire du fichier PE :

• En-tête Microsoft MS-DOS®
• Offset de l'en-tête PE (offset 0x3c)
• En-tête PE
• En-têtes de section
• Section
• Informations de débogage et certificats (le cas échéant)

L'en-tête PE commence par une séquence de 4 octets, "PE\0\0", identifiant l'en-tête MS-DOS. L'en-tête MS-DOS est suivi d'un en-tête au format de fichier objet COFF (Common Object File Format) standard. Cet en-tête COFF est lui-même suivi d'un en-tête facultatif toujours visible dans les fichiers Windows .exe et .dll. Le dernier champ d'un en-tête PE correspond à une table de répertoire de données facultative. Le tableau ci-dessous indique la taille des éléments de l'en-tête PE.

Chaque entrée de la table de répertoire de données se compose d'une structure IMAGE_DATA_DIRECTORY. La cinquième structure de la table de répertoire de données contient des informations sur la table de certificats. Ces informations sont stockées dans un tableau des structures WIN_CERTIFICATE. Un certificat correspond à une instruction dotée d'une signature numérique contenant des informations sur une entité et sur la clé publique de cette entité. Les certificats ne sont pas chargés dans la mémoire comme faisant partie du fichier PE.

L'exemple de code suivant indique le format d'une structure WIN_CERTIFICATE nécessaire pour prendre en charge le standard PKCS1.

typedef struct {
 // Champs WIN_CERTIFICATE standard (8 octets)
 DWORD dwLength;
 WORD wRevision;
 WORD wCertificateType; // = WIN_CERT_TYPE_PKCS1_SIGN
 // Champs WIN_CERT_TYPE_PKCS1_SIGN suivent
 DWORD cbSignedData;
 // attributs signés facultatifs
 BYTE bSignedData[MAX_WIN_CERT_SIGN_DATA_LEN];
 BYTE bSign[MAX_RSA_KEY_BITS/8]; // Signature PKCS1
} PKCS1_MODULE_SIGN ;

Signfile.exe ajoute la structure WIN_CERTIFICATE à la fin du fichier et met à jour l'en-tête du fichier de façon appropriée. Pour obtenir un exemple de code de Signfile.exe, reportez-vous à %_WINCEROOT%\Public\Common\Oak\Tools\Signfile.

Vérification d'une signature

Un OEM peut vérifier que les fichiers contiennent une signature appropriée en utilisant la fonction OEMCertifyModule avant que le fichier soit chargé par le noyau.

Avec cette méthode, le noyau applique la même formule de hachage afin de calculer une signature lors du processus de vérification lancé au cours du processus de génération de la signature. La fonction OEMCertifyModule compare la signature calculée d'après le hachage à la signature du fichier. Si les deux signatures ne correspondent pas, OEMCertifyModule empêche le chargement du fichier.

Étant donné que la taille d'un en-tête de fichier PE peut varier, OEMCertifyModule peut ne pas être capable de traiter la totalité de l'en-tête dans un seul appel. Les signatures situées à la fin des fichiers rendent impossible la spécification d'une fonction de hachage dans la signature même ; vous devez donc utiliser le hachage SHA ou une autre fonction de hachage définie. Lors du calcul du hachage, SHA exclut les données suivantes du fichier :

• Champ Checksum de l'en-tête COFF de Windows (4 octets)
• Structure du répertoire de données des certificats (8 octets)
• Structure WIN_CERTIFICATE (taille variable)

Vous pouvez soit écrire vous-même le code utile pour implémenter la vérification de la signature et l'outil de signature, soit utiliser l'exemple de bibliothèque de vérification Loadauth.lib. Cette dernière est incluse dans Platform Builder, dans le répertoire spécifique au processeur, sous %_WINCEROOT%\Public\Common\Oak\Lib et dans l'outil de signature Signfile.exe.

Le tableau suivant décrit les fonctions contenues dans la bibliothèque Loadauth.lib.

Voici comment utiliser l'exemple de bibliothèque de vérification (Loadauth.lib) :

1. Ajoutez OEMCertifyModuleInit et OEMCertifyModule à la couche d'adaptation OEM (OAL) et initialisez les pointeurs fonction.
2. Créez et exportez une clé publique pré-programmée.

   La clé doit se présenter sous un format PUBLICKEYBLOB. Vous pouvez utiliser l'outil Signfile.exe pour compléter cette étape.

3. Incorporez la clé publique dans l'image du système d'exploitation (SE).

   Vous pouvez alors modifier la couche OAL en fonction de l'exemple de code dans %_WINCEROOT%\Platform\%BSP%\Kernel\Hal.

L'exemple de code suivant illustre l'implémentation des fonctions OEMCertifyModuleInit et OEMCertifyModule à l'aide des fonctions Loadauth.lib.

/* 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 la signature lors du chargement
// des exécutables de la RAM
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 de la bibliothèque Loadauth
extern BOOL CertifyModuleInit(void);
extern BOOL CertifyModule(PBYTE pbBlock, DWORD cbBlock);
extern BOOL CertifyModuleFinal(PBYTE *ppbSignData,
 PDWORD pcbSignData);

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

// Appelée 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é comme
 // 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 la signature.\r\n"));
 #endif

 // Renvoie l'un des niveaux OEM_CERTIFY
 return dwTrustLevel;
 }
}

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

Remarque Vous pouvez utiliser n'importe quel nom pour les fonctions OEMCertifyModuleInit et OEMCertifyModule. Il reste cependant important d'initialiser les deux pointeurs kernel, pOEMLoadInit et pOEMLoadModule, dans la fonction OEMInit vers ces fonctions nommées.

Signfile.exe

Signfile.exe signe un fichier exécutable avec une clé privée fournie.

Cet outil fonctionne également avec les paramètres de ligne de commande suivants :

signfile [ paramètres ]

Paramètres

-f PEFile
Spécifie le fichier à signer.

-a
Attache la signature au fichier PE.

-k KeyName
Utilise une clé privée du conteneur de clé CryptoAPI nommé.

-p Cfile
Sort la clé publique vers un fichier sous forme de structure C.

-s AttribString
Spécifie une chaîne d'attributs facultative à inclure dans la signature. Par exemple, vous pouvez ajouter une chaîne pour indiquer le niveau de confiance de l'application.

-p SignFile
Sort la signature vers un fichier.

L'exemple de ligne de commande suivant illustre comment signer Xyz.dll à l'aide de la clé privée stockée dans le conteneur de clé TESTKEY1024.

Signfile -fXyz.dll -a -kTESTKEY1024

Pour obtenir davantage d'informations sur cet outil, reportez-vous à Création de signatures numériques.

API de confiance

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

Le tableau suivant liste les API pouvant être appelées uniquement par des applications de confiance :

Le tableau ci-dessous liste les API basées sur un fichier, influencées par l'attribut SYSTEM qui peut être défini sur un fichier.

Pour obtenir davantage d'informations, reportez-vous à Sécurisation du système de fichiers.

Le tableau ci-dessous liste les API de base de données influencées par l'attribut SYSTEM qui peut être défini sur une base de données.

Pour obtenir davantage d'informations, reportez-vous à Sécurité des bases de données.

De plus, les indicateurs de débogage DEBUG_ONLY_THIS_PROCESS et DEBUG_PROCESS de l'API CreateProcess sont soumis à des restrictions. Si ces indicateurs sont utilisés par une application jugée non fiable, le processus identifié sera certes lancé mais sans débogage.

Les indicateurs de débogage DEBUG_ONLY_THIS_PROCESS et DEBUG_PROCESS de l'API CreateProcess sont également soumis à des restrictions.

L'architecture de registre sécurisée offerte par Windows CE .NET autorise uniquement les applications de confiance que vous avez identifiées à modifier les clés et les valeurs dans les zones protégées du registre.

Étant donné que la majorité du registre reste non protégé, les OEM doivent donc placer toutes les informations de registre importantes dans une clé protégée.

Remarque Les applications disposent toutes d'un accès en lecture seule pour l'ensemble des clés et des valeurs de registre.

Sous Windows CE .NET, les clés de registre racines suivantes et leurs sous-clés sont protégées contre les applications non fiables :

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

Les applications non fiables ne sont pas autorisées à modifier les données protégées. À chaque tentative d'utilisation des fonctions de registre listées ci-dessous, la valeur ERROR_ACCESS_DENIED est renvoyée.

• RegSetValueEx
• RegCreateKeyEx
• RegDeleteKey
• RegDeleteValue

Voir aussi

• Valeurs et clés de registre protégées
• Sécurité des bases de données
• Interface SE principale

Sécurité du magasin d'objets

Le magasin d'objets fournit plusieurs éléments de sécurité dans un environnement fiable. Les fichiers système sont protégés, rendant ainsi impossible toute lecture ou modification par des applications non fiables. Ces fichiers système sont en fait des fichiers pour lesquels l'attribut système a été défini. Pour obtenir davantage d'informations, reportez-vous à Sécurisation du système de fichiers.

Le système protège également un ensemble de clés de registre pour éviter qu'elles ne soient modifiées par des applications non fiables. Les applications peuvent lire toutes les clés et les valeurs de registre, mais seules les applications de confiance sont autorisées à modifier les valeurs ou les sous-clés placées sous les clés protégées. Le système protège un ensemble de base de clés que l'OEM peut étendre à sa guise. Pour obtenir davantage d'informations, reportez-vous à Valeurs et clés de registre protégées et Demande de clés de registre sécurisées supplémentaires.

De plus, il est possible d'affecter un indicateur système aux bases de données stockées dans le magasin d'objets. Les bases de données système ne peuvent être ni lues, ni modifiées par des applications non fiables. Celles qui sont stockées dans des volumes de bases de données distincts et non pas dans le magasin d'objets peuvent être protégées en définissant l'attribut système sur le fichier, comme pour tout fichier du système de fichiers.

Sécurité des bases de données

Windows CE .NET permet aux applications de confiance de marquer un indicateur système sur des bases de données afin de refuser tout accès aux appelants jugés non dignes de confiance. Les applications non fiables ne peuvent ainsi ni ouvrir, ni lire, ni modifier les bases de données marquées avec cet indicateur système. Les appelants de confiance peuvent définir l'indicateur CEDB_SYSTEMDB à l'intérieur de la structure CEDBASEINFOEX transmise à CeCreateDatabaseEx2 ou à CeSetDatabaseInfoEx2 afin de protéger une base de données.

Cette fonctionnalité permet de protéger une seule base de données et non pas le volume entier. Pour protéger des volumes de bases de données, il vous suffit de définir FILE_ATTRIBUTE_SYSTEM sur le fichier du volume. Il est impossible de créer des bases de données système dans des volumes de bases de données ne disposant pas de FILE_ATTRIBUTE_SYSTEM défini pour empêcher les applications non fiables d'accéder et/ou de supprimer un fichier contenant une base de données système via les API de fichier Microsoft Win32®. Étant donné qu'une application non fiable ne peut pas accéder à un fichier si l'attribut du fichier système est défini, l'affectation d'un indicateur système à une base de données d'un volume ne permet pas d'accroître la sécurité. Cette fonctionnalité se révèle, par conséquent, plus utile pour les bases de données stockées dans le magasin d'objets. Si vous supprimez l'attribut du fichier système d'un volume de bases de données contenant une base de données système, vous exposez cette base de données à un risque d'accès par des applications non fiables, ce qui n'est pas recommandé.

Sécurisation de votre réseau de communication

La sécurisation des communications est particulièrement délicate puisque l'interface réseau fournit un point d'accès à un périphérique susceptible d'être utilisé à distance par des pirates. Les intrusions via le réseau assurent en effet aux pirates un moyen efficace de rester anonyme ou d'éviter d'être détecté. Déterminer la source de l'intrusion devient alors une tâche assez difficile.

De façon générale, les applications client d'un réseau sont relativement plus sûres que les serveurs ou les applications de service. Les clients établissent des contacts avec des serveurs spécifiques et précisent la nature de leurs requêtes. Cela permet aux applications client de déterminer la nature des données entrantes et l'identité du serveur ou du service ; elles peuvent ensuite rejeter les communications non sollicitées. Même si les clients ne sont pas immunisés contre les problèmes de sécurité, ils assurent un plus grand contrôle sur la nature des communications puisque les communications partent d'eux, ce qui réduit l'étendue de leur vulnérabilité. Les navigateurs, les clients de messagerie électronique et les clients FTP sont des exemples d'applications client.

Les serveurs sont, quant à eux, plus exposés étant donné qu'ils attendent les requêtes envoyées par les clients sur le réseau. Ces requêtes peuvent être émises depuis n'importe où sur le réseau. Lorsque le serveur est exposé à une interface publique, sa vulnérabilité est très fortement augmentée. Les serveurs Web, FTP et Telnet sont des exemples d'applications serveur.

La liste suivante décrit les diverses techniques de correction qui sont à votre disposition :

• Authentification. Avant de configurer l'authentification, vous devez décider s'il est préférable d'authentifier le client par rapport au serveur, le serveur par rapport au client, ou les deux. Lorsque vous vous connectez à une banque, par exemple, vous devez préalablement vérifier l'identité de l'entité à laquelle vous transmettez vos informations d'identification. Dans ce cas, c'est une authentification mutuelle qui est requise. Autre exemple, lorsque vous naviguez dans un site Web pour obtenir des informations, connaître l'identité de l'entité qui vous fournit ces informations ne vous est d'aucune utilité.

  Si vous utilisez des méthodes d'authentification, sachez que certaines méthodes sont plus vulnérables que d'autres. Certaines méthodes, en effet, transmettent des noms d'utilisateur et des mots de passe en texte clair, permettant ainsi à quiconque surveillant les communications d'intercepter les informations d'identification des utilisateurs.

  Pour obtenir davantage d'informations sur l'authentification, reportez-vous à Services d'authentification.

• Technologies anti-falsifications renforçant la confidentialité. Afin de protéger les données et autres biens contre toute tentative d'accès, de modification et de suppression, vous pouvez utiliser le protocole SSL (Secure Sockets Layer). Ce protocole crypte les données au moment où elles passent entre le client et le serveur et utilise des codes d'authentification de messages pour assurer l'intégrité des données. Pour obtenir davantage d'informations, reportez-vous à Utilisation de SSL pour sécuriser les communications sur le réseau.
• Accès restreint aux services et aux données. Afin de protéger les données et autres biens, vous pouvez utiliser les listes de contrôle d'accès avec les serveurs COM ou Web pour identifier les utilisateurs et définir les autorisations d'accès aux ressources ou aux services. La majorité des applications de serveur disposent de leur propre mécanisme de contrôle.
• Cryptage. Afin de préserver la confidentialité et l'intégrité des données, vous pouvez utiliser CryptoAPI. Cette API fournit des services de schémas de cryptage/décryptage, d'authentification via des signatures numériques et de codage/décodage depuis et vers ASN.1 aux applications Microsoft Win32.

  Pour obtenir davantage d'informations, reportez-vous à Système de cryptage Microsoft.

• Processus isolé et traitement des exceptions visant à apporter la stabilité et la disponibilité des services. Assurez-vous que vos serveurs ou vos applications de service gèrent correctement les échecs de processus ou mémoire à l'aide de messages d'erreur efficaces. Certains pirates peuvent provoquer l'échec général de votre application ou bloquer les services du réseau en inondant le périphérique de requêtes ou en envoyant des fichiers trop volumineux. Message Queuing (MSMQ), par exemple, rejette systématiquement les messages SOAP envoyés par HTTP dès que leur taille dépasse les limites définies dans le registre. MSMQ envoie alors un message d'erreur à chaque message rejeté. La taille de la mémoire tampon peut être optimisée pour des applications spécifiques via le registre.

  Vous pouvez apporter une certaine stabilité à votre application en mettant fin à un service avant que les ressources d'un périphérique ne soient toutes consommées. Par exemple, Universal Plug and Play (UPnP) limite le nombre d'abonnés au service et rejette tous les nouveaux abonnements dès que le nombre maximum a été atteint. La limite d'abonnements peut être optimisée pour des applications spécifiques via le registre.

• Ajout d'un pare-feu entre deux réseaux. Afin d'empêcher l'exposition sur Internet de certains paquets de données internes, vous pouvez ajouter un pare-feu réseau. Ce pare-feu empêche également le trafic Internet aléatoire d'entrer dans votre réseau.

Voir aussi

• Services d'authentification
• Utilisation de SSL pour sécuriser les communications sur le réseau
• Cryptographie
• Certificats

Sécurisation de votre réseau sans fil

Contrairement aux réseaux câblés, les réseaux sans fil traversent les murs des bâtiments. Dans la plupart des déploiements, la sécurité des réseaux câblés dépend de la sécurité physique des réseaux installés dans des locaux verrouillés à l'intérieur des bâtiments. Et pour accéder au réseau, il vous faut d'abord passer la sécurité du bâtiment, alors que les réseaux sans fils peuvent être contrôlés et attaqués depuis l'extérieur.

Afin de réduire les risques liés à la sécurité, de nombreux réseaux sans fil disposent de moyens pour crypter les transmissions. L'utilisation de clés réseau de cryptage statique simple (WEP) ou de technologies plus avancées qui génèrent et activent les clés WEP vous assure une plus grande confidentialité. Si vous souhaitez utiliser une protection plus performante, en particulier 802.11, nous vous conseillons la norme industrielle 802.1X telle qu'elle est définie par l'IEEE (Institute of Electrical and Electronics Engineers, Inc.). Cette protection offre une authentification et une confidentialité individuelles grâce à sa capacité à générer et à activer les clés WEP. De plus, les clés WEP peuvent être générées pour chaque utilisateur et activées généralement en fonction de la politique définie. Pour obtenir davantage d'informations, consultez le site Web de l'IEEE.

Remarque 802.1X est conçu uniquement pour les déploiements professionnels. Windows CE .NET ne prend pas en charge l'authentification mutuelle dans les réseaux sans fil.

Windows CE .NET utilise plusieurs méthodes d'authentification pouvant être connectées à 802.1x afin de personnaliser ces méthodes d'authentification. Vous pouvez recourir aux noms d'utilisateur et mots de passe simples, aux certificats, aux cartes à puce ou à la biométrie. EAP-MD5 gère les noms d'utilisateur et les mots de passe et EAP-TLS gère l'authentification basée sur les certificats. Vous pouvez également développer votre propre méthode d'authentification. Pour obtenir davantage d'informations, reportez-vous à Authentification 802.1x ou consultez le site Web de l'IEEE.

Mais attention, d'autres problèmes de sécurité, cette fois-ci non liés au logiciel, risquent de survenir. De simples interférences peuvent entraîner le ralentissement, voire l'interruption d'un réseau, si le spectre des fréquences radio du réseau se mélange aux interférences radioélectriques. Même si cette intrusion ne compromet pas directement la confidentialité, elle constitue un risque de refus de service. Contactez votre fournisseur de technologies sans fil afin de déterminer ensemble la meilleure approche à adopter pour éliminer ce risque.

Utilisation de l'authentification

Il vous est possible de contrôler l'accès au périphérique et aux services pour l'accorder uniquement aux utilisateurs autorisés, en mettant en place des protocoles d'authentification disponibles sous Windows CE .NET. Certains sont déjà incorporés dans la fonctionnalité et si vous souhaitez en utiliser d'autres, vous devrez ajouter des fonctionnalités à votre système d'exploitation. Si vous souhaitez, par exemple, utiliser NTLM SSP et/ou Kerberos SSP, vous devrez ajouter ces fonctionnalités à votre système d'exploitation. NTLM et Kerberos sont implémentés via l'interface SSPI (Security Support Provider Interface).

SSPI est disponible via le module Secur32.dll, qui correspond en fait à une API très courante et parfaitement définie permettant d'obtenir des services de sécurité intégrés pour l'authentification, l'intégrité et la confidentialité des messages. L'interface SSPI fournit une couche d'abstraction entre les protocoles de l'application et les protocoles de sécurité. Étant donné que chaque application dispose de ses propres méthodes d'identification ou d'authentification des utilisateurs et de ses propres techniques de cryptage des données lors de leur circulation sur le réseau, SSPI fournit un moyen d'accéder aux bibliothèques de liens dynamiques (DLL) contenant plusieurs schémas d'authentification et de données de cryptage. Le nom exact de ces DLL est : fournisseurs de prise en charge de la sécurité (SSP).

La figure suivante illustre la relation entre les DLL SSP et l'interface SSPI Secur32.dll, Winsock et WinInet.

Les fournisseurs de prise en charge de la sécurité disponibles sous Windows CE .NET sont :

• Microsoft Windows NT® LAN Manager SSP (NTLM SSP). NTLM SSP est basé sur le protocole de simulation/réponse de Microsoft Windows NT LAN Manager et sur le protocole d'authentification NTLM version 2 utilisés sur les réseaux exécutant les versions du système d'exploitation Windows NT ou des serveurs Windows CE .NET.
• Kerberos SSP. Le protocole Kerberos définit les modes d'interaction entre des clients et un service d'authentification du réseau. Le protocole d'authentification Kerberos fournit un mécanisme d'authentification mutuelle entre les entités avant l'établissement d'une connexion réseau sécurisée.

Nous vous rappelons que certains mécanismes sont plus sécurisés que d'autres. Lors du choix du mécanisme le mieux adapté à votre application, gardez à l'esprit que l'authentification Basic est moins puissante que Kerberos.

La liste suivante récapitule les meilleures pratiques d'authentification :

• Utilisez le composant StartUI pour protéger par mot de passe un périphérique. Sans mot de passe, chacun peut accéder au périphérique et réussir à atteindre les ressources d'un réseau.
• Activez les fonctions de verrouillage du périphérique de façon à ce qu'un mot de passe soit demandé à chaque tentative d'accès, une fois le périphérique sous tension.
• Si vous devez conserver les informations d'identification utilisateur sur un périphérique, sauvegardez-les dans le registre. Pour garantir une protection optimale, ne stockez pas ces informations sur le périphérique même. Ainsi, en cas de vol du périphérique, les informations d'identification réseau ne pourront pas être extraites et détournées par les pirates.
• Si vous souhaitez autoriser les utilisateurs à enregistrer les informations d'authentification sur le périphérique, utilisez le Gestionnaire d'informations d'identification. Vous pouvez néanmoins accroître le niveau de protection en enregistrant les informations d'identification utilisateur ailleurs que sur le périphérique même. Si l'application utilise le Gestionnaire d'informations d'identification, vous pouvez définir la valeur du registre DisallowSavedNetworkPasswords sur 1. Ainsi, en cas de vol du périphérique, les informations d'identification réseau ne pourront pas être extraites et détournées par les pirates.
• Utilisez des cartes à puce pour stocker les informations d'identification utilisateur. Ainsi, en cas de vol du périphérique, les informations d'identification réseau ne pourront pas être extraites et détournées par les pirates.
• Utilisez NTLM SSP ou Kerberos SSP dans les applications client-serveur. Les applications client fournissent le nom d'utilisateur, le nom de domaine et le mot de passe, alors que les applications serveur et client échangent des jetons pour réaliser l'authentification.
• Utilisez Kerberos pour obtenir une authentification mutuelle entre les entités. Le serveur peut ainsi authentifier le client et autoriser ensuite celui-ci à authentifier le serveur. Attention, NTLM ne fournit aucune authentification mutuelle.
• Utilisez un protocole d'authentification puissant. Avec NTLM SSP, vous avez la possibilité de spécifier des protocoles d'authentification distincts pour le client et pour le serveur. Pour éviter que NTLM SSP utilise un protocole d'authentification peu puissant, définissez la valeur du registre LmCompatibilityLevelClient sur 3. Le client utilisera alors uniquement NTLM v2 pour l'authentification ; toutefois, si le serveur ne peut pas prendre en charge le protocole NTLM v2, l'authentification échouera. Vous pouvez également définir la valeur LmCompatibilityLevelServer sur 2 ou 3. Le serveur utilisera alors uniquement NTLM v2 ; toutefois, si le client ne peut pas prendre en charge le protocole NTLM v2, l'authentification échouera.

  Le protocole d'authentification NTLM v2 est disponible uniquement sous Windows CE .NET 4.1 et toute version ultérieure. Les serveurs exécutant Microsoft Windows 2000 et les versions supérieures prennent en charge NTLM v2.

• Évitez les protocoles d'authentification qui utilisent des mots de passe en texte clair. Avec Lightweight Directory Access Protocol (LDAP), remplacez le protocole d'authentification Basic par NTLM ou Negotiate. Basic utilise des mots de passe en texte clair.
• Utilisez la fonction ldap_bind_s pour accéder aux services d'authentification, comme NTLM ou d'autres fournisseurs de prise en charge de la sécurité. La fonction ldap_simple_bind se sert de mots de passe en clair pour effectuer l'authentification. Pour obtenir davantage d'informations, reportez-vous à Modèle de sécurité LDAP.

Voir aussi

• Services d'authentification
• Client LDAP
• Carte à puce
• Gestionnaire des informations d'identification

Utilisation du Gestionnaire d'informations d'identification

Le Gestionnaire d'informations d'identification vous offre la possibilité d'autoriser les utilisateurs à sauvegarder les informations d'authentification sur un périphérique. Lorsqu'un site Web ou un autre ordinateur demande une authentification via NTLM ou Kerberos, une case à cocher Mettre à jour les références par défaut ou Enregistrer le mot de passe apparaît dans la boîte de dialogue Net UI. Si l'utilisateur active cette case, le Gestionnaire d'informations d'identification conserve une trace du nom d'utilisateur, du mot de passe et des informations liées pour le service d'authentification en cours.

Lors de la prochaine utilisation de ce service, le Gestionnaire d'informations d'identification fournira automatiquement les informations stockées. En cas de refus, l'utilisateur est invité à corriger les informations d'accès. Si l'accès est accepté, le Gestionnaire d'informations d'identification remplace les anciennes informations par celles nouvellement saisies.

Voir aussi

• Gestionnaire des informations d'identification
• CredRead
• CredWrite
• CredFree

Utilisation de SSL pour sécuriser les communications sur le réseau

Pour assurer la sécurité des communications sur le réseau, Windows CE .NET prend également en charge les protocoles de sécurité Secure Sockets Layer (SSL) 2.0, SSL 3.0 et SSL 3.1, disponibles via WinInet ou directement depuis WinSock. Le protocole SSL version 3.1 est aussi appelé Transport Layer Security (TLS). Ces applications utilisent des sockets sécurisés pour envoyer et recevoir des données codées sur les lignes de communication.

L'implémentation de sockets sécurisés se base sur l'authentification pour déterminer si un hôte distant peut être considéré comme digne de confiance. Les hôtes distants doivent justifier leur fiabilité en obtenant un certificat auprès d'une autorité de certification. Cette autorité peut, à son tour, obtenir une certification auprès d'une autorité supérieure, etc., créant ainsi une chaîne de confiance. Pour s'assurer de la fiabilité du certificat présenté, les applications doivent tout d'abord déterminer l'identité de l'autorité de certification racine, puis juger si elle est digne de confiance ou non.

Les protocoles SSL Windows CE .NET utilisent des autorités de certification de confiance. Lorsqu'une application tente une connexion sécurisée, le protocole SSL extrait le certificat racine de la chaîne de certification et le vérifie par rapport à la base de données de l'autorité de certification. Il délivre ensuite le certificat du serveur à l'application via une fonction de rappel de la validation du certificat, accompagné des résultats de la comparaison avec la base de données de l'autorité de certification. Il est possible de modifier le comportement par défaut du SSL en changeant les clés de registre. La clé de registre de base est HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL.

L'approbation finale du certificat est de la responsabilité des applications. Celles-ci ont, en effet, la capacité d'accepter ou de refuser un certificat. En cas de refus du certificat, la connexion est interrompue. Un certificat doit satisfaire aux exigences minimales suivantes :

• Un certificat doit être encore valide.
• L'identité précisée dans le certificat doit correspondre à l'identité de destination.

Une liste des autorités du certificat racine est incluse dans la base de données des autorités de certification Schannel. Ces certificats racines ont tous des dates d'expiration et doivent donc être mis à jour régulièrement. La base de données peut également être mise en jour en ajoutant des certificats au magasin cryptoAPI.

Les autorités de certificats racines suivantes sont incluses dans le magasin de certificats racines Windows CE .NET :

• 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
• ThawtePremium Server CA
• Thawte Server CA
• Entrust.net Secure Server CA
• Entrust.net Premium Secure Server CA, également appelée Entrust.net CA (2048)

Voir aussi

• Prise en charge SSL

Cryptage des données via CryptoAPI

CryptoAPI fournit des services permettant aux développeurs d'applications d'ajouter des schémas de cryptage/décryptage de données, de procéder à l'authentification via des signatures numériques, ainsi qu'au codage vers ASN.1 et/ou au décodage depuis ASN.1 vers leurs applications Microsoft Win32®. Les développeurs d'applications peuvent utiliser les fonctions prévues dans CryptoAPI, même s'ils ne maîtrisent pas l'implémentation sous-jacente. CryptoAPI exploite plusieurs fournisseurs de services cryptographiques (FSC) qui exécutent les fonctions cryptographiques réelles, telles que le cryptage, le décryptage et le stockage et la sécurité des clés.

Les trois composants du système de cryptage Microsoft sont : le système d'exploitation, l'application et le FSC. Les applications communiquent avec le système d'exploitation via la couche CryptoAPI et le système d'exploitation communique avec les FSC via l'interface du fournisseur de services cryptographiques. La figure suivante illustre ce concept.

Les FSC sont des modules indépendants, correspondant en général à des DLL contenant des algorithmes qui exécutent toutes les opérations de cryptage. L'idéal serait de programmer les FSC de façon à les rendre entièrement indépendants des applications, pour permettre à celles-ci de fonctionner avec une multitude de FSC. Or, dans la pratique, certaines applications ont des exigences spécifiques qui les lient à un FSC personnalisé. Les OEM peuvent programmer leurs propres FSC et les ajouter au registre.

Le tableau ci-dessous décrit les FSC prédéfinis inclus sous Windows CE .NET :

Les applications peuvent utiliser les fonctions CryptoAPI afin de :

• 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 le hachage.

Les fonctionnalités offertes par CryptoAPI 1.0 sous Windows CE sont pratiquement identiques à celles existant sous Windows 2000 et Windows NT ; cependant, seul un sous-ensemble de CryptoAPI 2.0 est pris en charge. Les fonctionnalités suivantes disponibles dans CryptoAPI 2.0 sont prises en charge par Windows CE : codage et décodage de certificats numériques basés sur le standard X.509 et gestion de certificats. Les fonctionnalités non prises en charge sont : outils de gestion des listes de révocation des certificats (CRL) et des listes de certificats de confiance (CTL), fonctions de messagerie de bas-niveau et fonctions de messagerie simplifiées.

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

Le tableau suivant décrit les différents algorithmes des FSC.

* Algorithmes pris en charge par le fournisseur de services cryptographiques de base Microsoft.

Meilleures pratiques

Si possible, évitez de sauvegarder vos données sensibles dans la RAM, le système de fichiers ou le registre. Voici une liste des meilleures pratiques à respecter pour sauvegarder des données sensibles :

• Placez vos données en mémoire cache dans la mémoire de traitement plutôt que dans le registre ou le système de fichiers.
• Autorisez l'utilisateur à choisir lui-même s'il souhaite sauvegarder des données sensibles comme les informations d'identification. Le paramètre de registre HKEY_LOCAL_MACHINE\Comm\Security\DisallowSavedNetworkPasswords indique si l'option de sauvegarde des informations d'identification est affichée. Si la valeur est définie sur 1, l'option de sauvegarde n'est pas affichée. Si la valeur est définie sur 0, l'interface utilisateur autorise l'utilisateur à sauvegarder ses informations d'identification.
• Cryptez ou décryptez les données de l'application via CryptProtectData et CryptUnprotectData.

  Remarque Même si CryptProtectData et CryptUnprotectData utilisent l'entropie, la performance du cryptage dépend des données fournies pour le cryptage. Il est donc important de fournir un mot de passe puissant. Les utilisateurs qui fournissent un mot de passe faible risquent de réduire les performances du cryptage.

• Supprimez les données du stockage temporaire après utilisation.
• L'application doit obtenir, le cas échéant, un mot de passe supplémentaire ou d'autres données secrètes auprès de l'utilisateur, puis utiliser pOptionalEntropy afin de transmettre les informations à CryptProtectData ou CryptUnprotectData.

Voir aussi

• Cryptographie
• Certificats

Utilisation de l'API Protected Store

Afin de protéger les informations sensibles et d'empêcher la falsification des données, l'API Protected Store offre une solution efficace pour la cryptographie, la gestion des clés et les problèmes liés à l'expérience des utilisateurs. Les deux fonctions CryptoAPI, CryptProtectData et CryptUnprotectData, extraient les informations d'identification d'ouverture de session utilisateur pour verrouiller ou déverrouiller les données confidentielles.

Généralement, seuls les utilisateurs dont les informations d'identification d'ouverture de session correspondent à celles du crypteur peuvent décrypter les données. Le décryptage doit, en outre, être effectué sur l'ordinateur ayant servi à crypter les données.

Voici les avantages offerts par Protected Store :

• Application facile à utiliser qui extrait des données, des mots de passes optionnels ou tout autre type d'entropie et qui reçoit des données masquées.
• Protection des données vis-à-vis des autres utilisateurs susceptibles de se connecter sur le même appareil.
• Protection des données contre toute falsification lorsque l'appareil est déconnecté.
• Utilisation transparente des informations d'identification d'ouverture de session afin de fournir une entropie pour la protection des données.
• Extensibilité OEM permettant l'utilisation de jetons matériels, tels que les cartes à puce ou les appareils biométriques.

Voir aussi

• Protected Store

Génération de données aléatoires sécurisée

Utilisez CryptGenRandom afin de générer des données aléatoires. Cette fonction présente deux des propriétés indispensables à un générateur performant de nombres aléatoires : l'imprévisibilité et la distribution homogène des valeurs.

Sur un périphérique Windows CE .NET, l'entropie est générée pour CryptGenRandom par les sources suivantes :

• Commutations de thread et de kernel (CeGetRandomSeed)
• Identificateur de processus courant (GetCurrentProcessId)
• Identificateur de thread courant (GetCurrentProcessId)
• Nombre de graduations depuis le démarrage (GetTickCount)
• Heure courante (GetLocalTime)
• Informations mémoire (GlobalMemoryStatus)
• Statistiques à propos du magasin d'objets (GetStoreInformation)

Toutes ces informations sont intégrées dans une mémoire tampon hachée via MD4 et utilisées comme clé pour modifier une mémoire tampon via RC4, fourni par l'utilisateur.

Si les fonctionnalités des services cryptographiques ne figurent pas dans votre plate-forme, utilisez alors CeGenRandom afin de générer des nombres aléatoires.

Stockage des données sensibles sur une carte à puce

Pour renforcer la sécurité d'un périphérique Windows CE .NET, vous pouvez stocker vos informations d'authentification ou un mécanisme de signature numérique sur une carte à puce. Vous avez également la possibilité de programmer un fournisseur CryptoAPI personnalisé qui reproduit la fonctionnalité de stockage sécurisé d'informations de la carte à puce.

Le sous-système de carte à puce Windows CE .NET prend en charge CryptoAPI via des fournisseurs de services de cartes à puce (SCSP) correspondant à des DLL qui autorisent l'accès à des services spécifiques. Ce sous-système assure la liaison entre le lecteur de carte à puce et les applications. Aucun SCSP n'est disponible sous Windows CE .NET ; c'est le revendeur de cartes à puce qui fournit généralement les fournisseurs appropriés. Windows CE .NET fournit toutefois les interfaces décrites dans le tableau ci-dessous.

Un système de carte à puce classique se compose de plusieurs applications, d'un sous-système de gestion des communications entre les lecteurs de cartes à puce et les applications, de lecteurs et de la carte à puce.

L'implémentation partielle de la fonctionnalité du fournisseur de services de carte à puce CryptoAPI sur un équipement séparé permet de conserver des opérations et des clés de cryptage sûres en :

• fournissant un stockage à l'abri des falsifications, protégeant ainsi les clés privées ou d'autres formes d'informations privées ;
• isolant les calculs critiques en matière de sécurité qui impliquent l'authentification, les signatures numériques et l'échange de clés provenant d'autres parties du système ;
• autorisant la portabilité d'informations d'identification ou d'autres informations confidentielles.

Dans une entreprise travaillant avec des cartes à puce, les utilisateurs sont dispensés d'apprendre par cœur un mot de passe, tout au plus un numéro d'identification personnel, et peuvent réutiliser un même certificat pour d'autres opérations sécurisées, comme la messagerie électronique à signature numérique.

Voir aussi

• Carte à puce
• Cryptographie

Techniques de codage sécurisées

Le livre Writing Secure Code rédigé par Michael Howard et David LeBlanc, Microsoft Press, 2002, est une excellente source pour connaître toutes les meilleures pratiques de programmation sécurisée. Cet ouvrage décrit les faiblesses des applications face à des attaques et fournit divers exemples d'erreurs de code.

L'un des problèmes majeurs sur lequel se sont penchés les auteurs (et souvent ignoré par les développeurs d'applications) est la saturation du tampon. Nous vous conseillons donc d'éviter d'utiliser les fonctions C/C++ listées ci-dessous. En saturant le tampon, ces fonctions provoquent l'échec de votre application ou l'introduction accidentelle de code dans votre espace de traitement :

• strcpy
• strcat
• memcpy
• gets
• sprintf
• scanf

Si vous devez appeler l'une des fonctions listées, assurez-vous de copier préalablement vos données dans un tampon basé sur la pile. Il s'avère généralement plus facile d'exécuter du code nuisible lorsque le tampon est défini sur la pile, plutôt que lorsque la mémoire est définie sur le segment. Pour obtenir davantage d'informations sur les saturations du tampon et les différentes techniques d'écriture de code sécurisé, reportez-vous au livre Writing Secure Code (en anglais) de Michael Howard et David LeBlanc, Microsoft Press Books, 2002.

À l'attention des OEM et des développeurs d'applications : vous pouvez utiliser des exemples de type VMini pour partager votre réseau Ethernet et vos connexions de débogage et être ainsi capable de concevoir et tester rapidement votre application ou votre système d'exploitation. Pour contourner ces types de vulnérabilité de sécurité, remplacez, avant d'expédier votre produit, les exemples par votre propre code d'application.

Dernière mise à jour le mercredi 9 avril 2003

• Documentation produit Windows CE .NET : Création d'un périphérique sécurisé