DE112016004345T5 - Technologien für eine anonyme kontextbestätigung und bedrohungsanalyse - Google Patents

Technologien für eine anonyme kontextbestätigung und bedrohungsanalyse Download PDF

Info

Publication number
DE112016004345T5
DE112016004345T5 DE112016004345.7T DE112016004345T DE112016004345T5 DE 112016004345 T5 DE112016004345 T5 DE 112016004345T5 DE 112016004345 T DE112016004345 T DE 112016004345T DE 112016004345 T5 DE112016004345 T5 DE 112016004345T5
Authority
DE
Germany
Prior art keywords
computing device
attributes
sensor data
generating
confirmation
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.)
Pending
Application number
DE112016004345.7T
Other languages
English (en)
Inventor
Abhilasha Bhargav-Spantzel
Hormuzd M. Khosravi
Alex Nayshtut
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 DE112016004345T5 publication Critical patent/DE112016004345T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • 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/3218—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 using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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/3271—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 using challenge-response

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

Technologien für eine anonyme Kontextbestätigung und Bedrohungsanalyse enthalten eine Rechenvorrichtung zum Empfangen von Sensordaten, die durch einen oder mehrere Sensor(en) der Rechenvorrichtung generiert werden, und Generieren einer Bestätigungsangabe auf der Basis der Sensordaten. Die Bestätigungsangabe enthält verschleierte Attribute der Rechenvorrichtung auf der Basis der Sensordaten. Die Rechenvorrichtung sendet eine kenntnisfreie Zusage der Bestätigungsangabe an einen Server und empfängt eine Aufforderung vom Server in Antwort auf das Senden der kenntnisfreien Zusage. Die Aufforderung verlangt eine Angabe, ob die verschleierten Attribute der Rechenvorrichtung Gemeinsamkeit mit Attributen haben, die in einem Aufforderungsprofil identifiziert wurden, das mit der Aufforderung empfangen wurde. Die Rechenvorrichtung generiert einen kenntnisfreien Beweis, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.

Description

  • QUERVERWEIS AUF VERWANDTE US PATENTANMELDUNG
  • Die vorliegende Anmeldung beansprucht die Priorität der US Gebrauchsmuster-Patentanmeldung, Seriennr. 14/866,628 , mit dem Titel „TECHNOLOGIES FOR ANONYMOUS CONTEXT ATTESTATION AND THREAT ANALYTICS“, die am 25. September 2015 eingereicht wurde.
  • HINTERGRUND
  • Sich rasch entwickelnde Cyberangriffe und fortgeschrittene beständige Sicherheitsbedrohungen beinhalten nicht nur böswillige Individuen, sondern auch Cyber-kriminelle Organisationen, die gegen Unternehmen, Regierungsorganisationen und andere Institutionen zusammenarbeiten. Solche böswilligen Individuen und Organisationen genießen eine kollaborative Infrastruktur, um Informationen bezüglich Systemschwachstellen, erfolgreiche Angriffe und andere Informationen zu teilen, die für einen Angriff auf ein Rechensystem nützlich sind. Unternehmen, Regierungen, gemeinnützige Organisationen und andere Gruppen und Individuen ziehen jedoch nicht aus demselben Maß an Zusammenarbeit Nutzen, indem sie Gefahrenerkennung und Cybersicherheitsmaßnahmen teilen, um Angriffe zu verhindern. Tatsächlich verstricken sich Bedenken bezüglich eines Teilens von Firmendaten, der Mangel an einer gemeinsamen Sprache, um nützliche Informationen zu teilen und/oder ein Mangel an Ressourcen und Infrastruktur, um solche Informationen zu teilen, häufig und errichten so eine Barriere gegenüber einer Einrichtung wirklich kollaborativer und universeller Cybersicherheitsmaßnahmen.
  • Figurenliste
  • Die hier beschriebenen Konzepte sind als Beispiel und nicht als Einschränkung in den beiliegenden Figuren angeführt. Der einfachen und deutlichen Veranschaulichung wegen sind Elemente, die in den Figuren gezeigt werden, nicht unbedingt im Maßstab gezeichnet. Falls als angemessen erachtet, wurden Bezugszeichen in den Figuren wiederholt, um entsprechende oder analoge Elemente anzugeben.
    • 1 ist ein vereinfachtes Blockdiagramm zumindest einer Ausführungsform eines Systems für eine anonyme Kontextbestätigung und Bedrohungsanalyse;
    • 2 ist ein vereinfachtes Blockdiagramm zumindest einer Ausführungsform einer Client-Vorrichtung des Systems von 1;
    • 3 ist ein vereinfachtes Blockdiagramm zumindest einer Ausführungsform einer Umgebung der Client-Vorrichtung von 2;
    • 4 ist ein vereinfachtes Flussdiagramm zumindest einer Ausführungsform eines Verfahrens zur anonymen Kontextbestätigung und Bedrohungsanalyse, das durch die Client-Vorrichtung von 2 ausgeführt werden kann;
    • 5 ist ein vereinfachtes Flussdiagramm zumindest einer Ausführungsform eines Verfahrens zur anonymen Kontextbestätigung und Bedrohungsanalyse, das durch einen Server des Systems von 1 ausgeführt werden kann; und
    • 6 ist ein vereinfachtes Datenflussdiagramm zumindest einer Ausführungsform der Verfahren von 4-5.
  • AUSFÜHRLICHE BESCHREIBUNG DER ZEICHNUNGEN
  • Während die Konzepte der vorliegenden Offenbarung für verschiedene Modifizierungen und alternative Formen zugänglich sind, sind spezielle Ausführungsformen derselben als Beispiel in den Zeichnungen dargestellt und werden hier ausführlich beschrieben. Es sollte jedoch klar sein, dass keine Absicht besteht, die Konzepte der vorliegenden Offenbarung auf die besonderen offenbarten Formen zu beschränken, sondern, im Gegenteil, die Absicht ist, alle Modifizierungen, Äquivalente und Alternativen in Übereinstimmung mit der vorliegenden Offenbarung und den beiliegenden Ansprüchen abzudecken.
  • Eine Bezugnahme in der Beschreibung auf „eine bestimmte Ausführungsform“, „eine Ausführungsform“, „eine veranschaulichende Ausführungsform“ usw. gibt an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft enthalten kann, aber jede Ausführungsform nicht unbedingt dieses bestimmte Merkmal, diese bestimmte Struktur oder Eigenschaft enthalten muss. Ferner beziehen sich solche Phrasen nicht unbedingt auf dieselbe Ausführungsform. Wenn ferner ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben ist, wird angenommen, dass einem Fachmann auf dem Gebiet bekannt ist, ein solches Merkmal, eine solche Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen umzusetzen, seien sie nun explizit beschrieben oder nicht. Zusätzlich sollte offensichtlich sein, dass Punkte, die in einer Liste in der Form „zumindest ein A, B und C“ enthalten sind, (A); (B); (C); (A und B); (B und C); (A und C); oder (A, B, und C) bedeuten können. Ebenso können Punkte, die in der Form „zumindest eines von A, B oder C“ aufgelistet sind, (A); (B); (C); (A und B); (B und C); (A und C); oder (A, B, und C) bedeuten.
  • Die offenbarten Ausführungsformen können in einigen Fällen in Hardware, Firmware, Software oder jeder Kombination davon implementiert sein. Die offenbarten Ausführungsformen können auch als Anweisungen implementiert sein, die von einem oder mehreren transitorischen oder nicht transitorischen, maschinenlesbaren (z.B. computerlesbaren) Speichermedium bzw. Speichermedien getragen oder auf diesen gespeichert sind, die dann von einem oder mehreren Prozessor(en) gelesen und ausgeführt werden können. Ein maschinenlesbares Speichermedium kann als jede Speichervorrichtung, jeder Mechanismus oder jede andere physische Struktur zum Speichern oder Senden von Informationen in einer Form, die von einer Maschine lesbar ist (z.B. einem flüchtigen oder nicht flüchtigen Speicher, einer Mediendisk oder anderen Medienvorrichtung), verkörpert sein.
  • In den Zeichnungen können einige Struktur- oder Verfahrensmerkmale in besonderen Anordnungen und/oder Reihenfolgen dargestellt sein. Es sollte jedoch klar sein, dass solche speziellen Anordnungen und/oder Reihenfolgen nicht notwendig sein können. Vielmehr können in einigen Ausführungsformen solche Merkmale in einer anderen Weise und/oder Reihenfolge als in der in den veranschaulichenden Figuren gezeigten angeordnet sein. Zusätzlich soll die Aufnahme eines Struktur- oder Verfahrensmerkmals in einer besonderen Figur nicht implizieren, dass ein solches Merkmal in allen Ausführungsformen erforderlich ist, und kann in einigen Ausführungsformen nicht enthalten sein oder kann mit anderen Merkmalen kombiniert sein.
  • Unter Bezugnahme nun auf 1 enthält ein System 100 für eine anonyme Kontextbestätigung und Bedrohungsanalyse eine oder mehrere Client-Vorrichtung(en) 102, ein oder mehrere Netzwerk(e) 104, einen oder mehrere Server 106, ein Netzwerk 108 und einen Root-Server 110. Obwohl nur ein Root-Server 110 und ein Netzwerk 108 als Veranschaulichung in 1 dargestellt sind, kann das System 100 eine beliebige Anzahl von Root-Servem 110 und/oder Netzwerken 108 in anderen Ausführungsformen enthalten. Zusätzlich, wie dargestellt, kann das System 100 eine beliebige Anzahl von Client-Vorrichtungen 102, Netzwerken 104 und/oder Servern 106 enthalten.
  • Wie in der Folge ausführlich beschrieben, führt das System 100 in der veranschaulichenden Ausführungsform ein OS-unabhängiges Modell für eine holistische Plattformbestätigung ein und definiert eine Hierarchie anonymisierter Bedrohungsanalyse- (ATA) Knoten, sodass Elternknoten kenntnisfreie Beweise (Zero Knowledge Proofs, ZKPs) der Kinderknoten verifizieren können, die Gefahrenerkennungsdaten enthalten, um somit zum Beispiel Bedrohungsinformationen mit minimalem Teilen von Informationen zwischen Vorrichtungen ableiten können. Im Speziellen kann jede der Client-Vorrichtungen 102 eine Bestätigungsangabe anhand von Sensordaten (z.B. Hardware- und/oder Software-Sensordaten) der Client-Vorrichtung 102 generieren und anonymisierte oder andersartige verschleierte Attribute bezüglich der Client-Vorrichtung 102 (z.B. einen Bereich identifizierter, verdächtiger Hash-Dateiinstanzen, einen Bereich erfasster Spoofing-Angriffe, eine Gruppe von Anwendungen, die als anfällig erachtet wird, usw.) in der Bestätigungsangabe zur Sendung an einen entsprechenden Server 106 (z.B. einen Server eines Unternehmensnetzwerks, einschließlich der entsprechenden Client-Vorrichtungen 102) enthalten. Basierend auf der Bestätigungsangabe kann der Server 106 die Client-Vorrichtungen 102 auffordern, eine Überlappung oder Gemeinsamkeit zwischen den Attributen der Client-Vorrichtungen 102 und/oder Referenzattributprofilen zu identifizieren. Es sollte offensichtlich sein, dass das System 100 kenntnisfreie Beweise (z.B. kenntnisfreie Wissensbeweise) und/oder andere Techniken zur Bestätigung verwenden kann, während die Anonymität gewahrt bleibt (z.B. direkte anonyme Bestätigung, Enhanced Privacy Identification(EPID)-Technologie, U-Prove-Technologie, Identity Mixer(IDEMIX)-Technologie usw.).
  • Jeder der anschaulichen Client-Vorrichtungen 102 kann als eine Art von Rechenvorrichtung verkörpert sein, die imstande ist, die hier beschriebenen Funktionen durchzuführen. Zum Beispiel kann jede der Client-Vorrichtungen 102 als Laptop Computer, Desktop Computer, Tablet Computer, Notebook, Netbook, Ultrabook™, Mobiltelefon, Smartphone, tragbare Rechenvorrichtung, persönlicher digitaler Assistent, mobile Internetvorrichtung, Hybridvorrichtung, Server, Router, Schalter und/oder jede andere Rechen-/Kommunikationsvorrichtung verkörpert sein. Unter Bezugnahme nun auf 2 ist eine anschauliche Ausführungsform einer Client-Vorrichtung 102 dargestellt. Wie dargestellt, enthält die anschauliche Client-Vorrichtung 102 einen Prozessor 210, ein Eingabe/Ausgabe- („I/O“) Teilsystem 212, einen Speicher 214, einen Datenspeicher 216, einen Kommunikationsschaltkreis 118, einen oder mehrere Sensor(en) 120, eine Sicherheitsmaschine 222, eine Authentifizierungsmaschine 224, eine Kontextmaschine 226 und eine oder mehrere periphere Vorrichtung(en) 228. Natürlich kann die Client-Vorrichtung 102 in anderen Ausführungsformen andere oder zusätzliche Komponenten enthalten, wie jene, die allgemein in einer typischen Rechenvorrichtung vorgefunden werden (z.B. in verschiedenen Eingabe/Ausgabe-Vorrichtungen und/oder anderen Komponenten). Zusätzlich können in einigen Ausführungsformen eine oder mehrere der anschaulichen Komponenten in einer anderen Komponente eingegliedert sein oder auf andere Weise einen Teil derselben bilden. Zum Beispiel können der Speicher 214 oder Abschnitte davon in einigen Ausführungsformen in den Prozessor 210 eingegliedert sein. Ferner können in einigen Ausführungsformen eine oder mehrere der anschaulichen Komponenten in der Client-Vorrichtung 102 fehlen (z.B. die Sicherheitsmaschine 222, die Authentifizierungsmaschine 224, die Kontextmaschine 226 und/oder eine oder mehrere der peripheren Vorrichtungen 228).
  • Der Prozessor 210 kann als eine Art von Prozessor verkörpert sein, der imstande ist, die hier beschriebenen Funktionen durchzuführen. Zum Beispiel kann der Prozessor 210 als Einzel- oder Mehrfach-Kern-Prozessor(en), Digitalsignalprozessor, Mikrosteuerung oder anderer Prozessor oder Verarbeitungs-/Steuerschaltung verkörpert sein. Ebenso kann der Speicher 214 als eine Art von flüchtigem oder nicht flüchtigem Speicher oder Datenspeicher verkörpert sein, der imstande ist, die hier beschriebenen Funktionen durchzuführen. In Betrieb kann der Speicher 214 verschiedene Daten und Software speichern, die während des Betriebs der Client-Vorrichtung 102 verwendet werden, wie Betriebssysteme, Anwendungen, Programme, Bibliotheken und Treiber. Der Speicher 214 ist kommunikativ über das I/O-Teilsystem 212, das als Schaltkreis und/oder Komponenten zur Erleichterung von Eingabe/Ausgabe-Operationen mit dem Prozessor 210, dem Speicher 214, und anderen Komponenten der Client-Vorrichtung 102 verkörpert ist, an den Prozessor 210 gekoppelt. Zum Beispiel kann das I/O-Teilsystem 212 als Speichersteuerungs-Hubs, Eingabe/Ausgabesteuerungs-Hubs, Firmware-Vorrichtungen, Kommunikationsverbindungen (d.h. Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterplattenbahnen usw.) und/oder andere Komponenten und Teilsysteme zum Erleichtern der Eingabe/Ausgabe-Operationen verkörpert sein oder aber diese enthalten. In einigen Ausführungsformen kann das I/O-Teilsystem 212 Teil eines System-on-Chip (SoC) bilden und, gemeinsam mit dem Prozessor 210, dem Speicher 214 und anderen Komponenten der Client-Vorrichtung 102 auf einem einzelnen integrierten Schaltungs-Chip eingegliedert sein.
  • Der Datenspeicher 216 kann als jede Art von Vorrichtung oder Vorrichtungen verkörpert sein, die für ein kurzfristiges oder langfristiges Speichern von Daten konfiguriert ist bzw. sind, wie zum Beispiel Speichervorrichtungen und -schaltungen, Speicherkarten, Festplattenlaufwerke, Solid-State-Laufwerke und andere Datenspeichervorrichtungen. Der Datenspeicher 216 und/oder der Speicher 214 können verschiedene Daten während des Betriebs der Client-Vorrichtung 102 wie hier beschrieben speichern.
  • Der Kommunikationsschaltkreis 218 kann als jede Kommunikationsschaltung, Vorrichtung oder Sammlung davon verkörpert sein, die imstande ist, eine Kommunikation zwischen der Client-Vorrichtung 102 und anderen fernen Vorrichtungen (z.B. dem entsprechenden Server 106) über ein Netzwerk (z.B. das entsprechenden Netzwerk 104) zu ermöglichen. Der Kommunikationsschaltkreis 218 kann konfiguriert sein, eine oder mehrere Kommunikationstechnologie(n) (z.B. drahtlose oder verdrahtete Kommunikationen) und zugehörige Protokolle (z.B. Ethernet, Bluetooth®, Wi-Fi®, WiMAX, LTE, 5G usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
  • Die Sensoren 220 können als Sensoren verkörpert sein, die konfiguriert sind, Daten/Signale zu generieren, die eine Umgebung oder einen Kontext der Client-Vorrichtung 102 und/oder einen Anwender der Client-Vorrichtung 102 anzeigen. In verschiedenen Ausführungsformen können die Sensoren 220 zum Beispiel als Trägheitssensoren, Positionssensoren, Näherungssensoren, optische Sensoren, Lichtsensoren, Audiosensoren, Temperatursensoren, Bewegungssensoren, piezoelektrische Sensoren, Kameras und/oder andere Arten von Sensoren verkörpert sein oder aber diese enthalten. Natürlich kann die Client-Vorrichtung 102 auch Komponenten und/oder Vorrichtungen enthalten, die konfiguriert sind, die Verwendung des Sensors (der Sensoren) 220 zu erleichtern. Abhängig von der besonderen Ausführungsform können die Sensoren 220 Hardware-Sensoren und/oder Software-Sensoren (z.B. Software-Sensoren zum Detektieren von Eindringungsversuchen und Viren und/oder Bestimmen anderen Anwendungsdaten) enthalten.
  • Die Sicherheitsmaschine 222 kann als Hardware-Komponente(n) oder Schaltkreis verkörpert sein, imstande, kryptografische Funktionen durchzuführen und/oder eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) einzurichten. Zum Beispiel kann die Sicherheitsmaschine 222 in einigen Ausführungsformen als Sicherheits-Co-Prozessor, wie ein vertrauenswürdiges Plattformmodul (Trusted Platform Module, TPM), oder ein bandexterner Prozessor verkörpert sein.
  • Die Authentifizierungsmaschine 224 kann als Hardware-Komponente(n) oder Schaltkreis verkörpert sein, imstande, Anwender- und/oder Vorrichtungsauthentifizierungsfunktionen durchzuführen. Zum Beispiel kann in einigen Ausführungsformen die Authentifizierungsmaschine 224 konfiguriert sein, die Identität eines Anwenders, einer Rechenvorrichtung und/oder Komponente einer Rechenvorrichtung zu bestätigen. Dazu kann die Authentifizierungsmaschine 224 ein Passwort, eine einzigartige Kennung und/oder andere geeignete Daten verwenden.
  • Die Kontextmaschine 226 kann als Hardware Komponente(n) oder Schaltkreis verkörpert sein, imstande, einen Kontext der Client-Vorrichtung 102 und/oder eines Anwenders der Client-Vorrichtung 102 zu bestimmen. Dazu kann die Kontextmaschine 226 Daten analysieren, die von einem oder mehreren Sensor(en) 220 der Client-Vorrichtung 102 (z.B. Hardware-Sensoren und/oder Software-Sensoren) generiert werden. Es sollte offensichtlich sein, dass die Kontextmaschine 226 den Zustand der Client-Vorrichtung 102 zu einem bestimmten Zeitpunkt bestimmen kann.
  • Die peripheren Vorrichtungen 228 können eine beliebige Anzahl zusätzlicher peripherer oder Schnittstellenvorrichtungen enthalten, wie Lautsprecher, Mikrophone, zusätzliche Speichervorrichtungen und so weiter. Die besonderen Vorrichtungen, die in den peripheren Vorrichtungen 228 enthalten sind, können zum Beispiel von der Art und/oder der geplanten Verwendung der Client-Vorrichtung 102 abhängen.
  • Unter erneuter Bezugnahme auf 1 kann jedes der Netzwerke 104 als eine Art von Kommunikationsnetzwerk verkörpert sein, imstande, eine Kommunikation zwischen den Client-Vorrichtungen 102 und fernen Vorrichtungen (z.B. den entsprechenden Servern 106) zu erleichtern. Ebenso kann das Netzwerk 108 als eine Art von Kommunikationsnetzwerk verkörpert sein, imstande, die Kommunikation zwischen dem Root-Server 110 und fernen Vorrichtungen (z.B. den Servern 106) zu erleichtern. Als solches kann jedes der Netzwerke 104, 108 ein oder mehrere Netzwerk(e), Router, Schalter, Computer und/oder andere dazwischenliegende Vorrichtungen enthalten. Zum Beispiel kann jedes Netzwerk 104, 108 als ein oder mehrere zellulare(s) Netzwerk(e), Telefonnetzwerk(e), lokale oder Weitverkehrsnetzwerk(e), öffentlich verfügbare globale Netzwerk(e) (z.B. das Internet), ein ad hoc Netzwerk oder jeder Kombination davon verkörpert sein oder aber diese enthalten.
  • Jeder der Server 106 und der Root-Server 110 können als eine Art von Rechenvorrichtung verkörpert sein, die imstande ist, die hier beschriebenen Funktionen durchzuführen. Zum Beispiel können die Server 106, 110 in einigen Ausführungsformen der Client-Vorrichtung 102 wie oben beschrieben ähnlich sein. Das heißt, jeder der Server 106, 110 kann als ein Server, ein Rackmount-Server, ein Blade-Server, Desktop Computer, Laptop Computer, Tablet Computer, Notebook, Netbook, Ultrabook™, Mobiltelefon, Smartphone, persönlicher digitaler Assistent, mobile Internetvorrichtung, tragbare Rechenvorrichtung, HybridVorrichtung und/oder jede andere Rechen-/Kommunikationsvorrichtung verkörpert sein. Ferner können die Server 106, 110 Komponenten ähnlich jenen der oben besprochenen Client-Vorrichtung 102 enthalten. Die Beschreibung dieser Komponenten der Client-Vorrichtung 102 gilt gleichermaßen für die Beschreibung von Komponenten der Server 106, 110 und wird hier der deutlichen Beschreibung wegen nicht wiederholt. Ferner sollte offensichtlich sein, dass die Server 106, 110 andere Komponenten, Teilkomponenten und Vorrichtungen enthalten können, die allgemein in einer Rechenvorrichtung vorgefunden werden, die zuvor nicht in Bezug auf die Client-Vorrichtung 102 besprochen wurden und hier der deutlichen Beschreibung wegen nicht besprochen werden. In einigen Ausführungsformen können eine oder mehrere der Komponenten der Client-Vorrichtung 102 in einem oder mehreren der Server 106, 110 fehlen (z.B. die Sicherheitsmaschine 222, die Authentifizierungsmaschine 224, die Kontextmaschine 226 und/oder die peripheren Vorrichtungen 228).
  • In einigen Ausführungsformen können die Server 106 als Zwischen- oder mittlere Aggregatoren verkörpert sein, die kenntnisfreie Beweise verifizieren können, die durch Kinderknoten (z.B. entsprechende Client-Vorrichtungen 102) behauptet werden. Zusätzlich können die Server 106 in einigen Ausführungsformen zusätzliche kenntnisfreie Beweise für den Root-Server 110 erstellen. Der Root-Server 110 kann konfiguriert sein, als globaler Gefahrenerkennungs-Root-Knoten zu dienen, der imstande ist, Beweise (z.B. kenntnisfreie Beweise) von mehreren Knoten (z.B. den Servern 106 und/oder den Client-Vorrichtungen 102) zu sammeln und zu verifizieren. Ferner kann der Root-Server 110 in einigen Ausführungsformen den Servern 106 und/oder den Client-Vorrichtungen 102 umsetzbare Sicherheitswarnungen und/oder Empfehlungen bereitstellen.
  • In einigen Ausführungsformen kann jeder der Server 106 einem anderen Unternehmenssystem oder einer anderen Organisation entsprechen. Zum Beispiel kann ein erster Server 106 mit einer IT-Organisation verknüpft sein, ein zweiter Server 106 kann mit einer pharmazeutischen Organisation verknüpft sein und/oder ein dritter Server 106 kann mit einer Regierungsorganisation verknüpft sein. In solchen Ausführungsformen kann der erste Server 106 konfiguriert sein, kenntnisfreie Beweise verschiedener verschleierter Attribute von den Client-Vorrichtungen 102 im Netzwerk 104 dieses Servers 106 zu empfangen. Solche Attribute können zum Beispiel ortsbasierte Bedrohungswarnungen (z.B. Ursprungsort, Zielort, Route usw.), Warnungsstufen an einem bestimmten geografischen Ort, eine Anzahl (z.B. als Bereich angegeben) verdächtiger identifizierter Hash-Dateiinstanzen, eine Anzahl (z.B. als Bereich angegeben) detektierter Spoofing-Angriffe, eine Gruppe von Anwendungen, die als anfällig erachtet werden, plattformspezifische verdächtige Datei-Hashes und/oder andere Attribute der Client-Vorrichtungen 102 enthalten.
  • Unter Bezugnahme nun auf 3 errichtet die Client-Vorrichtung 102 in Verwendung eine Umgebung 300 für eine anonyme Kontextbestätigung und Bedrohungsanalyse. Wie hier beschrieben, enthält die anschauliche Umgebung 300 der Client-Vorrichtung 102 eine vertrauenswürdige Ausführungsumgebung 302 oder ist sonst konfiguriert, diese zu errichten. In einigen Ausführungsformen wird die vertrauenswürdige Ausführungsumgebung 302 durch die Sicherheitsmaschine 222 errichtet. Wie dargestellt, können eines oder mehrere der Module der Umgebung 300, abhängig von der besonderen Ausführungsform, in der vertrauenswürdigen Ausführungsumgebung 302 errichtet und/oder ausgeführt werden.
  • Die anschauliche Umgebung 300 enthält ferner ein Anonyme-Bedrohungsanalyse-(ATA) Modul 304, ein Authentifizierungsmodul 306, ein Kontextmodul 308, ein Anonyme Bedrohungsanalyse-Schnittstellenmodul 310, ein Sicherheitsmodul 312 und ein Kommunikationsmodul 314. Die verschiedenen Module der Umgebung 300 können als Hardware, Software, Firmware oder eine Kombination davon verkörpert sein. Zum Beispiel können die verschiedenen Module, logischen und anderen Komponenten der Umgebung 300 einen Teil des Prozessors 210 oder anderer Hardware-Komponenten der Client-Vorrichtung 102 bilden oder aber durch diese etabliert sein. Als solches können in einigen Ausführungsformen ein oder mehrere der Module der Umgebung 300 als eine Schaltung oder Sammlung elektrischer Vorrichtungen (z.B. eine vertrauenswürdige Ausführungsumgebungsschaltung, eine ATA-Schaltung, eine Authentifizierungsschaltung, eine Kontextschaltung, eine ATA-Schnittstellenschaltung und/oder eine Kommunikationsschaltung) verkörpert sein. Zusätzlich können in einigen Ausführungsformen ein oder mehrere der anschaulichen Module Teil eines anderen Moduls bilden und/oder eines oder mehrere der anschaulichen Module können voneinander unabhängig sein.
  • Das ATA-Modul 304 ist zum „Ausblenden“ oder Anonymisieren von Bedrohungsinformationen konfiguriert, die an die entsprechenden Server 106 gesendet werden, indem kryptografische kenntnisfreie Zusagen erstellt werden. Insbesondere kann das ATA-Modul 304 Sensordaten empfangen, die von den Sensoren 220 der Client-Vorrichtung 102 (z.B. Hardware und/oder Software Sensoren) generiert werden, und eine Bestätigungsangabe erstellen, die anonymisierte oder andersartig verschleierte Attribute der Client-Vorrichtung 102 enthält, wie auf der Basis der Sensordaten bestimmt. Zum Beispiel kann das ATA-Modul 304 in einigen Ausführungsformen einen kenntnisfreien Wissensbeweis (ZKPK) generieren, dass die Anzahl böswilliger Hashes, die von der Client-Vorrichtung 102 identifiziert wurden, in einem Bereich von 50-100 Hashes liegt. Dabei sollte offensichtlich sein, dass das ATA-Modul 304 Sicherheitsinformationen enthüllen kann, ohne Einzelheiten bezüglich der exakten Anzahl und/oder des Namens des verdächtigen Hash zu liefern. Wie in der Folge beschrieben, kann das ATA-Modul 304 Anfragen oder Aufforderungen bezüglich der Attribute der Client-Vorrichtung 102 empfangen (z.B. eine Anfrage nach einem Beweis, dass die Attribute eine Gemeinsamkeit haben oder mit Attributen überlappen, die in einem Verweis- oder Aufforderungsprofil des entsprechenden Servers 106 identifiziert sind) Wie oben angegeben, kann das ATA-Modul 304 in einigen Ausführungsformen in der vertrauenswürdigen Ausführungsumgebung 302 errichtet werden. Ferner kann das ATA-Modul 304 in einigen Ausführungsformen eine Sicherheitsstrategie 318 beim Generieren der Bestätigungsangabe verwenden. Die Sicherheitsstrategie 318 kann zum Beispiel identifizieren, welche Attribute in der Bestätigungsangabe enthalten sein sollten und/oder welche Sensoren zum Bestimmen der Attribute verwendet werden sollten (z.B. nur Hardware-Sensoren). Es sollte offensichtlich sein, dass das ATA-Modul 304 kenntnisfreie Beweise und/oder Zusagen auf der Basis einer geeigneten Technologie generieren kann. Zum Beispiel kann das ATA-Modul 304 in verschiedenen Ausführungsformen eine Enhanced Privacy Identification(EPID)-Technologie, U-Prove-Technologie und/oder Identity Mixer(IDEMIX)-Technologie verwenden.
  • In einigen Ausführungsformen kann das ATA-Modul 304 eine Bestätigungsangabe auf der Basis von Sensordaten generieren, die durch das Authentifizierungsmodul 306 und/oder das Kontextmodul 308 generiert wurden. Das Authentifizierungsmodul 306 ist konfiguriert, eine Anwender- und/oder Vorrichtungsauthentifizierung zu bearbeiten. Daher kann das Authentifizierungsmodul 306 dem ATA-Modul 304 sämtliche Daten bereitstellen, die mit der Authentifizierung verknüpft sind, die nützlich sein können, die hier beschriebenen Funktionen durchzuführen. In einigen Ausführungsformen kann das Authentifizierungsmodul 306 einen Teil der Authentifizierungsmaschine 224 bilden oder durch diese ausgeführt werden.
  • Das Kontextmodul 308 kann den Kontext der Client-Vorrichtung 102 auf der Basis, zum Beispiel von Sensordaten bestimmen, die durch die Sensoren 220 (z.B. Hardware- und/oder Software-Sensoren), die Authentifizierungsmaschine 224 generiert werden und/oder anderen geeigneten Daten der Client-Vorrichtung 102 bestimmen. Dabei kann das Kontextmodul 308 den Hardware- und/oder Software-Zustand (z.B. Anwendungsausführungszustand) der Client-Vorrichtung 102 zu einem bestimmten Zeitpunkt bestimmen. Zum Beispiel kann das Kontextmodul 308 in einigen Ausführungsformen eine Stelle der Client-Vorrichtung 102, den Netzwerk-Konnektivitätszustand, Anwendungsdaten, Netzwerkbandbreite, verfügbaren Speicher (z.B. im Speicher 214 und/oder Datenspeicher 216), die aktuelle Zeit, Vorrichtungskapazitäten, Ausführungsanwendungen 316 und/oder andere Eigenschaften der Client-Vorrichtung 102 bestimmen. In einigen Ausführungsformen kann das Kontextmodul 308 Teil der Kontextmaschine 226 sein oder durch diese ausgeführt werden.
  • Das ATA-Schnittstellenmodul 310 ist konfiguriert, ATA-Anfragen und/oder andere Daten zu empfangen und diese Informationen zum ATA-Modul 304 weiterzuleiten (z.B. Ausführung in der vertrauenswürdigen Ausführungsumgebung 302). Zum Beispiel kann das ATA-Schnittstellenmodul 310 ATA/ZKP-Aufforderungen und/oder andere geeignete Anfragen vom Server 106 empfangen und diese Anfragen zum ATA-Modul 304 weiterleiten. Ebenso kann das ATA-Schnittstellenmodul 310 Daten vom ATA-Modul 304 empfangen (z.B. Bestätigungsangaben, ZKP-Zusagen, vertrauenswürdige Ausführungsumgebung-Unterschriftenbestätigungen usw.) empfangen und diese Informationen an einen entsprechenden Server 106 oder eine andere ferne Vorrichtung (z.B. über das Kommunikationsmodul 314) senden. Zusätzlich kann das ATA-Schnittstellenmodul 310 Daten vom Sicherheitsmodul 312 und/oder den Anwendungen 316 (z.B. Software-Sensordaten) zur Analyse durch das ATA-Modul 304 empfangen. In einigen Ausführungsformen sollte offensichtlich sein, dass das ATA-Schnittstellenmodul 310 als ATA-Agent dienen kann (z.B. Software, die auf einem Betriebssystem der Client-Vorrichtung 102 ausgeführt wird), der konfiguriert ist, mit einem Hardware-basierten ATA-Modul 304 zu interagieren.
  • Das Sicherheitsmodul 312 ist konfiguriert, sicherheitsbezogene Funktionen seitens der Client-Vorrichtung 102 durchzuführen. In einigen Ausführungsformen kann das Sicherheitsmodul 312 ein Host Intrusion Prevention System (HIPS) enthalten, das konfiguriert ist, unautorisierte Zugriffsversuche auf die Client-Vorrichtung 102 und/oder eine besondere Hardware- oder Software-Komponente der Client-Vorrichtung 102 zu detektieren und/oder zu verhindern. Ferner kann das Sicherheitsmodul 312 in einigen Ausführungsformen einen Anti-Virusagenten enthalten, der konfiguriert ist, Daten der Client-Vorrichtung 102 zu analysieren und Viren, Malware und/oder anderen verdächtigen Inhalt zu detektieren, der auf der Client-Vorrichtung 102 gespeichert ist. Es sollte offensichtlich sein, dass das Sicherheitsmodul 312 konfiguriert sein kann, auf Hardware, Firmware und/oder Software beruhende Sicherheitsmaßnahmen, abhängig von der besonderen Ausführungsform, zu implementieren. In anderen Ausführungsformen kann das Sicherheitsmodul 312 konfiguriert sein, auf Software beruhende Sicherheitsfunktionen zu implementieren, während die Sicherheitsmaschine 222 konfiguriert sein kann, auf Hardware und Firmware beruhende Sicherheitsfunktionen zu implementieren.
  • Das Kommunikationsmodul 314 bewältigt die Kommunikation zwischen der Client-Vorrichtung 102 und anderen Rechenvorrichtungen des Systems 100 (z.B. dem entsprechenden Server 106). Zum Beispiel kann die Client-Vorrichtung 102, wie hier beschrieben, Bestätigungsangaben und/oder ZKPK-Beweise/Zusagen an den entsprechenden Server 106 über das entsprechende Netzwerk 104 senden.
  • Unter Bezugnahme nun auf 4 können eine oder mehrere der Client-Vorrichtungen 102 in Verwendung ein Verfahren 400 für eine anonyme Kontext-/Bedrohungsbestätigung und Bedrohungsanalyse ausführen. Das anschauliche Verfahren 400 beginnt mit Block 402, in dem die Client-Vorrichtung 102 bestimmt, ob eine Bestätigung einer anonymen Bedrohung durchzuführen ist. Falls zutreffend, empfängt die Client-Vorrichtung 102 in Block 404 Sensordaten, die von den Sensoren 220 generiert werden. Wie oben besprochen, sind die Sensoren 220 konfiguriert, Daten/Signale zu generieren, die eine Umgebung oder einen Kontext der Client-Vorrichtung 102 und/oder des Anwenders der Client-Vorrichtung 102 angeben. Insbesondere kann die Client-Vorrichtung 102 in Block 406 Hardware-Sensordaten empfangen, die durch einen oder mehrere Hardware-Sensor(en) der Client-Vorrichtung 102 generiert werden. Zum Beispiel kann die Client-Vorrichtung 102 Daten empfangen, die eine Stelle der Client-Vorrichtung 102, einen Hardware-Zustand einer oder mehrerer Komponente(n) der Client-Vorrichtung 102, eine physische Umgebung der Client-Vorrichtung 102 und/oder andere Merkmale, Parameter und Eigenschaften angeben, die zur Durchführung der hier beschriebenen Funktionen geeignet sind. Ferner kann die Client-Vorrichtung 102 in Block 408 Sensordaten von einer oder mehreren Software-Anwendung(en) 316 und/oder andere Software-Sensordaten empfangen. Zum Beispiel kann die Client-Vorrichtung 102 Daten, die einen Ausführungszustand einer besonderen Software-Anwendung 316 anzeigen, Ergebnisse einer Anwendungsausführung und/oder andere Software-Daten (z.B. Software-basierte Host Intrusion Prevention Systeme und/oder Software-basierte Anti-Virussysteme) empfangen, die für die Durchführung der hier beschriebenen Funktionen geeignet sind. Ferner kann die Client-Vorrichtung 102 in einigen Ausführungsformen Sensor- und/oder andere Daten empfangen, die durch die Authentifizierungsmaschine 224 und/oder die Kontextmaschine 226 generiert werden. Es sollte offensichtlich sein, dass die Client-Vorrichtung 102 die Sensordaten analysieren kann, um verschiedene Attribute der Client-Vorrichtung 102 zu bestimmen.
  • In Block 410 generiert die Client-Vorrichtung 102 eine Bestätigungsangabe auf der Basis der empfangenen Sensordaten und/oder der Sicherheitsstrategie 318 der Client-Vorrichtung 102 (siehe z.B. Ablauf 602 von 6). In einigen Ausführungsformen, in Block 412, sollte offensichtlich sein, dass die Bestätigungsangabe durch die (oder innerhalb der) vertrauenswürdige(n) Ausführungsumgebung 302 der Client-Vorrichtung 102 generiert werden kann. Ferner kann die Client-Vorrichtung 102, wie oben beschrieben, die Attribute, die in der Bestätigungsangabe enthalten sind, in Block 414 verschleiern. Das heißt, wie oben angegeben, die anschauliche Bestätigungsangabe enthält Attribute der Client-Vorrichtung 102, die verschleiert wurden, um eine Anonymität beizubehalten (z.B. ausgedrückt als ein Bereich von Werten, sodass der tatsächliche Wert des entsprechenden Attributs in diesen Bereich fällt).
  • In Block 416 generiert die Client-Vorrichtung 102 eine kenntnisfreie Zusage der Bestätigungsangabe und sendet die kenntnisfreie Zusage an den entsprechenden Server 106 (siehe z.B. Ablauf 604 von 6). Wie oben angegeben, kann in Block 418 die kenntnisfreie Zusage durch die (oder innerhalb der) vertrauenswürdige(n) Ausführungsumgebung 302 der Client-Vorrichtung 102 generiert werden. Es sollte offensichtlich sein, dass die Client-Vorrichtung 102 jede geeignete Technik zum Generieren von Bestätigungsangaben und Verwenden kenntnisfreier Beweise und Zusagen verwenden kann. Zum Beispiel kann die Client-Vorrichtung 102 in einigen Ausführungsformen eine oder mehrere von einer direkten anonymen Bestätigung, Enhanced Privacy Identification (EPID), U-Prove und/oder Identity Mixer (IDEMIX) verwenden. Natürlich kann die Client-Vorrichtung 102 in anderen Ausführungsformen andere geeignete Techniken verwenden. In einigen Ausführungsformen kann die Zusage der Bestätigungsangabe kryptografisch unterzeichnet sein (z.B. durch einen privaten kryptografischen Schlüssel der Client-Vorrichtung 102). Ferner können in einigen Ausführungsformen die Bestätigungsangaben und kenntnisfreien Beweise/Zusagen anonymisiert sein, sodass der Server 106 die exakte Identität der Client-Vorrichtung 102 nicht bestätigen kann (z.B. aufgrund einer anonymen Bestätigung).
  • In Block 420 bestimmt die Client-Vorrichtung 102, ob eine Aufforderung vom Server 106 empfangen wurde. Wie oben angegeben, kann die Aufforderung zum Beispiel eine Bestimmung von der Client-Vorrichtung 102 verlangen, ob die verschleierten Attribute, die in der Bestätigungsangabe identifiziert wurden, überlappen oder Gemeinsamkeit mit Attributen haben, die in der Aufforderung identifiziert wurden (z.B. in einem „Aufforderungsprofil“ oder Anfälligkeitsprofil). Falls keine Aufforderung empfangen wurde, kehrt das Verfahren 400 zu Block 420 zurück und wartet auf dem Empfang einer Aufforderung oder anderen Anfrage. Falls die Client-Vorrichtung 102 eine Aufforderung empfängt, kann die Client-Vorrichtung 102 die Sensordaten oder insbesondere die Attribute der Client-Vorrichtung 102 auf der Basis der empfangenen Aufforderung analysieren. Zum Beispiel kann die Client-Vorrichtung 102 bestimmen, ob die verschleierten Attribute der Client-Vorrichtung 102 (z.B. ein Bereich von Werten) Gemeinsamkeit mit den Aufforderungsprofilattributen haben oder aber überlappen.
  • In Block 424 generiert die Client-Vorrichtung 102 eine Antwort auf die empfangene Aufforderung und sendet die Aufforderungsantwort an den Server 106. Natürlich sollte offensichtlich sein, dass in einigen Ausführungsformen die Aufforderung eine Anfrage sein kann, die Authentizität der Unterschrift auf der Bestätigungsangabe zu beweisen (siehe z.B. Ablauf 606 von 6). In solchen Ausführungsformen kann die Client-Vorrichtung 102 auf die Aufforderung in Block 426 antworten, indem sie einen auf TEE beruhenden Beweis der Unterschrift (z.B. durch die vertrauenswürdige Ausführungsumgebung 302) bereitstellt, und kann dies ohne Analyse der Sensordaten und/oder der Parameter der Client-Vorrichtung 102 machen (siehe z.B. Ablauf 608 von 6). Das heißt, in einigen Ausführungsformen kann der Server 106 verifizieren, dass die Unterschrift der Bestätigungsangabe authentisch ist, bevor weitere Informationen von der Client-Vorrichtung 102 angefragt werden (z.B. vor dem Senden der Aufforderungen bezüglich der anonymisierten und verschleierten Attribute).
  • In anderen Ausführungsformen kann die Aufforderung eine Bestimmung von der Client-Vorrichtung 102 anfragen, ob die verschleierten Attribute, die in der Bestätigungsangabe identifiziert werden, überlappen oder eine Gemeinsamkeit mit Attributen haben, die in der Aufforderung identifiziert werden, wie oben angegeben (siehe z.B. Ablauf 622 von 6). In solchen Ausführungsformen kann die Client-Vorrichtung 102 einen kenntnisfreien Beweis generieren, der die Gemeinsamkeit oder Überlappung, falls vorhanden, zwischen den verschleierten Attributen der Client-Vorrichtung 102 und dem Aufforderungsprofil angibt, und den kenntnisfreien Beweis an den Server 106 in Block 428 senden (siehe z.B. Ablauf 624 von 6). Zum Beispiel kann die Client-Vorrichtung 102 in einigen Ausführungsformen bestimmen, ob ein verschleierter Bereich eines Attributwertes der Client-Vorrichtung 102 ein Teilsatz eines Bereichs ist, der durch das Aufforderungsprofil definiert ist. In anderen Ausführungsformen kann die Client-Vorrichtung 102 bestimmen, ob ein verschleiertes Attribut der Client-Vorrichtung 102 ein verschleiertes Attribut einer anderen Client-Vorrichtung 102 des Systems 100 (z.B. einer anderen Client-Vorrichtung 102 innerhalb desselben Netzwerks 104 des entsprechenden Servers 106) überlappt (z.B. ein Teilsatz desselben ist oder diesen irgendwie schneidet). Es sollte offensichtlich sein, dass die besonderen analysierten Attribute zum Beispiel eine Anzahl von identifizierten Vorkommnissen eines besonderen böswilligen Hash, eine Anzahl von detektieren Snoop-Angriffen und/oder eine Anzahl von Angriffen enthalten können, die von einer besonderen geografischen Stelle empfangen werden; die verwendeten Attribute können jedoch abhängig von der Ausführungsform stark variieren.
  • Das anschauliche Verfahren 400 kehrt zu Block 420 zurück, in dem die Client-Vorrichtung 102 auf dem Empfang einer weiteren Aufforderung vom Server 106 wartet (z.B. eine weitere Anfrage zum Vergleichen der verschleierten Attribute mit einem anderen Attributprofil). Es sollte offensichtlich sein, dass die Client-Vorrichtung 102 in einigen Ausführungsformen periodisch oder gelegentlich die Attribute auf der Basis aktueller Sensordaten aktualisieren und eine neue Bestätigungsangabe auf der Basis der aktualisierten Daten regenerieren/senden kann.
  • Unter Bezugnahme nun auf 5 können in Verwendung einer oder mehrere der Server 106 ein Verfahren 500 zur anonymen Kontext-/Bedrohungsbestätigung und Bedrohungsanalyse ausführen. Das anschauliche Verfahren 500 beginnt mit Block 502, in dem der Server 106 eine Bestätigungsangabe von einer der Client-Vorrichtungen 102 (z.B. einer Client-Vorrichtung 102 innerhalb des Netzwerks 104 des Servers 106) anfragen kann. In anderen Ausführungsformen kann die Client-Vorrichtung 102 konfiguriert sein, die Bestätigungsangaben an den Server 106 zu senden, ohne zuvor eine Anfrage vom Server 106 zu empfangen (z.B. periodisch, gelegentlich, als Antwort auf eine gewisse Bedingung oder auf andere Weise).
  • In Block 504 empfängt der Server 106 eine Zusage der Bestätigungsangabe von der Client-Vorrichtung 102 wie oben beschrieben. In Block 506 verifiziert der Server 106 die Zusage der Bestätigungsangabe, die von der Client-Vorrichtung 102 empfangen wurde. In einigen Ausführungsformen kann der Server 106 dazu die Client-Vorrichtung 102 auffordern, die Authentizität der Unterschrift auf der Bestätigungsangabe zu beweisen, und, wie oben angegeben, die Client-Vorrichtung 102 kann mit einem auf TEE beruhenden Beweis der Unterschrift antworten, den der Server 106 bestätigen kann.
  • In Block 508 sendet der Server 106 eine oder mehrere Aufforderung(en) zum Server 106 für einen Beweis der Gemeinsamkeit, falls vorhanden, der Attribute der Client-Vorrichtung 102 mit Attributen eines Aufforderungsprofils oder mehrerer Aufforderungsprofile, die durch den Server 106 identifiziert wurden (z.B. Attributprofile, mit welchen die Client-Vorrichtung 102 auf Wunsch des Servers 106 die Client-Attribute vergleichen soll). Wie oben angegeben, bestimmt die Client-Vorrichtung 102, ob eine Gemeinsamkeit oder Überlappung mit dem (den) Aufforderungsprofil(en) vorliegt, und antwortet mit einem kenntnisfreien Beweis der Überlappung. Als solches empfängt der Server 106 in Block 510 die Aufforderungsantwort(en) von der Client-Vorrichtung 102.
  • In Block 512 bestimmt der Server 106, ob eine oder mehrere Aufforderung(en) an eine andere Client-Vorrichtung 102 (z.B. eine andere Client-Vorrichtung 102 im Netzwerk 104 des Servers 106) zu senden ist (sind), die in Verbindung mit den Informationen analysiert werden soll(en), die in den kenntnisfreien Beweisen der Client-Vorrichtung 102 in Block 510 empfangen wurden. Falls zutreffend, kehrt das Verfahren 500 zu Block 502 zurück, in dem der Server 106 eine Bestätigungsangabe von dieser Client-Vorrichtung 102 anfragen kann (siehe z.B. Abläufe 614-618 und 626-628 von 6). Natürlich können die Client-Vorrichtungen 102, wie oben angegeben, in einigen Ausführungsformen automatisch die Bestätigungsangaben an den Server 106 senden. Als solches sollte offensichtlich sein, dass der Server 106 mit einer oder mehreren der Client-Vorrichtungen 102 in einigen Ausführungsformen parallel kommunizieren kann.
  • Falls der Server 106 bestimmt, keine zusätzlichen Informationen von anderen Client-Vorrichtungen 102 anzufragen, fährt das Verfahren 500 mit Block 516 fort, in dem der Server 106 die Aufforderungsantworten analysieren kann, um gemeinsame Attribute zwischen den Client-Vorrichtungen 102 abzuleiten (siehe z.B. Ablauf 630 von 6). Dabei kann der Server 106 in einigen Ausfiihrungsformen imstande sein, netzwerkweite Sicherheitsrisiken abzuleiten. Ferner kann der Server 106 in Block 518 die Aufforderungsantworten und/oder sämtliche Ableitungen, die durch den Server 106 bestimmt werden, an den Root-Server 110 zur weiteren Analyse senden. Ferner kann der Server 106, wie oben angegeben, kenntnisfreie Beweise der Aufforderungsantworten und/oder Ableiten generieren und die kenntnisfreien Beweise an den Root-Server 110 senden. Auf diese Weise kann der Server 106 auch deren Anonymität bewahren, während Sicherheitsdaten geteilt werden, die zum Bewerten der systemweiten Sicherheit günstig sein können. Es sollte offensichtlich sein, dass der Root-Server 110 in einigen Ausführungsformen die vom Server 106 von verschiedenen Organisationen empfangenen Beweise verifizieren und die enthaltenden Daten analysieren kann, um zum Beispiel organisationsübergreifende Sicherheitsbedrohungen zu bewerten. Zum Beispiel kann der Root-Server 110 in einer Ausführungsform ableiten. Ob die Angriffsstellen für zwei Client-Vorrichtungen 102 innerhalb derselben Nachbarschaft (z.B. Land, Staat, Nähe usw.) liegen.
  • BEISPIELE
  • Anschauliche Beispiele der hier offenbarten Technologien sind unten angeführt. Eine Ausführungsform der Technologien kann eines oder mehrere und jede Kombination der unten beschriebenen Beispiele enthalten.
  • Beispiel 1 enthält eine Rechenvorrichtung zur anonymen Kontextbestätigung und Bedrohungsanalyse, wobei die Rechenvorrichtung ein Anonyme-Bedrohung-Analysemodul umfasst zum (i) Empfangen von Sensordaten, die durch einen oder mehrere Sensor(en) der Rechenvorrichtung generiert wurden, und (ii) Generieren einer Bestätigungsangabe auf der Basis der Sensordaten, wobei die Bestätigungsangabe verschleierte Attribute der Rechenvorrichtung auf der Basis der Sensordaten enthält; sowie ein Kommunikationsmodul zum (i) Senden einer kenntnisfreien Zusage der Bestätigungsangabe an einen Server und (ii) Empfangen einer Aufforderung vom Server als Antwort auf das Senden der kenntnisfreien Zusage, wobei die Aufforderung eine Angabe verlangt, ob die verschleierten Attribute der Rechenvorrichtung Gemeinsamkeit mit Attributen haben, die in einem Aufforderungsprofil identifiziert wurden, das mit der Aufforderung empfangen wurde; wobei das Anonyme-Bedrohung-Analysemodul ferner zum Generieren eines kenntnisfreien Beweises dient, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  • Beispiel 2 enthält den Gegenstand von Beispiel 1 und wobei das Empfangen der Sensordaten ein Empfangen von Sensordaten umfasst, die durch einen oder mehrere Hardware-Sensor(en) der Rechenvorrichtung generiert werden.
  • Beispiel 3 enthält den Gegenstand eines der Beispiele 1 und 2 und wobei das Empfangen der Sensordaten, die durch einen oder mehrere Hardware-Sensor(en) generiert werden, ein Empfangen von Sensordaten umfasst, die durch zumindest eine von einer Authentifizierungsmaschine oder einer Kontextmaschine der Rechenvorrichtung generiert werden.
  • Beispiel 4 enthält den Gegenstand eines der Beispiele 1-3 und wobei das Empfangen der Sensordaten ein Empfangen von Sensordaten von einer oder mehreren Software-Anwendung(en) umfasst.
  • Beispiel 5 enthält den Gegenstand eines der Beispiele 1-4 und wobei das Empfangen der Sensordaten von der einen oder den mehreren Software-Anwendung(en) ein Empfangen von Sensordaten von zumindest einem von einem Host Intrusion Prevention System oder einem Anti-Virusagent umfasst.
  • Beispiel 6 enthält den Gegenstand eines der Beispiele 1-5 und wobei die verschleierten Attribute ein als Bereich angegebenes Attribut umfassen, wobei ein tatsächlicher Wert des entsprechenden Attributs innerhalb des Bereichs liegt.
  • Beispiel 7 enthält den Gegenstand eines der Beispiele 1-6 und wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung umfasst.
  • Beispiel 8 enthält den Gegenstand eines der Beispiele 1-7 und ferner enthaltend eine Sicherheitsmaschine zum Etablieren der vertrauenswürdigen Ausführungsumgebung.
  • Beispiel 9 enthält den Gegenstand eines der Beispiele 1-8 und wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe auf der Basis der Sensordaten und einer Sicherheitsstrategie umfasst.
  • Beispiel 10 enthält den Gegenstand eines der Beispiele 1-9 und wobei die Sicherheitsstrategie zumindest eines der Attribute identifiziert, das in der Bestätigungsangabe oder den Sensordaten enthalten sein soll, um zum Bestimmen der Attribute verwendet zu werden.
  • Beispiel 11 enthält den Gegenstand eines der Beispiele 1-10 und wobei das Generieren der kenntnisfreien Zusage ein Generieren einer kenntnisfreien Zusage auf der Basis zumindest einer aus Enhanced Privacy Identification(EPID)-Technologie, U-Prove-Technologie oder Identity Mixer (IDEMIX)-Technologie umfasst.
  • Beispiel 12 enthält den Gegenstand eines der Beispiele 1-11 und wobei das Anonyme-Bedrohung-Analysemodul ferner einen Beweis einer Unterschrift der Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung in Antwort auf ein Empfangen einer Aufforderung bezüglich eines Beweises der Unterschrift generieren soll.
  • Beispiel 13 enthält den Gegenstand eines der Beispiele 1-12 und wobei das Anonyme-Bedrohung-Analysemodul ferner die verschleierten Attribute der Rechenvorrichtung auf der Basis der vom Server empfangenen Aufforderung analysieren soll.
  • Beispiel 14 enthält den Gegenstand eines der Beispiele 1-13 und wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, eine Bestimmung umfasst, ob ein verschleierter Bereich eines Attributwertes der Rechenvorrichtung ein Teilsatz eines Bereichs ist, der durch das Aufforderungsprofil definiert ist.
  • Beispiel 15 enthält den Gegenstand eines der Beispiele 1-14 und wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, eine Bestimmung umfasst, ob ein verschleiertes Attribut der Rechenvorrichtung mit einem verschleierten Attribut einer anderen Rechenvorrichtung überlappt.
  • Beispiel 16 enthält den Gegenstand eines der Beispiele 1-15 und wobei das Generieren des kenntnisfreien Beweises ein Generieren des kenntnisfreien Beweises in Antwort auf eine Bestimmung umfasst, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  • Beispiel 17 enthält ein Verfahren zur anonymen Kontextbestätigung und Bedrohungsanalyse, das Verfahren umfassend ein Empfangen, durch eine Rechenvorrichtung, von Sensordaten, die durch einen oder mehrere Sensor(en) der Rechenvorrichtung generiert werden; ein Generieren, durch die Rechenvorrichtung, einer Bestätigungsangabe auf der Basis der Sensordaten, wobei die Bestätigungsangabe verschleierte Attribute der Rechenvorrichtung auf der Basis der Sensordaten enthält; ein Senden, durch die Rechenvorrichtung, einer kenntnisfreien Zusage der Bestätigungsangabe an einen Server; ein Empfangen, durch die Rechenvorrichtung, einer Aufforderung vom Server in Antwort auf das Senden der kenntnisfreien Zusage, wobei die Aufforderung eine Angabe verlangt, ob die verschleierten Attribute der Rechenvorrichtung Gemeinsamkeit mit Attributen haben, die in einem Aufforderungsprofil identifiziert wurden, das mit der Aufforderung empfangen wurde; und Generieren, durch die Rechenvorrichtung, eines kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  • Beispiel 18 enthält den Gegenstand von Beispiel 17 und wobei das Empfangen der Sensordaten ein Empfangen von Sensordaten umfasst, die durch einen oder mehrere Hardware-Sensor(en) der Rechenvorrichtung generiert werden.
  • Beispiel 19 enthält den Gegenstand eines der Beispiele 17 und 18 und wobei das Empfangen der Sensordaten, die durch einen oder mehrere Hardware-Sensor(en) generiert werden, ein Empfangen von Sensordaten umfasst, die durch zumindest eine von einer Authentifizierungsmaschine oder einer Kontextmaschine der Rechenvorrichtung generiert werden.
  • Beispiel 20 enthält den Gegenstand eines der Beispiele 17-19 und wobei das Empfangen der Sensordaten ein Empfangen von Sensordaten von einer oder mehreren Software-Anwendung(en) umfasst.
  • Beispiel 21 enthält den Gegenstand eines der Beispiele 17-20 und wobei das Empfangen der Sensordaten von der einen oder den mehreren Software-Anwendung(en) ein Empfangen von Sensordaten von zumindest einem von einem Host Intrusion Prevention System oder einem Anti-Virusagent umfasst.
  • Beispiel 22 enthält den Gegenstand eines der Beispiele 17-21 und wobei die verschleierten Attribute ein als Bereich angegebenes Attribut umfassen, wobei ein tatsächlicher Wert des entsprechenden Attributs innerhalb des Bereichs liegt.
  • Beispiel 23 enthält den Gegenstand eines der Beispiele 17-22 und wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung umfasst.
  • Beispiel 24 enthält den Gegenstand eines der Beispiele 17-23 und wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe auf der Basis der Sensordaten und einer Sicherheitsstrategie umfasst.
  • Beispiel 25 enthält den Gegenstand eines der Beispiele 17-24 und wobei die Sicherheitsstrategie zumindest eines der Attribute identifiziert, das in der Bestätigungsangabe oder den Sensordaten enthalten sein soll, um zum Bestimmen der Attribute verwendet zu werden.
  • Beispiel 26 enthält den Gegenstand eines der Beispiele 17-25 und wobei das Generieren der kenntnisfreien Zusage ein Generieren einer kenntnisfreien Zusage auf der Basis zumindest einer aus Enhanced Privacy Identification(EPID)-Technologie, U-Prove-Technologie oder Identity Mixer (IDEMIX)-Technologie umfasst.
  • Beispiel 27 enthält den Gegenstand eines der Beispiele 17-26 und enthält ferner ein Generieren, durch die Rechenvorrichtung, eines Beweises einer Unterschrift der Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung in Antwort auf ein Empfangen einer Aufforderung bezüglich eines Beweises der Unterschrift.
  • Beispiel 28 enthält den Gegenstand eines der Beispiele 17-27 und enthält ferner ein Analysieren, durch die Rechenvorrichtung, der verschleierten Attribute der Rechenvorrichtung auf der Basis der vom Server empfangenen Aufforderung.
  • Beispiel 29 enthält den Gegenstand eines der Beispiele 17-28 und wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, ein Bestimmen umfasst, ob ein verschleierter Bereich eines Attributwertes der Rechenvorrichtung ein Teilsatz eines Bereichs ist, der durch das Aufforderungsprofil definiert ist.
  • Beispiel 30 enthält den Gegenstand eines der Beispiele 17-29 und wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, ein Bestimmen umfasst, ob ein verschleiertes Attribut der Rechenvorrichtung mit einem verschleierten Attribut einer anderen Rechenvorrichtung überlappt.
  • Beispiel 31 enthält den Gegenstand eines der Beispiele 17-30 und wobei das Generieren des kenntnisfreien Beweises ein Generieren des kenntnisfreien Beweises in Antwort auf ein Bestimmen umfasst, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  • Beispiel 32 enthält eine Rechenvorrichtung, die einen Prozessor umfasst; und einen Speicher, auf dem mehrere Anweisungen gespeichert sind, die bei Ausführung durch den Prozessor die Rechenvorrichtung veranlassen, das Verfahren eines der Beispiele 17-31 durchzuführen.
  • Beispiel 33 enthält ein maschinenlesbares Speichermedium oder mehrere maschinenlesbare Speichermedien, auf welchen mehrere Anweisungen gespeichert sind, die in Antwort auf ihre Ausführung dazu führen, dass eine Rechenvorrichtung das Verfahren eines der Beispiele 17-31 durchführt.
  • Beispiel 34 enthält eine Rechenvorrichtung, die Mittel zum Durchführen des Verfahrens eines der Beispiele 17-31 umfasst.
  • Beispiel 35 enthält eine Rechenvorrichtung zur anonymen Kontextbestätigung und Bedrohungsanalyse, wobei die Rechenvorrichtung Mittel zum Empfangen von Sensordaten, die durch einen oder mehrere Sensor(en) der Rechenvorrichtung generiert werden; Mittel zum Generieren einer Bestätigungsangabe auf der Basis der Sensordaten, wobei die Bestätigungsangabe verschleierte Attribute der Rechenvorrichtung auf der Basis der Sensordaten enthält; Mittel zum Senden einer kenntnisfreien Zusage der Bestätigungsangabe an einen Server; Mittel zum Empfangen einer Aufforderung vom Server in Antwort auf das Senden der kenntnisfreien Zusage, wobei die Aufforderung eine Angabe verlangt, ob die verschleierten Attribute der Rechenvorrichtung Gemeinsamkeit mit Attributen haben, die in einem Aufforderungsprofil identifiziert wurden, das mit der Aufforderung empfangen wurde; und Mittel zum Generieren eines kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, umfasst.
  • Beispiel 36 enthält den Gegenstand von Beispiel 35 und wobei das Mittel zum Empfangen der Sensordaten Mittel zum Empfangen von Sensordaten umfasst, die durch einen oder mehrere Hardware-Sensor(en) der Rechenvorrichtung generiert werden.
  • Beispiel 37 enthält den Gegenstand eines der Beispiele 35 und 36 und wobei das Mittel zum Empfangen der Sensordaten, die durch einen oder mehrere Hardware-Sensor(en) generiert werden, Mittel zum Empfangen von Sensordaten umfasst, die durch zumindest eine von einer Authentifizierungsmaschine oder einer Kontextmaschine der Rechenvorrichtung generiert werden.
  • Beispiel 38 enthält den Gegenstand eines der Beispiele 35-37 und wobei das Mittel zum Empfangen der Sensordaten Mittel zum Empfangen von Sensordaten von einer oder mehreren Software-Anwendung(en) umfasst.
  • Beispiel 39 enthält den Gegenstand eines der Beispiele 35-38 und wobei das Mittel zum Empfangen der Sensordaten von der einen oder den mehreren Software-Anwendung(en) Mittel zum Empfangen von Sensordaten von zumindest einem von einem Host Intrusion Prevention System oder einem Anti-Virusagent umfasst.
  • Beispiel 40 enthält den Gegenstand eines der Beispiele 35-39 und wobei die verschleierten Attribute ein als Bereich angegebenes Attribut umfassen, wobei ein tatsächlicher Wert des entsprechenden Attributs innerhalb des Bereichs liegt.
  • Beispiel 41 enthält den Gegenstand eines der Beispiele 35-40 und wobei das Mittel zum Generieren der Bestätigungsangabe Mittel zum Generieren einer Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung umfasst.
  • Beispiel 42 enthält den Gegenstand eines der Beispiele 35-41 und wobei das Mittel zum Generieren der Bestätigungsangabe Mittel zum Generieren einer Bestätigungsangabe auf der Basis der Sensordaten und einer Sicherheitsstrategie umfasst.
  • Beispiel 43 enthält den Gegenstand eines der Beispiele 35-42 und wobei die Sicherheitsstrategie zumindest eines der Attribute identifiziert, das in der Bestätigungsangabe oder den Sensordaten enthalten sein soll, um zum Bestimmen der Attribute verwendet zu werden.
  • Beispiel 44 enthält den Gegenstand eines der Beispiele 35-43 und wobei das Mittel zum Generieren der kenntnisfreien Zusage Mittel zum Generieren einer kenntnisfreien Zusage auf der Basis zumindest einer aus Enhanced Privacy Identification(EPID)-Technologie, U-Prove-Technologie oder Identity Mixer(IDEMIX)-Technologie umfasst.
  • Beispiel 45 enthält den Gegenstand eines der Beispiele 35-44 und enthält ferner Mittel zum Generieren eines Beweises einer Unterschrift der Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung in Antwort auf ein Empfangen einer Aufforderung bezüglich eines Beweises der Unterschrift.
  • Beispiel 46 enthält den Gegenstand eines der Beispiele 35-45 und enthält ferner Mittel zum Analysieren der verschleierten Attribute der Rechenvorrichtung auf der Basis der vom Server empfangenen Aufforderung.
  • Beispiel 47 enthält den Gegenstand eines der Beispiele 35-46 und wobei das Mittel zum Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, Mittel zum Bestimmen umfasst, ob ein verschleierter Bereich eines Attributwertes der Rechenvorrichtung ein Teilsatz eines Bereichs ist, der durch das Aufforderungsprofil definiert ist.
  • Beispiel 48 enthält den Gegenstand eines der Beispiele 35-47 und wobei das Mittel zum Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, Mittel zum Bestimmen umfasst, ob ein verschleiertes Attribut der Rechenvorrichtung mit einem verschleierten Attribut einer anderen Rechenvorrichtung überlappt.
  • Beispiel 49 enthält den Gegenstand eines der Beispiele 35-48 und wobei das Mittel zum Generieren des kenntnisfreien Beweises Mittel zum Generieren des kenntnisfreien Beweises in Antwort auf ein Bestimmen, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, umfasst.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 14/866628 [0001]

Claims (25)

  1. Rechenvorrichtung für eine anonyme Kontextbestätigung und Bedrohungsanalyse, die Rechenvorrichtung umfassend: ein Anonyme-Bedrohung-Analysemodul zum (i) Empfangen von Sensordaten, die durch einen oder mehrere Sensor(en) der Rechenvorrichtung generiert wurden, und (ii) Generieren einer Bestätigungsangabe auf der Basis der Sensordaten, wobei die Bestätigungsangabe verschleierte Attribute der Rechenvorrichtung auf der Basis der Sensordaten enthält; und ein Kommunikationsmodul zum (i) Senden einer kenntnisfreien Zusage der Bestätigungsangabe an einen Server und (ii) Empfangen einer Aufforderung vom Server als Antwort auf das Senden der kenntnisfreien Zusage, wobei die Aufforderung eine Angabe verlangt, ob die verschleierten Attribute der Rechenvorrichtung Gemeinsamkeit mit Attributen haben, die in einem Aufforderungsprofil identifiziert wurden, das mit der Aufforderung empfangen wurde; wobei das Anonyme-Bedrohung-Analysemodul ferner zum Generieren eines kenntnisfreien Beweises dient, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  2. Rechenvorrichtung nach Anspruch 1, wobei das Empfangen der Sensordaten ein Empfangen von Sensordaten umfasst, die durch einen oder mehrere Hardware-Sensor(en) der Rechenvorrichtung generiert werden.
  3. Rechenvorrichtung nach Anspruch 2, wobei das Empfangen der Sensordaten, die durch einen oder mehrere Hardware-Sensor(en) generiert werden, ein Empfangen von Sensordaten umfasst, die durch zumindest eine von einer Authentifizierungsmaschine oder einer Kontextmaschine der Rechenvorrichtung generiert werden.
  4. Rechenvorrichtung nach Anspruch 1, wobei, das Empfangen der Sensordaten ein Empfangen der Sensordaten von einer oder mehreren Software-Anwendung(en) umfasst.
  5. Rechenvorrichtung nach Anspruch 4, wobei das Empfangen der Sensordaten von der einen oder den mehreren Software-Anwendung(en) ein Empfangen von Sensordaten von zumindest einem von einem Host Intrusion Prevention System oder einem Anti-Virusagent umfasst.
  6. Rechenvorrichtung nach Anspruch 1, wobei die verschleierten Attribute ein als Bereich angegebenes Attribut umfassen, wobei ein tatsächlicher Wert des entsprechenden Attributs innerhalb des Bereichs liegt.
  7. Rechenvorrichtung nach Anspruch 1, wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung umfasst.
  8. Rechenvorrichtung nach Anspruch 7, ferner umfassend eine Sicherheitsmaschine zum Etablieren der vertrauenswürdigen Ausführungsumgebung.
  9. Rechenvorrichtung nach Anspruch 1, wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe auf der Basis der Sensordaten und einer Sicherheitsstrategie umfasst.
  10. Rechenvorrichtung nach Anspruch 9, wobei die Sicherheitsstrategie zumindest eines der Attribute identifiziert, das in der Bestätigungsangabe oder den Sensordaten enthalten sein soll, um zum Bestimmen der Attribute verwendet zu werden.
  11. Rechenvorrichtung nach Anspruch 1, wobei das Generieren der kenntnisfreien Zusage ein Generieren einer kenntnisfreien Zusage auf der Basis zumindest einer aus Enhanced Privacy Identification(EPID)-Technologie, U-Prove-Technologie oder Identity Mixer(IDEMIX)-Technologie umfasst.
  12. Rechenvorrichtung nach Anspruch 1, wobei das Anonyme-Bedrohung-Analysemodul ferner einen Beweis einer Unterschrift der Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung in Antwort auf ein Empfangen einer Aufforderung bezüglich eines Beweises der Unterschrift generieren soll.
  13. Rechenvorrichtung nach Anspruch 1, wobei das Anonyme-Bedrohung-Analysemodul ferner die verschleierten Attribute der Rechenvorrichtung auf der Basis der vom Server empfangenen Aufforderung analysieren soll.
  14. Rechenvorrichtung nach einem der Ansprüche 1-13, wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, eine Bestimmung umfasst, ob ein verschleierter Bereich eines Attributwertes der Rechenvorrichtung ein Teilsatz eines Bereichs ist, der durch das Aufforderungsprofil definiert ist.
  15. Rechenvorrichtung nach einem der Ansprüche 1-13, wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, eine Bestimmung umfasst, ob ein verschleiertes Attribut der Rechenvorrichtung mit einem verschleierten Attribut einer anderen Rechenvorrichtung überlappt.
  16. Rechenvorrichtung nach einem der Ansprüche 1-13, wobei das Generieren des kenntnisfreien Beweises ein Generieren des kenntnisfreien Beweises in Antwort auf eine Bestimmung umfasst, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  17. Verfahren zur anonymen Kontextbestätigung und Bedrohungsanalyse, das Verfahren umfassend: Empfangen, durch eine Rechenvorrichtung, von Sensordaten, die durch einen oder mehrere Sensor(en) der Rechenvorrichtung generiert werden; Generieren, durch die Rechenvorrichtung, einer Bestätigungsangabe auf der Basis der Sensordaten, wobei die Bestätigungsangabe verschleierte Attribute der Rechenvorrichtung auf der Basis der Sensordaten enthält; Senden, durch die Rechenvorrichtung, einer kenntnisfreien Zusage der Bestätigungsangabe an einen Server; Empfangen, durch die Rechenvorrichtung, einer Aufforderung vom Server in Antwort auf das Senden der kenntnisfreien Zusage, wobei die Aufforderung eine Angabe verlangt, ob die verschleierten Attribute der Rechenvorrichtung Gemeinsamkeit mit Attributen haben, die in einem Aufforderungsprofil identifiziert wurden, das mit der Aufforderung empfangen wurde; und Generieren, durch die Rechenvorrichtung, eines kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  18. Verfahren nach Anspruch 17, wobei die verschleierten Attribute ein als Bereich angegebenes Attribut umfassen, wobei ein tatsächlicher Wert des entsprechenden Attributs innerhalb des Bereichs liegt.
  19. Verfahren nach Anspruch 17, wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe durch eine vertrauenswürdige Ausführungsumgebung der Rechenvorrichtung umfasst.
  20. Verfahren nach Anspruch 17, wobei das Generieren der Bestätigungsangabe ein Generieren einer Bestätigungsangabe auf der Basis der Sensordaten und einer Sicherheitsstrategie umfasst; und wobei die Sicherheitsstrategie zumindest eines der Attribute identifiziert, das in der Bestätigungsangabe oder den Sensordaten enthalten sein soll, um zum Bestimmen der Attribute verwendet zu werden.
  21. Verfahren nach Anspruch 17, ferner umfassend ein Analysieren, durch die Rechenvorrichtung, der verschleierten Attribute der Rechenvorrichtung auf der Basis der vom Server empfangenen Aufforderung.
  22. Verfahren nach Anspruch 17, wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, ein Bestimmen umfasst, ob ein verschleierter Bereich eines Attributwertes der Rechenvorrichtung ein Teilsatz eines Bereichs ist, der durch das Aufforderungsprofil definiert ist.
  23. Verfahren nach Anspruch 17, wobei das Generieren des kenntnisfreien Beweises, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden, ein Bestimmen umfasst, ob ein verschleiertes Attribut der Rechenvorrichtung mit einem verschleierten Attribut einer anderen Rechenvorrichtung überlappt.
  24. Verfahren nach Anspruch 17, wobei das Generieren des kenntnisfreien Beweises ein Generieren des kenntnisfreien Beweises in Antwort auf ein Bestimmen umfasst, dass die verschleierten Attribute der Rechenvorrichtung eine Gemeinsamkeit mit den Attributen haben, die im Aufforderungsprofil identifiziert wurden.
  25. Maschinenlesbares Speichermedium oder mehrere maschinenlesbare Speichermedien, umfassend mehrere darauf gespeicherte Anweisungen, die in Antwort auf ihre Ausführung dazu führen, dass eine Rechenvorrichtung das Verfahren nach einem der Ansprüche 17-24 durchführt.
DE112016004345.7T 2015-09-25 2016-08-25 Technologien für eine anonyme kontextbestätigung und bedrohungsanalyse Pending DE112016004345T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/866,628 US10440046B2 (en) 2015-09-25 2015-09-25 Technologies for anonymous context attestation and threat analytics
US14/866,628 2015-09-25
PCT/US2016/048680 WO2017052971A1 (en) 2015-09-25 2016-08-25 Technologies for anonymous context attestation and threat analytics

Publications (1)

Publication Number Publication Date
DE112016004345T5 true DE112016004345T5 (de) 2018-06-07

Family

ID=58386868

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112016004345.7T Pending DE112016004345T5 (de) 2015-09-25 2016-08-25 Technologien für eine anonyme kontextbestätigung und bedrohungsanalyse

Country Status (4)

Country Link
US (1) US10440046B2 (de)
CN (1) CN107925663B (de)
DE (1) DE112016004345T5 (de)
WO (1) WO2017052971A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11194864B2 (en) * 2016-05-10 2021-12-07 Aircloak Gmbh Systems and methods for anonymized statistical database queries
RU2666644C1 (ru) * 2017-08-10 2018-09-11 Акционерное общество "Лаборатория Касперского" Система и способ выявления потенциально опасных устройств при взаимодействии пользователя с банковскими сервисами
WO2019195989A1 (en) * 2018-04-09 2019-10-17 Huawei Technologies Co., Ltd. Zero-knowledge range proof with reversible commitment
EP3767245B1 (de) * 2018-04-24 2022-10-19 Mitsubishi Electric Corporation Angriffsdetektionsvorrichtung, angriffsdetektionsverfahren und angriffsdetektionsprogramm
US10652019B1 (en) 2019-08-28 2020-05-12 Qed-It Systems Ltd. Atomic swap using zero-knowledge proofs, and applications thereof
US11621846B2 (en) * 2021-03-25 2023-04-04 Lenovo (Singapore) Pte. Ltd. Privacy protecting transparency tree for device attestation

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060031938A1 (en) 2002-10-22 2006-02-09 Unho Choi Integrated emergency response system in information infrastructure and operating method therefor
US20070288247A1 (en) * 2006-06-11 2007-12-13 Michael Mackay Digital life server
WO2008026086A2 (en) * 2006-08-31 2008-03-06 International Business Machines Corporation Attestation of computing platforms
KR100862194B1 (ko) 2007-04-06 2008-10-09 한국전자통신연구원 침해사건 공유 장치 및 방법, 그리고 이를 포함하는네트워크 보안 시스템
GB2450869B (en) * 2007-07-09 2012-04-25 Hewlett Packard Development Co Establishing a trust relationship between computing entities
GB0801662D0 (en) * 2008-01-30 2008-03-05 Hewlett Packard Development Co Direct anonymous attestation using bilinear maps
JP2011154410A (ja) * 2010-01-25 2011-08-11 Sony Corp 解析サーバ及びデータ解析方法
CN101964034B (zh) * 2010-09-30 2012-08-15 浙江大学 一种模式信息损失最小化的序列类数据隐私保护方法
KR20130027941A (ko) 2011-09-08 2013-03-18 한국전자통신연구원 사이버 보안 이벤트 정보 관리 장치 및, 사이버 보안 이벤트 정보 관리 방법
KR101575282B1 (ko) 2011-11-28 2015-12-09 한국전자통신연구원 보안관리 도메인들 간에 익명 식별자 기반의 보안정보를 공유하기 위한 에이전트 장치 및 방법
US9787667B2 (en) * 2012-10-16 2017-10-10 Nokia Technologies Oy Attested sensor data reporting
EP2786268A4 (de) * 2012-12-20 2015-08-19 Intel Corp Bereitstellung anonymer kontextinformationen und erzeugung gezielter inhalte
US20140281491A1 (en) * 2013-03-15 2014-09-18 Microsoft Corporation Identity escrow management for minimal disclosure credentials
US9009827B1 (en) 2014-02-20 2015-04-14 Palantir Technologies Inc. Security sharing system
US9652604B1 (en) * 2014-03-25 2017-05-16 Amazon Technologies, Inc. Authentication objects with delegation
US9715590B2 (en) * 2014-05-05 2017-07-25 Analog Devices, Inc. System and device for verifying the integrity of a system from its subcomponents
CN104486435B (zh) * 2014-12-22 2018-04-27 厦门大学 基于传感器网络的低能耗生态环境监控节点部署方法

Also Published As

Publication number Publication date
US20170093906A1 (en) 2017-03-30
WO2017052971A1 (en) 2017-03-30
CN107925663A (zh) 2018-04-17
CN107925663B (zh) 2021-04-13
US10440046B2 (en) 2019-10-08

Similar Documents

Publication Publication Date Title
US10887330B2 (en) Data surveillance for privileged assets based on threat streams
DE112016004345T5 (de) Technologien für eine anonyme kontextbestätigung und bedrohungsanalyse
US11722875B2 (en) IoT device discovery and identification
US9667657B2 (en) System and method of utilizing a dedicated computer security service
US10362053B1 (en) Computer security threat sharing
JP6736657B2 (ja) 標準化されたフォーマットでサイバー脅威情報を安全に配送し交換するコンピュータ化されたシステム
JP2019096339A (ja) クラウド・コンピューティング・サービス（ｃｃｓ）上に保存された企業情報をモニター、コントロール、及び、ドキュメント当たりの暗号化を行うシステム及び方法
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
US20150161398A1 (en) Method and apparatus for privacy and trust enhancing sharing of data for collaborative analytics
Chen et al. Towards autonomic security management of healthcare information systems
DE112018006443T5 (de) Multifaktor-authentifizierung
Akram et al. Security, privacy and trust of user-centric solutions
US20230231860A1 (en) Iot device identification by machine learning with time series behavioral and statistical features
Choi et al. Enhanced SDIoT security framework models
US20240098062A1 (en) Iot device application workload capture
US20230125310A1 (en) Iot device identification with packet flow behavior machine learning model
Feng et al. Autonomous Vehicles' Forensics in Smart Cities
DE112018006451T5 (de) Multifaktor-authentifizierung
US9619840B2 (en) Backing management
US10693895B2 (en) Security indicator access determination
US20200344057A1 (en) Cybersecurity guard for core network elements
Mishra Supervising data transmission services using secure cloud based validation and admittance control mechanism
CODES 9.6 VERIFYING ONLINE TRANSACTION INTEGRITY AND AUTHENTICATION WITH QR CODES
Patil et al. Security Challenges in SDN Implementation
Kamdem et al. Data Security in healthcare Systems

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: MAIWALD GMBH, DE

Representative=s name: MAIWALD PATENTANWALTS- UND RECHTSANWALTSGESELL, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0065000000

R012 Request for examination validly filed