Windows Dev Center

Leitfaden zur Implementierung von gerätebezogener App-Logik mit der anwendungsspezifischen Hardware-ID (ASHWID)

In diesem Thema erfahren Sie, wie Apps mit einer Cloudkomponente unter Verwendung der anwendungsspezifischen Hardware-ID (ASHWID) sowie des zugehörigen Back-End-Diensts eine gerätebezogene Logik implementieren können. Apps mit gerätebezogenen Lizenzierungsrichtlinien sind ein Beispiel für Anwendungen, die in diese Kategorie fallen.

Hinweis  In diesem Thema wird vorausgesetzt, dass Sie über eingehende Kryptologiekenntnisse verfügen und mit der Lizenzierung von Inhalten vertraut sind.

Einführung

Windows Store-Apps sind so konzipiert, dass Daten und Inhalte auf einfache Weise mit einer Vielzahl von Geräten geteilt werden können. Dies bringt für den Konsumenten viele Vorteile mit sich. Lizenzgeber sind darüber hinaus jedoch auch daran interessiert, die Weitergabe ihrer Inhalte auf eine bestimmte Anzahl von Geräten zu begrenzen. Einige App, beispielsweise Apps zur Lizenzierung von Inhalten, müssen gerätebezogene Lizenzierungsrichtlinien implementieren. Die anwendungsspezifische Hardware-ID (ASHWID) bietet hierfür in Verbindung mit einem Back-End-Cloud-Dienst eine Lösung. Die ASHWID beinhaltet mehrere individuelle Hardwaremerkmale und stellt so eine enge Bindung zwischen der App bzw. dem Paket und dem Gerät her. Aus Datenschutzgründen unterscheidet sich die ASHWID von App zu App. Solange keine Änderungen an der zugrunde liegenden Hardware vorgenommen werden, ergeben zwei Aufrufe von derselben App identische ASHWIDs. Wenn sich jedoch das Hardwareprofil des Geräts ändert, etwa weil der Benutzer einen Bluetooth-Adapter trennt, ändert sich auch die ASHWID. Die ASHWID kann vom Back-End-Cloud-Dienst überprüft und mit früheren Werten verglichen werden. Auch wenn die ASHWID veränderlich ist, kann sie analysiert werden. So lässt sich leicht feststellen, ob der Abweichung möglicherweise nur eine geringfügige Änderung wie das Hinzufügen von Speicher zugrunde liegt. Inwieweit Abweichungen toleriert werden, ist von der Implementierung des Back-End-Cloud-Diensts abhängig. In den nachfolgenden Abschnitten finden Sie Informationen zu den spezifischen Bestandteilen der ASHWID; außerdem wird dort erläutert, wie Sie diese analysieren können.

Die nachstehenden Schritte können von einer App auf übergeordneter Ebene ausgeführt werden:

  1. In der App ruft der Clientcode die HardwareIdentification.GetPackageSpecificToken-Methode auf und gibt die ASHWID an das Server-Back-End für die App zurück.
  2. Der Clouddienst überprüft, ob der Wert von Windows stammt und vertrauenswürdig ist.
  3. Der Clouddienst vergleicht die abgerufene ASHWID mit früheren Werten von diesem Benutzer, um zu prüfen, ob sie übereinstimmen. Außerdem bestimmt der Dienst, ob das Gerät in den vom Dienst zulässigen Toleranzbereich fällt.
  4. Die Nutzung des Inhalts auf dem speziellen Gerät wird vom Clouddienst zugelassen oder nicht zugelassen.

Hilfreiche Begriffe

In diesem Thema verwendete DefinitionenBeschreibung

Package ID

Ein Tupel mit fünf Bestandteilen: Paketname, Herausgeber, Version, Ressource und architecture (x86, x64, ARM oder neutral).

Package full name

Verkettete Paket-ID mit Herausgebername mit Hash. ( <Paketname>_<Version>_<Architektur>_< Ressourcen>_<Base32(SHA256(Herausgeber))>) z. B. microsoft.office_15.0.0.0_x86_en-us_tf9ntdy1vxe7p (der letzte Ausdruck ist der Hash des Herausgebers) .

Package family name

Paketname, verkettet mit dem Herausgebernamen mit Hash.

KryptografischeNonce

Im Sicherheitsengineering ist eine Nonce eine Nummer, die nur einmal verwendet wird. Bei der Implementierung wird dann normalerweise eine zufällige Nummer verwendet, die groß genug ist, um die Wahrscheinlichkeit einer doppelten Verwendung möglichst gering zu halten. Noncen werden in Authentifizierungsprotokollen verwendet, um Replay-Angriffe zu verhindern. .

ASHWID

Anwendungsspezifische Hardware-ID.

 

Struktur einer ASHWID

Eine ASHWID enthält mehrere individuelle Hardwaremerkmale eines bestimmten Geräts, auf dem eine App ausgeführt wird. Die ASHWID ist so aufgebaut, dass für jede App bzw. für jedes Paket eine eigene ASHWID verwendet werden kann. Dadurch wird verhindert, dass das Verhalten des Benutzers im gesamten System überwacht wird, und die Privatsphäre wird geschützt. Die ASHWID ist nicht für plattformübergreifende Werbeszenarien geeignet.

Sie wird anhand der Komponenten generiert, aus denen das Gerät besteht. Jede vorhandene Komponente hat Anteil am zurückgegebenen ASHWID-Bytestream. Neun dieser Komponenten sind nachfolgend aufgelistet:

  1. CPU-ID des Prozessors
  2. Größe des Arbeitsspeichers
  3. Seriennummer des Datenträgergeräts
  4. Netzwerkadapter (wie NIC-MAC-Adresse)
  5. Audioadapter
  6. Dockingstation
  7. Bluetooth-Adresse
  8. ID des mobilen Breitbandgeräts
  9. BIOS

ASHWIDs beinhalten unter Umständen nicht genau neun Komponenten-IDs. Dies kann folgende Gründe haben:

  • Möglicherweise verfügt die Zielhardware über mehr oder weniger als neun einzelne Komponenten. So verfügt Ihr Desktopcomputer wahrscheinlich nicht über eine Dockingstation.
  • Ein Gerät kann mehrere Komponenten des gleichen Typs aufweisen. Beispielsweise können zwei Audioadapter vorhanden sein.
  • Jedes physische Laufwerk trägt eine Komponenten-ID bei. Ein Desktopsystem mit drei physischen Laufwerken gibt drei Komponenten-IDs zurück.
  • Ein Tablet, das mit einer Dockingstation verbunden ist, gibt darüber hinaus die Komponenten-IDs des zusätzlichen Netzwerkadapters (Ethernet) sowie des Audioadapters (HDMI- oder analoger Audioausgang) zurück.

Sie können den jeweiligen Abschnitt des Bytestreams identifizieren, der für eine Komponente steht. Diese Vorgehensweise wird unten veranschaulicht.

Der Bytestream umfasst mehrere Gruppen, die jeweils aus vier Bytes bestehen. Die ersten zwei Bytes enthalten den Typ der Komponente, und die zwei folgenden Bytes enthalten den zugehörigen Wert. Mithilfe der nachstehenden Tabelle können Sie den Typ der jeweiligen Komponente identifizieren:

BytestreamdarstellungKomponente
1.0Prozessor
2.0 Arbeitsspeicher
3.0Datenträgergerät
4.0Netzwerkadapter
5.0 Audioadapter
6.0Dockingstation
7.0Mobiles Breitband
8.0Bluetooth
9.0System-BIOS

 

ASHWID-Beispiele

Die einzelnen Komponenten-IDs können auch in einer anderen Reihenfolge aufgelistet werden. In den folgenden Streams finden Sie einige ASHWID-Beispiele. Beachten Sie, dass sich von Stream zu Stream sowohl die Anzahl als auch die Reihenfolge der Komponenten-IDs unterscheiden kann.

  • 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

    Mobiles Breitband auf Samsung Intel Core i5-Slate-Computer gefunden.

  • 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

    Drei verschiedene Audioadapter und drei verschiedene Netzwerkadapter, jeweils bei Verbindung mit einem Dockinganschluss.

  • 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

    Drei verschiedene Datenträger auf einem Desktopcomputer.

  • 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

    Nvidia Tegra 3-Gerät. Der Stream " 6,0,1,0 " gehört zur Dockingstation und ist unabhängig vom Gerät oder Formfaktor.

Generieren der ASHWID auf dem Client

Verwenden der API

HardwareIdentification.GetPackageSpecificToken ermöglicht Windows Store-Apps das Generieren einer ASHWID für das Gerät, auf dem sie ausgeführt werden. Zwei Apps, die diese API auf einem Gerät aufrufen, geben unterschiedliche ASHWIDs zurück. Folgende Vorgänge wirken sich bei einer bestimmten App bzw. einem bestimmten Paket nicht auf die ASHWID aus:

  • Neuinstallation des Betriebssystems
  • Zurücksetzen mithilfe der Push-Schaltfläche
  • Aktualisierung der Betriebssystem-SKU
  • Versionsaktualisierung einer App
  • Änderungen von Benutzern auf dem gleichen Gerät

Die Clouddienstkomponente einer Windows Store-App kann die Authentizität einer ASHWID überprüfen. Dazu werden eine optionale Nonce, die Signatur sowie das Zertifikat verwendet. Diese WinRT-API ist in allen unterstützten Programmiersprachen über eine Projektion verfügbar.

Verwenden einer optionalen Nonce

Apps können eine kryptografische Nonce als Eingabe für die GetPackageSpecificToken-Methode übergeben. Da bei jedem Vorgang eine andere Nonce übermittelt wird, kann von der Cloud sichergestellt werden, dass die zurückgegebene ASHWID tatsächlich von Windows stammt und nicht erneut vom Benutzer eingegeben wurde. Mithilfe einer Nonce kann ferner sichergestellt werden, dass die zurückgegebene ASHWID möglichst aktuell ist. Außerdem wird auf diese Weise ein Schutz vor Replay-Angriffen gewährleistet. Im Rahmen der Verwendung einer Nonce durch einen Cloud-Dienst kann dieser auch überprüfen, ob die ASHWID generiert wurde, nachdem die Nonce vom Cloud-Dienst gesendet wurde. Es wird nicht empfohlen, eine Nullnonce zu übergeben, es sei denn, Replay-Angriffe spielen bei dem Cloud-Dienst keine Rolle.

Clientseitiger Beispielcode

Beispiele für das Erstellen von clientseitigem Beispielcode zum Erstellen einer ASHWID finden Sie unter HardwareIdentification.GetPackageSpecificToken.

Verarbeiten der ASHWID in der Cloud

Berücksichtigen von Hardwareabweichungen

Die Komponenten, aus denen ein Gerät besteht, können sich ändern. Diese Änderung wird auch als "Hardwareabweichung" bezeichnet. Änderungen der ASHWID eines Geräts können verschiedene Ursachen haben. Diese sind abhängig davon, wann die Abfrage ausgeführt wurde:

  • Vorhandene Geräte können aktualisiert oder erweitert werden. Dies kann zu Änderungen bei Komponenten führen, die sich auf die ASHWID auswirken.
  • Durch das Anschließen von Peripheriegeräten kann die Liste der Komponenten vorübergehend erweitert werden.
  • Energieverwaltungsgeräte (für Slates und Geräte mit ARM-Prozessor) können bestimmte Hardwarekomponenten vorübergehend abschalten, um die Akkulaufzeit zu verlängern.

Aufgrund möglicher Hardwareabweichungen sollte der ASHWID-Bytestream von der App auch nicht ungefiltert verarbeitet werden. Wenn sich einige Hardwarekomponenten ändern oder deaktiviert werden, gibt die API eine abweichende ASHWID zurück. Es besteht ein Risiko, dass das Gerät von der App irrtümlicherweise als neues Gerät identifiziert wird. Hardwareabweichungen können u. a. folgende Ursachen haben:

  • Gegen Abend schaltet ein Benutzer die Bluetooth- und die WiFi-Funktionen seines Geräts ab, damit der Akku noch hält, bis er nach Hause kommt. Das 3G/4G-Netzwerk bleibt jedoch aktiv, um die Verbindung mit der Cloud nicht zu verlieren.
  • Eine 3G-Datenkarte wird über den USB-Anschluss mit dem Gerät verbunden.
  • Das zugrunde liegende Betriebssystem bzw. die System-on-a-Chip-Energieverwaltung kann bestimmte Kerne abschalten.

Eine Möglichkeit für die App, auf entsprechende Hardwareabweichungen zu reagieren, besteht darin, einen Wert zu berechnen. Dazu werden die zurückgegebenen Komponenten-IDs auf Grundlage der Geschäftslogik gewichtet. Der berechnete Wert muss den von der Cloud-Komponente festgelegten Wert übertreffen, um als identisches Gerät identifiziert zu werden.

Nachfolgend wird eine Möglichkeit zur Behandlung von Hardwareabweichungen im Cloud-Dienst auf einfache Weise veranschaulicht:


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	

Identifizieren von Geräten mithilfe relativer Gewichtungen

Relative Gewichtungen sind abhängig von der jeweiligen Geschäftslogik sowie davon, was als akzeptable Hardwareabweichung betrachtet wird. Aus diesem Grund ist es auch nicht möglich, explizite Werte für Gewichtungen zu empfehlen. Einige Komponenten weisen eine geringere Wahrscheinlichkeit für Veränderungen auf und können daher stärker gewichtet werden. Beispielsweise ist es weniger wahrscheinlich, dass sich das BIOS ändert, als dass sich der Audioadapter ändert. Je nachdem, mit wie vielen Laufwerken das System verbunden ist, können mehrere Datenträgerlaufwerke angezeigt werden. Die Wahrscheinlichkeit, dass sich die Komponenten-ID des Laufwerks ändert, auf dem Betriebssystem installiert wurde, ist geringer. Die ID der Prozessorkomponente auf den meisten x86-/x86-64-Bit-Systemen ist relativ stabil. Wenn Sie feststellen, dass die Dockingstation dieselbe Komponenten-ID zurückgibt, kann es hilfreich sein, die zugehörige Gewichtung auf null festzulegen.

Authentifizierung der ASHWID in der Cloud

Die zurückgegebene ASHWID ist signiert. Auf diese Weise kann die App sicherstellen, dass die zurückgegebene ASHWID tatsächlich von Windows stammt. Das Übergeben von wechselnden Noncen als Eingabe schützt vor Replay-Angriffen.

Mithilfe eines privaten Schlüssels im Client wird ein Hash auf die ASHWID angewendet. Das Format der Signatur wird im nachfolgenden Diagramm veranschaulicht.

Format der Signatur

Zertifikatsperrlisten

Es ist kaum wahrscheinlich, aber dennoch möglich, dass der private Schlüssel in die falschen Hände gelangt. In diesem Fall benötigt Ihre App (Client oder Cloud) keinen zusätzlichen Code, um den Schlüssel zu aktualisieren. Voraussetzung dafür ist jedoch, dass Sie das Überprüfen der Sperrung für alle Zertifikate in der Kette aktiviert haben.

Richtlinien für den cloudseitigen Workflow

Nachfolgend finden Sie einen Beispielworkflow für Entwickler der cloudseitigen Komponente. Nach Erhalt des Zertifikats, der Signatur und der Hardware-ID können Sie die Authentizität der ASHWID mithilfe der folgenden Schritte überprüfen:

  1. Überprüfen Sie die Vertrauenswürdigkeit und die Gültigkeit des Zertifikats. Dieser Schritt setzt voraus, dass das Stammzertifikat „Microsoft Assurance Designation Root 2011“ vom Cloudsystem als vertrauenswürdig angesehen wird. Das Stammzertifikat muss dem vertrauenswürdigen Stammspeicher auf Windows-basierten Servern manuell hinzugefügt werden.
    1. Die Zertifikatkette des Zertifikat-Blobs wurde mit PKCS#7 formatiert. Erstellen Sie die Zertifikatkette, und überprüfen Sie ihre Vertrauenswürdigkeit. Fehler bei der Überprüfung von Vertrauensketten aufgrund untergeordneter Zertifikate, die abgelaufen sind, können ignoriert werden.
    2. Stellen Sie sicher, dass die Zertifikatkette auf Sperrfehler überprüft wurde. Sperrfehler aufgrund von Offline-CDPs sollten ignoriert werden.
    3. Das untergeordnete Zertifikat muss die EKU „1.3.6.1.4.1.311.10.5.40“ aufweisen.
    4. Fragen Sie den öffentlichen Schlüssel für das Stammzertifikat in der Zertifikatkette ab. Überprüfen Sie anschließend, ob er mit dem öffentlichen Schlüssel des Stammzertifikats „Microsoft Assurance Designation Root 2011“ übereinstimmt.
  2. Vergewissern Sie sich, dass die ASHWID tatsächlich durch vertrauenswürdigen Windows-Code erzeugt wird.
    1. Das Signatur-Blob ist das signierte Blob des SHA1-Hashs für die Verkettung der Nonce (sofern vorhanden) und der ASHWID.
    2. Überprüfen Sie mit dem untergeordneten Zertifikat, ob die signierte Hashsignatur mit der ursprünglich vom Clouddienst gesendeten Nonce sowie mit dem empfangenen Hardwarebytestream übereinstimmt.

Verwandte Themen

Cloudkomponente für anwendungsspezifische Hardware-ID (App Specific Hardware ID, ASHWID)
HardwareToken
HardwareToken.Certificate
HardwareToken.Signature
HardwareIdentification
HardwareIdentification.GetPackageSpecificToken

 

 

Anzeigen:
© 2015 Microsoft