DE112010005069T5 - Bereitstellen, Aufrüsten und/oder Ändern von Hardware - Google Patents

Bereitstellen, Aufrüsten und/oder Ändern von Hardware Download PDF

Info

Publication number
DE112010005069T5
DE112010005069T5 DE112010005069T DE112010005069T DE112010005069T5 DE 112010005069 T5 DE112010005069 T5 DE 112010005069T5 DE 112010005069 T DE112010005069 T DE 112010005069T DE 112010005069 T DE112010005069 T DE 112010005069T DE 112010005069 T5 DE112010005069 T5 DE 112010005069T5
Authority
DE
Germany
Prior art keywords
hardware
authorization
secure
remote site
entitlement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE112010005069T
Other languages
English (en)
Other versions
DE112010005069B4 (de
Inventor
Alberto J. Martinez
Ernie Brickell
William A. Stevens
Purushottam Goel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112010005069T5 publication Critical patent/DE112010005069T5/de
Application granted granted Critical
Publication of DE112010005069B4 publication Critical patent/DE112010005069B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Communication Control (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Bei einigen Ausführungsformen wird eine sichere Berechtigungsanfrage, um eine Hardwarekonfiguration zu ändern, erzeugt. Die sichere Berechtigungsanfrage wird an einen entfernten Standort gesendet und eine Berechtigung, die vom entfernten Standort als Reaktion auf die Berechtigungsanfrage gesendet wird, wird empfangen. Die Hardwarekonfiguration wird als Reaktion auf die empfangene Berechtigung geändert. Weitere Ausführungsformen sind beschrieben und werden beansprucht.

Description

  • TECHNISCHES GEBIET
  • Die Erfindungen beziehen sich generell auf das Bereitstellen, Aufrüsten und/oder Ändern von Hardware.
  • HINTERGRUND
  • Um Hardware (wie beispielsweise eine SKU oder Stock Keeping Unit) in einem Computersystem zu ändern, verwenden Hersteller gegenwärtig eine Teststation in der Fertigungsumgebung. Es wäre nützlich, Hardware-(und/oder SKU)-Bereitstellung oder -Änderung, direkt für den Verbraucher der Komponente (beispielsweise durch den OEM und/oder Endbenutzer oder die IT-Abteilung des Endbenutzers) zu ermöglichen, anstatt den aktuellen Prozess des Testens in der Fertigungsumgebung zu verwenden.
  • Des Weiteren erfordern aktuelle Techniken in der Computerindustrie, um eine Hardwarekonfiguration zu aktualisieren, den Ersatz der Hardware. Beispielsweise umfassen einige zuvor verwendete Techniken das Ändern der Hardwarekonfiguration mit physischen Veränderungen an der Hardware, wie beispielsweise das Ändern von Pins, Brücken, Bändern, Sicherungen usw. Es wäre vorteilhaft, eine Veränderung oder Aktualisierung einer Hardwarekonfiguration bereitzustellen, ohne den Ersatz der tatsächlichen Hardware oder solche physischen Änderungen vornehmen zu müssen.
  • Einkäufe unter Netzwerkverkehr schützen gegenwärtig nicht die Privatsphäre an den Endpunkten der Transaktion. Gegenwärtig werden beispielsweise eindeutige Identifikatoren für den Transport von Interneteinkäufen verwendet. Es wäre vorteilhaft, eine Transaktion für den Verkäufer der Dienste anonym zu gestalten, um die Privatsphäre für den Käufer sicherzustellen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindungen sind vollständiger durch die nachfolgende ausführliche Beschreibung und die begleitenden Zeichnungen von einigen Ausführungsformen der Erfindungen zu verstehen, die jedoch nicht hergenommen werden sollten, um die Erfindungen auf die spezifischen beschriebenen Ausführungsformen zu begrenzen, sondern sie dienen nur der Erklärung und dem Verstehen.
  • 1 zeigt ein System gemäß einiger Ausführungsformen der Erfindungen.
  • 2 zeigt ein System gemäß einiger Ausführungsformen der Erfindungen.
  • 3 zeigt ein System gemäß einiger Ausführungsformen der Erfindungen.
  • 4 zeigt ein System gemäß einiger Ausführungsformen der Erfindungen.
  • 5 zeigt ein System gemäß einiger Ausführungsformen der Erfindungen.
  • 6 veranschaulicht eine Berechtigung gemäß einiger Ausführungsformen der Erfindungen.
  • 7 veranschaulicht einen Fluss gemäß einiger Ausführungsformen der Erfindungen.
  • 8 veranschaulicht Schlüsselstellen gemäß einiger Ausführungsformen der Erfindungen.
  • 9 veranschaulicht einen Fluss gemäß einiger Ausführungsformen der Erfindungen.
  • 10 veranschaulicht ein System gemäß einiger Ausführungsformen der Erfindungen.
  • 11 veranschaulicht einen Fluss und ein System gemäß einiger Ausführungsformen der Erfindungen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Einige Ausführungsformen der Erfindungen beziehen sich auf das Bereitstellen, Aufrüsten und/oder Ändern von Hardware.
  • 1 veranschaulicht ein System 100 gemäß einiger Ausführungsformen. Bei einigen Ausführungsformen umfasst System 100 einen Prozessor 102 (und/oder Hauptprozessor oder CPU), einen Grafik- und Memory-Controller-Hub 104 (und/oder GMCH und/oder Memory-Controller-Hub oder MCH) und ein Ein-/Ausgabe-Controller-Hub 106 (und/oder ICH). Bei einigen Ausführungsformen umfasst GMCH 104 eine Managementengine 112 (und/oder Handhabbarkeitsengine und/oder ME), welche ein Mikrocontroller und/oder eine Hardwareverarbeitungsengine ist. Bei einigen Ausführungsformen kann ME 112 Firmware-Dienste und -Anwendungen ablaufen lassen und bei einigen Ausführungsformen ist sie gleich oder ähnlich anderen ME-Geräten, die nachfolgend ausführlicher beschrieben werden.
  • Bei einigen Ausführungsformen enthält GMCH 104 einen Memory-Controller, der Zugriff zum Systemspeicher bietet. Ein kleiner Teil des Systemspeichers wird von der ME 112 für ihren Laufzeitspeicher verwendet. Dieser Speicher ist vom Speicher, auf den das Betriebssystem (OS) zugreift, getrennt, indem spezielle Hardware-Mechanismen verwendet werden. Bei einigen Ausführungsformen wird die Architektur, die die Trennung herstellt, Unified Memory Architecture (UMA) genannt. Bei einigen Ausführungsformen umfasst der ICH 106 unter anderem einen Ethernet-Netzwerk-Controller, einen Netzwerk-Filter und/oder einen nichtflüchtigen Flash-Speicher-Controller. Bei einigen Ausführungsformen ist beispielsweise ein drahtloses lokales Netzwerk (LAN) oder WiFi-Netzwerk-Controller mit dem ICH 106 über ein PCI-Express-Bus verbunden. Der Netzwerk-Controller, das verdrahtete und das drahtlose LAN und die Netzwerk-Filter bieten bei einigen Ausführungsformen Außerband-(OOB)-Kommunikation, um auf die ME 112 zuzugreifen. OOB-Kommunikation ermöglicht der ME 112, über ein Netzwerk zu kommunizieren, ohne irgendeine Abhängigkeit vom OS oder den Treibern, die sich darin befinden, zu haben. OOB-Kommunikation ist betriebsfähig, selbst wenn der Computer sich in einigen Zuständen befindet, in denen das OS nicht arbeitet oder schläft (beispielsweise, wenn das OS abgestürzt ist oder sich in einem Standby-Zustand oder einem Ruhezustand befindet). Der Flash-Controller im ICH 106 bietet Zugriff zum Flash-Speicher (beispielsweise auch als Permanentspeicher oder NVM bezeichnet), der sich auf dem Motherboard des Computers befindet. Der NVM beherbergt bei einigen Ausführungsformen unter anderem Basic Input/Output System-(BIOS)-Code, ME-Code und/oder Daten.
  • GMCH 104 und ICH 106 kommunizieren bei einigen Ausführungsformen miteinander, indem sie einen Direct Media Interface-(DMI)-Bus und/oder einen Controller-Link-(CLink)-Bus verwenden. Der DMI-Bus ist eine Chip-zu-Chip-Kopplungsstruktur zwischen dem ICH 106 und dem GMCH (oder MCH) 104. Diese Hochgeschwindigkeitsschnittstelle stellt sicher, dass das Ein-/Ausgabe-(I/O)-Subsystem (wie beispielsweise PCI Express, Intel High Definition Audio, Serial ATA oder SATA, universeller serieller Bus oder USB usw.) die erforderliche Bandbreite für die Spitzenleistung erhält. Bei einigen Ausführungsformen ist der CLink-Bus eine proprietäre Schnittstelle, die verwendet werden kann, selbst wenn der Computer sich in einem Schlafzustand oder einem Ruhezustand befindet, zusätzlich zur Verwendung, wenn das OS in Betrieb ist.
  • Bei einigen Ausführungsformen ist GMCH 104 (und/oder MCH 104) direkt und/oder indirekt mit einer Anzahl an Geräten u. a. ohne Einschränkung ein oder mehreren Displays und/oder Displayanschlüsse (wie beispielsweise CRT, HDMI, TV, LVDS), einer oder mehreren Grafikbaugruppen und/oder Grafikanschlüssen und/oder einem oder mehreren Speicherbausteinen (wie beispielsweise Dual In-Line Memory Module oder DIMM-Bausteinen) gekoppelt.
  • Bei einigen Ausführungsformen ist ICH 106 direkt und/oder indirekt mit einer Anzahl an Geräten u. a. ohne Einschränkung Peripheral Component Interconnect-(PCI)-Geräten und/oder PCI-Bussen, universellen seriellen Bus-(USB)-Geräten und/oder USB-Bussen, Serial ATA-Geräten, SPI-Flash-Geräten, diskreten TPM-Geräten, Super-I/O-Geräten, SMBus-Geräten, High-Definition-Audiogeräten, PCI Express-Geräten, lokalen Netzwerk-(LAN)-Geräten, Weitverkehrsnetzwerk-(WAN)-Geräten, drahtlosen lokalen Netzwerk-(WLAN)-Geräten, Wireless Wide Area Network-(WWAN)-Geräten, WiMAX-Geräten, Flash-Speicher-Geräten, Express-Karten-Geräten usw. gekoppelt.
  • 2 veranschaulicht ein System 200 gemäß einiger Ausführungsformen. Bei einigen Ausführungsformen umfasst System 200 einen Prozessor 202 (und/oder Hauptprozessor oder CPU) und einen Plattform-Controller-Hub 204. Bei einigen Ausführungsformen umfasst Prozessor 202 zwei oder mehr Kerne (wie beispielsweise veranschaulicht durch Kern 222 und Nichtkern 224 in 2). Bei einigen Ausführungsformen umfasst PCH 204 eine Managementengine 212 (und/oder Handhabbarkeitsengine und/oder ME), welche ein Mikrocontroller und/oder eine Hardwareverarbeitungsengine ist. Bei einigen Ausführungsformen ist ME 212 fähig, Firmware-Dienste und Anwendungen ablaufen zu lassen. Bei einigen Ausführungsformen ist ME 212 gleich oder ähnlich ME 112 und/oder anderen ME-Geräten, die nachfolgend ausführlicher beschrieben werden.
  • Bei einigen Ausführungsformen kommunizieren der Prozessor 202 und der PCH 204 miteinander, indem sie einen Direct Media Interface-(DMI)-Bus verwenden. Diese Hochgeschwindigkeitsschnittstelle stellt sicher, dass das Ein-/Ausgabe-(I/O)-Subsystem (wie beispielsweise PCI Express, Intel High Definition Audio, Serial ATA oder SATA, universeller serieller Bus oder USB usw.) die erforderliche Bandbreite für die Spitzenleistung erhält. Bei einigen Ausführungsformen führt der PCH 104 viele oder alle Funktionen und Merkmale aus und/oder er weist viele oder alle verbundenen Geräte wie oben beschrieben unter Bezugnahme auf ICH 106 auf. Bei einigen Ausführungsformen sind einige der Funktionen, Merkmale und/oder Verbindungen, die oben unter Bezugnahme auf GMCH 104 beschrieben sind, zum Prozessor 202 verschoben und einige zum PCH 204.
  • Bei einigen Ausführungsformen ist Prozessor 202 direkt und/oder indirekt mit einer Anzahl an Geräten u. a. ohne Einschränkung einem oder mehreren Displays und/oder Displayanschlüssen (wie beispielsweise CRT, HDMI, TV, LVDS), einer oder mehreren Grafikbaugruppen und/oder Grafikanschlüssen und/oder einem oder mehreren Speicherbausteinen (wie beispielsweise Dual In-Line Memory Module oder DIMM-Bausteine) gekoppelt.
  • Bei einigen Ausführungsformen ist PCH 204 direkt und/oder indirekt mit einer Anzahl an Geräten u. a. ohne Einschränkung Peripheral Component Interconnect-(PCI)-Geräten und/oder PCI-Bussen, universellen seriellen Bus-(USB)-Geräten und/oder USB-Bussen, Serial ATA-Geräten, SPI-Flash-Geräten, diskreten TPM-Geräten, Super-I/O-Geräten, SMBus-Geräten, High-Definition-Audiogeräten, PCI Express-Geräten, lokalen Netzwerk-(LAN)-Geräten, Weitverkehrsnetzwerk-(WAN)-Geräten, drahtlosen lokalen Netzwerk-(WLAN)-Geräten, Wireless Wide Area Network-(WWAN)-Geräten, WiMAX-Geräten, Flash-Speicher-Geräten, Express-Karten-Geräten usw. gekoppelt.
  • 3 veranschaulicht eine Handhabbarkeitsengine, Managementengine und/oder ME 300 gemäß einiger Ausführungsformen. Bei einigen Ausführungsformen ist ME 300 gleich oder ähnlich zu anderen hier beschriebenen ME-Geräten (bei einigen Ausführungsformen ist ME 300 beispielsweise gleich oder ähnlich zu ME 112 und/oder ME 212, die oben beschrieben sind). Bei einigen Ausführungsformen umfasst ME 300 einen Prozessor (wie beispielsweise einen ARC-Prozessor) 302, einen Codecache 304, einen Daten-Cache 306, eine direkter Speicherzugriff-(DMA)-Engine 308, eine Crypto-Engine 310, eine Read Only Memory (Rom) 312, eine Controller-Link-(CLink)-Schnittstelle 314, eine Managementengine-Schnittstelle 316, eine Memory-Controller-Schnittstelle 318, einen Interrupt-Controller 320, hochpräzise und/oder Watchdog-Timer 322, interner RAM (und/oder SRAM) 324 und/oder ein Verbinder 326 zu einem Hauptspeicher-Controller, die über einen ME-Backbone-Bus 330 miteinander gekoppelt sind.
  • Der Codecache 304 und Daten-Cache 306 helfen dabei, die ME-Funktionalität durch Reduzieren von Speicherzugriffen auf den Systemspeicher zu beschleunigen. Die DMA-Engine 308 unterstützt den ME-300 dabei, Daten zu und vom OS-Speicher und ME-UMA-(Unified Memory Architecture)-Speicher zu bewegen. Auf die DMA-Engine 308 kann nur von der ME-300 zugegriffen werden, und das OS kann nicht auf sie zugreifen. Weiter bietet die ME 300 keine generischen Schnittstellen zum OS, um auf die DMA-Engine 308 zuzugreifen. Die Crypto-Engine 310 bietet Hardware-Offloads, um die kryptografischen Operationen zu beschleunigen, die innerhalb der ME 302 für sichere Kommunikationsprotokolle, wie beispielsweise drahtlose Sicherheit, HTTP-Sicherheit über TLS usw. ausgeführt werden. Der anfängliche Bootcode für die ME 300 befindet sich im ROM 312 und wird von diesem ausgeführt. Bei einigen Ausführungsformen wird die CLink-Schnittstelle 314 für die Kommunikation zwischen dem GMCH und ICH bei Energiesparzuständen wie beispielsweise Standby-Modus oder Ruhezustand verwendet. Einige spezielle ME-Geräte im ICH kommunizieren mit der ME 300 ausschließlich über CLink, während einige Geräte über DMI sowie CLink (beispielsweise dem Netzwerk-Controller) kommunizieren.
  • Ein kleiner Teil des Systemspeichers wird von der ME 300 für ihren Laufzeitspeicher verwendet. Diese Trennung erfolgt unter Verwendung des UMA-Mechanismus. Bei einigen Ausführungsformen verwendet ein integrierter Grafikcontroller im GMCH auch den gleichen Mechanismus, um einen Teil des Hauptsystem-Speichers für seine Zwecke zu verwenden. Bei einigen Ausführungsformen ist die Größe dieses Speichers 16 MB, was weniger als 1% des gesamten System-RAM in einem Computer beträgt, der 2–3 GB an DRAM aufweist. Von der Perspektive des OS wird der Grafik-UMA-Speicherabschnitt ein wenig größer erscheinen, als derjenige von Computer, die keine ME haben.
  • Bei einigen Ausführungsformen verwendet die ME 300 einen NOR-Flash-Permanentspeicher (NVM), der sich auf dem Motherboard für die permanente Speicherung des Codes, der Konfiguration, der Anwenderdaten usw. befindet. Der NVM wird auch verwendet, um den BIOS-Code und andere OEM-spezifische Daten zu speichern. Der NVM ist in spezifische Regionen unterteilt, einschließlich beispielsweise separaten Regionen für die ME, das BIOS und den Netzwerk-Controller. Der NVM enthält einen Zugangskontrollen-Beschreiber (wie beispielsweise ganz zu Beginn und/oder bei Adresse 0 der NVM), der die Genehmigungen für den Zugriff auf die verschiedenen Regionen des NVM bestimmt. Die ICH-Hardware stellt sicher, dass diese Genehmigungen durchgesetzt werden. Der Controller, den der ICH verwendet, um auf den Flash zuzugreifen, beruht auf Serial Peripheral Interface (SPI). Die ME-Region des Flashs ist weiter in Regionen für Code, Wiederherstellungs-Code, interne Konfigurationsdaten und variablen Speicher, Ereignisprotokolle und benutzer-/ISV-relevante Daten unterteilt.
  • Bei einigen Ausführungsformen ist nur bei Desktop-Plattformen der Ethernet-Netzwerkadapter mit der ME 300 verbunden. Bei einigen Ausführungsformen hat bei mobilen Plattformen die ME 300 Zugriff sowohl auf Ethernet- als auch auf WiFi-Netzwerk-Controller (beispielsweise beide, wenn das OS funktionsfähig ist und wenn es nicht funktionsfähig ist, wie beispielsweise wenn das System abgestürzt ist, schläft usw.). Netzwerk-Controller wie beispielsweise Ethernet- und WiFi-Controller kommunizieren bei einigen Ausführungsformen mit der ME 300 unter Verwendung der CLink-Schnittstelle, und die ME greift auf den Verkehr von einem Ethernet-Controller (beispielsweise einem Gigabit-Ethernet-Controller) auf andere Weise zu als von einem WiFi-Controller. Die ME sendet und empfängt Verkehr direkt über den Ethernet-Controller ohne das OS zu verwenden. Bei einigen Ausführungsformen mit WiFi hat der Netzwerk-Controller einen einzelnen Master, und wenn das OS betriebsfähig ist, wird der WiFi-Verkehr zur ME über den WiFi-Treiber im OS geroutet. Wenn jedoch das OS abstürzt oder schlafen geht, übernimmt die ME die Eigentümerschaft des WiFi-Netzwerk-Controllers und führt die Kommunikation direkt durch.
  • Fernkommunikation mit Computern kann von einer Managementkonsole (wie beispielsweise unter Verwendung von HTTP und anderen Protokollen) über diese Schnittstellen implementiert werden. Die ME-Firmware kann einen gewöhnlichen LAN-MAC, Hostnamen und IP-Adresse mit dem OS teilen, was hilft, die IT-Infrastrukturkosten zu minimieren.
  • Bei einigen Ausführungsformen unterstützt die Außerband-(OOB)-Kommunikationsarchitektur der ME beispielsweise ARP, DHCP und IP-Port-Filter. Die OOB-Kommunikationsarchitektur unterstützt ARP bei der Versendung von ARP-Paketen, die eine spezifische IP-Adresse enthalten, zum Host und/oder der ME. Die OOB-Kommunikationsarchitektur unterstützt DHCP bei der Versendung von DHCP-Offer- und ACK-Paketen zum Host und/oder der ME. Die OOB-Kommunikationsarchitektur unterstützt IP-Port-Filter (beispielsweise HTTP und Umleitung) bei der Umleitung eingehender IP-Pakete an einem spezifischen Port zur ME.
  • Bei einigen Ausführungsformen wird der ME-ROM (beispielsweise ROM 312) in das Silizium des GMCH-Chips maskiert. Der ROM enthält den Reset-Vektor (der allererste Befehlssatz, der auszuführen ist, nachdem die ME zurückgesetzt ist). Der ROM ist nur von der ME zugänglich und nicht vom Host oder dem OS. Da der ROM-Code im Chip während der Fertigung maskiert wird, kann er nie geändert werden und ist deshalb sicher. Der ROM wird beispielsweise verwendet, um ME-Speicherbereiche zu konfigurieren, bestimmte Hardware-Teile zu initialisieren, die Integrität und Signatur auf dem Firmware-Image auf dem Flash zu prüfen und Kontrolle auf das Firmware-Image zu übertragen. Bei einigen Ausführungsformen ist der ROM die Vertrauenswurzel der ME-Firmware.
  • Bei einigen Ausführungsformen ist ein ME-Kernmodul aus Diensten und Treibern zusammengesetzt, welche die Grundfunktionalität der ME-Umgebung bereitstellen. Der Kern stellt das grundlegende Dienstepaket bereit, das für jede Mehrzweck-Ausführungsumgebung erwartet wird. Bei einigen Ausführungsformen schließen diese Dienste beispielsweise Bootstrap und Initialisierung, Task- und Thread-Verwaltung, Speicherverwaltung, Interruptverwaltung, Zeitgeber, Messaging und Ereignisse-/Ereignis-Überwachung, Sicherheit und kryptografische Funktionen, Treiber für lokale und Netzwerkschnittstellen, Speicher usw., Power-Management, Schnittstellenauffindung und/oder Firmware-Aktualisierung ein.
  • Da die ME einige sehr sicherheitsrelevante Technologien beherbergt (wie beispielsweise das Trusted Platform Module oder TPM), ist es erforderlich, einen hohen Abscheidegrad und einen hohen Grad an Isolation von der Kernebene zwischen den hochsicherheitsrelevanten Anwendungen und anderen bereitzustellen. Deshalb ist der Kern bei einigen Ausführungsformen in privilegierte und nicht privilegierte Teile partitioniert. Der privilegierte Teil schließt den ROM, die Initialisierungsmodule, wie beispielsweise Lader und Bring-Up-Module, einen Teil des Kerns genannt privilegierter Kern und die TPM-Firmware ein. Der nicht privilegierte Teil schließt den verbleibenden Teil des Kerns genannt nicht privilegierter Kern, Support-Module, allgemeine Dienste-Module und andere Firmware-Anwendungen ein. Firmware, die im privilegierten Modus ausführt, hat Zugriff zu privilegierten Hardware-Ressourcen wie beispielsweise bestimmte Speicherbereiche und bestimmte Hardware-Register. Nicht privilegierte Firmware, die versucht, auf privilegierte Ressourcen zuzugreifen, bewirkt das Auftreten einer Ausnahme oder eines Interrupts. Ein Register in der ME enthält die Adresse des Codes, um in den privilegierten Modus ein- und aus ihm auszusteigen.
  • Bei einigen Ausführungsformen hat die ME 300 Zugriff auf einen Spezial-Takt auf dem Chipsatz genannt Protected Real Time Clock (PRTC), auf den vom OS nicht zugegriffen werden kann und der nur von der ME zugänglich ist.
  • 4 zeigt ein System 400 gemäß einiger Ausführungsformen. Bei einigen Ausführungsformen umfasst das System 400 eine Handhabbarkeitsengine (und/oder Managementengine und/oder ME) 402 gekoppelt mit einem Berechtigungs-Server 404 (wie beispielsweise ein oder mehrere Business-to-Business-Server oder B2B-Server) über das Internet 406.
  • Eine Berechtigung 412 wird zwischen der ME 402 und dem Berechtigungs-Server 402 übertragen. Die ME 402 ist mit dem Internet über Host-Kommunikationslink 408 und/oder OOB-Netzwerk-Kommunikationslink 410 gekoppelt.
  • Bei einigen Ausführungsformen umfasst ME 402 einen Host zu Embedded Controller Interface (HECI) 422, einen HECI-Treiber 424, eine Netzwerkkarte (NIC) 426, einen Netzwerk-Stack 428, Active Management Technology (AMT) 430, flexible SKU 432, Capabilities and Licensing Services (CLS) und/oder Intel Capabilities and Licensing Services (iCLS) 434, Sicherungszugriff 436, Hardwarekennung (HWID) 438, Sicherungslesezugriff 440, Sicherungsaufhebung 442, sicheres Dateisystem 444, Serial Peripheral Interface-(SPI)Flash 446, kryptografischer Treiber 448, schlüsselbasierte Rivest Shamir Adleman-(RSA)-Verschlüsselung 450, sicherer Hash-Algorithmus Version 1 (SHA-1) 452, echter Zufallszahlengenerator (TRNG) 454, sichere Zeit 456 und/oder Protected Real Time Clock (PRTC) 458. Bei einigen Ausführungsformen sind HECI 422, NIC 426, HWID 438, Sicherungs-Lesezugriff 440, Sicherungsaufhebung 442, SPI-Flash-446, RSA 450, SHA-1 452, TRNG 454 und/oder PRTC 458 in Hardware implementiert. Bei einigen Ausführungsformen sind HECI-Treiber 424, Netzwerk-Stack 428, AMT 430, flexible SKU 432, CLS 434, Sicherungszugriff 436, sicheres Dateisystem 444, Crypto-Treiber 448 und/oder sichere Zeit 456 in Firmware implementiert.
  • Bei einigen Ausführungsformen veranschaulicht System 400 Baustein- und Datenstruktur, die verwendet werden kann, um sichere Operationen zwischen ME 402 und einem Signaturserver durchzuführen. Gemäß einigen Ausführungsformen ist die Berechtigung 412 eine binäre Datenstruktur, die authentische Merkmal-Information an das ME-System bereitstellt. Bei einigen Ausführungsformen ist Berechtigungs-Server 404 ein Back-End-Infrastruktur-Server (oder mehrere Server), die eine Berechtigung, wie beispielsweise Berechtigung 412 generieren können. Bei einigen Ausführungsformen läuft ME-Firmware auf ME-402 ab, die mehrere Komponenten einschließt. Bei einigen Ausführungsformen validiert und parst beispielsweise CLS 434 Berechtigungen, um Information an CLS-Plugins, wie beispielsweise die Flex-SKU 432 und/oder SaaS/SMT (nicht veranschaulicht in 4) bereitzustellen. Bei einigen Ausführungsformen erreichen CLS-Plugins wie beispielsweise Flex-SKU (oder andere CLS-Plugins wie beispielsweise SaaS) spezifische Merkmale der ME. Bei einigen Ausführungsformen werden Firmware-Dienste und Treiber verwendet, um wesentliche Dienste an CLS 434 und CLS-Plugins bereitzustellen. Bei einigen Ausführungsformen ermöglichen externe Schnittstellen-Firmware-Komponenten der ME eine Schnittstelle mit externen Entitäten über diese externen Schnittstellen-Komponenten (wie beispielsweise AMT 430, HECI Treiber 424, Netzwerk-Stack 428 usw.) herzustellen.
  • Bei einigen Ausführungsformen ist HWID 438 ein eindeutiger Identifikator in jedem Chipsatz, der während des Fertigungsverfahrens des Chipsatzes in der Chipsatz-Hardware erzeugt wird (beispielsweise implementiert als Sicherungen im Chipsatz). Bei einigen Ausführungsformen ist Sicherungs-Lesezugriff 440 eine Hardware-Logik, die verwendet wird, um die Sicherungen im Chipsatz zu lesen. Bei einigen Ausführungsformen ist die Sicherungsaufhebung 442 ein Mechanismus, anhand dessen die Hardware die tatsächlichen Sicherungen mit einer bereitgestellten Bitmap während eines Punktes in der Initialisierung der Chipsatz-Hardware aufhebt. Bei einigen Ausführungsformen ist der Sicherungszugriff 436 Firmware-Logik, die die Sicherungs-Lese- und Aufhebungsmechanismen in der Firmware-Komponente CLS 434 implementiert. Bei einigen Ausführungsformen ist SPI-Flash 446 ein nichtflüchtiger Speichermechanismus (beispielsweise NOR-basierter Flash), der vom Chipsatz unter Verwendung des SPI-Protokolls zugänglich ist (und deshalb mit einem SPI-Controller im Chipsatz verbunden ist). Bei einigen Ausführungsformen ist RSA 450 eine Hardware-Einheit im Chipsatz, die bei der Beschleunigung der RSA-Berechnung über hardwareorientierte Addier- und Multiplizierschaltungen hilft (und bei einigen Ausführungsformen ist der Rest der RSA-Logik in der Firmware implementiert). Bei einigen Ausführungsformen ist SHA-1 452 eine Hardware-Einheit im Chipsatz, die einen SHA-1-Algorithmus implementiert. Bei einigen Ausführungsformen ist TRNG 454 eine Hardware-Einheit im Chipsatz, die eindeutige Zufallszahlen im Chipsatz generiert, indem beispielsweise ein Konzept des thermischen Rauschens verwendet wird. Bei einigen Ausführungsformen ist Crypto-Treiber 448 ein Firmware-Treiber, der Verschlüsselungsvorgänge als nutzbare Schnittstellen (beispielsweise RSA-2048-Zeichen, verschlüsseln, verifizieren, entschlüsseln, SHA-1-Hash generieren, TRNG generieren usw.) an andere Firmware-Komponenten wie beispielsweise CLS 434 bereitstellt.
  • Bei einigen Ausführungsformen ist PRTC 458 ein geschützter Takt, der die Zeit behält, die von Host-OS-Software nicht veränderbar ist, wodurch eine sicherere Zeitvorstellung an ME-Firmware-Komponenten wie beispielsweise die CLS 434 bereitgestellt wird. Bei einigen Ausführungsformen hat die ME (beispielsweise ME 112, ME 212, ME 300 und/oder ME 402) Zugriff auf einen Spezial-Takt auf dem Chipsatz (beispielsweise PRTC 458). Auf diesen Takt kann nur von der ME zugegriffen werden und er ist nicht vom OS zugänglich. Die ME verwendet diesen Takt für ihre zeitbezogenen Überprüfungen (wie beispielsweise Zertifikatvalidierungen, Kerberos Zeitstempel-Überprüfungen usw.) anstatt sich auf die Systemechtzeituhr (RTC) zu verlassen. Die RTC kann durch den Benutzer oder Malware im OS geändert (rückdatiert oder vorgestellt) werden. Deshalb verlässt sich die ME nicht auf die RTC. Bei einigen Ausführungsformen wird die PRTC durch einen Akku mit Energie versorgt, sodass die PRTC die Zeit beibehält, selbst wenn der Computer vollständig abgeschaltet ist. Bei einigen Ausführungsformen wird, wenn ein System beispielsweise in einem Kleinunternehmens-Modus bereitgestellt wird, der ME-Takt mit dem Takt des BIOS beim Booten synchronisiert, und beide repräsentieren generell die Ortszeit. Bei einigen Ausführungsformen sind die Takte separat, und der PRTC-Takt in der ME wird beispielsweise auf GMT-Zeit eingestellt, wenn beispielsweise ein System in einem Unternehmensmodus bereitgestellt wird.
  • Bei einigen Ausführungsformen schließt eine ME einen echten Zufallszahlengenerator ein (wie beispielsweise TRNG 454), der auf Varianten des thermischen Rauschens beruht.
  • Der TRNG ist beim Unterstützen in kryptografischen Transaktionen sehr hilfreich, wie beispielsweise zufällige Sitzungsschlüssel, Tokens, Noncen usw. zu generieren. Der TRNG gibt beispielsweise 32-Bit-Zufallszahlen zu einer Zeit aus.
  • Viele Verschlüsselungsalgorithmen und -mechanismen machen von Zufallszahlen Gebrauch. Ein wichtiges Merkmal eines Zufallsgenerators (RNG) ist seine Entropie, was die Messung des Unvermögens eines externen Betrachters ist, die nächste Zahl vorherzusagen, die vom RNG generiert wird, selbst wenn der Betrachter alle zuvor erzeugten Zufallszahlen von diesem Generator kennt. Ein Pseudo-RNG (PRNG) kann verwendet werden, welcher ein deterministischer Algorithmus ist, der die nächste Zufallszahl basierend auf dem Zustand des aktuellen Generators erzeugt. Solch ein Algorithmus hält ein hohes Niveau an Entropie aufrecht, solange der Anfangszustand (oder „Saat-Zustand”) des PRNG nicht bekannt ist. Einige PRNG-Implementierungen säen sich selbst, indem sie einen Wert von einem der Plattform-Takte verwenden. Dieser Wert kann aufgrund der hohen Auflösung des Taktes ein wenig umvorhersagbar sein und schafft deshalb eine vernünftige Saat für den PRNG, der für Anwendungen geeignet ist, die ein moderates Sicherheitsniveau erfordern. Vorausgesetzt, dass eine große Anzahl von Plattformen zur gleichen Zeit hochfährt (eine Zeit, die innerhalb von ein paar Minuten oder Sekunden bekannt sein kann), könnte dies einem potenziellen Angreifer helfen, die Möglichkeiten einzugrenzen und deshalb den PRNG-Saat-Zustand zu knacken, was die Vorhersage der nächsten vom PRNG generierten Zahlen ermöglicht. Ein Angreifer könnte auch von den generierten Zahlen einer gehackten Plattform lernen, um andere Plattformen im Unternehmen zu knacken (auch bekannt als ein BORE-Angriff: „Einmal geknackt, läuft überall”).
  • Bei einigen Ausführungsformen kann ein echter Zufallszahlengenerator (TRNG), wie beispielsweise TRNG 454, ein TRNG-Hardwaregerät sein. Bei einigen Ausführungsformen kann solch ein TRNG auf zwei Widerständen beruhen, die ein thermisches Rauschen generieren. Das Rauschen wird verstärkt und einem frequenzmodulierten Niederfrequenzoszillator als Eingang bereitgestellt. Kombiniert mit einem Hochfrequenzoszillator wird ein beinahe zufälliger Bitstrom generiert. Ein Spannungsregler steuert die Hardware-Komponenten, um jede auf der Spannung basierende Vorspannung zu vermeiden. Des Weiteren versucht ein Logikblock, den Bitstrom jeder Vorspannung zu korrigieren, die eingeführt worden sein kann (wie beispielsweise aufgrund eines unvollständigen Arbeitszyklus des Oszillators), indem ein Standard-Antivorspannungs-Korrekturalgorithmus verwendet wird.
  • Bei einigen Ausführungsformen kann ein PRNG für den TRNG implementiert werden, wo der Zustand des PRNG gelegentlich zurückgesetzt wird, um auf einen vom TRNG generierten Zustand zu initialisieren. Dies erzeugt einen machtvollen hochklassigen RNG, der in der Lage ist, mit der hohen Verwendung von Zufallszahlen im Subsystem Schritt zu halten.
  • Bei einigen Ausführungsformen hat der Chipsatz einen Schlüssel (beispielsweise einen 128-Bit-Schlüssel) zur Verwendung durch Firmware bei symmetrischer Verschlüsselung und Integritätsschutz-Operationen. Dieser Schlüssel wird während der Fertigung des Chipsatzes generiert, indem zufällig Sicherungen durchgebrannt werden, die für diesen Zweck vorgesehen sind. Die ME ist die einzige Komponente, die auf dieses Schlüsselerstellungsmaterial zugreifen kann, und sie stellt die Vertrauenswurzel für mehrere ME-Operationen bereit. Keine Einheit außerhalb der ME kennt den Wert dieses Schlüssels. Bei einigen Ausführungsformen wird ein Chipsatz-Sicherungsschlüssel verwendet, der für jedes System eindeutig und beispielsweise nur der Firmware bekannt ist. Gemäß einiger Ausführungsformen ist der Chipsatz-Sicherungsschlüssel eine Reihe von 128 Sicherungen im Chipsatz. Jede Sicherung wird entsprechend einem Wert von 0 oder 1 durchgebrannt oder geschlossen. Der Status von jeder Sicherung (0 oder 1) wird bei der Fertigung bestimmt. Ein zufälliger Teilsatz der Sicherungen wird beim Chipsatz-Fertigungsprogramm durchgebrannt, während der Rest unverändert verbleibt. Somit wird ein zufälliger eindeutiger Wert für jeden Chipsatz erzeugt. Der 128-Sicherungen-Satz erzeugt somit einen 128-Bit-Schlüssel (oder einen Schlüssel mit irgendeiner anderen Anzahl an Bits abhängig von der Anzahl an Sicherungen).
  • Bei einigen Ausführungsformen wird die Verschlüsselung von Geheimnissen mit der Verwendung von Standardverschlüsselungstechniken erreicht, aber das interessante Merkmal ist der Schlüssel, der für die Verschlüsselung verwendet wird. Der Verschlüsselungsschlüssel muss in einer nicht flüchtigen Form gespeichert werden, aber der Flash selbst ist keine gute Stelle, um ihn zu speichern (andernfalls würde der Angreifer zuerst diesen Schlüssel vom Flash lesen und ihn dann verwenden, um den Rest der geschützten Daten im Flash zu entschlüsseln). Deshalb leitet bei einigen Ausführungsformen Firmware den Verschlüsselungsschlüssel vom Chipsatz-Sicherungsschlüssel ab und verwendet diesen Verschlüsselungsschlüssel, um die empfindlichen Elemente zu verschlüsseln, die auf dem nicht flüchtigen Flash platziert sind. Da sichere Firmware (beispielsweise ME-Firmware) die einzige Entität ist, die Kenntnis vom Chipsatz-Sicherungsschlüssel hat (und daher vom Verschlüsselungsschlüssel und vom Integritätsschutzschlüssel) ist alles, was der Angreifer sieht, verschlüsselte und/oder integritätsgeschützte Daten, selbst wenn er den Flash-Teil vom System herauszieht und versucht, ihn direkt zu lesen.
  • Gemäß einiger Ausführungsformen befindet sich ein Berechtigungs-Server (wie beispielsweise Berechtigungs-Server 404) in der Ferne auf einem Netzwerk von einer ME (beispielsweise ME 112, ME 212, ME 300 und/oder ME 402). Bei einigen Ausführungsformen ist ein Berechtigungs-Server (wie beispielsweise ein Berechtigungs-Server 404) ein vertrauenswürdiger Provisioning Server, der authentifizierte Berechtigungen erzeugt, die von der ME zu verwenden sind (beispielsweise ME 112, ME 212, ME 300 und/oder ME 402). Der Berechtigungs-Server hat sicheren Zugriff (beispielsweise über ein oder mehrere Hardware-Signiermodule und/oder HSM) auf einen kryptografischen privaten RSA-(Rivest Shamir Aldeman)-Schlüssel, dessen öffentliche Komponente in der signierten ME-Firmware eingebettet ist. Bei einigen Ausführungsformen entspricht das Hardware-Signiermodul (HSM) FIPS-140-2 Ebene 3. Bei einigen Ausführungsformen ist der HSM eine in einem Signaturserver installierte PCI-Karte. Bei einigen Ausführungsformen ist der HSM verfälschungssicher, stellt aktive Überwachung bereit, zerstört Schlüsselerstellungsmaterial im Falle von Manipulation, schützt einen Berechtigungssignierschlüssel, führt Berechtigungssignierungscode aus und/oder ist für Berechtigungserwerbe verantwortlich.
  • Bei einigen Ausführungsformen kann der Berechtigungs-Server Berechtigungen erzeugen, die die ME als von einer vertrauenswürdigen Entität entsprungen authentisieren kann. Der Berechtigungs-Server bettet Hardware-Sicherungsaufhebungsinformationen in einer signierten Berechtigung ein (wie beispielsweise Berechtigung 412), den die ME verbraucht, um einen weichen SKU-Prozess zu implementieren. Bei einigen Ausführungsformen führen ein oder mehrere Server abhängig beispielsweise von der Implementierung von Infrastruktur und Übertragungskapazitätsanforderungen die hier beschriebenen Operationen durch, die in Zusammenhang mit einem Berechtigungs-Server stehen.
  • Bei einigen Ausführungsformen ist eine Berechtigung (wie beispielsweise Berechtigung 412) eine signierte Datenstruktur, die Hardware-Sicherungsaufhebungsinformationen enthält. Bei einigen Ausführungsformen kann niemand außer einer Entität (beispielsweise der Eigentümer des Berechtigungs-Servers) eine Berechtigung erzeugen, die erfolgreich von einer ME validiert werden kann (beispielsweise ME 112, ME 212, ME 300 und/oder ME 402). Die Berechtigung enthält auch beispielsweise einen Klassen- und Teilklassen-Identifikator, um die Interpretation des Rests der Datenstruktur anzuzeigen. Die Berechtigung enthält beispielsweise auch einen Zeitstempel, der anzeigt, wann die Berechtigung erzeugt wurde (beispielsweise in einem „Zeitstempel”-Feld). Die Berechtigung enthält auch beispielsweise einige Attribute (wie beispielsweise in einem „Flag”-Feld), die einige Eigenschaften der Berechtigung anzeigen, wie beispielsweise ob das System unmittelbar nach der Installation der Berechtigung neu bootet.
  • Bei einigen Ausführungsformen ist eine Handhabbarkeitsengine, Managementengine, und/oder ME (wie beispielsweise ME 112, ME 212, ME 300 und/oder ME 402) unter anderem eine Hardware-Engine, die das Programmieren eines Sicherungsaufhebungsmechanismus ausführt. Die ME führt beispielsweise signierten/authentifizierten und verifizierten Firmware-Code aus. Diese ME-Firmware ist fähig, mit Benutzer-Code zu interagieren, der im Betriebssystem (OS) ausführt. Der Benutzer-Code kann mit dem ME-Firmware-Code interagieren, um Hardware-Sicherungsaufhebungsregister zu programmieren. Die ME-Firmware stellt sicher, dass alle Bedingungen erfüllt sind (beispielsweise einschließlich der Berechtigungsvalidierung), bevor sie die Werte in den Hardware-Sicherungsaufhebungsregistern ändert. Die ME führt auch ihr Ende des Berechtigungs-Installationsprotokolls aus.
  • Bei einigen Ausführungsformen verwendet eine ME ein Berechtigungssignierschlüsselpaar (beispielsweise ein symmetrisches RSA-Schlüsselpaar) für die Berechtigungssignierung und – überprüfung. Der private Teil dieses Schlüsselpaars wird von einem Unternehmen, wie beispielsweise einem Hersteller der ME, besessen und befindet sich in einer sicheren Datenzentrumseinrichtung dieses Unternehmens (wie beispielsweise in einem Computer, der ein Hardware-Signiermodul oder HSM verwendet). Der öffentliche Teil des Schlüssels wird in einem signierten ME-Firmware-Image aufrechterhalten, das von niemandem geändert werden kann. Berechtigungen werden durch den privaten Teil des Schlüsselpaars signiert, und der öffentliche Teil des Schlüssels wird von einer ME verwendet, um die Signatur zu verifizieren.
  • Bei einigen Ausführungsformen wird ein SafeID-System von Schlüsseln implementiert, in dem jede ME einen eindeutigen privaten SafeID-Schlüssel hat, der in den Chipsatz während eines Fertigungsverfahrens des Chipsatzes als Sicherungen gebrannt wird. Die ME ermöglicht niemals irgendeinen externen Zugriff auf diesen Schlüssel. Der Gruppenteil des Schlüssels wird von einem Unternehmen wie beispielsweise dem Hersteller des Chipsatzes besessen und befindet sich in einem Berechtigungs-Server-System, das sich in einem Datenzentrum dieses Unternehmens befindet. Der SafeID-Schlüssel im Chipsatz wird verwendet, um eine Signatur zu erzeugen (beispielsweise auf einem Zeitstempel und einer Nonce), der vom Berechtigungs-Server unter Verwendung des Gruppenschlüssels verifiziert wird. Dies versichert dem Berechtigungs-Server, dass die Signatur von einer wahren und gültigen ME durchgeführt wurde.
  • Bei einigen Ausführungsformen ist der Chipsatz-Sicherungsschlüssel ein symmetrischer Schlüssel, der für jeden Chipsatz (und/oder für jeden Chipsatz-Teil) eindeutig ist. Er wird einzigartig in jeden Chipsatz während eines Fertigungsverfahrens programmiert, indem zufällig Sicherungen in einer Programmieren-und-Vergessen-Weise durchgebrannt werden. Niemand (einschließlich des Herstellers des Chipsatzes oder Chipsatz-Teils) hat Kenntnis von diesem Schlüssel, und die ME lässt nie zu, dass auf diesen Schlüssel außerhalb der ME zugegriffen wird.
  • 5 veranschaulicht ein System 500 gemäß einiger Ausführungsformen. System 500 schließt einen Kundenstandort 502, einen Berechtigungs-Server 504 (beispielsweise bei einigen Ausführungsformen ähnlich und/oder gleich Berechtigungs-Server 404), einen Enrollment Server 506 und ein Netzwerk 508 (beispielsweise das Internet) ein. Bei einigen Ausführungsformen koppelt Netzwerk 508 Kundenstandort 502, Berechtigungs-Server 504 und Enrollment Server 506 zusammen. Bei einigen Ausführungsformen umfasst Kundenstandort 502 einen Kunden, das Computersystem eines Kunden, eine Anmeldeanwendung (EA) 512 und eine ME 514. Bei einigen Ausführungsformen befinden sich EA 512 und/oder ME 514 auf dem Computersystem des Kunden. Bei einigen Ausführungsformen schließt Berechtigungs-Server (PS) 504 ein oder mehrere Business-to-Business-(B2B)-Server und/oder ein oder mehrere Back-End-Server ein. Bei einigen Ausführungsformen schließt Enrollment Server 506 ein oder mehrere Business-to-Customer-(B2C)-Server, ein oder mehrere ISV-Server und/oder ein oder mehrere Front-End-Server ein. Bei einigen Ausführungsformen repräsentiert die punktierte Linie 522 Berechtigungsreihenfolgen- und/oder Erfüllungstransaktionen, beispielsweise ISV-Berechtigungsreihenfolgen- und/oder Erfüllungstransaktionen zwischen Berechtigungs-Server 504 und Enrollment Server 506. Bei einigen Ausführungsformen repräsentiert die punktierte Linie 524 Kunden-Berechtigungsreihenfolgen- und/oder -erfüllungstransaktionen zwischen Kundenstandort 502 und Enrollment Server 504. Bei einigen Ausführungsformen ist Berechtigungs-Server 504 ähnlich oder gleich Berechtigungs-Server 404. Bei einigen Ausführungsformen ist ME 514 gleich oder ähnlich zu ME 112, ME 212, ME 300 und/oder ME 402.
  • Wie oben erwähnt ist bei einigen Ausführungsformen ES 506 ein B2C-Server (und/oder mehr als ein B2C-Server). Bei einigen Ausführungsformen ist ES 506 mehr als ein Server für den Lastausgleich. Bei einigen Ausführungsformen interagiert ES 506 mit Kunden, um das Frontend des Beschaffungsprozesses zu betreiben und mit dem PS 504 zu interagieren, um Berechtigungen zu erwerben/zu erhalten.
  • Bei einigen Ausführungsformen ist die Anmeldeanwendung (EA) 512 eine lokale Hostanwendung oder ein Agent, der mit dem Enrollment Server (beispielsweise ES 506) interagiert, um einen Kunden-Beschaffungsprozess durchzuführen und Berechtigungen anzufordern/zu erhalten. EA 512 interagiert auch mit der ME 514, um Berechtigungen in einer In-Band-Weise zu installieren. Zum Zwecke des Berechtigungs-Installationsprotokolls agiert bei einigen Ausführungsformen der EA 512 größtenteils als einen Durchleitagent zwischen der ME 514 und dem Back-End (beispielsweise dem Berechtigungs-Server 504 und dem Enrollment Server 506). Der EA 512 interagiert mit dem Benutzer (Kunde), um Bezahlungs- und Transaktionsinformationen zu generieren, und diese Informationen im Berechtigungs-Installationsprotokoll zu verwenden.
  • Bei einigen Ausführungsformen betreibt der Kunde am Kundenstandort 502 den EA-Agent 512, um ein neues Merkmal (wie beispielsweise Flex-SKU-Merkmal) vom Computersystem des Kunden zu erwerben. Bei einigen Ausführungsformen kann der Kunde beispielsweise ein Endbenutzer oder ein Firmen-IT-Einkäufer sein.
  • Bei einigen Ausführungsformen ist Enrollment Server 506 eine ISV/MSP/MSP-Domain, die dafür verantwortlich ist, mit dem Kunden (beispielsweise ein Endbenutzer) eine Schnittstelle herzustellen, um einen Berechtigungserwerbs- und Installationsvorgang zu erreichen. Bei einigen Ausführungsformen wird ISV/MSP verwendet, um den Verkauf von Merkmalen zu schließen (wie beispielsweise Transaktionsinitiierung, Einnahmenerhebung, Management und Support usw. zu implementieren).
  • Bei einigen Ausführungsformen stellt ein Unternehmen mit einem Berechtigungs-Server wie beispielsweise Berechtigungs-Server 504 den Electronic Commerce-Support für Bestell-, Liefer- und Rechnungsstellungsberechtigungen bereit und ist die einzige Quelle von Berechtigungen. Bei einigen Ausführungsformen steht der Berechtigungs-Server 506 unter der direkten physischen Kontrolle dieses Unternehmens (beispielsweise befindet sich der Berechtigungs-Server 506 auf dem Gelände dieses Unternehmens, und dieses Unternehmen stellt Support und Sicherheit für den Berechtigungs-Server 506 bereit).
  • Bei einigen Ausführungsformen wird Schutz gegen Hacking beim Endkunden und/oder den Produktherstellungsstandorten bereitgestellt und der Missbrauch der Benutzerprivatsphäre wird verhindert, Einzeldaten werden nicht preisgegeben, eine fehlertolerante Operation kann während einer Feldaktualisierung der CLS-Firmware und/oder Berechtigungsdaten beibehalten werden, und Support für Erstattungen und Umtausch wird für Merkmal-Aktualisierungen, Merkmal-Stornierungen und/oder Test-Merkmale usw. bereitgestellt.
  • 6 veranschaulicht eine Berechtigung 600 gemäß einiger Ausführungsformen. Bei einigen Ausführungsformen schließt Berechtigung 600 eine Berechtigungsnachricht 602 und/oder eine Berechtigungssignatur 604 ein. Berechtigungsnachricht 602 schließt bei einigen Ausführungsformen einen Berechtigungs-Header 612, einen Fähigkeitsbeschreiber 614, einen Berechtigungs-Authentifizierungsidentifikator 616 und/oder einen Kunden-Authentifizierungsidentifikator 618 ein. Bei einigen Ausführungsformen schließt Berechtigungsheader 612 einen ID-String 622, eine Berechtigungsversion 624, eine Berechtigungslänge 626, eine Nachrichtenlänge 628, einen Zeitstempel 630, eine Klasse 632 und/oder Flags 634 ein. Bei einigen Ausführungsformen schließt Fähigkeitsbeschreiber 614 eine Teilklasse 642, eine Lieferanten-ID 644, eine Gerätekennung 646 und/oder einen Merkmal-Identifikator 648 ein. Bei einigen Ausführungsformen schließt Berechtigungssignatur 604 ein Berechtigungsnachricht-Digest 652 ein. Bei einigen Ausführungsformen wird Berechtigungssignatur 604 und/oder Berechtigungsnachricht-Digest 652 mit einem privaten E-Commerce-Schlüssel (wie beispielsweise RPSK-priv) signiert.
  • 7 veranschaulicht ein Berechtigungsinstallationsprotokoll 700 gemäß einiger Ausführungsformen. 7 veranschaulicht einen Kunden 702, eine Anmeldeanwendung (EA) 704, eine Managementengine (ME) 706, einen Enrollment Server (ES) 708 und einen Berechtigungs-Server (PS) 710, von denen jeder am Berechtigungsinstallationsvorgang gemäß einiger Ausführungsformen teilnimmt.
  • Bei einigen Ausführungsformen startet der Kunde 702 zuerst eine Anwendung mit dem EA 704. Dann erhält der EA 704 Plattform-Informationen von der ME 706. Der Kunde 702 sendet dann Einkaufsfähigkeiten wie beispielsweise Geldbeträge zum EA 704. Dann erzeugt der EA 704 eine Berechtigungsanfrage mit der ME 706. Die ME 706 sendet dann eine Nachricht zum EA 704 für den PS 710, um eine Berechtigungsanfrage zu erzeugen. Der EA 704 sendet dann eine Nachricht zum PS 710 im Zusammenhang mit dem Erzeugen einer Berechtigungsanfrage, mit PS-Kunden-Authentifizierung und/oder Geldbeträgen. Der PS 710 sendet dann eine Nachricht zur ME 706, dass er eine Berechtigungsanfrage erzeugt. Dann arbeitet die ME 706 mit dem PS 710, um eine Berechtigung zu installieren. Der PS 710 sendet dann eine Antwort zur ME 706, dass die Berechtigung installiert ist.
  • Gemäß einiger Ausführungsformen wird ein Berechtigungsinstallationsprotokoll wie folgt beschrieben:
    chritt Akteur Beschreibung
    Kunde Kunde startet EA
    EA EA fragt ME auf installierte Berechtigungen ab und präsentiert dem Kunden Optionen.
    Kunde Kunde stellt fest, er hat keine Berechtigungen installiert und entscheidet, Fähigkeit X für seinen PC zu kaufen. Hinweis: Gekaufte Menge wird erfasst von E-Commerce-Server. Wird später verwendet für ausgefüllten $-Betrag im CAID-Feld durch den PS.
    EA Berechtigungsanfragen-Befehl zur ME erzeugen, um Berechtigung X zu erzeugen.
    ME ME bildet Anfrage PS Berechtigung erzeugen und sendet sie als eine Antwort zur EA ME erzeugt Berechtigungsauthentifizierungs-ID (PAID) mit dem Chipsatz-Sicherungsschlüssel, um die Berechtigung an diesen Computer zu binden ME erzeugt neuen Berechtigung-X-Körper (unsigniert). Berechtigung-X-Körper ist ein Objekt, das den PAID und Zeitstempel enthält. ME generiert einen Zufallswert RAND1 ME erzeugt SafeIDBlob = RSA-Verschlüsselung{RPSK-pub, „Ich bin eine ME” | Aktuelle UTC-Zeit |SafeIDSign („Ich bin eine ME” | Aktuelle UTC-Zeit)} ME erzeugt M1 = PS Erzeugungsberechtigungsanfrage | RAND1 | Berechtigung X | SafeIDBlob ME sendet M1 zu EA
    EA EA erstellt PS-Kunden-Authentifizierungsnachricht und sendet sie und die PS-Erzeugungsberechtigungsanfragen-Nachricht zum Berechtigungs-Server. Kunde (EA) hat einen Customer_Auth_Key. CAID ist pro Transaktion. Kunde berechnet CAID = Hash (Customer_Auth_Key, CustomerAuthMessage). EA/ES erzeugt M2 = RSA-Verschlüsselung (RPSK-pub, PS-Kunden-Authentifizierung | CAID) EA sendet M1 und M2 zum Back-End (ES/PS)
    PS PS entschlüsselt und validiert EA-Nachrichten und erstellt PS-Erzeugungsberechtigungsantwort-Nachricht zur ME. PS entschlüsselt M2 mit RPSK-priv PS fügt CAID von M2 und $$ in den Berechtigung-X-Nachrichtenkörper ein. Jetzt enthält Berechtigung X PAID, CAID und Zeitstempel von der ME. Andere Informationen in der Berechtigung X schließen Berechtigungsversion, Berechtigungslänge, Fähigkeitsbeschreibungen, Berechtigungs-ID, Flags usw. ein. PS verifiziert $ von EA/ES, verifiziert Inhalte von Berechtigung X und signiert dann Berechtigung X. PS muss die Zeitstempel-Informationen in Berechtigung X verifizieren und aktualisieren. PS entschlüsselt den SafeIDBlob unter Verwendung von RPSK-priv und verifiziert die SafeID-Signatur mit dem weithin bekannten String „Ich bin eine ME” und der aktuellen UTC-Zeit. PS verifiziert auch, ob die UTC-Zeit innerhalb eines +/– 48-Stunden-Bereichs ist. PS erzeugt M3 = RSA-Zeichen-Nachricht (RPSK-priv, PS-Erzeugungsberechtigungsantwort | RAND1 | RAND2 | Berechtigung X). PS sendet M3 zur ME (über EA)
    ME ME installiert Berechtigung X und erstellt PS-Berechtigung-installiert-Nachricht zum PS. ME validiert M3 unter Verwendung von RPSK-pub. Die folgenden Elemente sind mindestens verifiziert: Signatur PAID Merkmal RAND1 Flags ME erzeugt Antwort M4 = RSA-Verschlüsselung (RPSK-Pub, PS-Berechtigung installiert | RAND2 | RAND3 | Berechtigung (X) | PAID_Auth_Key(x) | PAID_Auth_Key(Null) | „Intel-CLS-Berechtigung” | SafeIDSign (RAND2 | RAND3)) M4 wird von PS verwendet, um ausstehende Rechnung bei der Erzeugung von M3 zu schließen PAID_Auth_Key(null) ist ein Behälter von gleicher Größe wie PAID_Auth_Key(x) vom Wert „0×0”. Er wird platziert, um sicherzustellen, dass M4-Implementierungen sowohl für die Firmware als auch für den PS dem gleichen Codepfad für die M4-Erzeugung folgen. ME speichert RAND2 im sicheren Flash, für Fehlertoleranz-Anforderungen auf Anfrage regeneriert ME M4-Nachricht mit einer neuen Nonce für RAND3. Dies wird gemacht, um den Missbrauch der Privatsphäre des M4-Wertes zu verhindern. ME speichert Berechtigung X im sicheren Flash-Dateisystem. Diese Maßnahme als Upgrade-Operation Permit(x) = NewPermit und CurrentPermit = Null. Wenn ein Netzausfall oder irgendein anderer Fehler auftritt, kehrt das System zur Null-Berechtigungsgrundfunktionalität zurück. Es ist zu beachten, dass die Zahlungsbestätigung noch nicht ausgegeben ist, aber das Merkmal auch noch nicht verfügbar ist. Dies erfolgt in den folgenden Schritten. ME sendet M4 zum PS über EA/ES
    PS PS bestätigt Nachricht M4 von ME und PS erstellt Berechtigung-installiert-Antwortnachricht und sendet sie zur ME. Bezahlung geht durch, nachdem der Berechtigungs-Server M4 empfängt. PS verifiziert die SafeID-Signatur auf RAND2 | RAND3. PS generiert PAID von Daten (PAID_Auth_Key(x)) in M4 und prüft, ob er mit dem PAID in der Berechtigung übereinstimmt PS erzeugt Nachricht M5 = RSA-Zeichen (RPSK-Pub, PS-Berechtigung-installiert-Antwort | RAND3 | RAND4) PS zerstört RAND3
    0 ME ME validiert M5 und löscht RAND2. ME installiert Berechtigung X, was die Produktionsprüfberechtigung oder -versuchsberechtigung ersetzt und das Merkmal beim nächsten Systemneustart aktiviert. Hinweis: Bis M5 eingeht, ist das Merkmal nicht als bezahlt bestätigt. Deshalb wird ME auf M5 warten. Für die Fehlertoleranz-Operation sollte jede vorausgehende Konfiguration für die Herstellung, den Test oder das Upgrade bis zum Eintreffen von M5 beibehalten werden
  • Wie zuvor erörtert wird bei einigen Ausführungsformen ein SafeID-System von Schlüsseln implementiert, in dem jede ME einen eindeutigen privaten SafeID-Schlüssel hat, der in den Chipsatz als Sicherungen während eines Fertigungsverfahrens des Chipsatzes gebrannt wird. Die ME ermöglicht niemals irgendeinen externen Zugriff auf diesen Schlüssel. Der Gruppenteil des Schlüssels wird von einem Unternehmen wie beispielsweise dem Hersteller des Chipsatzes besessen und befindet sich in einem Berechtigungs-Server-System, das sich in einem Datenzentrum dieses Unternehmens befindet. Der SafeID-Schlüssel im Chipsatz wird verwendet, um eine Signatur zu erzeugen (beispielsweise auf einem Zeitstempel und einer Nonce), der vom Berechtigungs-Server unter Verwendung des Gruppenschlüssels verifiziert wird. Dies versichert dem Berechtigungs-Server, dass die Signatur von einer wahren und gültigen ME durchgeführt wurde.
  • Die Verwendung eines SafeID-Schlüsselsystems versichert dem Berechtigungs-Server, dass er mit einer wahren ME und nicht einem Darsteller einer ME spricht. Der Grund dafür ist, dass nur die ME Kenntnis vom privaten SafeID-Schlüssel hat, und die ME signiert beispielsweise einen Zeitstempelwert in der M1-Nachricht und signiert später (RAND21 RAND3) in M4. Wenn der PS die SafeID-Signatur bei M1 verifiziert, weiß er, dass er zu einer wahren ME spricht, es sei denn, dass die Nachricht in den letzten 48 Stunden abgespielt wurde. Wenn jedoch der PS M4 empfängt, bestätigt er auf der Grundlage der Prüfung der SafeID-Signatur bei (RAND21 RAND3), dass er zu einer wahren ME spricht.
  • Gemäß einiger Ausführungsformen ist ein Prozess für das Installieren einer Berechtigung auf einem Computer nachfolgend beschrieben. Der Fluss dieses Prozesses nimmt gemäß einiger Ausführungsformen eine vom Kunden initiierte Transaktion an (d. h. der Kunde wählt beispielsweise eine bestimmte Aktualisierung aus und zahlt dafür mit einer Kreditkarte) und die Berechtigung wird dann auf dem Computer dieses Kunden installiert. Eine vom Managementdienstanbieter (MSP) initiierte Transaktion ist auch gemäß einiger Ausführungsformen möglich, wobei eine Managementanwendung mit einer entsprechenden Konsolenanwendung kommuniziert, um den Berechtigungsinstallationsvorgang auf eine Weise direkt zu initiieren, die den Endbenutzer des Computers nicht einschließt.
    chritt Komponente Rollenbeschreibung
    Kunde Kunde doppelklickt auf EA und sucht nach verfügbaren Merkmalen, welche die Client-Plattform des Kunden unterstützt.
    Anmelde anwendung Die EA fragt die ME ab, um zu bestimmen, welche Merkmale mit einer weichen SKU ausgeführt sein können, und ob eine Berechtigung gegenwärtig installiert ist. Die Anmeldeanwendung präsentiert dem Kunden kohärente Optionen, um den Kunden davon abzuhalten, eine Berechtigung für ein Merkmal zu erwerben, das von der aktuellen Konfiguration nicht unterstützt wird.
    Kunde Kunde trifft Kaufentscheidung und kommuniziert seine Präferenzen an die EA. Die EA sendet finanzielle Informationen (Kreditkarte #, Rechnungsdaten usw.) zum ES (gehostet von ISV/MSP) zusammen mit dem Merkmal, das der Kunde kaufen möchte.
    Anmelde anwendung Der EA kommuniziert mit der ME, um eine Berechtigungserstellungsanfrage zu generieren und sendet diese Anfrage zusammen mit den finanziellen Informationen zum ES.
    Enrollment Server Der ES bestätigt Informationen und kann den Verkauf mit der Kreditkartengesellschaft vorautorisieren.
    Enrollment Server Der Enrollment Server sendet eine P.O. zur Back-End-Infrastruktur der Intel Berechtigungs-Server.
    Berechtigungs-Server Der Berechtigungs-Server autorisiert den auf ISV/MSP basierenden Einkauf, generiert, signiert und sendet die Berechtigung zum Enrollment Server zurück und fakturiert dann den ISV/MSP für die Berechtigung.
    Enrollment Server Der Enrollment Server sendet die Berechtigung zur Anmeldeanwendung und schließt anschließend die Fakturierung des Kunden für die Berechtigung ab.
    0 Anmelde anwendung Die Anmeldeanwendung installiert die Berechtigung auf dem Kundensystem durch Senden der Berechtigung zur ME.
    1 Managementengine Die ME validiert die Berechtigung und speichert sie in der ME-Region des Flashs. Beim nächsten Systemwiederanlauf aktiviert die ME die Merkmale von der Berechtigung.
  • Bei einigen Ausführungsformen bilden ein privater Teil eines Berechtigungssignierschlüsselpaares und ein öffentlicher Teil des Berechtigungssignierschlüsselpaares zusammen ein RSA-Schlüsselpaar. Der private Teil des Berechtigungssignierschlüsselpaares befindet sich im Berechtigungs-Server und der öffentliche Teil des Berechtigungssignierschlüsselpaares befindet sich im Chipsatz-ROM.
  • Bei einigen Ausführungsformen bilden ein Gruppenteil eines SafeID-Schlüssels und ein privater Teil des SafeID-Schlüssels zusammen ein Paar von ECC-basierten SafeID-Schlüsseln. Der Gruppenteil des SafeID-Schlüssels befindet sich im Berechtigungs-Server und der private Teil des SafeID-Schlüssels befindet sich in Chipsatz-Sicherungen. Bei einigen Ausführungsformen befindet sich ein Chipsatz-Sicherungsschlüssel auch in Chipsatz-Sicherungen
  • 8 veranschaulicht Schlüsselinfrastruktur 800 gemäß einiger Ausführungsformen. Wie veranschaulicht in 8 schließen die Schlüssel 802, die sich im Berechtigungs-Server befinden, einen privaten Teil des Berechtigungssignierschlüsselpaares und einen Gruppenteil des SafeID-Schlüssels ein, die Schlüssel 804, die sich in Chipsatz-Sicherungen befinden, schließen einen privaten Teil der SafeID-Schlüssel und einen Chipsatz-Sicherungsschlüssel ein, und die Schlüssel 806, die sich im Chipsatz-ROM befinden, schließen einen öffentlichen Teil des Berechtigungssignierschlüsselpaares ein.
  • Bei einigen Ausführungsformen ist ein Firmware-Signierschlüssel (FWSK) ein 2048-Bit-RSA-Schlüsselpaar (beispielsweise ein asymmetrisches Schlüsselpaar einschließlich FWSK-privat und FWSK-public). Der FWSK wird verwendet, um ein oder mehrere Firmware-(FW)-Module zu signieren. Der ROM validiert die Signatur, um die Integrität des FW-Moduls sicherzustellen, d. h. dass es für die korrekte Herstellerfirma kam und dass es nicht modifiziert wurde. Der FWSK-priv-Schlüssel wird in einem Schlüsseltresor innerhalb von Codesignierungs-Systemeinrichtungen (wie beispielsweise der Herstellerfirma) gespeichert. Der FWSK-pub-Schlüssel befindet sich im maskierten ROM der ME. Der FWSK-pub-Schlüssel wird verwendet, um die Signatur von ankommender Firmware vor der Installation und Ausführung zu verifizieren.
  • Bei einigen Ausführungsformen ist ein Wurzel-Berechtigungssignierschlüssel (RPSK) ein 2048-Bit-RSA-Schlüsselpaar, das verwendet wird, um Berechtigungen zu signieren (beispielsweise ein asymmetrisches Schlüsselpaar einschließlich RPSK-privat und RPSK-public). Der RPSK-priv-Schlüssel wird in einem Schlüsseltresor innerhalb von Berechtigungssignierungseinrichtungen eines Unternehmens (beispielsweise einer Herstellerfirma) gespeichert. Der RPSK-pub-Schüssel ist als Teil der ME-Firmware lokalisiert (und signiert von FWSK-priv). RPSK-Pub wird verwendet, um die Signatur der ankommenden Berechtigungen zu verifizieren, die durch RPSK-priv signiert sind.
  • Bei einigen Ausführungsformen ist ein Chipsatz-Sicherungsschlüssel (CFK) ein zufälliger symmetrischer Pro-Einheit-Schlüssel (beispielsweise von 128 Bit). Der CFK ist als Teil des Fertigungsverfahrens in Sicherungen „gebrannt”. Der CFK wird als der Wurzelschlüssel für die ME verwendet, um andere symmetrische Schlüssel während der Laufzeit zu generieren (einschließlich eines Chipsatz-Speicherschlüssels oder CSK). Bei einigen Ausführungsformen ist ein Chipsatz-Speicherschlüssel (CSK) ein zufälliger symmetrischer Schlüssel (beispielsweise von 128 Bit). Der CSK wird in der ME unter Verwendung des CFK generiert. Der CSK wird verwendet, um im Flash-Speicher zu speichernde Daten zu verschlüsseln.
  • 9 veranschaulicht ein Fluss-Protokoll 900 gemäß einiger Ausführungsformen. Der Fluss 900 von 9 schließt eine ME 902, eine EA 904 und einen PS 906 ein. In Fluss 900 erzeugt die ME 902 M1, um eine RSA-Verschlüsselung einzuschließen (beispielsweise RPSK-pub, aktuelle Zeit, ein SafeID-Zeichen, das anzeigt „Ich bin eine ME”, eine aktuelle Zeit usw.). Die EA erstellt dann eine Authentifizierungsnachricht und sendet sie als M2 zum PS 906. Der PS 906 verifiziert die SafeID-Signatur und prüft einen Zeitwert, um zu sehen, ob er sich innerhalb einer bestimmten Zeittoleranzgrenze befindet (beispielsweise innerhalb von 48 Stunden). Der PS 906 erzeugt M3, der RAND1 und RAND2 einschließt, und sendet sie zur ME 902 (beispielsweise über die EA 904). Die ME 902 erzeugt eine Antwort M4, um SafeID-Zeichen, RAND2 und RAND3 einzuschließen und sendet sie zum PS 906 (beispielsweise über die EA 904 und/oder ein ES). Der PS 906 verifiziert dann die SafeID-Signatur, um definitiv nachzuweisen, dass die andere Seite eine ME 902 und kein Betrüger ist. Der PS sendet eine Nachricht M5 zur ME 902 und die ME 902 validiert dann M5, bevor sie die Berechtigung installiert, ersetzt eine Produktions-Prüfberechtigung oder -Versuchsberechtigung und/oder aktiviert das nächste Merkmal beim nächsten Systemneustart.
  • Bei einigen Ausführungsformen wird das Aktualisieren und/oder Rekonfigurieren der Hardware (SKU) über einen Remote-Protokoll-Mechanismus zugelassen. Bei einigen Ausführungsformen wird die Implementierung in einem ICH (I/O-Controller-Hub), einem MCH (Memory-Controller-Hub), einem GMCH (Grafik- und Memory-Controller-Hub), einem PCH (Plattform-Controller-Hub) und/oder einem anderen Chipsatz- oder Hardwaregerät durchgeführt. Bei einigen Ausführungsformen kann Hardware entfernt und sicher aktualisiert werden, während der Datenschutz für den Benutzer beibehalten und sichergestellt wird.
  • Bei einigen Ausführungsformen ist ein integrierter Controller mit einem Netzwerkprotokoll und eingebetteten kryptografischen Funktionen kombiniert, um die Entwicklung eines robusten Protokolls zu ermöglichen und bandextern vom Kunden-OS zu kommunizieren und um eine sichere, private und zuverlässige Art und Weise bereitzustellen, Informationen auszutauschen. Bei einigen Ausführungsformen werden Informationen außerhalb des Bereichs von System-OS und Malware-Angriffen ausgetauscht. Bei einigen Ausführungsformen stellt ein CLS (Capability Licensing Service) Information dazu bereit, wie man Hardware ermöglicht, einen Konfigurationszustand zu ändern.
  • Bei einigen Ausführungsformen kann die Hardwarekonfiguration eines Computers geändert werden. Bei einigen Ausführungsformen kann die Hardwarekonfiguration eines Computers unter Verwendung eines Aufhebungssteuerungsmechanismus beim Booten/Initialisieren geändert werden. Bei einigen Ausführungsformen wird ein softwarebasierter Upgrademechanismus verwendet, um die Hardware selbst ohne irgendeine Notwendigkeit, den Computer zu öffnen oder Hardware zu ersetzen, zu aktualisieren. Bei einigen Ausführungsformen wird dies mit einem eingebetteten Mikrokontroller, Firmware und Hardware implementiert, um ein softwarebasiertes Hardware-Upgrade zu ermöglichen.
  • 10 veranschaulicht ein System 1000 gemäß einiger Ausführungsformen. Bei einigen Ausführungsformen schließt System 1000 einen Memory-Controller-Hub (MCH) 1002 und einen Ein-/Ausgabe-(I/O)-Controller-Hub (ICH) 1004 ein. Bei einigen Ausführungsformen umfasst MCH 1002 ein oder mehrere Hardware-Sicherungsaufhebungsregister 1012, eine Managementengine (und/oder Handhabbarkeitsengine und/oder ME) 1014, ein oder mehrere flexible SKU-(Flex-SKU)-Deaktivierungs-Sicherungen 1016, eine oder mehrere schreibgeschützte Hardware-Sicherungsregister 1018 und/oder Firmware-Authentifizierungsmodul 1020. Bei einigen Ausführungsformen umfasst ICH 1004 ein oder mehrere Hardware-Sicherungs-Register 1022, ein oder mehrere flexible SKU-(Flex-SKU)-Deaktivierungs-Sicherungen 1026, ein oder mehrere schreibgeschützte Hardware-Sicherungsregister 1028.
  • Bei einigen Ausführungsformen ermöglichen die Hardware-Sicherungsaufhebungsregister 1012 und/oder 1022, dass die ME-Firmware die Einstellung der Hardware-Merkmalsicherungen jeder Komponente überschreiben kann, die an der flexiblen SKU-Lösung teilhaben (beispielsweise der MCH 1002 und/oder der ICH 1004). Diese Register sind durch den Host nicht beschreibbar. Dies stellt sicher, dass Host-Software sie nicht programmieren kann, sobald sie von der ME-Firmware konfiguriert sind und/oder, dass andere Firmware-Laufzeitfehler nicht in den Registern resultieren, die neu programmiert werden. Die ME-Firmware programmiert und sperrt diese Register sehr früh im Boot-/Initialisierungszyklus der Plattform.
  • Bei einigen Ausführungsformen ist die ME 1014 eine Hardwareverarbeitungsengine, die das Programmieren der Sicherungsaufhebungskonfiguration ausführt, die in 10 veranschaulicht ist. Die ME 1014 führt signierten/authentifizierten und verifizierten Firmware-Code aus. Diese ME-Firmware interagiert mit Benutzer-Code, der im Betriebssystem (OS) ausführt. Der Benutzer-Code kann mit dem ME-Firmware-Code interagieren, um die Hardware-Sicherungsaufhebungsregister 1012 und/oder 1022 zu programmieren. Die ME-Firmware stellt sicher, dass alle Bedingungen erfüllt sind, bevor sie die Werte in den Hardware-Sicherungsaufhebungsregistern ändert. Auf diese Weise kann nur die Firmware, die auf der ME 1014 läuft, die Hardware-Sicherungsaufhebungsregister 1012 und 1022 programmieren.
  • Die Flex-SKU-Deaktivierungssicherung 1016 und/oder Flex-SKU-Deaktivierungssicherung 1026 sind Hardware-Sicherungen, die verwendet werden, um die Hardware-Sicherungsaufhebungskonfiguration von System 1000 der 10 zu deaktivieren. Die Sicherungen 1016 und 1026 sind von der Firmware lesbar und die flexible SKU-Firmware arbeitet nur, wenn die Sicherungen 1016 und/oder 1026 auf einen aktivierten Zustand eingestellt sind (d. h. eingestellt sind, um beispielsweise flexible SKU zu aktivieren). Die Sicherungen 1016 und/oder 1026 sind für den anfänglichen Aufhebungsmechanismus sehr wichtig, sodass das Aufhebungsmerkmal im Falle eines schwerwiegenden Fehlers deaktiviert werden kann. Diese Hardwaredeaktivierung kann auch bei einigen Ausführungsformen verwendet werden, um SKUs des Chipsatzes mit dem Aufhebungsmechanismus oder denjenigen zu definieren, die ohne den Mechanismus ausgeliefert werden.
  • Bei einigen Ausführungsformen ermöglichen die schreibgeschützten Hardwaresicherungsregister 1018 und/oder 1028 der Hardware, Firmware-Lesezugriff auf die Hardware-Merkmalsicherungen jeder Komponente zu unterstützen, die an der Aufhebungslösung teilhaben.
  • Bei einigen Ausführungsformen stellt die Firmware-Authentifizierung 1020 eine Art und Weise bereit, zu authentisieren, dass das ME-Firmware-Modul, das Hardware-Aufhebungsregister modifizieren kann, nur Firmware sein darf, die von einem bestimmten Unternehmen geschrieben ist (beispielsweise dem Unternehmen, das die Hardware herstellte). Dies stellt sicher, dass ein Angreifer nicht seine eigene Firmware schreiben und verwenden kann, um Merkmale auf der Hardware zu aktivieren.
  • Bei einigen Ausführungsformen schließt der MCH 1002 veranschaulicht in 10 Zusatzeinrichtungen ein, die nicht in 10 veranschaulicht sind. Beispielsweise umfasst bei einigen Ausführungsformen MCH 1002 einen Chipsatz-Identifikator (Chipsatz-ID), einen ME-Fehlersuchprogramm-Deaktivierungsmechanismus, einen Chipsatz-Sicherungsschlüssel, einen Zufallsgenerator (RNG), einen monotonen Zähler und/oder zusätzliche Einrichtungen.
  • Bei einigen Ausführungsformen ist eine Chipsatz-ID in MCH 1002 eingeschlossen, um einen Mechanismus bereitzustellen, um Firmware zu ermöglichen, zu erkennen, dass sie auf einer gegebenen Hardware-Familie läuft. Bei einigen Ausführungsformen schließt MCH 1002 ein ME-Fehlersuchprogramm-Deaktivierungsmechanismus ein, der unterstützt wird, um zu verhindern, dass Systemfehlersuchprogramm-Fähigkeiten in Produktions-Hardware als eine Methode verwendet wird, um ein CLS-System anzugreifen. Bei einigen Ausführungsformen schließt MCH 1002 einen Chipsatz-Sicherungsschlüssel ein, der Firmware-Lesezugriff von einer Reihe von Sicherungen bereitstellt, die CLS-Hardware eindeutig identifizieren. Der Chipsatz-Sicherungsschlüssel wird von Firmware verwendet, um ein Signal zu generieren, das verwendet wird, um Plattform-Hardware mit Berechtigungen übereinzustimmen. Bei einigen Ausführungsformen umfasst MCH 1002 einen Zufallsgenerator (RNG) (beispielsweise einen echten RNG), um einen sicheren CLS und ein flexibles SKU-System bereitzustellen. Bei einigen Ausführungsformen, wo Hardware-RNG nicht möglich ist, wird eine Firmware-Implementierung eines Pseudozufallszahl-Generators verwendet, um Sicherheits- und Datenschutzangelegenheiten zu entsprechen. Bei einigen Ausführungsformen schließt MCH 1002 einen monotonen Zähler ein, um Berechtigungsaufhebung und Upgrade-Flüsse zu unterstützen.
  • Gemäß einiger Ausführungsformen erfolgt ein Kontrollfluss, um Hardware-Aufhebungsregister während einer Systeminitialisierung/einem Booten zu programmieren in der folgenden Weise. Zuerst startet der Benutzer das System, und die ME 1014 initialisiert dann. Dann liest die ME 1014 die Hardware-Sicherungsmatrix und schreibt sie in das schreibgeschützte Hardwaresicherungsregister 1018 und/oder 1028. Die ME 1014 setzt in einem internen Register ein Bit, um den Aufhebungsmechanismus wissen zu lassen, dass er ausführen kann. Dann prüft die Aufhebungsfirmware, um zu bestimmen, ob der Mechanismus ein- oder ausgeschaltet ist, indem sie die Flex-SKU-Deaktivierungssicherung 1016 und/oder 1026 liest. Wenn sie nicht aktiviert ist, ermöglicht die Aufhebungsfirmware dem Plattform-Boot-Prozess fortzufahren, ohne weitere Firmware-Aufhebungsschritte auszuführen. Wenn sie aktiviert ist, dann fährt die Aufhebungsfirmware in der ME fort, in welchem Fall sie die neue Sicherungsaufhebungskarte von einem sicheren/vertrauenswürdigen Ort liest. Die ME-Aufhebungsfirmware schreibt dann die neue Sicherungsaufhebungskarte in das Hardware-Sicherungs-Aufhebungsregister 1012 und/oder 1022.
  • Gemäß einiger Ausführungsformen ist ein Hardware-Upgrade-Service implementiert in dem Endbenutzer Hardwarekonfigurationen ändern können (beispielsweise von ihren Chipsätzen), um neue Merkmale als Gegenleistung für eine Geldzahlung zu aktivieren. Eine sichere Transaktion wird zwischen dem Endbenutzer und einem Unternehmen durchgeführt, wie beispielsweise dem Unternehmen, das die Hardware herstellte. Nach Erhalt der Bezahlung gibt das Unternehmen eine sichere und signierte Berechtigung an den Computer des Benutzers heraus (beispielsweise an den Chipsatz des Computers des Benutzers). Der Computer des Benutzers (und/oder Chipsatz) verifiziert die Berechtigung und verwendet die Informationen in der Berechtigung, um das Sicherungsaufhebungsregister beim Booten zu programmieren, um die neue Konfiguration zu aktivieren.
  • Gemäß einiger Ausführungsformen werden Hardwarekonfigurationen unter Verwendung von Softwareprogrammierung ohne irgendwelche physischen Änderungen der Hardware geändert.
  • 11 veranschaulicht einen Protokoll-Fluss 1100 gemäß einiger Ausführungsformen. Bei einigen Ausführungsformen umfasst 11 eine ME 1102 (beispielsweise ist bei einigen Ausführungsformen ME 1102 ähnlich oder gleich wie alle oder einige der hier beschriebenen MEs, wie beispielsweise ME 112, ME 212, ME 300, ME 402 usw.) und einen Berechtigungs-Server (PS) 1104 (beispielsweise ist bei einigen Ausführungsformen PS 1104 ähnlich oder gleich wie alle oder einige der anderen hier beschriebenen Berechtigungs-Server wie beispielsweise PS 404, 504 usw.).
  • Bei einigen Ausführungsformen ist ein Berechtigungssignierschlüsselpaar ein asymmetrisches (RSA) Schlüsselpaar, das für die Berechtigungssignierung und Überprüfung verwendet wird. Der private Schlüssel des Paares befindet sich in einem Berechtigungs-Server wie beispielsweise PS 1104, der sich in einer sicheren Datenzentrumeinrichtung (wie beispielsweise mit HSM) befindet. Der öffentliche Teil dieses Schlüsselpaares befindet sich beispielsweise in einem Chipsatz-ROM und/oder einem signierten ME-Firmware-Image und kann von niemandem geändert werden. Berechtigungen werden durch den privaten Teil dieses Schlüsselpaares signiert, und der öffentliche Teil wird von einer ME (beispielsweise ME 1102) verwendet, um die Signatur zu verifizieren.
  • Bei einigen Ausführungsformen befindet sich ein Chipsatz-Sicherungsschlüssel in Chipsatz-Sicherungen. Bei einigen Ausführungsformen ist der Chipsatz-Sicherungsschlüssel für jeden Chipsatz-Teil eindeutig. Der Chipsatz-Sicherungsschlüssel wird einzigartig in jeden Chipsatz während eines Fertigungsverfahrens programmiert, indem zufällig Sicherungen in einer Programmieren-und-Vergessen-Weise durchgebrannt werden. Niemand (einschließlich des Herstellers) hat Kenntnis dieses Schlüssels, und die ME (beispielsweise ME 1102) lässt nie zu, dass auf diesen Schlüssel von außen zugegriffen wird.
  • Bei einigen Ausführungsformen generiert der Chipsatz eines Computers wie veranschaulicht in 11 einen eindeutigen Identifikator wie beispielsweise einen Berechtigungsauthentifizierungsidentifikator (oder PAID) auf solche Weise, dass der Identifikator an einen bestimmten Chipsatz oder Chipsatz-Teil gebunden ist. Gemäß einiger Ausführungsformen wird das auf eine Art und Weise gemacht, sodass es nicht möglich ist, den PAID mit dem bestimmten Chipsatz-Fall zu verknüpfen. Durch Schauen auf den Identifikator kann der Chipsatz bestimmen, ob der Identifikator an diesen bestimmten Chipsatz-Fall gebunden ist. Jedoch ist es durch Schauen auf den Identifikator nicht möglich, ihn zurück zu dem bestimmten Chipsatz-Fall zu verknüpfen, an den der Identifikator gebunden ist. Solch ein Berechtigungsauthentifizierungsidentifikator (PAID) ist in 11 als PAID 1112 veranschaulicht.
  • Bei einigen Ausführungsformen generiert ME 1102 einen neuen PAID 1112, der an den bestimmten Chipsatz, Chipsatz-Fall und/oder Computer gebunden ist, in der sich ME 1102 befindet. Berechtigungs-Server (PS) 1104 hat PAID 1112 von ME 1102 empfangen und generiert dann eine Berechtigung 1122 und bettet PAID 1112 innerhalb der Berechtigung 112 als PAID 1124 ein. Berechtigung 1122 schließt PAID 1124 und andere Berechtigungsdaten 1126 ein. Berechtigung 1122 enthält auch Signatur 1128 und/oder ist an diese angehängt.
  • ME 1102 empfangt die Signatur 1128 und verifiziert sie mit einem öffentlichen Berechtigungssignierungsschlüssel (d. h. beispielsweise ein öffentlicher Teil eines Berechtigungssignierschlüsselpaares). Dann verifiziert die ME 1102 PAID 1124. Wenn die PAID-Überprüfung erfolgreich ist, bestimmt die ME 1102, dass die Berechtigung 1122 als Reaktion auf PAID 1112 erfolgt, der nur von der ME 1102 gesendet wurde (und/oder dem Computer, in dem die ME 1102 sich befindet) und von keiner anderen ME (und/oder anderem Computer) gesendet wurde.
  • Bei einigen Ausführungsformen ist PS 1104 ein vertrauenswürdiger Provisioning Server, der authentifizierte Berechtigungen erzeugt, die von der ME 1102 zu verwenden sind. PS 1104 hat sicheren Zugriff (beispielsweise über HSM) auf einen kryptografischen RSA-Schlüssel, dessen öffentliche Komponente in der signierten ME-Firmware eingebettet ist. Deshalb kann PS 1104 Berechtigungen, wie beispielsweise Berechtigung 1122, erzeugen, die eine ME, wie beispielsweise ME 1102, als in einer vertrauenswürdigen Entität entstanden authentisieren kann. Bei einigen Ausführungsformen bettet der Berechtigungs-Server 1104 Hardware-Sicherungsaufhebungsinformationen in der signierten Berechtigung ein, die die ME 1102 dann verwendet (beispielsweise für die weiche SKU und/oder die Aufrüstung der Hardware innerhalb des Computers, in der sich ME 1102 befindet). Bei einigen Ausführungsformen umfasst PS 1104 einen oder mehrere Server, die diese Operationen (beispielsweise abhängig von Infrastruktur-Implementierung, Übertragungskapazitätsanforderungen usw.) durchführen.
  • Bei einigen Ausführungsformen ist Berechtigung 1122 eine signierte Datenstruktur, die gleich und/oder ähnlich anderen hier beschriebenen Berechtigungen ist (wie beispielsweise bei einigen Ausführungsformen Berechtigung 412, Berechtigung 602 usw.). Berechtigung 1122 ist eine signierte Datenstruktur, die die Hardware-Sicherungsaufhebungsinformationen enthält (beispielsweise in einem ,Merkmal-ID'-Feld). Niemand außer einem bestimmten Unternehmen kann eine Berechtigung 1122 in einer Art und Weise erzeugen, die erfolgreich von der ME 1102 validiert werden kann. Bei einigen Ausführungsformen ist dieses Unternehmen beispielsweise der Eigentümer des Berechtigungs-Servers 1104 und/oder der Hersteller der ME 1102, vom Chipsatz, der ME 1102 einschließt, usw. Bei einigen Ausführungsformen schließt die Berechtigung 1122 weiter einen Klassen- und Teilklassen-Identifikator ein, der eine Interpretation des Restes der Datenstruktur anzeigt. Bei einigen Ausführungsformen enthält Berechtigung 1122 einen Zeitstempel, der anzeigt, wann er erzeugte (beispielsweise in einem ,Zeitstempel'-Feld). Berechtigung 1122 schließt auch bei einigen Ausführungsformen Attribute ein (beispielsweise in einem ,Flag'-Feld) die einige Berechtigungseigenschaften, wie beispielsweise ob das System unmittelbar nach der Berechtigungsinstallation neu booten wird oder nicht, anzeigen.
  • Bei einigen Ausführungsformen ist ME 1102 eine Hardwareverarbeitungsengine, die das Programmieren des Sicherungsaufhebungsmechanismus ausführt. ME 1102 führt signierten/authentifizierten und verifizierten Firmware-Code aus. Diese ME-Firmware kann mit Benutzer-Code interagieren, der im Betriebssystem (OS) ausführt. Der Benutzer-Code kann mit dem ME-Firmware-Code interagieren, um die Hardware-Aufhebungsregister zu programmieren. Die ME-Firmware stellt sicher, dass alle Bedingungen erfüllt sind (einschließlich der Berechtigungsvalidierung), bevor es die Werte in den Hardware-Sicherungsaufhebungsregistern ändert. Die ME 1102 führt auch ihr Ende des Berechtigungs-Installationsprotokolls aus.
  • Bei einigen Ausführungsformen (beispielsweise bei einigen Ausführungsformen von 11) wird die PAID-Regeneration gemäß den folgenden Schritten durchgeführt:
    • – einen Zufallswert ,R' generieren
    • – R in einem sicheren Flash speichern
    • – PAID generieren = H (X 1 Y 1 Z), wobei X Y und Z nachfolgend definiert sind, und H ist eine sichere Hash-Funktion, wie nachfolgend beschrieben. X = Berechtigungsautorisierungsschlüssel = H (R, CFK) Y = Berechtigungsnachricht = ein weithin bekannter String – „Berechtigungsauthorisierungs-Nachricht” Z = Merkmal-ID angefordert vom Kunden, für den die Aktualisierung erforderlich ist
  • Bei einigen Ausführungsformen ist der sichere Flash eine Komponente auf dem Motherboard des Computers, die ständig Daten in nicht flüchtigen Flash-Medien speichern kann. Bei einigen Ausführungsformen werden die auf diesen Flash-Medien gespeicherten Daten vertraulich geschützt, integritätsgeschützt, und/oder wiedergabegeschützt.
  • Bei einigen Ausführungsformen ist die sichere Hash-Funktion (H) eine kryptografisch sichere Einweg-Hash-Funktion. Bei einigen Ausführungsformen ist die Hash-Funktion (H) ein oder mehr aus SHA1, SHA-256, MDS usw.
  • Bei einigen Ausführungsformen wird ein PAID-Wert in einem CLS-Berechtigungsinstallationsprotokoll verwendet, um die Berechtigungsanfrage und die Berechtigung an eine spezifische Rechenmaschine, ein Hardwaregerät, Hardware-Teil, Chipsatz, Chipsatz-Teil usw. zu binden. Der PAID wird in der anfänglichen Nachricht eingeschlossen, die zum PS (beispielsweise PS 1104) von der ME (beispielsweise ME 1102) gesendet wird. Der PS bettet den PAID-Wert in der signierten Berechtigung ein, die vom PS an die ME in der Antwortnachricht zurückgesendet wird. Die ME verifiziert zuerst die Signatur bei der Berechtigung. Wenn erfolgreich, verifiziert die ME dann den PAID-Wert innerhalb der Berechtigung. Um den PAID zu verifizieren, stellt die ME den PAID (beispielsweise unter Verwendung der oben beschriebenen Schritte) wieder her und vergleicht sie mit dem PAID in der Berechtigung (beispielsweise PAID 1124 in der Berechtigung 1122). Wenn die Überprüfung erfolgreich ist, dann ist die ME sicher, dass diese Berechtigung vom PS als Reaktion auf die Anfrage gesendet und nur von dieser ME und von keiner anderen Entität gesendet wurde. Die ME akzeptiert dann die Berechtigung.
  • Bei einigen Ausführungsformen generiert die ME (beispielsweise ME 1102) jedes Mal einen neuen PAID, wenn sie eine Berechtigungsanfrage erstellt, um zum PS zu senden. Da einer der Bestandteile des PAID eine Zufallszahl ist (beispielsweise ,R'), werden keine zwei PAIDs gleich aussehen, solange die Zufallszahl unterschiedlich ist. Dies stellt sicher, dass irgendwelche zwei von der gleichen ME generierten PAID-Werte vollständig unterschiedlich zueinander aussehen. Niemand kann zwischen zwei PAID-Werten unterscheiden, die von der gleichen ME oder von separaten MEs kommen. Dies stellt den Datenschutz für den Benutzer beim Kaufen und/oder Erhalten von Berechtigungen vom PS sicher. Der PS kann zwei PAID-Werte auf seiner Seite nicht miteinander korrelieren und sie verwenden, um die zwei PAID-Werte mit dem gleichen Benutzer zu verknüpfen.
  • Bei einigen Ausführungsformen schützen Einkäufe unter Netzwerkverkehr den Datenschutz an den Enden der Transaktion. Gemäß einiger Ausführungsformen ist die Transaktion für den Verkäufer der Dienste anonym. Bei einigen Ausführungsformen ist eine Transaktion (beispielsweise für einen Interneteinkauf) ohne die Notwendigkeit von eindeutigen Identifikatoren gesichert. Die eindeutige ID wird als ein Erfordernis für eine Netzwerk-Kauftransaktion entfernt.
  • Bei einigen Ausführungsformen ist ein Hardware-Upgrade-Dienst implementiert, bei dem die Transaktion für den Verkäufer anonym ist. Endbenutzer können eine Hardwarekonfiguration ändern (beispielsweise eines Chipsatzes), um neue Merkmale als Gegenleistung für eine Bezahlung zu aktivieren. Eine sichere Transaktion wird zwischen dem Endbenutzer und dem Provider des Hardware-Upgrades ermöglicht, wobei der Provider des Hardware-Upgrades nach dem Empfang der Bezahlung eine sichere und signierte Berechtigung an den Computer des Benutzers herausgibt (beispielsweise an den Chipsatz). Der Computer des Benutzers (und/oder der Chipsatz dieses Computers) kann sicherstellen, dass PAIDs, die in unterschiedlichen Berechtigungen für den gleichen Computer eingebettet sind, nicht gleich aussehen. Dies schützt die Privatsphäre des Endbenutzers, da keine Entität (einschließlich des PS) die Berechtigung (oder den PAID) mit der gleichen Hardware-Instanz verknüpfen kann (beispielsweise Chipsatz-Instanz), die den PAID erzeugte.
  • Obwohl einige Ausführungsformen hier als in einem Chipsatz, einem MCH, einem GMCH, einem ICH, einem PCH usw. implementiert beschrieben wurden, können gemäß einiger Ausführungsformen diese bestimmten Implementierungen nicht erforderlich sein. Bei einigen Ausführungsformen können beispielsweise Implementierungen in anderen Einheiten auftreten (beispielsweise können einige Ausführungsformen, die hier als im MCH oder GMCH erfolgend beschrieben sind, auch gemäß einiger Ausführungsformen im PCH oder bei einigen Ausführungsformen in irgendeiner anderen hier nicht beschriebenen Einheit auftreten).
  • Obwohl einige Ausführungsformen in Bezugnahme auf bestimmte Implementierungen beschrieben wurden, sind andere Implementierungen gemäß einiger Ausführungsformen möglich. Zusätzlich brauchen die Anordnung und/oder Reihenfolge von Schaltelementen oder anderen Eigenschaften, die in den Zeichnungen gezeigt und/oder hiernach beschrieben sind, nicht auf die bestimmte gezeigte und beschriebene Weise angeordnet sein. Viele andere Anordnungen sind gemäß einiger Ausführungsformen möglich.
  • Bei jedem in einer Figur gezeigten System können die Elemente in einigen Fällen jeweils dieselbe Referenznummer oder eine unterschiedliche Referenznummer haben, um zu empfehlen, dass die repräsentierten Elemente unterschiedlich und/oder ähnlich sein könnten. Ein Element kann jedoch flexibel genug sein, um unterschiedliche Implementierungen zu haben und es kann mit einigen oder allen hier dargestellten oder beschriebenen Systemen arbeiten. Die verschiedenen in den Figuren dargestellten Elemente können dieselben Elemente oder unterschiedlich sein. Welches ein erstes Element genannt wird und welches ein zweites Element, ist willkürlich.
  • In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt” und „verbunden” gemeinsam mit ihren Ableitungen verwendet werden. Es sollte selbstverständlich sein, dass diese Begriffe nicht als Synonyme für einander zu verstehen sind. Vielmehr kann bei bestimmten Ausführungsformen „verbunden” verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt miteinander stehen. „Gekoppelt” kann bedeuten, dass sich zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt befinden. Jedoch kann „gekoppelt” auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander sind, trotzdem aber miteinander arbeiten oder interagieren.
  • Ein Algorithmus ist hier und wird generell als eine selbstkonsistente Sequenz von Vorgängen oder Operationen betrachtet, die zu einem gewünschten Resultat führen. Diese enthalten physische Bearbeitungen von physischen Mengen. Gewöhnlich, obwohl nicht notwendigerweise, nehmen diese Mengen die Form von elektrischen oder magnetischen Signalen an, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Es hat sich grundsätzlich aus Gründen des allgemeinen Sprachgebrauchs als geeignet erwiesen, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder Ähnliches zu bezeichnen. Alle diese und ähnlichen Begriffe sind jedoch mit den passenden physischen Mengen zu verbinden und stellen lediglich geeignete Bezeichnungen dar, die auf diese Mengen angewendet werden.
  • Einige Ausführungsformen können in einer Hardware, Firmware und Software oder einer Kombination davon implementiert werden. Einige Ausführungsformen können auch als auf einem maschinenlesbaren Medium gespeicherte Anweisungen implementiert werden, die von einer Computerplattform gelesen und ausgeführt werden können, um die hier beschriebenen Operationen auszuführen. Ein maschinenlesbares Medium kann jeden Mechanismus für das Speichern oder Senden von Information in von einer Maschine (z. B. einem Computer) lesbaren Form enthalten. Zum Beispiel kann ein maschinenlesbares Medium Read Only Memory (ROM); Random Access Memory (RAM); Magnetplattenspeichermedien; optische Speichermedien; Flash-Speicher-Geräte; elektrische, optische, akustische oder andere Formen von propagierten Signalen (z. B. Trägerwellen, Infrarotsignale, Digitalsignale, die Schnittstellen, die Signale senden und/oder empfangen usw.) und andere enthalten.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Die Bezugnahme auf „eine Ausführungsform”, „einige Ausführungsformen” oder „andere Ausführungsformen” bedeutet, dass eine bestimmte Funktion, Struktur oder ein bestimmtes Merkmal, die/das im Zusammenhang mit den Ausführungsformen beschrieben wird, in mindestens einigen Ausführungsformen, aber nicht notwendigerweise allen Ausführungsformen der Erfindungen eingeschlossen ist. Das verschiedenartige Auftreten von „eine Ausführungsform” oder „einige Ausführungsformen” bezieht sich nicht notwendigerweise auf die gleichen Ausführungsformen.
  • Nicht alle Komponenten, Funktionen, Strukturen, Merkmale usw., die hier beschrieben und gezeigt sind, müssen in einer bestimmten Ausführungsform oder Ausführungsformen enthalten sein. Wenn die Beschreibung einer Komponente, Funktion, Struktur oder eines Merkmals aussagt, dass sie enthalten sein „kann” oder „könnte”, dann ist es zum Beispiel für diese bestimmte Komponente, Funktion, Struktur oder dieses bestimmte Merkmal nicht erforderlich, enthalten zu sein. Wenn die Beschreibung oder der Anspruch Bezug nimmt auf „ein” Element, bedeutet das nicht, dass es nur eines von diesem Element gibt. Wenn die Beschreibung oder die Ansprüche Bezug nehmen auf „ein zusätzliches” Element, schließt das nicht aus, dass es dort mehr als ein zusätzliches Element gibt.
  • Obwohl Flussdiagramme und/oder Zustandsdiagramme in dieser Schrift verwendet worden sein können, um Ausführungsformen zu beschreiben, sind die Erfindungen nicht auf diese Diagramme oder auf entsprechende Beschreibungen begrenzt. Zum Beispiel braucht der Fluss sich nicht durch jeden gezeigten Kasten oder Zustand oder in genau derselben Reihenfolge wie hier veranschaulicht und beschrieben zu bewegen.
  • Die Erfindungen sind nicht auf die bestimmten in dieser Schrift aufgelisteten Einzelheiten beschränkt. Für fachkundige Personen, die diese Offenlegung lesen, ist es in der Tat offensichtlich, dass viele weitere Variationen der vorstehenden Beschreibung und Zeichnungen im Rahmen der vorliegenden Erfindungen möglich sind. Nur die nachfolgenden Ansprüche und alle Änderungen dazu stellen eine genaue Definition des Umfangs der Erfindungen dar.

Claims (68)

  1. Verfahren, umfassend: das Erzeugen einer sicheren Berechtigungsanfrage, um eine Hardwarekonfiguration zu ändern; das Senden der sicheren Berechtigungsanfrage zu einem entfernten Standort; das Empfangen einer Berechtigung, die vom entfernten Standort als Reaktion auf die Berechtigungsanfrage gesendet wird; und das Ändern der Hardwarekonfiguration als Reaktion auf die empfangene Berechtigung.
  2. Verfahren nach Anspruch 1, wobei die sichere Berechtigungsanfrage und die Berechtigung die Privatsphäre eines Benutzers der Hardware schützen.
  3. Verfahren nach Anspruch 1, wobei die sichere Berechtigungsanfrage und die Berechtigung die Privatsphäre der Hardware schützen.
  4. Verfahren nach Anspruch 1, wobei die Hardwarekonfiguration eine Hardwarekonfiguration eines Chipsatzes oder eines Chipsatz-Teils ist.
  5. Verfahren nach Anspruch 1, wobei ein oder mehrere kryptografische Schlüssel verwendet werden, um die sichere Kommunikation mit dem entfernten Standort sicherzustellen.
  6. Verfahren nach Anspruch 1, wobei ein eindeutiger Schlüssel während der Herstellung der Hardware dauerhaft in der Hardware eingeschlossen wurde und der eindeutige Schlüssel verwendet wird, um eine sichere Kommunikation und Berechtigungsauthentifizierung mit dem entfernten Standort sicherzustellen.
  7. Verfahren nach Anspruch 6, wobei der eindeutige Schlüssel in die Hardware während der Herstellung einzigartig programmiert wird, indem zufällig Sicherungen in der Hardware während der Herstellung durchgebrannt werden.
  8. Verfahren nach Anspruch 6, wobei der eindeutige Schlüssel nicht durch Software zugänglich ist, die außerhalb der Hardware abläuft.
  9. Verfahren nach Anspruch 1, wobei die Berechtigung eine eindeutige Signatur vom entfernten Standort einschließt.
  10. Verfahren nach Anspruch 1, weiter umfassend das Validieren der empfangenen Berechtigung vor dem Ändern der Hardwarekonfiguration.
  11. Verfahren nach Anspruch 1, weiter umfassend das Validieren der empfangenen Berechtigung mit einem öffentlichen Schlüssel, der einem privaten am entfernten Standort befindlichen Signierschlüssel entspricht.
  12. Verfahren nach Anspruch 1, wobei der entfernte Standort ein sicherer und vertrauenswürdiger Standort ist.
  13. Verfahren nach Anspruch 1, wobei das Ändern der Hardwarekonfiguration ohne jede physische Veränderung an der Hardware durchgeführt wird.
  14. Verfahren nach Anspruch 1, wobei die Berechtigung eine sichere Berechtigung und/oder eine signierte Berechtigung ist.
  15. Verfahren nach Anspruch 1, wobei Transaktionsinformationen innerhalb der Berechtigung gebunden sind, sodass zukünftige Rückläufer oder Umtausche aktiviert werden können.
  16. Verfahren nach Anspruch 1, wobei eine Berechtigung nicht bei einem anderen Hardware-Teil verwendet werden kann, sobald sie für einen bestimmten Hardware-Teil signiert ist.
  17. Verfahren nach Anspruch 1, wobei Software, die außerhalb der Hardware abläuft, die Funktionalität der Software nicht emulieren kann, die innerhalb der Hardware abläuft.
  18. Verfahren nach Anspruch 1, weiter umfassend eine Aufhebung während eines Boot- und/oder Initialisierungsprozesses durchzuführen und die Hardwarekonfiguration als Reaktion auf die Aufhebung zu ändern.
  19. Verfahren nach Anspruch 1, wobei die sichere Berechtigungsanfrage nicht eindeutig identifizierbar ist.
  20. Verfahren nach Anspruch 1, wobei die Identität der Hardware und/oder des Benutzers der Hardware von der sicheren Berechtigungsanfrage nicht feststellbar ist.
  21. Verfahren nach Anspruch 1, weiter umfassend einen Zufallswert zu generieren und die sichere Berechtigungsanfrage als Reaktion auf den Zufallswert zu generieren.
  22. Verfahren, umfassend: von einem entfernten Standort eine sichere Berechtigungsanfrage zu empfangen, um eine Hardwarekonfiguration am entfernten Standort zu ändern; das Senden einer sicheren Berechtigung zum entfernten Standort als Reaktion auf die Berechtigungsanfrage, wobei die Berechtigung ist, dem entfernten Standort zu ermöglichen, die Hardwarekonfiguration zu ändern.
  23. Verfahren nach Anspruch 22, wobei die sichere Berechtigungsanfrage und die Berechtigung die Privatsphäre eines Benutzers der Hardware schützen.
  24. Verfahren nach Anspruch 22, wobei die Hardwarekonfiguration eine Hardwarekonfiguration eines Chipsatzes oder eines Chipsatz-Teils ist.
  25. Verfahren nach Anspruch 22, wobei ein oder mehrere kryptografische Schlüssel verwendet werden, um die sichere Kommunikation und Berechtigungsauthentifizierung mit dem entfernten Standort sicherzustellen.
  26. Verfahren nach Anspruch 22, wobei die Berechtigung eine eindeutige Signatur einschließt.
  27. Verfahren nach Anspruch 22, wobei die Berechtigung ist, dem entfernten Standort die Veränderung der Hardwarekonfiguration ohne jede physische Veränderung der Hardware zu ermöglichen.
  28. Verfahren nach Anspruch 22, wobei die Berechtigung eine sichere Berechtigung und/oder eine signierte Berechtigung ist.
  29. Verfahren nach Anspruch 22, wobei die Berechtigung ist, dem entfernten Standort zu ermöglichen, die Hardwarekonfiguration als Reaktion auf eine Aufhebungsoperation zu ändern, die während eines Boot- und/oder Initialisierungsprozesses durchgeführt wird.
  30. Verfahren nach Anspruch 22, wobei die sichere Berechtigungsanfrage nicht eindeutig identifizierbar ist.
  31. Verfahren nach Anspruch 22, wobei die Identität der Hardware und/oder des Benutzers der Hardware von der sicheren Berechtigungsanfrage nicht feststellbar ist.
  32. Verfahren nach Anspruch 22, wobei die sichere Berechtigungsanfrage am entfernten Standort als Reaktion auf den Zufallswert erzeugt worden ist.
  33. Verfahren nach Anspruch 22, weiter umfassend das Verwenden eines privaten Signierschlüssels, der einem öffentlichen Schlüssel entspricht, welcher sich am entfernten Standort befindet, um bei der Validierung der Berechtigung am entfernten Standort zu unterstützen.
  34. Verfahren nach Anspruch 22, wobei Transaktionsinformationen innerhalb der Berechtigung gebunden sind, sodass zukünftige Rückläufer oder Umtausche aktiviert werden können.
  35. Verfahren nach Anspruch 22, wobei eine Berechtigung nicht bei einem anderen Hardware-Teil verwendet werden kann, sobald sie für einen bestimmten Hardware-Teil signiert ist.
  36. Verfahren nach Anspruch 22, wobei Software, die außerhalb der Hardware läuft, die Funktionalität der Software nicht emulieren kann, die innerhalb der Hardware läuft.
  37. Vorrichtung, umfassend: ein Hardwaregerät, das eine Hardwarekonfiguration aufweist, die entfernt konfiguriert werden kann, wobei das Hardwaregerät einen Controller umfasst, um eine sichere Berechtigungsanfrage zu erzeugen, um die Hardwarekonfiguration zu ändern, die sichere Berechtigungsanfrage zu einem entfernten Standort zu senden, eine Berechtigung zu empfangen, die vom entfernten Standort als Reaktion auf die Berechtigungsanfrage gesendet wurde, und die Hardwarekonfiguration als Reaktion auf die empfangene Berechtigung zu ändern.
  38. Vorrichtung nach Anspruch 37, wobei das Hardwaregerät ein Chipsatz oder ein Chipsatz-Teil ist.
  39. Vorrichtung nach Anspruch 37, weiter umfassend ein oder mehrere kryptografische Schlüssel, um die sichere Kommunikation und Berechtigungsauthentifizierung mit dem entfernten Standort sicherzustellen.
  40. Vorrichtung nach Anspruch 37 weiter umfassend einen eindeutigen Schlüssel, der dauerhaft im Hardwaregerät enthalten ist, wobei der eindeutige Schlüssel verwendet wird, um sichere Kommunikations- und Berechtigungsauthentifizierung mit dem entfernten Standort sicherzustellen.
  41. Vorrichtung nach Anspruch 40, wobei der eindeutige Schlüssel zufällig durchgebrannte Sicherungen im Hardwaregerät umfasst.
  42. Vorrichtung nach Anspruch 40, wobei der eindeutige Schlüssel nicht durch Software zugänglich ist, die außerhalb des Hardwaregeräts abläuft.
  43. Vorrichtung nach Anspruch 37, wobei die Berechtigung eine eindeutige Signatur vom entfernten Standort einschließt.
  44. Vorrichtung nach Anspruch 37, wobei der Controller weiter die empfangene Berechtigung vor dem Ändern der Hardwarekonfiguration validiert.
  45. Vorrichtung nach Anspruch 37, wobei der Controller weiter die empfangene Berechtigung validiert, indem er einen öffentlichen Schlüssel, der einem privaten am entfernten Standort befindlichen Signierschlüssel entspricht, verwendet.
  46. Vorrichtung nach Anspruch 37, wobei der entfernte Standort ein sicherer und vertrauenswürdiger Standort ist.
  47. Vorrichtung nach Anspruch 37, wobei der Controller die Hardwarekonfiguration ohne jede physische Veränderung an der Hardware ändert.
  48. Vorrichtung nach Anspruch 37, wobei die Berechtigung eine sichere Berechtigung und/oder eine signierte Berechtigung ist.
  49. Vorrichtung nach Anspruch 37, wobei Transaktionsinformationen innerhalb der Berechtigung gebunden sind, sodass zukünftige Rückläufer oder Umtausche aktiviert werden können.
  50. Vorrichtung nach Anspruch 37, wobei eine Berechtigung nicht bei einem anderen Hardwaregerät verwendet werden kann, sobald eine Berechtigung für ein bestimmtes Hardwaregerät signiert ist.
  51. Vorrichtung nach Anspruch 37, wobei Software, die außerhalb des Hardwaregeräts läuft, die Funktionalität der Software nicht emulieren kann, die innerhalb des Hardwaregeräts läuft.
  52. Vorrichtung nach Anspruch 37, wobei der Controller eine Aufhebung während eines Boot- und/oder Initialisierungsprozesses durchführt und die Hardwarekonfiguration als Reaktion auf die Aufhebung ändert.
  53. Vorrichtung nach Anspruch 37, wobei die sichere Berechtigungsanfrage nicht eindeutig identifizierbar ist.
  54. Vorrichtung nach Anspruch 37, wobei die Identität der Hardware und/oder des Benutzers der Hardware von der sicheren Berechtigungsanfrage nicht feststellbar ist.
  55. Vorrichtung, umfassend: einen Server, um von einem entfernten Standort eine sichere Berechtigungsanfrage zu empfangen, um eine Hardwarekonfiguration am entfernten Standort zu ändern, eine sichere Berechtigung zum entfernten Standort als Reaktion auf die Berechtigungsanfrage zu senden, wobei die Berechtigung ist, dem entfernten Standort zu ermöglichen, die Hardwarekonfiguration zu ändern.
  56. Vorrichtung nach Anspruch 55, wobei die Hardwarekonfiguration eine Hardwarekonfiguration eines Chipsatzes oder eines Chipsatz-Teils ist.
  57. Vorrichtung nach Anspruch 55, wobei ein oder mehrere kryptografische Schlüssel verwendet werden, um die sichere Kommunikations- und Berechtigungsauthentifizierung mit dem entfernten Standort sicherzustellen.
  58. Vorrichtung nach Anspruch 55, wobei die Berechtigung eine eindeutige Signatur einschließt.
  59. Vorrichtung nach Anspruch 55, wobei die Berechtigung ist, dem entfernten Standort zu ermöglichen, die Hardwarekonfiguration ohne jede physische Veränderung an der Hardware zu ändern.
  60. Vorrichtung nach Anspruch 55, wobei die Berechtigung eine sichere Berechtigung und/oder eine signierte Berechtigung ist.
  61. Vorrichtung nach Anspruch 55, wobei die Berechtigung ist, dem entfernten Standort zu ermöglichen, die Hardwarekonfiguration als Reaktion auf eine Aufhebungsoperation zu ändern, die während eines Boot- und/oder Initialisierungsprozesses durchgeführt wird.
  62. Vorrichtung nach Anspruch 55, wobei die sichere Berechtigungsanfrage nicht eindeutig identifizierbar ist.
  63. Vorrichtung nach Anspruch 55, wobei die Identität der Hardware und/oder des Benutzers der Hardware von der sicheren Berechtigungsanfrage nicht feststellbar ist.
  64. Vorrichtung nach Anspruch 55, wobei die sichere Berechtigungsanfrage am entfernten Standort als Reaktion auf den Zufallswert erzeugt worden ist.
  65. Vorrichtung nach Anspruch 55, wobei der Server einen privaten Signierschlüssel verwendet, der einem am entfernten Standort befindlichen öffentlichen Schlüssel entspricht, um bei der Validierung der Berechtigung am entfernten Standort zu helfen.
  66. Vorrichtung nach Anspruch 55, wobei Transaktionsinformationen innerhalb der Berechtigung gebunden sind, sodass zukünftige Rückläufer oder Umtausche aktiviert werden können.
  67. Vorrichtung nach Anspruch 55, wobei eine Berechtigung nicht bei einem anderen Hardware-Teil verwendet werden kann, sobald sie für einen bestimmten Hardware-Teil signiert ist.
  68. Verfahren nach Anspruch 55, wobei Software, die außerhalb der Hardware abläuft, die Funktionalität der Software nicht emulieren kann, die innerhalb der Hardware abläuft.
DE112010005069.4T 2009-12-31 2010-12-13 Bereitstellen, Aufrüsten und/oder Ändern von Hardware Active DE112010005069B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/655,579 US8966657B2 (en) 2009-12-31 2009-12-31 Provisioning, upgrading, and/or changing of hardware
US12/655,579 2009-12-31
PCT/US2010/060115 WO2011081890A2 (en) 2009-12-31 2010-12-13 Provisioning, upgrading and/or changing of hardware

Publications (2)

Publication Number Publication Date
DE112010005069T5 true DE112010005069T5 (de) 2012-11-29
DE112010005069B4 DE112010005069B4 (de) 2021-08-26

Family

ID=44188912

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112010005069.4T Active DE112010005069B4 (de) 2009-12-31 2010-12-13 Bereitstellen, Aufrüsten und/oder Ändern von Hardware

Country Status (7)

Country Link
US (1) US8966657B2 (de)
JP (1) JP5526450B2 (de)
CN (1) CN102667802A (de)
DE (1) DE112010005069B4 (de)
GB (1) GB2509479B (de)
TW (1) TW201145041A (de)
WO (1) WO2011081890A2 (de)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9075958B2 (en) * 2009-06-24 2015-07-07 Uniloc Luxembourg S.A. Use of fingerprint with an on-line or networked auction
US8578161B2 (en) * 2010-04-01 2013-11-05 Intel Corporation Protocol for authenticating functionality in a peripheral device
US8484474B2 (en) * 2010-07-01 2013-07-09 Rockwell Automation Technologies, Inc. Methods for firmware signature
WO2012023050A2 (en) 2010-08-20 2012-02-23 Overtis Group Limited Secure cloud computing system and method
EP2503482A1 (de) * 2011-03-23 2012-09-26 ST-Ericsson SA Elektronische Vorrichtung mit Flash-Speicherkomponente
US20120331290A1 (en) * 2011-06-24 2012-12-27 Broadcom Corporation Method and Apparatus for Establishing Trusted Communication With External Real-Time Clock
US9203617B2 (en) * 2011-08-17 2015-12-01 Vixs Systems, Inc. Secure provisioning of integrated circuits at various states of deployment, methods thereof
WO2013095387A1 (en) 2011-12-20 2013-06-27 Intel Corporation Secure replay protected storage
US9411748B2 (en) 2011-12-20 2016-08-09 Intel Corporation Secure replay protected storage
US9058201B2 (en) * 2011-12-28 2015-06-16 Intel Corporation Managing and tracking thread access to operating system extended features using map-tables containing location references and thread identifiers
US9262340B1 (en) 2011-12-29 2016-02-16 Cypress Semiconductor Corporation Privileged mode methods and circuits for processor systems
AU2012100460B4 (en) 2012-01-04 2012-11-08 Uniloc Usa, Inc. Method and system implementing zone-restricted behavior of a computing device
US8863273B2 (en) * 2012-01-30 2014-10-14 Mediatek Inc. Method of using an account agent to access superuser account shell of a computer device
AU2012100462B4 (en) 2012-02-06 2012-11-08 Uniloc Usa, Inc. Near field authentication through communication of enclosed content sound waves
US8949818B2 (en) * 2012-06-29 2015-02-03 Intel Corporation Mechanism for facilitating dynamic and trusted cloud-based extension upgrades for computing systems
CN103840937A (zh) * 2012-11-23 2014-06-04 许丰 虚拟量子加密系统
AU2013100355B4 (en) 2013-02-28 2013-10-31 Netauthority, Inc Device-specific content delivery
US9819661B2 (en) * 2013-09-12 2017-11-14 The Boeing Company Method of authorizing an operation to be performed on a targeted computing device
US9297559B2 (en) * 2013-09-25 2016-03-29 Intel Corporation Adaptive thermoelectric cooling in a processor
US20150242597A1 (en) * 2014-02-24 2015-08-27 Google Inc. Transferring authorization from an authenticated device to an unauthenticated device
US11030122B2 (en) * 2014-04-08 2021-06-08 Micron Technology, Inc. Apparatuses and methods for securing an access protection scheme
CN104317613A (zh) * 2014-10-15 2015-01-28 广西大学 广播电视发射台远程监控系统的采集控制器软件升级方法
US9735968B2 (en) * 2014-10-20 2017-08-15 Microsoft Technology Licensing, Llc Trust service for a client device
US20160180095A1 (en) * 2014-12-23 2016-06-23 Nitin V. Sarangdhar Measured boot capability
WO2016130114A1 (en) 2015-02-10 2016-08-18 Hewlett Packard Enterprise Development Lp Chipset reconfiguration based on device detection
WO2016159935A1 (en) 2015-03-27 2016-10-06 Intel Corporation Dynamic configuration of input/output controller access lanes
US9930050B2 (en) * 2015-04-01 2018-03-27 Hand Held Products, Inc. Device management proxy for secure devices
US9882934B2 (en) * 2015-06-29 2018-01-30 Synopsys, Inc. Simple trusted transfer to internet of things devices
US10067770B2 (en) 2015-12-21 2018-09-04 Hewlett-Packard Development Company, L.P. Platform key hierarchy
US10778435B1 (en) * 2015-12-30 2020-09-15 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
WO2017161305A1 (en) * 2016-03-18 2017-09-21 University Of Florida Research Foundation, Incorporated Bitstream security based on node locking
US10318748B2 (en) * 2016-09-30 2019-06-11 Intel Corporation Techniques to protect fuses against non-destructive attacks
US10762006B2 (en) * 2017-03-31 2020-09-01 Intel Corporation Techniques to dynamically enable memory channels on a compute platform
CN107179911B (zh) * 2017-05-19 2020-08-18 苏州浪潮智能科技有限公司 一种重启管理引擎的方法和设备
US10211979B2 (en) 2017-05-19 2019-02-19 Swfl, Inc. Systems and methods securing an autonomous device
US10467416B2 (en) 2017-06-16 2019-11-05 International Business Machines Corporation Securing operating system configuration using hardware
CN110062016B (zh) 2018-01-18 2023-05-09 阿里巴巴集团控股有限公司 用于可信服务管理的方法及装置
CN111382433B (zh) * 2018-12-29 2022-12-13 龙芯中科技术股份有限公司 模块加载方法、装置、设备以及存储介质
US11627049B2 (en) * 2019-01-31 2023-04-11 Hewlett Packard Enterprise Development Lp Failsafe firmware upgrade for cloud-managed devices
US11139991B2 (en) * 2019-09-28 2021-10-05 Intel Corporation Decentralized edge computing transactions with fine-grained time coordination
US11416639B2 (en) * 2020-06-29 2022-08-16 Nuvoton Technology Corporation PQA unlock
US11574079B2 (en) 2021-05-27 2023-02-07 Nuvoton Technology Corporation Multi-stage provisioning of secret data
US11494330B2 (en) 2021-06-22 2022-11-08 Intel Corporation Fuse recipe update mechanism

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5960464A (ja) * 1982-09-30 1984-04-06 株式会社東芝 プログラムの暗号化方式
US7124302B2 (en) * 1995-02-13 2006-10-17 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
JP3486043B2 (ja) * 1996-03-11 2004-01-13 株式会社東芝 ソフトウエア流通システムの動作方法及びソフトウエアシステム
US5948101A (en) * 1996-12-02 1999-09-07 The Foxboro Company Methods and systems for booting a computer in a distributed computing system
US6789135B1 (en) * 1998-09-09 2004-09-07 Matsushita Electric Industrial Co., Ltd. Apparatus function change system having an apparatus service center containing customer information and setting information for a reconfigurable chip
US6304831B1 (en) * 1998-11-09 2001-10-16 Crystal Group Inc. Computer having multiple alarm function communication paths
US6510513B1 (en) * 1999-01-13 2003-01-21 Microsoft Corporation Security services and policy enforcement for electronic data
US6683954B1 (en) * 1999-10-23 2004-01-27 Lockstream Corporation Key encryption using a client-unique additional key for fraud prevention
US7278016B1 (en) * 1999-10-26 2007-10-02 International Business Machines Corporation Encryption/decryption of stored data using non-accessible, unique encryption key
US7213152B1 (en) * 2000-02-14 2007-05-01 Intel Corporation Modular bios update mechanism
US20010051928A1 (en) * 2000-04-21 2001-12-13 Moshe Brody Protection of software by personalization, and an arrangement, method, and system therefor
FR2810759A1 (fr) * 2000-06-26 2001-12-28 Radoslaw Galka Procede pour effectuer une transaction commerciale en ligne par l'intermediaire d'un reseau de communication et dispositif electronique pour passer des commandes commerciales en ligne
KR20020005929A (ko) 2000-07-11 2002-01-18 정재용 통신망을 이용한 컴퓨터 ａ／ｓ 시스템 및 방법
US6621293B2 (en) * 2001-05-31 2003-09-16 Koninklijke Philips Electronics N.V. Integrated circuit arrangement with feature control
GB0114317D0 (en) * 2001-06-13 2001-08-01 Kean Thomas A Method of protecting intellectual property cores on field programmable gate array
DE10130786C1 (de) 2001-06-26 2003-02-13 Infineon Technologies Ag Laser-Programmierung integrierter Schaltkreise sowie zugehöriger integrierter Schaltkreis
US20040010643A1 (en) 2002-07-09 2004-01-15 Thomas William John Method for providing multiple configurations in a computer system with multiple components
JP2004086392A (ja) 2002-08-26 2004-03-18 Hitachi Ltd 計算機構成変更方法およびシステム
US7353543B2 (en) * 2003-01-10 2008-04-01 Matsushita Electric Industrial Co., Ltd. Contents distribution system
US20050039016A1 (en) * 2003-08-12 2005-02-17 Selim Aissi Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution
CA2455043A1 (en) * 2004-01-09 2005-07-09 Digital Multitools Inc. Method and apparatus for facilitating control of a target computer by a remote computer
JP2005202503A (ja) 2004-01-13 2005-07-28 Hitachi Ltd 車載情報装置、車載機器管理システム、車両の制御機器のプログラムのバージョンアップ情報の配信方法、車両の制御機器のプログラムのバージョンアップ方法及び車両の制御機器のプログラムのバージョンアップシステム
US7802085B2 (en) * 2004-02-18 2010-09-21 Intel Corporation Apparatus and method for distributing private keys to an entity with minimal secret, unique information
JP2006295872A (ja) * 2005-03-18 2006-10-26 Matsushita Electric Ind Co Ltd 機器固有鍵の生成方法、これを用いた機密情報処理機能を備えた機密情報ｌｓｉ、これを搭載したホスト機器、これに用いられる認証機能付き記録媒体、および認証機能を備えた記録媒体付き携帯端末
US9436804B2 (en) * 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
CN100454250C (zh) 2005-10-25 2009-01-21 北京飞天诚信科技有限公司 信息安全设备固件程序的远程升级方法
CN101133420B (zh) 2005-12-19 2011-04-13 日本电信电话株式会社 终端识别方法、认证方法、认证系统、服务器、终端、无线基站、程序以及记录介质
US8429406B2 (en) * 2007-06-04 2013-04-23 Qualcomm Atheros, Inc. Authorizing customer premise equipment into a network
US20080320263A1 (en) * 2007-06-20 2008-12-25 Daniel Nemiroff Method, system, and apparatus for encrypting, integrity, and anti-replay protecting data in non-volatile memory in a fault tolerant manner
DE602007012538D1 (de) 2007-07-27 2011-03-31 Ntt Docomo Inc Verfahren und Vorrichtung zur Durchführung delegierter Transaktionen
US7978850B2 (en) * 2007-07-31 2011-07-12 Lsi Corporation Manufacturing embedded unique keys using a built in random number generator
US8189793B2 (en) * 2007-08-28 2012-05-29 Panasonic Corporation Key terminal apparatus, crypto-processing LSI, unique key generation method, and content system
US9069990B2 (en) * 2007-11-28 2015-06-30 Nvidia Corporation Secure information storage system and method
US8693692B2 (en) * 2008-03-18 2014-04-08 Cisco Technology, Inc. Direct delivery of content descrambling keys using chip-unique code
US8001380B2 (en) * 2008-07-01 2011-08-16 Verizon Patent And Licensing Inc. System and method for providing unique encryption key
US7795899B1 (en) * 2009-04-08 2010-09-14 Oracle America, Inc. Enabling on-chip features via efuses

Also Published As

Publication number Publication date
WO2011081890A2 (en) 2011-07-07
DE112010005069B4 (de) 2021-08-26
US8966657B2 (en) 2015-02-24
WO2011081890A3 (en) 2011-11-03
US20110161672A1 (en) 2011-06-30
JP5526450B2 (ja) 2014-06-18
CN102667802A (zh) 2012-09-12
TW201145041A (en) 2011-12-16
GB2509479A (en) 2014-07-09
GB2509479B (en) 2016-06-15
GB201209890D0 (en) 2012-07-18
JP2013516003A (ja) 2013-05-09

Similar Documents

Publication Publication Date Title
DE112010005069B4 (de) Bereitstellen, Aufrüsten und/oder Ändern von Hardware
US11119905B2 (en) System and method for managing electronic assets
US9210140B2 (en) Remote functionality selection
US7640541B2 (en) In-system reconfiguring of hardware resources
JP5502198B2 (ja) デバイスのシリアライゼーションを実行するためのシステムおよび方法
JP5342649B2 (ja) ハードウェアベースセキュリティのためのシステムおよび方法
AU2007276673B2 (en) System and method for authenticating a gaming device
US8843764B2 (en) Secure software and hardware association technique
US10917243B2 (en) Secure server and compute nodes
CN103119560A (zh) 用于服务处理器复合体中的数据存储的基于需求的usb代理
CN104160405A (zh) 用于信任配置的安全设备环境
CN108846263B (zh) 软件授权处理及运行方法和装置、电子设备
US11868474B2 (en) Securing node groups
US11822669B2 (en) Systems and methods for importing security credentials for use by an information handling system
US20230011005A1 (en) Systems and methods for authenticating configurations of an information handling system
CN113515414A (zh) 可编程逻辑器件的验证
US11843707B2 (en) Systems and methods for authenticating hardware of an information handling system
US20120005049A1 (en) Alpha ii license management system
DE102022120902A1 (de) Rekonfigurationsmechanismus für integrierte schaltungspackung
AU2013200551B2 (en) System and method for authenticating a gaming device

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021200000

Ipc: G06F0021730000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021200000

Ipc: G06F0021730000

Effective date: 20121207

R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final