Aide sur l’utilisation de l’ID matériel spécifique à l’application (ASHWID) pour l’implémentation d’une logique d’application en fonction du périphérique

Aide sur l’utilisation de l’ID matériel spécifique à l’application (ASHWID) pour l’implémentation d’une logique d’application en fonction du périphérique

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Cette rubrique montre comment une application avec un composant cloud peut utiliser l’ID matériel spécifique à l’application (ASHWID) en association avec son service frontal pour implémenter une logique spécifique au périphérique. Les applications qui utilisent des stratégies de gestion de licences par périphérique sont des exemples d’applications de cette catégorie.

Remarque  Cette rubrique suppose une connaissance approfondie du chiffrement et une expérience de la gestion des licences de contenu.
 

Introduction

Les applications du Windows Store sont conçues pour partager facilement des données et du contenu sur plusieurs périphériques. Bien que les consommateurs apprécient cette expérience utilisateur, les concédants de licences de contenu ont souvent besoin d’un mécanisme permettant de limiter la distribution du contenu à un nombre fixe de périphériques. Certaines applications telles que les applications de gestion des licences de contenu ont besoin de se conformer aux stratégies d’octroi de licences par périphérique. En association avec un service cloud frontal, l’ID matériel spécifique à l’application (ASHWID) offre une solution. L’ID matériel spécifique à l’application (ASHWID) fournit une liaison forte entre l’application/le package et le périphérique en représentant plusieurs caractéristiques matérielles individuelles. Pour protéger la confidentialité des utilisateurs, l’ID matériel spécifique à l’application (ASHWID) varie d’une application à l’autre. À moins que le matériel sous-jacent ne change, deux appels de la même application se traduisent par des ID matériels spécifiques à l’application (ASHWID) identiques. Toutefois, l’ID matériel spécifique à l’application (ASHWID) change si le profil matériel du périphérique change, par exemple quand l’utilisateur débranche un adaptateur Bluetooth USB. Le service cloud frontal peut vérifier l’ID matériel spécifique à l’application (ASHWID) et le comparer aux valeurs rapportées antérieurement. Bien que l’ID matériel spécifique à l’application (ASHWID) varie, il est possible de l’analyser afin de détecter si cette variation est due simplement à une modification mineure, par exemple l’ajout de mémoire au système. Le niveau de tolérance de la variation dépend de l’implémentation du service cloud frontal. Vous trouverez les éléments particuliers qui constituent l’ID matériel spécifique à l’application (ASHWID) et les informations permettant de les analyser dans les sections suivantes.

De façon générale, une application peut suivre les étapes ci-après :

  1. Dans l’application, le code client appelle la méthode HardwareIdentification.GetPackageSpecificToken et renvoie l’ID matériel spécifique à l’application (ASHWID) au serveur principal de l’application.
  2. Le service cloud vérifie si la valeur provient de Windows et si elle est fiable.
  3. Le service cloud compare l’ID matériel spécifique à l’application (ASHWID) obtenu aux valeurs précédemment enregistrées fournies par cet utilisateur pour déterminer si elles correspondent. Il détermine ensuite si le périphérique peut bénéficier du degré de tolérance autorisé par le service.
  4. Le service cloud autorise ou interdit l’utilisation de son contenu sur le périphérique spécifique.

Termes utiles

Définitions utilisées dans cette rubriqueDescription

Package ID

Comprend un tuple en 5 parties incluant le nom du package, l’éditeur, la version, les ressources et l’architecture (x86, x64, ARM ou neutre).

Package full name

ID de package concaténé avec hachage du nom de l’éditeur. (<nom du package>_<version>_<architecture>_<ressources>_<Base32(SHA256(éditeur))>) Exemple : microsoft.office_15.0.0.0_x86_fr-fr_tf9ntdy1vxe7p (le dernier terme est le hachage de l’éditeur) .

Package family name

Nom du package concaténé avec hachage du nom de l’éditeur.

Valeur nonce de chiffrement

En ingénierie de sécurité, une valeur « nonce » est un nombre utilisé une seule fois. Ce type de valeur est généralement implémenté sous forme de nombre aléatoire suffisamment grand pour éviter la probabilité d’une réutilisation du nombre. Une valeur nonce est utilisée dans les protocoles d’authentification afin d’empêcher les attaques par relecture. .

ID matériel spécifique à l’application (ASHWID)

ID matériel spécifique à l’application.

 

Structure d’un ID matériel spécifique à l’application (ASHWID)

Un ID matériel spécifique à l’application (ASHWID) encapsule plusieurs caractéristiques matérielles individuelles correspondant au périphérique sur lequel une application est en cours d’exécution. L’ID matériel spécifique à l’application (ASHWID) est volontairement conçu pour être différent selon chaque application/package afin d’empêcher le ciblage du comportement à l’échelle du système et de protéger la confidentialité de l’utilisateur. L’ID matériel spécifique à l’application (ASHWID) n’est pas conçu pour les scénarios de publicité à l’échelle d’une plateforme.

Un ID matériel spécifique à l’application (ASHWID) est généré à l’aide des composants du périphérique. Chaque composant présent contribue à une section du flux d’octets de l’ID matériel spécifique à l’application (ASHWID) renvoyé. Neuf composants sont répertoriés ci-dessous :

  1. ID d’UC du processeur
  2. Taille de la mémoire
  3. Numéro de série du périphérique de disque
  4. Carte réseau (telle que l’adresse MAC de la carte réseau)
  5. Carte audio
  6. Station d’accueil
  7. Adresse Bluetooth
  8. ID du périphérique en haut débit mobile
  9. BIOS

Un ID matériel spécifique à l’application (ASHWID) n’a pas toujours neuf ID de composant. Raisons possibles :

  • Le matériel cible n’a pas neuf composants individuels. Par exemple, votre Bureau n’a pas de station d’accueil.
  • Le périphérique peut avoir plusieurs composants du même type. Par exemple, il peut y avoir deux cartes audio.
  • Chaque lecteur de disque physique contribue à un ID de composant. Un système de bureau avec 3 lecteurs de disques physiques renvoie 3 ID de composants.
  • Lorsqu’elle est connectée à une station d’accueil, une tablette renvoie les ID de composants de la carte réseau (Ethernet) supplémentaire et de la carte audio (à partir du port HDMI ou du port de sortie audio analogique).

Comme indiqué ci-dessous, vous pouvez identifier la section du flux d’octets qui représente chaque composant.

Le flux d’octets est constitué de plusieurs groupes de quatre octets. Les deux premiers octets contiennent le type du composant et les deux octets suivants contiennent sa valeur. Utilisez le tableau ci-dessous pour identifier le type de chaque composant :

Représentation du flux d’octetsComposant
1,0Processeur
2,0 Mémoire
3,0Périphérique de disque
4,0Carte réseau
5,0 Carte audio
6,0Station d’accueil
7,0Haut débit mobile
8,0Bluetooth
9,0BIOS système

 

Exemples d’ID matériels spécifiques à l’application (ASHWID)

L’ordre d’énumération des différents ID de composants n’est pas nécessairement séquentiel. Les flux suivants illustrent quelques exemples d’ID matériels spécifiques à l’application (ASHWID). Notez que le nombre d’ID de composants, ainsi que leur ordre peut varier dans le flux.

  • 7,0,124,215,3,0,206,143,8,0,128,55,5,0,12,222,5,0,128,255,6,0,1,0,4,0,20,22,4,0,48,155,1,0,250,155,2,0,162,217,9,0,92,101

    Haut débit mobile détecté sur une tablette Samsung Intel Core i5.

  • 7,0,124,215,3,0,206,143,8,0,128,55,5,0,126,129,5,0,12,222,5,0,128,255,6,0,1,0,4,0,20,22,4,0,48,155,4,0,178,193 ,1,0,250,155,2,0,162,217,9,0,92,101

    Trois cartes audio différentes sur le même périphérique lors de la connexion à la station d’accueil et trois cartes réseau différentes lors de la connexion à la station d’accueil.

  • 3,0,188,97,3,0,76,128,3,0,250,138,5,0,220,130,6,0,1,0,4,0,20,164,1,0,204,49,2,0,226,37,9,0,22,72

    Trois disques différents détectés sur un ordinateur de bureau.

  • 3,0,24,211 ,5,0,182,46,5,0,54,49,6,0,1,0,4,0,203,9,1,0,148,99,2,0,162,255,9,0,140,234

    Périphérique Nvidia Tegra 3. Notez que le flux « 6,0,1,0 » correspond à la station d’accueil, indépendamment du périphérique ou du facteur de forme.

Génération de l’ID matériel spécifique à l’application (ASHWID) sur le client

L’utilisation de la méthode de l’API permet aux applications

HardwareIdentification.GetPackageSpecificToken Windows Store de générer un ID matériel spécifique à l’application (ASHWID) pour le périphérique sur lequel elles sont exécutées. Deux applications qui appellent cette API renvoient des ID matériels spécifiques à l’application (ASHWID) distincts pour le même périphérique. Pour une application/un package particulier, l’ID matériel spécifique à l’application (ASHWID) n’est pas affecté par les aspects suivants :

  • Réinstallations du système d’exploitation
  • Réinitialisation rapide
  • Mise à niveau de la référence (SKU) du système d’exploitation
  • Mises à jour de version d’une application
  • Changements d’utilisateurs pour le même périphérique

Le composant relatif au service cloud d’une application du Windows Store peut valider l’authenticité de l’ID matériel spécifique à l’application (ASHWID) à l’aide d’une valeur nonce facultative, de la signature et du certificat. Cette API WinRT est disponible via une projection dans chaque langage de programmation pris en charge.

Utilisation d’une valeur nonce facultative

Une application peut passer une valeur nonce de chiffrement sous forme d’entrée à la méthode GetPackageSpecificToken. En fournissant une valeur nonce distincte à chaque reprise, le nuage peut vérifier que l’ID matériel spécifique à l’application (ASHWID) qui est renvoyé provient bien de Windows et qu’il n’a pas été relu par l’utilisateur. Une valeur nonce permet de valider l’actualisation de l’ID matériel spécifique à l’application (ASHWID) et de prévenir les risques d’attaques par relecture. Si un service cloud utilise une valeur nonce, il peut vérifier si l’ID matériel spécifique à l’application (ASHWID) a été généré après que le service cloud a envoyé la valeur nonce. Le passage d’une valeur nonce n’est pas recommandé, sauf si votre service cloud n’est pas concerné par les attaques par relecture.

Exemple de code côté client

Pour obtenir des exemples de code côté client permettant de créer un ID matériel spécifique à l’application (ASHWID), voir HardwareIdentification.GetPackageSpecificToken.

Traitement de l’ID matériel spécifique à l’application (ASHWID) dans le nuage

Prise en compte de la variation du matériel

Les éléments qui composent un périphérique peuvent changer. Ce changement se nomme la « variation du matériel ». L’ID matériel spécifique à l’application (ASHWID) d’un périphérique donné peut changer pour diverses raisons selon le moment où il est interrogé :

  • Les utilisateurs peuvent décider de mettre à niveau ou d’améliorer leurs périphériques existants, ce qui se traduit par un changement des composants affectant l’ID matériel spécifique à l’application (ASHWID).
  • Les utilisateurs peuvent connecter temporairement des accessoires à leurs périphériques, ce qui étend la liste des composants.
  • Les périphériques de gestion de l’alimentation (pour les tablettes et les périphériques basés sur des processeurs ARM) peuvent couper l’alimentation de certains composants matériels afin de préserver l’autonomie de la batterie.

La variation du matériel est la raison pour laquelle l’application ne doit pas consommer en l’état le flux d’octets de l’ID matériel spécifique à l’application (ASHWID). Si quelques composants matériels changent ou sont éteints, l’API renvoie un autre ID matériel spécifique à l’application (ASHWID). L’application risque d’identifier de manière incorrecte le même périphérique en tant que nouveau périphérique. Voici quelques scénarios plausibles de variation du matériel :

  • C’est la fin de la journée. Un utilisateur veut faire durer sa batterie jusqu’à ce qu’il rentre à la maison. Par conséquent, il désactive les fonctionnalités Bluetooth et Wi-Fi, tout en gardant la fonctionnalité 3G/4G pour maintenir la connectivité avec le nuage.
  • Un utilisateur connecte une carte de données 3G USB.
  • La fonctionnalité de gestion de l’alimentation du système/système d’exploitation sous-jacent peut désactiver certains cœurs.

Dans chaque situation, l’une des façons dont l’application peut tenir compte de la variation du matériel consiste à calculer un score en associant des poids à chacun des ID de composants renvoyés en fonction de sa logique métier. Le score calculé doit dépasser le seuil fixé par le composant cloud pour être identifié en tant que périphérique identique.

Vous trouverez ci-dessous une illustration simple correspondant à une façon de gérer la variation du matériel au sein du service cloud :


If 	[(Component_1_previous == Component_1_current) x Weight_1 + 
(Component_2_previous == Component_2_current) x Weight_2 + 
(Component_3_previous == Component_3_current) x Weight_3 + ……..
(Component_n_previous == Component_n_current) x Weight_n]  
>= [Threshold_for_being_the_same_device]
Then It_is_the_same_device	

Utilisation de poids relatifs dans l’identification d’un périphérique

Les poids relatifs dépendent de votre logique métier et de ce que vous identifiez comme une variation de matériel acceptable. Il n’existe aucune recommandation explicite pour la valeur des poids. Certains composants sont moins susceptibles de varier que d’autres et méritent des poids plus élevés. Par exemple, le BIOS est moins susceptible de varier que la carte audio. Plusieurs lecteurs de disque peuvent apparaître en fonction du nombre de lecteurs connectés au système. L’ID de composant du lecteur sur lequel l’OS est installé est moins susceptible de varier. L’ID de composant du processeur sur la plupart des systèmes x86/x86-64 est plutôt stable. Si vous constatez que le composant de station d’accueil renvoie le même ID de composant, il est préférable de lui affecter un poids égal à zéro.

Authentification de l’ID matériel spécifique à l’application (ASHWID) dans le nuage

L’ID matériel spécifique à l’application (ASHWID) qui est renvoyé est signé. Cela permet à l’application de vérifier si l’ID matériel spécifique à l’application (ASHWID) est bien renvoyé à partir de Windows. Le passage d’une valeur nonce de variation en entrée sert de protection contre les attaques par relecture.

L’ID matériel spécifique à l’application (ASHWID) est haché à l’aide d’une clé privée sur le client. Le diagramme ci-dessous illustre le format de la signature.

Format de la signature

Listes de révocation de certificats

Il existe une possibilité (faible) que la clé privée soit compromise. Si cela se produit, votre application (client ou nuage) n’a pas besoin de code supplémentaire pour mettre à jour la clé du moment que vous activez la vérification de révocation pour tous les certificats de la chaîne.

Aide relative au flux de travail côté nuage

Voici un flux de travail qui peut être suivi par le développeur du composant côté cloud. À la réception du certificat, de la signature et de l’ID matériel, vérifiez l’authenticité de l’ID matériel spécifique à l’application (ASHWID) comme suit :

  1. Vérifiez la fiabilité et la validité du certificat. Cette étape suppose que le certificat racine « Microsoft Assurance Designation Root 2011 » est approuvé sur le système nuage. Le certificat racine doit être ajouté manuellement au magasin racine approuvé sur les serveurs Windows.
    1. Le blob de certificat comporte la chaîne de certificats au format PKCS#7. Créez la chaîne de certificats et assurez-vous qu’elle est approuvée. Les échecs de vérification de la chaîne d’approbation liés à un certificat feuille arrivé à expiration doivent être ignorés.
    2. Assurez-vous que la chaîne de certificats ne comporte pas de problèmes de révocation. Nous vous recommandons d’ignorer les échecs de révocation liés à des CDP hors ligne.
    3. Assurez-vous que le certificat feuille dispose d’une utilisation améliorée de la clé avec la valeur « 1.3.6.1.4.1.311.10.5.40 ».
    4. Interrogez la clé publique du certificat racine de la chaîne de certificats, puis comparez-la à la clé publique du certificat racine « Microsoft Assurance Designation Root 2011 » pour vérifier leur correspondance.
  2. Assurez-vous que l’ID matériel spécifique à l’application (ASHWID) est bien produit par du code de confiance Windows.
    1. Le blob de signature correspond au blob signé du hachage SHA1 de la concaténation de la valeur nonce (si elle est présente) et de l’ID matériel spécifique à l’application (ASHWID).
    2. Utilisez le certificat feuille pour vérifier si la signature de hachage correspond à la valeur nonce d’origine envoyée par le service cloud et au flux d’octets reçu pour le matériel.

Rubriques associées

Composant cloud de l’ID matériel spécifique à l’application (ASHWID)
HardwareToken
HardwareToken.Certificate
HardwareToken.Signature
HardwareIdentification
HardwareIdentification.GetPackageSpecificToken

 

 

Afficher:
© 2017 Microsoft