DE60308971T2 - Verfahren und Vorrichtung für sichere Datenkommunikationsverbindungen - Google Patents

Verfahren und Vorrichtung für sichere Datenkommunikationsverbindungen Download PDF

Info

Publication number
DE60308971T2
DE60308971T2 DE60308971T DE60308971T DE60308971T2 DE 60308971 T2 DE60308971 T2 DE 60308971T2 DE 60308971 T DE60308971 T DE 60308971T DE 60308971 T DE60308971 T DE 60308971T DE 60308971 T2 DE60308971 T2 DE 60308971T2
Authority
DE
Germany
Prior art keywords
data
key
delegation
message
data processing
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.)
Expired - Fee Related
Application number
DE60308971T
Other languages
English (en)
Other versions
DE60308971D1 (de
Inventor
Georgios Kalogridis
Gary Clemo
Chan Yeob Yeun
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.)
Toshiba Corp
Original Assignee
Toshiba 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 Toshiba Corp filed Critical Toshiba Corp
Application granted granted Critical
Publication of DE60308971D1 publication Critical patent/DE60308971D1/de
Publication of DE60308971T2 publication Critical patent/DE60308971T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • 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/3297—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 time stamps, e.g. generation of time stamps
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • 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/80—Wireless

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)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Description

  • Die vorliegende Erfindung betrifft allgemein Verfahren, Vorrichtungen und Computerprogrammcode für sichere Kommunikationsverbindungsteilstrecken, insbesondere dort, wo Verantwortlichkeit erforderlich ist. Die Erfindung ist insbesondere zum Aufbau von Verantwortlichkeitsketten in Systemen, in denen Vertrauen delegiert wird, von Nutzen.
  • Sichere Datenübertragung ist für den Internethandel wichtig, wie etwa für den Kauf von Softwarekomponenten, System- oder Anwendungssoftware, die die Arbeitsweise eines Endgeräts anpassen soll. Das sichere Herunterladen und Installieren von Software auf mobile Endgeräte ist auch für Multimedia-Unterhaltung, Tele-Medizin, Aktualisierungen für programmierbare mobile Endgeräte, Aktualisierungen für verschiedene drahtlose Standards und dergleichen von Bedeutung. Rekonfigurierbare mobile Endgeräte sind imstande, Endbenutzern, die die Endgeräte durch Herunterladen und Installieren der erwünschten Anwendungen für ihre persönlichen Bedürfnisse einrichten können, eine erhöhte Flexibilität zu bieten, zum Beispiel um unterschiedliche Typen von Funksystemen zu unterstützen und um die Integration unterschiedlicher Systeme zu ermöglichen. Jedoch werden Methoden benötigt, um mobile Endgeräte vor Hackern zu schützen, die von einem Telefonhersteller, einem Netzwerkbetreiber oder einer vertrauenswürdigen dritten Quelle erhältliche Software böswillig durch ihre Software ersetzen.
  • Ein PAN kann eine Anzahl von mobilen Vorrichtungen aufweisen, die Information miteinander und mit ihren Benutzern austauschen müssen. Technologien wie etwa zellularer Mobilfunk, Bluetooth (Warenzeichen) (Bluetooth-Interessengruppe (SIG), http://www.bluetooth.com/), IrDA (Infrarotdaten-Interessenverband (IrDA), http://www.irda.org/) und WLAN (zum Beispiel der IEEE-Standard 802.11 für drahtlose lokale Netzwerke, "1999 Edition ISO/IEC 8802-5-1998, Standards for Local and Metropolitan Area Networks – Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", 1999) können verwendet werden. Eine sichere Datenübermittlung wird wegen solcher Eigenschaften wie etwa Vertraulichkeit, Integrität, Authentifizierung und Unleugbarkeit von Daten benötigt.
  • Es gibt in einer PAN-Umgebung (persönliches Netzwerk) oft einen begrenzten Umfang an Vertrauen zwischen mobilen Endgeräten, wie etwa Taschen-PCs, Mobiltelefonen und Laptops. Es gibt einen Bedarf an Protokollen zur sicheren mobilen Delegierung für rekonfigurierbare mobile Endgeräte, die im Kontext eines persönlichen Netzwerks (PAN) arbeiten. Insbesondere besteht ein Bedarf an sicheren Schlüsselverteilungsmethoden, um eine sichere Delegierung für rekonfigurierbare Endgeräte in einem PAN-Kontext zu unterstützen. In einer PAN-Umgebung kann es sein, daß sich eine Vorrichtung rekonfigurieren muß, zum Beispiel um sich mit einem alternativen Netzwerk zu verbinden und/oder Anwendungsdienste über andere mobile Endgeräte mit anderen Netzwerkbetreibern zu empfangen. Die Fähigkeit einer Vorrichtung, sich zu rekonfigurieren, wirft eine Anzahl von Sicherheitsfragen auf, die behandelt werden müssen, um das Potential des rekonfigurierbaren Bereichs zu verwirklichen. Eine stark verteilte Umgebung legt das Erfordernis von Sicherheitsdelegationsmethoden nahe. Zusätzlich erwachsen Bedrohungen aus schädlicher Software, wie etwa Viren, trojanische Pferde und Würmer. Potentiell kann man in rekonfigurierbaren Endgeräten von Anwendungen hoher Ebenen und Systemsoftware, wie etwa Rufzeichen, bis hin zu Basisbandmodulen niedrigerer Ebenen sichere mobile Delegierung zur Sicherung von Softwaremodifikationen bzw. -aktualisierungen verwenden.
  • Es ist nützlich, die allgemeinen kryptographischen Methoden zu untersuchen. Allgemein gesagt, werden derzeit zwei grundlegende kryptographische Methoden verwendet, nämlich symmetrisch und asymmetrisch, um eine sichere Datenübertragung zum Beispiel für das Herunterladen von Software zu ermöglichen. Symmetrische Kryptographie verwendet traditionell einen gemeinsamen geheimen Schlüssel sowohl zur Verschlüsselung als auch zur Entschlüsselung. Die Daten werden durch Beschränkung des Zugriffs auf diesen geheimen Schlüssel und durch Schlüsselverwaltungsmethoden geschützt, zum Beispiel durch Verwendung eines anderen Schlüssels für jede Übertragung oder für eine kleine Gruppe von Datenübertragungen. Ein bekanntes Beispiel für symmetrische Kryptographie ist der Algorithmus des US-Datenverschlüsselungsstandards (DES) (FIPS-46, FIPS-47-1, FIPS-74, FIPS-81 des Nationalen Instituts für Normung der USA). Eine Variante davon ist Dreifach-DES (3DES), bei dem drei Schlüssel nacheinander verwendet werden, um für zusätzliche Sicherheit zu sorgen. Andere Beispiele für symmetrische kryptographische Algorithmen sind RC4 von RSA Data Security, Inc., und der Internationale Datenverschlüsselungsalgorithmus (IDEA).
  • Die asymmetrische Kryptographie oder sogenannte Kryptographie mit öffentlichem Schlüssel verwendet ein Paar von Schlüsseln, von denen einer "privat" und einer "öffentlich" ist (wenngleich in der Praxis oft auch die Verteilung des öffentlichen Schlüssels eingeschränkt ist). Eine mit dem öffentlichen Schlüssel verschlüsselte Nachricht kann nur mit dem privaten Schlüssel entschlüsselt werden und umgekehrt. Eine Person kann somit unter Verwendung des privaten Schlüssels Daten für die Entschlüsselung durch jeden mit dem entsprechenden öffentlichen Schlüssel verschlüsseln, und ebenso kann jeder mit dem öffentlichen Schlüssel Daten sicher an die Person senden, indem er sie in dem Wissen, daß nur der private Schlüssel zur Entschlüsselung der Daten verwendet werden kann, mit dem öffentlichen Schlüssel sicher verschlüsselt.
  • Asymmetrische kryptographische Systeme werden im allgemeinen innerhalb einer als Infrastruktur mit öffentlichen Schlüsseln (PKI) bekannten Infrastruktur verwendet, die Schlüsselverwaltungsfunktionen bereitstellt. Asymmetrische Kryptographie kann auch verwendet werden, um Nachrichten digital zu signieren, indem entweder die Nachricht oder eine Nachrichtenzusammenfassung unter Verwendung des privaten Schlüssels verschlüsselt wird. Vorausgesetzt, daß der Empfänger die ursprüngliche Nachricht hat, kann er die gleiche Zusammenfassung berechnen und somit die Signatur authentifizieren, indem er die Nachrichtenzusammenfassung unter Verwendung des entsprechenden öffentlichen Schlüssels entschlüsselt, den er zum Beispiel aus einem digitalen Zertifikat (siehe unten) erlangt hat. Eine Nachrichtenzusammenfassung wird aus der ursprünglichen Nachricht abgeleitet und ist im allgemeinen kürzer als die ursprüngliche Nachricht, was es schwierig macht, die ursprüngliche Nachricht aus der Zusammenfassung zu berechnen; eine sogenannte Hash-Funktion (h) kann verwendet werden, um eine Nachrichtenzusammenfassung zu erzeugen. Beispiele für kollisionsresistente (schwer zu erratende) Einweg-Hash-Funktionen werden in R. Rivest, "The MD4 message-digest algorithm", Internet Request for Comments 1320, April 1992, und R. Rivest, "The MD5 message-digest algorithm", Internet Request for Comments 1321, April 1992, gegeben.
  • In der symmetrischen Kryptographie gibt es ein Äquivalent zur digitalen Signatur, nämlich einen sogenannten MAC (Nachrichtenauthentifikationscode), der unter Verwendung eines gemeinsam genutzten geheimen Schlüssels berechnet wird. Beispiele für MACs sind in ISO 8731-1, "Banking – Approved algorithms for message authentication – Part 1:DEA", Internationale Organisation für Standardisierung, Genf, Schweiz, 1987, zu finden. Ein anderes Beispiel für einen MAC ist eine chiffrierte Hash-Funktion, wie sie zum Beispiel in "Computer Data Authentication", FIPS-Veröffentlichung 113 des Nationalen Instituts für Normung der USA, 1985, beschrieben ist. Ein MAC kann die Integrität eines empfangenen Softwaremoduls prüfen, zum Beispiel durch Vergleichen von Hash-Werten des empfangenen Softwaremoduls mit einem, der in einem zugehörigen Installationsticket enthalten ist. Jedoch garantiert diese Methode nicht die Unleugbarkeit im Fall irgendeiner Auseinandersetzung zwischen dem vertrauenswürdigen Anbieter und einem Endgerätebenutzer, da der geheime Schlüssel gemeinsam genutzt wird.
  • Eine Infrastruktur mit öffentlichen Schlüsseln weist normalerweise die Bereitstellung von Zertifikaten für die digitale Identität auf. Um zu verhindern, daß sich eine Person als jemand anders ausgibt, kann eine Person ihre Identität einer Zertifizierungsbehörde beweisen, die dann ein Zertifikat ausstellt, das unter Verwendung des privaten Schlüssels der Behörde signiert wurde und den öffentlichen Schlüssel der Person aufweist. Der öffentliche Schlüssel der Zertifizierungsbehörde (CA) ist weithin bekannt, daher wird ihm vertraut, und da das Zertifikat nur unter Verwendung des privaten Schlüssels der Behörde verschlüsselt werden konnte, wird der öffentliche Schlüssel der Person durch das Zertifikat bestätigt. Im Kontext eines Mobiltelefonnetzes können ein Benutzer oder der Netzwerkbetreiber ihre Identität durch Signieren einer Nachricht mit ihrem privaten Schlüssel authentifizieren; ebenso kann ein öffentlicher Schlüssel verwendet werden, um eine Identität zu bestätigen. Weitere Einzelheiten von PKI für drahtlose Anwendungen können in WPKI, WAP-217-WPKI, Version 24, April 2001, verfügbar unter http://www.wapforum.org/, und in den X.509-Spezifikationen (PKIX), die unter http://www.ietf.org/ zu finden sind, deren Inhalt hierin durch Bezugnahme aufgenommen wird, gefunden werden.
  • In Ausführungsformen der Erfindung, die später beschrieben werden, wird angenommen, daß PKI (Infrastruktur mit öffentlichen Schlüsseln) verwendet wird. In einer solchen Umgebung erteilen vertrauenswürdige Teilnehmer, wie etwa Hersteller und Betreiber, ihre Zertifikate normalerweise mobilen Endgeräten, die sie in sicheren manipulationssicheren Modulen, wie etwa Chipkarten oder anderen Karten (zum Beispiel ein SIM (Teilnehmeridentitätsmodul), WIM (Modul für drahtlose Identität); SWIM (Kombiniertes SIM und WIM), USIM (Universelles Teilnehmeridentitätsmodul)), speichern. Allgemeiner können öffentliche Schlüssel bei der Herstellung im Endgerät gespeichert werden, oder auf einer SIM-Karte, oder sie können heruntergeladen werden. Zum Beispiel kann ein mobiles Endgerät auf ein nur lesbares Verzeichnis eines Netzwerkbetreibers zugreifen, um öffentliche Schlüssel oder Zertifikate für andere mobile Endgeräte herunterzuladen.
  • PKI sorgt für Unleugbarkeit und beschützt beide Seiten; dagegen sorgt ein symmetrischer Sitzungsschlüssel für wenig Aufwand und schnelles Herunterladen (zum Beispiel wenn er, etwa unter Verwendung eines zertifizierten öffentlichen Schlüssels, von einer anderen vertrauenswürdigen Seite transportiert worden ist). Es ist möglich, daß ein solcher Sitzungsschlüssel zwecks erhöhter Sicherheit nur für einen kurzen Zeitraum gültig ist. Methoden für das sichere Herunterladen von Software unter Verwendung asymmetrischer kryptographischer Methoden, um eine Kommunikationsverbindungsteilstrecke unter Verwendung symmetrischer Kryptographie einzurichten, sind in C. Yeun und T. Farnham, "Secure Software Download for Programmable Mobile User Equipment", IEEE-Konferenz über mobile Kommunikationstechnologien der dritten Generation, 8.-10. Mai 2002, und auch in den gleichzeitig anhängigen UK-Patentanmeldungen des Antragstellers Nr.0201048.6 und Nr. 0201049.4, beide am 17. Januar 2002 angemeldet, beschrieben.
  • Die asymmetrische Kryptographie wurde zuerst 1976 öffentlich durch Diffie und Hellman offenbart (W. Diffie und D. E. Hellman, "New directions in cryptography", IEEE Transactions on Information Theory, 22 (1976), S. 644-654), und inzwischen sind eine etliche asymmetrische kryptographische Methoden Allgemeingut, von denen die bekannteste der RSA-(Rivest-Shamir-Adleman-)Algorithmus ist (R. L. Rivest, A. Shamir und L. M. Adleman, "A method for obtaining digital signatures and public-key cryptosystems", Communications of the ACM, 21 (1978), S. 120-126). Andere, neuere Algorithmen, weisen Kryptographiesysteme mit elliptischen Kurven auf (siehe zum Beispiel X9.63, "Public key cryptography for the financial services industry: Key agreement and key transport using elliptic curve cryptography", Entwurf für ANSI X9F1, Oktober 1999). Der X.509-Standard der ITU (Internationale Telekommunikationsunion) wird allgemein für öffentliche Schlüsselzertifikate verwendet. Dabei ist ein Zertifikat mit einer eindeutigen Kennung für einen Schlüsselausgeber zusammen mit dem öffentlichen Schlüssel (und normalerweise mit Information über den Algorithmus und die Zertifizierungsbehörde) in ein Verzeichnis, das heißt einen öffentlichen Aufbewahrungsort für Zertifikate zur Verwendung durch Personen und Organisationen, eingeschlossen.
  • Die oben skizzierten symmetrischen und asymmetrischen Kryptographiemethoden haben jeweils Vor- und Nachteile. Asymmetrische Ansätze sind weniger ressourceneffizient, da sie komplexe Berechnungen und vergleichsweise längere Schlüssellängen als symmetrische Ansätze erfordern, um ein entsprechendes Sicherheitsniveau zu erreichen. Ein symmetrischer Ansatz erfordert jedoch die Speicherung von geheimen Schlüsseln innerhalb des Endgeräts und stellt keine Unleugbarkeit bereit (die das Senden oder den Empfang von Daten beweist).
  • Die Datenübertragung gewinnt innerhalb von Mobiltelefonnetzen zunehmend an Bedeutung, und dies ist insbesondere für sogenannte 2.5G- und 3G-(Dritte-Generation-)Netzwerke wichtig, wie sie zum Beispiel in den vom Partnerschaftsprojekt der Dritten Generation (3GPP, 3GPP2) erzeugten Standards beschrieben sind, wofür technische Spezifikationen unter http://www.3gpp.org/ zu finden sind und denen Inhalt hierin durch Bezugnahme aufgenommen wird.
  • 1 zeigt eine allgemeine Struktur eines digitalen Mobiltelefonsystems der dritten Generation unter 10. In 1 ist ein Funkmast 12 mit einer Basisstation 14 gekoppelt, die wiederum durch einen Basisstationscontroller 16 gesteuert wird. Eine Mobilfunk-Kommunikationsvorrichtung 18 ist in Zweirichtungskommunikation mit der Basisstation 14 über eine Funk- oder Luftschnittstelle 20 gezeigt, die in GSM-Netzwerken (Globales System für Mobilfunk-Kommunikation) und GPRS-Netzwerken (Allgemeiner Paketvermittelter Funkdienst) als Um-Schnittstelle und in CDMA2000- und W-CDMA-Netzwerken als Uu-Schnittstelle bekannt ist. Normalerweise ist jederzeit eine Vielzahl von Mobilfunkvorrichtungen 18 an eine gegebene Basisstation angeschlossen, die eine Vielzahl von Funk-Senderempfängern aufweist, um diese Vorrichtungen zu versorgen.
  • Der Basisstationscontroller 16 ist gemeinsam mit einer Vielzahl anderer Basisstationscontroller (nicht gezeigt) mit einer Mobilfunk-Vermittlungsstelle (MSC) 22 gekoppelt. Eine Vielzahl solcher MSCs ist wiederum mit einer Gateway-MSC (GMSC) 24 gekoppelt, die das Mobiltelefonnetz mit dem öffentlichen Fernsprechwählnetzwerk (PSTN) 26 verbindet. Eine Heimatdatei (HLR) 28 und eine Besucherdatei (VLR) 30 verwalten die Anruf-Leitweglenkung und den Verkehrsbereichswechsel, und andere Systeme (nicht gezeigt) verwalten Authentifizierung und Rechnungsstellung. Ein Betriebs- und Wartungszentrum (OMC) 29 sammelt die Statistiken von Netzwerk-Infrastrukturelementen, wie etwa Basisstationen und Vermittlungsstellen, um Netzwerkbetreibern eine Zusammenfassung über das Leistungsvermögen des Netzwerks zu verschaffen. Das OMC kann zum Beispiel verwendet werden, um zu bestimmen, wieviel von der verfügbaren Kapazität des Netzwerks oder von Teilen des Netzwerks zu unterschiedlichen Tageszeiten genutzt wird.
  • Die oben beschriebene Netzwerkinfrastruktur verwaltet im wesentlichen leitungsvermittelte Sprachverbindungen zwischen einer Mobilfunk-Kommunikationsvorrichtung 18 und anderen Mobilfunkvorrichtungen und/oder dem PSTN 26. Sogenannte 2.5G-Netzwerke, wie etwa GPRS, und 3G-Netzwerke fügen Paketdatendienste zu den leitungsvermittelten Sprachdiensten hinzu. Allgemein gesagt wird zum Basisstationscontroller 16 eine Paketsteuerungseinheit (PCU) 32 hinzugefügt, und diese ist mit einem Paketdatennetzwerk, wie etwa dem Internet 38, mittels einer hierarchischen Folge von Vermittlungsstellen verbunden. In einem GSM-basierten Netzwerk umfassen diese einen Serving-GPRS-Unterstützungsknoten (SGSN) 34 und einen Gateway-GPRS-Unterstützungsknoten (GGSM) 36. Man wird anerkennen, daß sich sowohl in dem System von 1 als auch in dem später beschriebenen System die Funktionalitäten von Elementen innerhalb des Netzwerks in einem einzelnen physischen Knoten oder in getrennten physischen Knoten des Systems befinden können.
  • Kommunikation zwischen der Mobilfunkvorrichtung 18 und der Netzwerkinfrastruktur weist im allgemeinen sowohl Daten als auch Steuerungssignale auf. Die Daten können digital codierte Sprachdaten umfassen, oder ein Datenmodem kann verwendet werden, um Daten transparent zu und von der Mobilfunkvorrichtung zu übertragen. In einem Netzwerk des GSM-Typs können Text und andere Daten geringer Bandbreite auch unter Verwendung des GSM-Kurznachrichtendienstes (SMS) gesendet werden.
  • In einem 2.5G- oder 3G-Netzwerk kann die Mobilfunkvorrichtung 18 mehr als eine einfache Sprachverbindung zu einem anderen Telefon bereitstellen. Zum Beispiel kann die Mobilfunkvorrichtung 18 zusätzlich oder alternativ Zugriff auf Video- und/oder Multimedia-Datendienste, Webbrowsing, E-Mail und andere Datendienste bereitstellen. Logisch kann die Mobilfunkvorrichtung 18 so betrachtet werden, daß sie ein mobiles Endgerät (das eine Teilnehmerkennungsmodul-(SIM-)Karte einschließt) mit einer seriellen Verbindung zu einer Endgeräteausrüstung wie etwa einem Datenprozessor oder Personalcomputer umfaßt. Grundsätzlich ist die Mobilfunkvorrichtung, wenn sie sich dem Netzwerk angeschlossen hat, "immer eingeschaltet", und Benutzerdaten können transparent zwischen der Vorrichtung und einem externen Datennetzwerk übertragen werden, zum Beispiel mittels Standard-AT-Befehlen an der Schnittstelle zwischen dem mobilen Endgerät und der Endgeräteausrüstung. Wenn ein herkömmliches Mobiltelefon als Mobilfunkvorrichtung 18 verwendet wird, wird möglicherweise ein Endgeräteadapter, wie etwa eine GSM-Datenkarte, benötigt.
  • 2 stellt ein Modell 200 eines grundlegenden sicheren Mobilfunk-Kommunikationssystems schematisch dar. Ein(e) Mobilfunkvorrichtung oder -endgerät 202 ist über eine ortsfeste oder Basisstation 206 mit einem Mobilfunk-Kommunikationsnetzwerk 208, wie etwa einem Mobiltelefon-Netzwerk oder WLAN, gekoppelt. Das Mobilfunk-Kommunikationsnetzwerk 208 ist wiederum mit einem Computernetzwerk 210, wie etwa dem Internet 208, gekoppelt, an das ein Server 204 angeschlossen ist. Die Mobilfunkvorrichtung 202 und/oder der Server 204 speichern ein digitales Zertifikat, wobei ein in der Mobilfunkvorrichtung 202 gespeichertes digitales Zertifikat 212 einen öffentlichen Schlüssel für den Server 204 aufweist und ein im Server 204 gespeichertes digitales Zertifikat 214 einen öffentlichen Schlüssel für die Mobilfunkvorrichtung 202 aufweist (in anderen Anordnungen können diese bei Bedarf heruntergeladen werden). Der Server kann zum Beispiel durch einen Netzwerkbetreiber, den Hersteller der Mobilfunkvorrichtung oder durch eine dritte Seite betrieben werden. Die Mobilfunkvorrichtung wird normalerweise durch einen Benutzer betrieben, und der Einfachheit halber ist nur eine einzelne Mobilfunkvorrichtung gezeigt, obwohl es grundsätzlich eine Vielzahl solcher Vorrichtungen gibt. Ein Kommunikationsmechanismus 216 ist ausgebildet, um Daten zwischen der Mobilfunkvorrichtung 202 und dem Server 204 zu übermitteln, aber normalerweise bewegen sich solche Daten über eine Vielzahl von Vermittlern (in 2 nicht gezeigt).
  • Im Kontext der 3G-Mobiltelefonsysteme müssen noch Standards für sichere Datenübertragungen festgelegt werden, und gegenwärtig finden Diskussionen im MExE-Forum (Forum für eine Ausführungsumgebung für Mobilstationsanwendungen) auf http://www.mexeforum.org/ statt. Es kann auch auf ISO/IEC 1170-3, "Information Technology – Security Techniques – Key Management – Part 3: Mechanism Using Asymmetric Techniques", DIS 1996, Bezug genommen werden.
  • Allgemein gesagt definiert MExE eine standardisierte Anwendungsumgebung. Ein Delegationsprotokoll für ein verteiltes Netzwerk ist insbesondere in 3GPP TS 23.057 "Mobile Station Application Execution Environment (MExE)" dargelegt. Zur Zeit ist ein relativ einfaches Authentifizierungsprotokoll unter Verwendung von PKI vorgesehen, bei dem das mobile Endgerät (MT) einen öffentlichen Schlüssel hat, entweder einen Hauptschlüssel, der sicher im MT installiert ist (zum Beispiel können Hauptschlüssel für eine Anzahl von CAs während der Herstellung installiert werden), oder eineb signierten öffentlicher Schlüssel, der einem Zertifikat angehängt oder in diesem bereitgestellt wird. Dieser öffentliche Schlüssel wird dann verwendet, um einen ausführbaren Code zu überprüfen, der mit einem entsprechenden privaten Schlüssel signiert ist. Wenn zum Beispiel Software von einem dritten Softwareentwickler erlangt wird, erzeugt der Entwickler (oder erlangt von einer CA) ein öffentlich-privates Schlüsselpaar und ein Zertifikat (das durch die CA signiert ist und den öffentlichen Schlüssel des Entwicklers aufweist). Dieses (oder in manchen Fällen ein Satz von Zertifikaten für eine Schlüsselkette) wird an den ausführbaren Code angehängt, und das MT kann dann bestätigen, daß die Software durch einen privaten Schlüssel signiert wurde, der dem (zertifizierten) öffentlichen Schlüssel des Entwicklers entspricht.
  • Konzepte für rekonfigurierbare softwaredefinierte Funkgeräte (SDR) sind ebenfalls Gegenstand neuerer, aktiver Forschung gewesen (siehe zum Beispiel "Authorization and use of Software Defined Radio: First Report and Order", U.S. Federal Communication Commission, Washington, D.C., September 2001). SDR-fähige Benutzervorrichtungen und Netzwerktechnik können dynamisch programmiert werden, um ihre charakteristischen Merkmale zu rekonfigurieren, um ein verbessertes Leistungsvermögen und/oder zusätzliche Merkmale bereitzustellen, und bieten folglich auch die Möglichkeit zusätzlicher Einnahmequellen für einen Diensteanbieter. Softwaredefinierter Funk hat Anwendungen sowohl im zivilen und kommerziellen als auch im militärischen Sektor.
  • Das SDR-Forum (Forum für softwaredefinierte Funkgeräte (SDR), http://www.sdrforum.org/) hat eine offene Architektur mit einer gemeinsamen Software-API-Schicht mit standardisierten Funktionen definiert. Eine Skizze dieser Anordnung ist in 3 gezeigt. In 3 umfaßt ein SDR eine Menge von sieben unabhängigen Teilsystemen 302a-g, von denen wiederum jedes Hardware, Firmware, ein Betriebssystem und Softwaremodule umfaßt, die mehr als einer Anwendung gemein sein können. Eine Steuerungsfunktion 304 stellt die Steuerung ("C") für jeden der Funktionsblöcke bereit, während der Benutzerverkehr ("I") Daten und Information umfaßt, die zwischen den Modulen ausgetauscht werden. Eine SDR-Implementierung in einem mobilen (drahtlosen) Endgerät ist analog zu Software, die auf einem normalen PC läuft, wenngleich der Geschwindigkeit halber einige Basisband-Dienstimplementierungen und Steuerungsfunktionen direkt mit der Hardwareschicht gekoppelt sind, statt etwa über einen dazwischenliegenden Echtzeit-Kern oder Treiber. Das SDR-System von 3 ist zur Verwendung bei der Implementierung später beschriebener Ausführungsformen von Verfahren gemäß der Erfindung geeignet.
  • Es gibt jedoch einen Bedarf, Konzepte zur sicheren Delegierung mit sicherem Herunterladen von (SDR-)Software zu verbinden, zum Beispiel im Kontext eines PAN. Der Rekonfigurationsprozeß muß Anforderungen, Fähigkeiten und Profile von Anwendungen, Vorrichtungen und Benutzern erlangen, wobei Information aus der Netzwerkerkennung oder von Überwachungsinstanzen zusammengestellt wird und Softwarekomponenten von Aufbewahrungsorten heruntergeladen werden. Dies ist potentiell eine hochgradig verteilte Umgebung, in der die Delegierung von Vertrauen wichtig ist.
  • Einige der Ziele eines Sicherheitssystems sind Authentifizierung (des Datenabsenders oder -empfängers, zum Beispiel mit Paßwort- und/oder biometrischen Methoden), Zugangssteuerung, Unleugbarkeit, Integrität der übertragenen Daten, zum Beispiel zwischen PAN-Knoten, und Vertraulichkeit (zum Beispiel durch Verschlüsselung von Nachrichten zwischen PAN-Knoten). Es kann auch Vorkehrungen für das "anonyme" Herunterladen von Daten geben, das heißt für die Bereitstellung oder das Rundsenden von Daten, ohne speziell einen Empfänger anzugeben. Jedoch fehlt den bestehenden Sicherheitsmechanismen die Unterstützung für Verantwortlichkeit und die Delegierung von Aufgaben an andere Instanzen. In diesem Zusammenhang bedeutet "Verantwortlichkeit", allgemein gesagt, die Zuordnung eines Objekts, einer Aktion oder eines Rechts zu einer Instanz, vorzugsweise auf eine solche Weise, daß einer anderen Instanz oder Seite die Zuordnung bewiesen (oder zumindest mit einer hohen Wahrscheinlichkeit bestimmt) werden kann. Allgemein gesagt bedeutet "Delegation" die Autorisierung (zum Beispiel zur Durchführung einer Handlung) einer zweiten Instanz durch eine erste, indem Rechte (oder ein gewisser Teil einer Sicherheitsstrategie oder anderer Daten) gemeinsam genutzt werden, so daß die zweite Instanz befähigt wird, anstelle der ersten zu agieren. Wenn Verantwortlichkeit delegiert wird, werden die Rechte oder andere Daten vorzugsweise übermittelt, statt sie gemeinsam zu nutzen, so daß eine Aktion eindeutig mit einer Instanz verknüpft werden kann.
  • Hintergrundinformation zum Stand der Technik in bezug auf sichere Delegationsprotokolle ist in M. Gasser und E. McDermott, "An architecture for practical delegation in a distributed system", Proceedings of the IEEE Symposium on Security and Privacy, S. 20-30, 1990; M. Low und B. Christianson, "Self authenticating proxies", Computer Journal, Bd. 33, S. 422-428, Oktober 1994; Y. Ding, P. Horster und H. Peters "A new approach for delegation using hierarchical delegation token", Proceedings of the 2nd Conference on Computer and Communication Security, S. 128-143, 1996; und vor allem in B. Crispo, "Delegation Protocols for Electronic Commerce", Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunesien, 3.-5. Juli 2001, zu finden. Jedoch fehlt es heutigen Lösungen sowohl an Verantwortlichkeit als auch an Vertrauen oder sie sind relativ ineffizient. Insbesondere das von Crispo (ebenda) vorgeschlagene Protokoll erfordert vier Nachrichtendurchläufe und ist auf asymmetrische Methoden beschränkt, und es ist von einer Komplexität, die in der Praxis eine Staffelung von Delegierungen verhindert.
  • Es ist erwünscht, Protokolle mit weniger Nachrichtendurchläufen bereitzustellen, als durch den Stand der Technik gelehrt wird, und die vorzugsweise imstande sind, sowohl mit asymmetrischen als auch mit symmetrischen kryptographischen Methoden zu arbeiten. Es ist ferner erwünscht, Protokolle bereitzustellen, die für gestaffeltes Delegieren geeignet sind, während sie relativ kompakte und effiziente Nachrichten beibehalten.
  • GB 2337145A beschreibt ein Verfahren zur Delegierung der Verwendung eines elektronischen Schlüssels zur Anwendung digitaler Signaturen, bei dem der Schlüssel auf einer Chipkarte eines primären Benutzers gespeichert ist und einem Delegierten ein elektronisches Überantwortungszertifikat gesendet wird, das in eine Nachricht von dem Delegierten an die Chipkarte eingeschlossen ist, die die Verwendung des Schlüssels (zum Anhängen einer Signatur) anfordert. US 2001/005841 beschreibt eine Autorisierungs-Delegationskette, die Attributzertifikate verwendet, und US 5224163 beschreibt ein Verfahren zur Delegierung der Autorisierung in einem Rechensystem.
  • Das Dokument "Proxy-based authorization and accounting for distributed systems", Neuman B. C., Proceedings of the International Conference on Distributed Computing Systems, Pittsburgh, 25.-28. Mai 1993, Los Alamitos, IEEE Comp. Soc. Press, USA, S. 283-291, offenbart ein Verfahren, das die sichere Übermittlung eines Delegationsschlüssels an ein beauftragtes System umfaßt.
  • Allgemein gesagt werden in Ausführungsformen der hierin beschriebenen Verfahren, um Probleme der Verantwortlichkeit bei bekannten Protokollen zu behandeln, zwei unterschiedliche Schlüssel eingeführt, einer nur für die Authentifizierung und ein getrennter Schlüssel, der als Delegationsschlüssel fungiert. Dies ermöglicht die Unabhängigkeit der Gültigkeitsdauern der Authentifizierung und der Delegierung, und eine solche Trennung unterstützt außerdem die Implementierung von rollenbasierten Modellen. Wenn die Schlüsselfunktionen nicht getrennt wären, dann könnte zum Beispiel, wenn die delegierte(n) Rechte/Verantwortlichkeit eine andere Nutzungsdauer als der Authentifikationsschlüssel haben, die Erneuerung eines Schlüssels sehr umständlich sein. Außerdem unterstützen die hierin beschriebenen Protokolle die gestaffelte Delegierung und erhalten die durchgehende Verantwortlichkeit zwischen allen beteiligten Instanzen (zum Beispiel mobilen Teilnehmern) aufrecht.
  • Unter einem Aspekt der Erfindung wird daher ein Verfahren zur Initialisierung einer sicheren Kommunikationsverbindungsteilstrecke zwischen einem ersten, delegierenden Datenverarbeitungssystem (A) und einem zweiten Datenverarbeitungssystem (B), an das das erste System delegiert, bereitgestellt, wobei das Verfahren ein erstes Delegationstoken DT mit einem ersten Delegationsschlüssel (KP-T-E) und zugeordneten ersten Anforderungsdaten (R) verwendet, wobei die ersten Anforderungsdaten eine Anforderung des ersten Systems bezeichnen und der erste Delegationsschlüssel zur Verschlüsselung von Daten dient, die als Antwort auf die Anforderung an das erste System zurückgesendet werden sollen, wobei das Verfahren die folgenden Schritte umfaßt: Erzeugen, in dem ersten System, einer ersten Nachricht (M1) mit dem ersten Delegationsschlüssel und zugeordneten ersten Anforderungsdaten und ersten Authentifikationsdaten (SA) zur Authentifizierung des ersten, delegierenden Systems, wobei die ersten Authentifikationsdaten durch Bearbeiten mindestens eines von folgendem, nämlich des ersten Delegationsschlüssels und/oder der ersten Anforderungsdaten, mit einem geheimen Authentifikationsschlüssel des ersten Systems erzeugt werden; Verschlüsseln der ersten Nachricht unter Verwendung eines Verbindungsteilstrecken-Verschlüsselungsschlüssels (PB), der sowohl dem ersten als auch dem zweiten Datenverarbeitungssystem bekannt ist, um eine verschlüsselte erste Nachricht zu bilden; und Senden der verschlüsselten ersten Nachricht von dem ersten System an das zweite System, um die sichere Kommunikationsverbindungsteilstrecke zu initialisieren.
  • Vorzugsweise werden die Authentifikationsdaten durch Bearbeitung sowohl des ersten Schlüssels als auch der ersten Anforderungsdaten, das heißt durch Bearbeitung des ersten Tokens erzeugt. Das Token ist eigentlich ein Delegationstoken, das einen Delegationsschlüssel umfaßt, und die Nachricht mit dem Token umfaßt, insbesondere mit den Authentifikationsdaten, ist nachweisbar, zum Beispiel, weil die Authentifikationsdaten eine digitale Signatur oder einen MAC (Nachrichtenauthentifikationscode) umfassen.
  • Der geheime Schlüssel des ersten Systems kann einen privaten Schlüssel umfassen, dessen entsprechender öffentlicher Schlüssel auf das zweite System zugriffsfähig ist, oder er kann einen geheimen Schlüssel umfassen, der von (mindestens) dem ersten und dem zweiten System gemeinsam genutzt wird, oder er kann den ersten (das heißt Delegations-)Schlüssel umfassen (zum Beispiel, wenn Unleugbarkeit und nicht Verschlüsselung am wichtigsten ist). Vorzugsweise ist der geheime Schlüssel jedoch ein privater Schlüssel eines asymmetrischen Kryptographiesystems (mit öffentlichem Schlüssel).
  • Der sowohl dem ersten als auch dem zweiten Datenverarbeitungssystem bekannte Schlüssel, der verwendet wird, um die erste Nachricht zu verschlüsseln, kann ein Schlüssel für ein symmetrisches oder für ein asymmetrisches kryptographisches System sein. Im Fall eines asymmetrischen kryptographischen Systems kann der Schlüssel einen öffentlichen Schlüssel des zweiten Systems umfassen (theoretisch muß das zweite System nur das private Gegenstück zum öffentlichen Schlüssel kennen, wenngleich in der Praxis das zweite System sowohl den privaten als auch den öffentlichen Schlüssel kennen dürfte). Die verschlüsselte Nachricht kann über eine beliebige herkömmliche Kommunikationsverbindungsteilstrecke, wie etwa eine drahtgebundene oder drahtlose Verbindungsteilstrecke, gesendet werden.
  • Die Anforderungsdaten können Daten zur Anforderung einer Rolle, einer Aufgabe, eines Dienstes oder von Daten, wie etwa Software, oder irgendwelche anderen Anforderungsdaten umfassen. Der erste oder Delegationsschlüssel kann durch das zweite System, oder in einer Kette von Delegationen durch ein Endsystem verwendet werden, um eine sichere Kommunikationskette mit dem ersten oder Anfangspunktsystem einzurichten. Somit kann der erste oder Delegationsschlüssel zur Verschlüsselung von Daten verwendet werden, die an das erste System zurückzusenden sind, oder er kann für irgendeine andere Sicherheitsfunktion verwendet werden, wie etwa eine digitale Signatur, um eine Identität zu bestätigen (eine digitale Signatur kann als ein spezifischer Typ von verschlüsselten Daten betrachtet werden). Daten können an das erste System entweder direkt oder entlang einer Kette von Systemen zurückgesendet werden. In einer solchen Kette von Systemen kann der erste Schlüssel zur direkten Kommunikation zwischen dem Endsystem und dem ersten System verwendet werden, aber wenn Daten entlang der Kette von Systemen zurückgesendet werden, also indirekt, wird ein Satz oder eine Kette von Delegationsschlüsseln verwendet, einer für jede Verbindungsteilstrecke in der Kette.
  • Wenn das erste Datenverarbeitungssystem ein Zwischen-Datenverarbeitungssystem in einer Kette von Datenverarbeitungssystemen ist, kann das Verfahren ferner die folgenden Schritte umfassen: In dem ersten Datenverarbeitungssystem erfolgendes Empfangen einer vorigen verschlüsselten Nachricht mit einem vorigen Token und vorigen Anforderungsdaten von einem vorigen Datenverarbeitungssystem, wobei das vorige Token einen vorigen Schlüssel und zugeordnete vorige Anforderungsdaten umfaßt, wobei die vorigen Authentifikationsdaten Daten umfassen, die durch Bearbeiten mindestens eines von folgendem, nämlich des vorigen Schlüssels und/oder der vorigen Anforderungsdaten, mit einem geheimen Schlüssel des vorigen Systems erzeugt wurden; Entschlüsseln der vorigen verschlüsselten Nachricht unter Verwendung eines Schlüssels, der sowohl dem ersten als auch dem vorigen Datenverarbeitungssystem bekannt ist; und Einbeziehen des vorigen Tokens und der vorigen Authentifikationsdaten in die erste Nachricht.
  • Vorzugsweise werden die vorigen Authentifikationsdaten überprüft, zum Beispiel durch Bearbeiten der vorigen Authentifikationsdaten mit einem öffentlichen Schlüssel des vorigen Systems oder durch Bearbeiten der Authentifikationsdaten mit einem gemeinsam genutzten Schlüssel eines symmetrischen kryptographischen Systems. Ebenso können die ersten Authentifikationsdaten im zweiten Datenverarbeitungssystem überprüft werden. Auf diese Weise kann eine sichere Kommunikationsverbindungsteilstrecke zwischen jedem Paar von Datenverarbeitungssystemen in der Kette eingerichtet werden, wobei jedes Datenverarbeitungssystem die Authentifikationsdaten überprüft, die dem vom vorigen System empfangenen Delegationstoken zugeordnet sind.
  • Obwohl hier von einer "Kette" von Datenverarbeitungssystemen die Rede ist, schließt dies andere Kommunikationsverbindungsteilstrecken zwischen Elementen der Kette nicht aus, so daß die Kette zum Beispiel eine Folge von Elementen in einem mehrfach verbundenen Netzwerk von Elementen umfassen kann. Ausführungsformen des Delegationsprozesses sind jedoch imstande, eine sichere Kette herzustellen, die eine Folge von sicheren Verbindungsteilstrecken innerhalb eines solchen Netzwerks umfaßt.
  • Unter einem weiteren Aspekt stellt die Erfindung ein Verfahren zum Aufbau einer Kette von sicheren Kommunikationsverbindungsteilstrecken zwischen einer Vielzahl von Datenverarbeitungsmaschinen bereit, so daß die Identität jeder nachfolgenden, die Kette bildenden Datenverarbeitungsmaschine mittels jeweiliger Authentifikationsdaten bestätigt werden kann, wobei das Verfahren den folgenden Schritt umfaßt: Durchführen, in jeder nachfolgenden Datenverarbeitungsmaschine in der Kette nach einer ersten Maschine, der folgenden Schritte: Empfangen, von einer vorigen Datenverarbeitungsmaschine (A) in der Kette, einer durch das Verfahren nach Anspruch 1 erzeugten verschlüsselten Nachricht mit den ersten Authentifikationsdaten (SA) und dem ersten Delegationstoken (DT), das den ersten Delegationsschlüssel (KP-T-E) aufweist, wobei der erste Delegationsschlüssel zur Verschlüsselung von Daten dient, die an das erste System zurückgesendet werden sollen; Entschlüsseln der verschlüsselten Nachricht; Hinzufügen weiterer Delegationstoken-Daten (DT') und weiterer Authentifikationsdaten (SB) für die folgende Datenverarbeitungsmaschine zur entschlüsselten Nachricht, um eine erweiterte Nachricht (M2) zu bilden; Verschlüsseln der erweiterten Nachricht; und Weiterleiten der verschlüsselten erweiterten Nachricht zur nächsten Maschine (C) in der Kette; bis eine End-Maschine in der Kette erreicht ist, wodurch die Kette sicherer Kommunikationsverbindungsteilstrecken eingerichtet ist.
  • Die Erfindung stellt auch ein Datenverarbeitungssystem und Datenverarbeitungssysteme bereit, das bzw. die dafür konfiguriert oder programmiert ist bzw. sind, die oben beschriebenen Verfahren zu implementieren.
  • Unter einem weiteren Aspekt stellt die Erfindung daher eine Datenverarbeitungsvorrichtung zur Delegierung an ein zweites Datenverarbeitungssystem unter Verwendung eines Delegationstokens (DT) mit einem Delegationsschlüssel (KP-T-E) und zugeordneten Anforderungsdaten (R) bereit, wobei die Anforderungsdaten eine Anforderung der Vorrichtung bezeichnen und der Delegationsschlüssel zur Verschlüsselung von Daten dient, die als Antwort auf die Anforderung an die Vorrichtung zurückgesendet werden sollen, wobei die Vorrichtung folgendes umfaßt: einen Datenspeicher, der betriebsfähig ist, Daten zu speichern, die verarbeitet werden sollen; einen Anweisungsspeicher, der Anweisungen speichert, die durch einen Prozessor implementiert werden können; und einen Prozessor, der mit dem Datenspeicher und dem Anweisungsspeicher gekoppelt und betriebsfähig ist, Daten gemäß den Anweisungen zu verarbeiten, wobei die Anweisungen Anweisungen zur Steuerung des Prozessors umfassen, um folgende Schritte durchzuführen: Erzeugen, in der Vorrichtung, einer Nachricht (M1) mit dem Delegationsschlüssel und zugeordneten Anforderungsdaten und Authentifikationsdaten (SA) zur Authentifizierung der delegierenden Vorrichtung, wobei die Authentifikationsdaten durch Bearbeitung mindestens eines von folgendem, nämlich des Delegationsschlüssels und/oder der Anforderungsdaten, mit einem geheimen Authentifikationsschlüssel der Vorrichtung erzeugt werden; Verschlüsseln der Nachricht unter Verwendung eines Verbindungsteilstrecken-Verschlüsselungsschlüssels (PB), der sowohl der besagten Vorrichtung als auch der zweiten Datenverarbeitungsvorrichtung bekannt ist, um eine verschlüsselte Nachricht zu bilden; und Senden der verschlüsselten Nachricht von der besagten Vorrichtung an die zweite Vorrichtung, und die sichere Kommunikationsverbindungsteilstrecke zu initialisieren.
  • Diese Datenverarbeitungsvorrichtung kann zum Beispiel ein intelligentes Endgerät oder ein nicht programmierbares Endgerät in Verbindung mit einem anderen Verarbeitungssystem umfassen, zum Beispiel um die erforderlichen kryptographischen Funktionen durchzuführen.
  • Unter weiteren Aspekten stellt die Erfindung Computerprogrammcode zur Implementierung der oben beschriebenen Verfahren in einem oder mehreren Datenverarbeitungssystemen einer Kette bereit. Dieser Code wird vorzugsweise auf einem Träger gespeichert, wie etwa einer Festplatte oder Diskette, CD- oder DVD-ROM, oder auf einem programmierten Speicher, wie etwa einem Festwertspeicher oder Flash-Speicher, oder er kann auf einem optischen oder elektrischen Signalträger bereitgestellt werden. Der Fachmann wird anerkennen, daß die Erfindung entweder ausschließlich in Software oder durch eine Kombination von Software (oder Firmware) und Hardware oder ausschließlich in Hardware implementiert werden kann. Ebenso müssen die Schritte des Verfahrens nicht unbedingt innerhalb eines einzigen Verarbeitungselements durchgeführt werden, sondern können auf eine Vielzahl solcher Elemente verteilt werden, zum Beispiel auf ein Netzwerk von Prozessoren.
  • Ausführungsformen der Erfindung unterstützen somit das Herunterladen von Software, Tickets und Coupons und anderen Daten, zum Beispiel Auszügen aus Medienstromdaten, wie etwa Musik und MPEG-Filmausschnitte, und Internethandel-Daten.
  • Die Erfindung wird nunmehr nur zu Beispielzwecken mit Bezug auf die beigefügten Zeichnungen weiter beschrieben, wobei diese folgendes zeigen:
  • 1 zeigt eine allgemeine Struktur für ein 3G-Mobiltelefonsystem;
  • 2 zeigt eine schematische Darstellung einer sicheren Kommunikationsverbindungsteilstrecke zwischen einem mobilen Endgerät eines Kommunikationsnetzwerks und einem Server;
  • 3 zeigt ein Beispiel einer Hardware- und Software-Architektur für softwaredefinierte Funkgeräte (SDR);
  • 4 zeigt ein Beispiel eines persönlichen Netzwerks und dazugehöriger Infrastruktur;
  • 5 zeigt eine Kette von mobilen Instanzen in Kommunikation mit einem Server, der dafür konfiguriert ist, ein sicheres Delegationsprotokoll zu implementieren; und
  • 6 zeigt ein Computersystem, das zur Verwendung als Endgerät oder als der Server von 5 geeignet ist, um ein Verfahren gemäß einer Ausführungsform der vorliegenden Erfindung zu implementieren.
  • Menschen sind zunehmend auf Mobiltelefone, Laptops, PDAs und ähnliche Ausrüstung angewiesen und können auch Peripheriegeräte, wie etwa Kopfhörer und Musikwiedergabegeräte, bei sich tragen. Das Konzept eines persönlichen Netzwerks (PAN) zieht die lokale (das heißt personengebundene) Kommunikation zwischen diesen Vorrichtungen unter Verwendung von Technologien wie etwa IrDA, Bluetooth und/oder WLAN-Technologien (zum Beispiel IEEE 802.11) in Betracht. Einige PANs können einen Komponentenadministrator aufweisen, um für Kontrolle durch die Autorisationsbehörde zu sorgen. Endgeräte eines PAN werden grundsätzlich in zwei Klassen kategorisiert, nämlich intelligente Endgeräte (wie etwa PDA, intelligentes Telefon, Laptop oder Auto), die das PAN steuern und konfigurieren können, und nicht programmierbare Endgeräte (wie etwa Drucker, Scanner, Speichermedien und Benutzerschnittstellenvorrichtungen), die grundsätzlich nur eine Funktion bereitstellen und mit intelligenten Endgeräten verbunden sind. Ein nicht programmierbares Endgerät kann mit einem intelligenten Endgerät kommunizieren, um zum Beispiel eine Anforderung für ein Delegationstoken zu bewerten, wobei das intelligente Endgerät ein Ergebnis einer solchen Bewertung zurücksendet. Von den zwei Klassen von Endgeräten wird erwartet, daß sie eine einheitliche Schnittstelle zur Konfiguration und Zugangssteuerung sowohl auf der Ebene der jeweiligen Vorrichtung als auch auf der PAN-Ebene unterstützen. Für nicht programmierbare Endgeräte ist dies eine Ergänzung zu ihrem spezialisierten Funktionsumfang und kann Fähigkeit zur Schlüsselverwaltung, Fähigkeit zur Softwareaktualisierung und Dienstankündigung aufweisen. Manche nicht programmierbare Endgeräte können auch imstande sein, Dienstermittlung durchzuführen, und können sogar imstande sein, ohne Unterstützung Dienste von anderen Vorrichtungen anzufordern.
  • Es gibt zwei hauptsächliche Sicherheitsfragen für heruntergeladene Software, nämlich erstens den Schutz des Ursprungs und der Integrität der Software gegen jegliche zufällige oder absichtliche Verfälschung und zweitens die Bereitstellung eines Autorisationssystems, das zum Beispiel ein SDR befähigt, eine automatische Entscheidung zu treffen, ob heruntergeladene Software akzeptiert und daraus folgend zur Rekonfiguration des SDR verwendet werden soll oder nicht. Das Hinzufügen einer digitalen Signatur in einer PKI zu einem Stück eines Codes kann durch den Empfänger des Codes verwendet werden, um dessen Korrektheit und Ursprung zu überprüfen. Wie oben beschrieben, kann der öffentliche Schlüssel, der nötig ist, um die Signatur zu prüfen, aus einem öffentlichen Schlüssel-Zertifikat erlangt werden, das entweder mit dem signierten Code gesendet oder durch den Empfänger des Codes aus einem Aufbewahrungsort abgerufen wird. Wenn der Code bestätigt worden ist, kann das SDR entscheiden, ob der Code akzeptiert wird oder nicht, und zwar auf der Grundlage eines oder mehrerer der folgenden, nämlich der Identität der Zertifikatsbehörde, der Strategiekennungen in dem bzw. den Zertifikat(en), die überprüft wurden, um den öffentlichen Schlüssel des Unterzeichners des Codes zu erlangen, einer oder mehrerer Grundsatzerklärungen, die durch den Hersteller in die Vorrichtung eingebaut wurden, zusammen mit jeglichen Grundsatzerklärungen, die durch den Besitzer und/oder Benutzer der Vorrichtung eingegeben wurden, und jeglicher Information, die dem Code direkt zugeordnet ist, wie etwa Einzelheiten über den beabsichtigten Verwendungsbereich des Codes.
  • In Ausführungsformen der Erfindung, die asymmetrische Kryptographie (das heißt Kryptographie mit öffentlichen Schlüsseln) verwenden, wird angenommen, daß PKI verwendet wird und daß vertrauenswürdige Teilnehmer, wie etwa Hersteller, Betreiber, vertrauenswürdige Dritte und Regierungsbehörden, ihre Zertifikate an mobile Endgeräte ausgeben, die sie speichern können, zum Beispiel in manipulationssicheren Hardwaremodulen. In einigen Ausführungsformen, die symmetrische Kryptographie (das heißt gemeinsam genutzter geheimer Schlüssel) verwenden, ist keine PKI-Infrastruktur nötig, zum Beispiel, wenn nur die Sicherstellung der Integrität erforderlich ist.
  • 4 zeigt ein Beispiel eines PAN und der zugeordneten Netzwerkinfrastruktur. Ein PAN 400 im dargestellten Beispiel umfaßt ein mobiles Endgerät 402, einen PDA 404 und eine Kamera 406 in drahtloser (RF-)Kommunikation miteinander. Das mobile Endgerät 402 kommuniziert auch mit einer Basisstation 408 eines ersten 3G-Mobiltelefonnetzes 410, das ein Gateway 412 zum Internet 414 hat. Ein zweites mobiles Endgerät 416, das ein zweiter Benutzer bei sich trägt, kommuniziert mit einer zweiten Basisstation 418 eines zweiten 3G-Mobiltelefonnetzes 420 mit einem zweiten Gateway 422 zum Internet 414. Der PDA 404 kommuniziert ebenfalls mit einem WLAN 424, wie etwa einem IEEE-802.11-WLAN, das ebenfalls mit dem Internet 414 gekoppelt ist. Wie man anerkennen wird, können viele andere Systeme mit dem Internet gekoppelt sein, wie die dargestellten ersten und zweiten Server dritter Softwareentwickler 426, 428, die Heim-PCs 430 und ein oder mehrere Internethandel-Server 432. Die mobilen Endgeräte 402 und 416 können auch eine direkte Kommunikationsleitung zueinander haben, wie durch die gestrichelte Linie 434 dargestellt, zum Beispiel über eine Bluetooth-Verbindungsteilstrecke.
  • Es ist hilfreich, die Verwendung einer Delegierung anhand eines Beispiels darzustellen. In einem einfachen Beispiel möchte der Benutzer des mobilen Endgeräts 402 die Software seines Endgeräts durch Herunterladen neuer Software vom Hersteller des Endgeräts aktualisieren. Um dies zu erreichen, kann das mobile Endgerät 402 ein Delegationstoken (DT) an einen Diensteanbieter oder den Netzwerkbetreiber des Telefonnetzes 410 weitergeben, der wiederum das Delegationstoken an den Hersteller weitergibt, wobei dann der Hersteller die Aufgabe der Durchführung der Softwareaktualisierung an den Diensteanbieter oder Netzwerkbetreiber delegiert.
  • In einem anderen Beispiel möchte der Benutzer des mobilen Endgeräts 402 (der von nun an als mobiler Teilnehmer A bezeichnet wird) einen Ausschnitt eines neuen Films (oder irgendeine andere Software) erlangen, aber das zugeordnete Netzwerk 410 stellt diesen Dienst nicht bereit. Jedoch stellt das Netzwerk 420, das von einem anderen Betreiber betrieben wird, diesen Dienst bereit, und der mobile Teilnehmer A ist deshalb imstande, den Filmausschnitt vom Benutzer des mobilen Endgeräts 416 zu erlangen (der von nun an als mobiler Teilnehmer B bezeichnet wird), der ihn, wenn nötig, zuerst vom Netzwerk 420 erlangt. Im Folgenden werden zwei Beispiele betrachtet, zuerst jenes, in dem der mobile Teilnehmer A den Filmausschnitt direkt vom mobilen Teilnehmer B erlangen kann, und zweitens eine Situation, wo der mobile Teilnehmer B den Ausschnitt von einem weiteren mobilen Teilnehmer C, in diesem Fall dem Netzwerkbetreiber 420, anfordern muß.
  • 5 zeigt eine Kette 500 von Endgeräten, die mit einem mobilen Endgerät A 502 beginnt, das mit einem Endgerät B 504 kommuniziert, wobei die Kette in dem dargestellten Beispiel schließlich in einem Endgerät Z 506, wie etwa einem Server, endet. Jedes Endgerät umfaßt einen Prozessor, der mit einem Speicher gekoppelt ist, wobei der Speicher kryptographischen Code, wie etwa symmetrischen und/oder asymmetrischen Verschlüsselungs- und Entschlüsselungscode, und öffentliche Schlüsselzertifikate (oder, in anderen Ausführungsformen, gemeinsam genutzte symmetrische Schlüssel) speichert. Jeder Prozessor ist außerdem mit einer oder mehreren Kommunikationsverbindungsteilstrecken verbunden, um drahtlose (oder drahtgebundene) Kommunikationsverbindungsteilstrecken mit dem Endgerät oder den Endgeräten auf jeder Seite der Kette zu implementieren. Das Endgerät A 502 im dargestellten Beispiel umfaßt ein mobiles Endgerät mit einer SIM-Karte, die zum Beispiel auch digitale Zertifikatsdaten speichern kann.
  • 6 zeigt ein Allzweck-Computersystem 600, das zur Verwendung als eines der Endgeräte in der Kette geeignet ist. Das Computersystem 600 umfaßt einen Adreß- und Datenbus 602, mit dem eine Tastatur 608, eine Anzeige 610 und eine Mensch-Maschine-Schnittstelle (MMI) 606, wie etwa eine Audio- und/oder Berührungsbildschirm-Schnittstelle, gekoppelt sind. In einigen Ausführungsformen kann ein kryptographisches Verarbeitungssystem, das heißt ein Speicher und ein (möglicherweise zweckgebundener) Prozessor, auf einer auswechselbaren Karte, wie etwa einer SIM-Karte, ausgebildet sein. 6 kann somit ein solches System darstellen, wenngleich dann im allgemeinen keine MMI vorhanden sein wird. Ebenfalls mit dem Bus 602 gekoppelt ist eine Kommunikationsschnittstelle 604, wie etwa eine Netzwerkschnittstelle (für einen Server), eine Funk- oder Infrarot-Schnittstelle (für ein Telefon oder einen PDA) oder eine Kontaktflächen-Schnittstelle (für eine SIM-Karte). Außerdem mit dem Bus 602 gekoppelt sind ein Prozessor 612, ein Arbeitsspeicher 614, ein nichtflüchtiger Datenspeicher 616 und ein nichtflüchtiger Programmspeicher 618, wobei der nichtflüchtige Speicher normalerweise Flash-Speicher umfaßt.
  • Der nichtflüchtige Programmspeicher 618 speichert Kryptographiecode, das heißt Verschlüsselungs- und Entschlüsselungscode, Verifizierungscode für digitale Signaturen bzw. MACs, Code zur Erzeugung von Nachrichten- und Delegationsschlüsseln und Treibercode für die Kommunikationsschnittstelle. Der Prozessor 612 implementiert diesen Code, um entsprechende Prozesse bereitzustellen, um Verfahren gemäß den Ausführungsformen der Erfindung zu implementieren. Der nichtflüchtige Datenspeicher 616 speichert einen öffentlichen Schlüssel, vorzugsweise innerhalb eines digitalen Zertifikats (wenn asymmetrische Kryptographie verwendet wird) und/oder von symmetrischen Sitzungsschlüsselzertifikaten (wenn symmetrische Kryptographie verwendet wird).
  • Der Arbeitsspeicher kann verwendet werden, um ein oder mehrere Delegationstoken mit Delegationsschlüsseln zu speichern und um Software zu speichern, die empfangen oder heruntergeladen wurde, um sie an ein anderes Endgerät weiterzugeben (am Ende der Kette kann diese Software in einem nichtflüchtigen Speicher gespeichert werden, zum Beispiel in einem SDR). Die Software kann Computerprogrammcode und/oder Daten, wie etwa Video- oder MP3-Daten, umfassen.
  • Zur Vereinfachung wird im folgenden Text auf mobile Teilnehmer Bezug genommen, da die beschriebenen Protokolle vor allem für die Kommunikation zwischen solchen Teilnehmern nützlich sind. Jedoch sollte dies nicht so interpretiert werden, daß es in irgendeiner Weise die Anwendungen der Protokolle einschränkt, die auch mit stationären Teilnehmern oder Endgeräten nutzbringend verwendet werden können. Außerdem wird "Endgerät" hier in einem weiten Sinn verwendet, um ein Datenverarbeitungssystem mit einer gewissen Kommunikationsfähigkeit zu bezeichnen.
  • In einer Ausführungsform eines Protokolls zum sicheren mobilen Delegieren, zum Beispiel für ein rekonfigurierbares Endgerät, sendet ein mobiler Teilnehmer A eine signierte Nachricht M1 an einen mobilen Teilnehmer B, wie in nachstehender Gleichung 1 dargelegt: M1: A → B : B ∥ TA/NA ∥ PB(KP-T-E ∥ Γ ∥ SA(h(DT))) (Gleichung 1)wobei A → B bedeutet, daß A M1 an B sendet, und ∥ die Verkettung von Daten bezeichnet. In Gleichung 1 ist DT ein Delegationstoken, und PB(Y) bezeichnet die asymmetrische Verschlüsselung (mit öffentlichem Schlüssel) (zum Beispiel unter Verwendung von RSA) von Y unter Verwendung des öffentlichen Schlüssels von B, SA(Y) bezeichnet eine Signaturoperation auf Y unter Verwendung des privaten (Signatur-)Schlüssels von A, und h bezeichnet eine kollisionsresistente Einweg-Hash-Funktion (wie etwa die oben erwähnten MD4- oder MD5-Algorithmen). Das Delegationstoken DT ist gegeben durch: DT = KP-T-E ∥ B ∥ TA/NA ∥ Γ (Gleichung 2)wobei Γ = (R, L) ist, R eine Anforderung oder eine Menge an Rollen oder Aufgaben bezeichnet und L eine Nutzungsdauer des Delegationstokens DT bezeichnet, das durch den mobilen Teilnehmer A erzeugt wurde, und wobei KP-T-E als "Ausführungsvollmacht"-Delegationsschlüssel für die Verbindungsteilstrecke zwischen dem mobilen Teilnehmer A und dem mobilen Teilnehmer B bezeichnet wird (welcher entweder ein symmetrischer Schlüssel oder ein öffentlicher Schlüssel sein kann, der durch den mobilen Teilnehmer A erzeugt wurde). Der Ausdruck "Ausführungsvollmacht" trifft zum Beispiel zu, wenn ein Endgerät A ein neues Betriebssystem von einem Hersteller über einen Netzwerkbetreiber herunterladen und ausführen soll, da der auszuführende Code durch KP-T-E verschlüsselt wird. Der entsprechende geheime Schlüssel, der durch den mobilen Teilnehmer A erzeugt wurde, wird geheimgehalten. Wenn der Schlüssel KP-T-E ein öffentlicher Schlüssel ist, dann hat der mobile Teilnehmer A einen öffentlichen Schlüssel, der als öffentlicher Verschlüsselungsschlüssel verwendbar ist, und einen geheimen Schlüssel, der zum Signieren verwendet wird. Dieses Paar von Schlüsseln, die jeweils eine große Primzahl umfassen, kann auf herkömmliche Weise erzeugt werden, zum Beispiel unter Verwendung eines Generators vom Blum-Blum-Shub-Typ.
  • Methoden zur Erzeugung von Pseudo-Zufallszahlen sind in L. Blum, M. Blum und M. Shub, "A simple unpredictable random number generator", SIAM Journal on Computing, Bd. 15, S. 364-383, 1986, und in W. Alexi, B. Chor, O. Goldreich und C.P. Schnorr, "RSA and Rabin Functions: Certain parts are as hard as the whole", SIAM Journal of Computing, Bd. 17, S. 194-209, 1988, beschrieben, worauf Bezug genommen werden kann.
  • Der Wert TA ist ein optionaler Zeitstempel, der durch A erzeugt wird, und NA ist eine optionale Einmalzahl (nur einmal verwendete Zahl), die durch A erzeugt wird. Eine Einmalzahl kann durch einen deterministischen Pseudozufallszahlen-Generator erzeugt oder als Ausgangselement für ihn verwendet werden (zum Beispiel, um synchronisierte Folgen von Pseudo-Zufallszahlen zu erzeugen). Die Frage, ob man einen Zeitstempel oder eine Einmalzahl verwendet, hängt von den technischen Möglichkeiten der mobilen Teilnehmer und von der Umgebung ab – zum Beispiel behindert die Nutzung eines Zeitstempels Aufzeichnungswiedergabe-Angriffe, aber eine Einmalzahl kann bevorzugt werden, wenn die Endgeräte keine angemessen synchronisierten Taktgeber haben.
  • Die Einbeziehung einer Kennung B in M1 und eines Delegationstokens DT ist erwünscht, um zu verhindern, daß das Token durch irgendjemand anders als den vorgesehenen Prüfer akzeptiert wird.
  • In einer Variante dieses Protokolls kann symmetrische statt asymmetrischer Kryptographie verwendet werden. In dieser Variante haben der mobile Teilnehmer A und der mobile Teilnehmer B eine vorher eingerichtete Beziehung in Form eines gemeinsam genutzten geheimen Schlüssels k1, und ein chiffrierter Hash- oder Nachrichtenauthentifikationscode (MAC), wie etwa einer der in ISO 8731-1 (oben erwähnt) definierten MAC-Algorithmen kann als digitale Signatur verwendet werden. Ein oder mehrere gemeinsam genutzte Schlüssel können zum Beispiel unter Verwendung der in Yeun und Farnham (ebenda) und in den UK-Patentanmeldungen 0201048.6 und 0201049.4 beschriebenen Methoden eingerichtet werden. In einem Szenarium, wo ein mobiler Teilnehmer häufig mit dem gleichen mobilen Teilnehmer (oder einer Menge von mobilen Teilnehmern) kommuniziert, kann dies eine effizientere Lösung sein, da weniger Verarbeitungsleistung erforderlich ist.
  • Eine Nachricht M1 wird wie folgt von A nach B gesendet: M1: A → B : B ∥ TA/NA ∥ EK1(KP-T-E ∥ Γ ∥ MACk1(DT)) (Gleichung 3)
  • Hierbei bezeichnet EK1(Y) die symmetrische Verschlüsselung von Y unter Verwendung eines Schlüssels K1, der von A und B gemeinsam genutzt wird. Wenn ein mobiler Teilnehmer auf einem Hauptrechner Aktivitäten ausführt, der vertrauenswürdig ist, und die Geheimnisse des mobilen Teilnehmers (das heißt zum Beispiel die kryptographischen Schlüssel, die sich in sicheren Hardwaremodulen befinden) nicht gefährdet waren, ist das Protokoll von Gleichung 3 hinreichend, um eine Datenursprungsgarantie zu gewähren. Wenn KP-T-E ein symmetrischer kryptographischer Schlüssel ist, kann er auf herkömmliche Weise erzeugt werden, zum Beispiel unter Verwendung einer Pseudo-Zufallszahl, die wahlweise hashverarbeitet und/oder mit Zeitdaten kombiniert ist, abhängig von den Fähigkeiten des Endgeräts. Der Schlüssel KP-T-E ist eine Form eines Sitzungsschlüssels, der nicht wiederverwendet wird (nach einer Sitzung oder nach einem Nutzungszeitraum), wodurch seine Anfälligkeit für Angriffe verringert wird.
  • Wie bereits ausgeführt, ist das Delegationstoken DT zum Schutz gegen Delegationstoken-Vervielfältigung und Delegationstoken-Löschung vorzugsweise so aufgebaut, daß es den vorgesehenen Empfänger und einen "Neuheitswert", wie etwa einen Zeitstempel und/oder eine Zufallszahl (die mehr als einmal verwendet werden kann, zum Beispiel eine Zahl aus einer Pseudozufallssequenz), und/oder eine Einmalzahl aufweist. Wie bereits erwähnt, erfordern taktbasierte Zeitstempel synchronisierte Takte, was möglicherweise für einige Plattformen nicht praktikabel ist.
  • Die oben erwähnten Protokolle eignen sich zur gestaffelten Delegierung, das heißt, wenn es mehrere mobile Teilnehmer gibt, nämlich zur Delegierung, die von einem ersten mobilen Teilnehmer A zu einem zweiten Teilnehmer in der Kette B, dann zu einem dritten Teilnehmer C und so weiter gestaffelt ist, bis zu einem letzten Teilnehmer der Kette, sagen wir Z, bevor Daten zurückgesendet werden oder eine Endnachricht an den ursprünglichen mobilen Teilnehmer A gesendet wird. Eine solche Kette ist bereits mit Bezug auf 5 ausführlicher beschrieben worden.
  • In den nachstehend beschriebenen gestaffelten Protokollen wird angenommen, daß dem ersten mobilen Teilnehmer A durch die anderen mobilen Teilnehmer vollständig vertraut wird und daß jeder der mobilen Teilnehmer A bis Z imstande ist, eine gültige Signatur zu erzeugen, indem er einfach den kryptographischen Schlüssel des mobilen Teilnehmers verwendet, um ein Delegationstoken zu signieren. Die beschriebenen Protokolle haben den Vorteil einer relativ geringen Erhöhung der Komplexität und Nachrichtengröße, während die Staffelung der Delegation entlang der Kette fortschreitet.
  • Sowohl für die asymmetrischen als auch für die symmetrischen kryptographischen Ausführungsformen ist der Anfangsschritt der Delegation (das heißt der von A nach B) der gleiche wie bereits beschrieben. Somit gilt für die asymmetrische Kryptographie: M1: A → B : B ∥ TA/NA ∥ PB(KP-T-E ∥ Γ ∥ SA(hDT))) (Gleichung 4)
  • Die Nachricht für einen zweiten Delegationsschritt von B nach C lautet dann: M2: B → C : C ∥ TB/NB ∥ B ∥ TA/NA ∥ PC(KP-T-E ∥ Γ' ∥ SB(h(DT')) ∥ Γ ∥ KP-T-E ∥ SA(h(DT))) (Gleichung 5)wobei DT' = KP-T-E ∥ C ∥ TB/NB ∥ Γ'
  • KP-T-E ist ein "Ausführungsvollmacht"-Delegationsschlüssel zwischen dem mobilen Teilnehmer B und dem mobilen Teilnehmer C, und Γ' = (R', L'), wobei R' eine Anforderung oder Menge von Rollen oder Aufgaben ist und L' eine Nutzungsdauer des Delegationstokens DT ist, das durch den mobilen Teilnehmer B erzeugt wurde. Es wird anerkannt, daß SA(h(DT)) für B zur Einbeziehung in M2 verfügbar ist, da es durch B (verschlüsselt) in Nachricht M1 empfangen wurde.
  • Somit wird das durch den mobilen Teilnehmer A bereitgestellte DT in die Nachricht des mobilen Teilnehmers B einbezogen oder gestaffelt. Die Einbeziehung der Kennung C in M2 und DT' ist erwünscht, um zu verhindern, daß das Token durch irgendjemand anders als den vorgesehenen Prüfer akzeptiert wird, und wie zuvor kann außerdem ein Neuheitswert, wie etwa ein Zeitstempel TB oder eine Einmalzahl NB, hinzugefügt werden. Weitere Delegierungen haben weitere signierte DTs durch Erweiterung der gleichen Prozedur bei Bedarf zur Folge.
  • Im Fall der symmetrischen Kryptographie wird eine vorher hergestellte Beziehung in Form gemeinsam genutzter geheimer Schlüssel ki, i = 1, 2, ..., n und chiffrierter Hash- oder MAC-Signaturen angenommen. Hierbei ist ein mobiler Teilnehmer imstande, einen gültigen MAC zu erzeugen, indem er seinen kryptographischen Schlüssel verwendet, um das relevante Delegationstoken zu MAC-codieren. Da jedoch jeder symmetrische Schlüssel vorzugsweise nur zwischen jedem Paar von mobilen Teilnehmern in der Kette gemeinsam genutzt wird (im Gegensatz zum Beispiel dazu, daß jeder Teilnehmer die gemeinsam genutzten geheimen Schlüssel für jeden anderen Teilnehmer in der Kette kennt), wird, wenn es eine Auseinandersetzung gibt, jeder Teilnehmer in der Kette in die Überprüfung und Bestätigung oder Verifizierung der Delegationskette einbezogen, zum Beispiel indem jeder Teilnehmer den MAC bestätigt, den er empfangen hat.
  • Ein Protokoll für die Staffeldelegation bei symmetrischer Kryptographie folgt.
  • Der Anfangsschritt der Delegation (das heißt der von A nach B) ist der gleiche, wie bereits für die symmetrische Kryptographie beschrieben: M1: A → B : B ∥ TA/NA ∥ EK1(KP-T-E ∥ Γ ∥ MACk1(DT)) (Gleichung 6)
  • Die Nachricht für einen zweiten Schritt der Delegation, von B nach C, ist dann: M2: B → C : C ∥ TB/NA ∥ B ∥ TA/NA ∥ EK2(KP-T-E' ∥ Γ' ∥ MACk2((DT') ∥ Γ ∥ KP-T-E ∥ MACk1(DT)) (Gleichung 7)wobei EK1(Y) die symmetrische Verschlüsselung von Y unter Verwendung des gemeinsam genutzten Schlüssels Ki, i = 1, 2, ..., n zwischen i und i + 1 bezeichnet, wobei das durch B erzeugte Delegationstoken DT lautet: DT' = KP-T-E ∥ C ∥ TB/NB ∥ Γ'und wobei KP-T-E ein "Ausführungsvollmacht"-Delegationsschlüssel zwischen dem mobilen Teilnehmer B und dem mobilen Teilnehmer C ist und Γ' = (R', L'), wobei R' eine Anforderung oder Menge von Rollen oder Aufgaben ist und L' eine Nutzungsdauer des Delegationstokens DT ist, das durch den mobilen Teilnehmer B erzeugt wurde.
  • Wieder wird das durch den mobilen Teilnehmer A bereitgestellte DT in die Nachricht des mobilen Teilnehmers B einbezogen oder gestaffelt. Die Einbeziehung der Kennung C in M2 und DT' ist erwünscht, um zu verhindern, daß das Token durch irgendjemand anders als den vorgesehenen Prüfer akzeptiert wird, und wie zuvor kann außerdem ein Neuheitswert, wie etwa ein Zeitstempel TB oder eine Einmalzahl NB, hinzugefügt werden. Weitere Delegationen haben weitere signierte DTs durch Erweiterung der gleichen Prozedur bei Bedarf zur Folge.
  • Ein Beispiel für die Prozedur am Endpunkt der Kette der Delegation wird nunmehr beschrieben. Wenn ein Absender, wie etwa der mobile Teilnehmer A, Rechte an einen Übermittler und schließlich an einen letzten Delegierten weitergibt, etwa den mobilen Teilnehmer Y, dann kontaktiert der letzte Delegierte zum Beispiel den Server Z eines geeigneten Dienstanbieters (den Endpunkt der Kette) und demonstriert, daß er gültige (das heißt richtig signierte) DTs innehat, um anzufordern, daß dem mobilen Teilnehmer A ein Dienst bewilligt wird.
  • Damit der Server die Anforderung verifizieren kann, werden alle (signierten) DTs angefügt, so daß, wenn eine Registrierung der Verantwortlichkeit benötigt wird, die Ausbreitung der DTs registriert werden kann. Dies wird erreicht, indem jeder Teilnehmer ein bestimmtes DT signiert, wenn er es zum nächsten Teilnehmer weitergibt, und indem außerdem alle signierten DTs angehängt werden, die in einer gestaffelten Delegation erzeugt worden sind. Der Endpunkt ist imstande, alle angefügten Signaturen zu bestätigen (weil zum Beispiel in PKI geeignete öffentliche Schlüsselzertifikate verfügbar sind), aber es ist möglicherweise nur zulässig, ausschließlich das delegierte KP-T-E zu verwenden, das durch den letzten Teilnehmer in der Kette von mobilen Teilnehmern beigebracht wurde. Die Ursache dafür ist, daß Daten, die unter Verwendung dieses Schlüssels (ganz gleich, ob asymmetrischer oder symmetrischer Schlüssel) verschlüsselt wurden, möglicherweise nur durch den letzten Teilnehmer in der Kette der mobilen Teilnehmer entschlüsselt oder verstanden werden können. Alternativ kann der Server Z, abhängig zum Beispiel von der Anwendung und von den verfügbaren Kommunikationsverbindungsteilstrecken, unter Verwendung des KP-T-E von A direkt zurück an A antworten.
  • Diese Anordnung ermöglicht auch eine Registrierung darüber, wo Token verwendet wurden. Ein DT stellt eine Vollmacht dar, das heißt es ermöglicht eine sichere Kommunikation oder irgendeine andere Sicherheitsfunktion (ein KP-T-E kann zum Beispiel für eine Signatur verwendet werden), aber ein DT stellt nicht unbedingt eine Erlaubnis bereit, diese Vollmacht auszuüben. Zum Beispiel kann mit Bezug auf 4 das Netzwerk 420 dem mobilen Endgerät 416 verbieten, dem Endgerät 402, das durch ein anderes Netzwerk, das Netzwerk 410, versorgt wird, Software (Code oder Daten) bereitzustellen. Somit kann die Erlaubnis, eine Vollmacht zu gebrauchen, nur gewährt werden, wenn dem Endpunkt (zum Beispiel Server Z) auf eine Dienstanforderung folgend ein DT vorgelegt und erfolgreich auf eine Zugriffssteuerungsstrategie hin geprüft wurde. Solche Prüfungen können zusätzliche Kommunikation mit dem mobilen Teilnehmer A erfordern, und wenn dem so ist, kann diese Kommunikation zum Beispiel über einen sicheren Kanal durchgeführt werden, wie etwa SSL (Secure Sockets Layer) mit PKI-Unterstützung, der für gegenseitige Authentifizierung, Vertraulichkeit und Integrität zwischen dem mobilen Teilnehmer A und dem Endpunkt sorgt. Normalerweise wird eine Erlaubnis benötigt, zum Beispiel von einem Entwickler, um Software herunterzuladen und auszuführen, aber andere Dateninstanzen, zum Beispiel Coupons, können möglicherweise ohne Erlaubnis übertragen werden.
  • Mit erneutem Bezug auf das oben erwähnte Beispiel, das mit Bezug auf 4 erörtert wurde, wo der mobile Teilnehmer A einen Filmausschnitt vom mobilen Teilnehmer B anfordert, ist in einer Ausführungsform des Verfahrens oder Protokolls der Ablauf der Ereignisse wie folgt:
    • 1. Das mobile Endgerät 402 (A) erzeugt ein Delegationstoken, das einen Delegationsschlüssel K und eine Anforderung Γ für den erwünschten Filmausschnitt umfaßt (wobei zum Beispiel der Schlüssel K auf herkömmliche Weise erzeugt wird, wie oben beschrieben). Die Anforderung Γ weist vorzugsweise Nutzungsdauerdaten L auf, die einen Gültigkeitszeitraum für das Delegationstoken DT festlegen, zum Beispiel eine Stunde oder ein Tag für einen Filmausschnitt, sowie die Anforderungsdaten R. Eine Anforderung kann in eine Folge von Teilanforderungen zerlegt werden, so daß zum Beispiel ein vollständiger Film angefordert werden kann, indem eine Reihe von 15-minütigen Filmausschnitten angefordert wird, oder ein Softwareartikel, wie etwa ein Spiel, in einer ursprünglichen Grundversion angefordert werden kann, wobei zusätzliche Merkmale später hinzugefügt werden.
    • 2. Das Endgerät A unterzieht das Delegationstoken DT einer Hash-Verarbeitung und verschlüsselt dann den der Hash-Verarbeitung unterzogenen Wert mit dem privaten Schlüssel von A, um eine digitale Signatur zu erzeugen (alternativ kann eine MAC-Funktion auf das DT angewendet werden). Die Hash-Verarbeitung ist nicht zwingend, wird aber bevorzugt, da sie den Umfang der zu sendenden Daten verringert; in anderen Ausführungsformen kann das DT jedoch ohne Hash-Verarbeitung signiert werden (optional mit einem Algorithmus, der die Wiederherstellung der Nachricht zuläßt).
    • 3. Das Endgerät A ruft einen öffentlichen Schlüssel PB aus einem Zertifikat für das Endgerät B ab, das zum Beispiel aus einem (nur lesbaren) Aufbewahrungsort heruntergeladen wird, der vom Netzwerkbetreiber 410 oder dem Netzwerkbetreiber 420 betrieben wird. Das Endgerät A verschlüsselt dann den Delegationsschlüssel K, die Anforderung Γ und die digitale Signatur (oder den MAC) unter Verwendung des öffentlichen Schlüssels PB (oder eines gemeinsam genutzten geheimen Schlüssels von A und B).
    • 4. Das Endgerät A erzeugt eine Nachricht M1, wie oben beschrieben, mit einer Kennung B für das Endgerät B (erforderlich, wenn es mehr als einen möglichen Empfänger gibt, und in jedem Fall bevorzugt, um einen Nachahmungsangriff zu verhindern) und vorzugsweise einem Zeitstempel oder einer Einmalzahl zwecks Neuheit. Das ermöglicht, daß die Nachricht M1 nach einem Zeitintervall verfällt, zum Beispiel, wenn es keine Antwort innerhalb eines Zeitfensters gibt, und ermöglicht somit, daß ein relativ kurzer Zeitabschnitt definiert wird, währenddessen ein Angriff möglich ist. Ein Zeitstempel kann bevorzugt werden, wenn die Endgeräte in der Kette synchronisierte Takte haben (etwa auf weniger als eine Sekunde), andernfalls kann eine Einmalzahl verwendet werden, die durch einen Pseudozufallszahlen-Generator erzeugt wird, der von einem bekannten Samen ausgeht. Vorzugsweise weist das Delegationstoken DT auch die Kennung für B und den Zeitstempel und/oder die Einmalzahl auf. Auf diese Weise wird, wenn ein Angreifer versucht, den Zeitstempel oder die Einmalzahl zu ändern, dies im Delegationstoken DT zutage treten.
    • 5. Das Endgerät A sendet dann die Nachricht M1 an das Endgerät B unter Verwendung beliebiger herkömmlicher Kommunikationsmittel.
    • 6. Das Endgerät B empfängt die Nachricht M1 vom Endgerät A.
    • 7. Das Endgerät B entschlüsselt den Abschnitt der Nachricht M1, der mit dem öffentlichen Schlüssel (oder, in einem symmetrischen System, mit dem von A und B gemeinsam genutzten geheimen Schlüssel) des Endgeräts B verschlüsselt wurde (in einer PKI-Infrastruktur besitzt das Endgerät B ein digitales Zertifikat für A oder ist imstande, es zu erlangen). Das Endgerät B extrahiert dann den Delegationsschlüssel K, die Anforderung Γ und die digitale Signatur oder den MAC des Endgeräts A.
    • 8. Das Endgerät B rekonstruiert das Delegationstoken DT unter Verwendung des Delegationsschlüssels K, der Anforderung Γ und, wenn verwendet, der Kennung des Endgeräts B und des Zeitstempels bzw. der Einmalzahl. Das Endgerät B wendet dann die gleiche Hash-Funktion wie das Endgerät A auf das Delegationstoken DT an, um h(DT) zu bestimmen, entschlüsselt die Nachricht h(DT), die mit dem privaten Schlüssel von Endgerät A unter Verwendung des öffentlichen Schlüssels von Endgerät A (der zum Beispiel aus einem Aufbewahrungsort heruntergeladen wurde) signiert wurde, und vergleicht die beiden Hash-Werte (alternativ können in einem symmetrischen System die beiden MACs verglichen werden). Wenn die beiden Werte gleich sind, wird die Nachricht als bestätigt oder authentifiziert und somit als gültig betrachtet. (In alternativen Ausführungsformen kann das Endgerät A den Delegationsschlüssel K verwenden, um eine digitale Signatur von h(DT) zu erzeugen, da das Endgerät B diesen Schlüssel kennt oder ihn erlangen kann, um die Signatur zu prüfen. Jedoch bietet dies eine schwächere Sicherheit.) An diesem Punkt hat das Endgerät B das vom Endgerät A gesendete Delegationstoken DT rekonstruiert und bestätigt. Somit ist das Endgerät B im Besitz einer gültigen, authentifizierten Anforderung, von der bekannt ist, daß sie vom Endgerät A stammt (das heißt, verantwortlich ist), und eines Delegationsschlüssels K. Das Endgerät B ist somit imstande, auf die Anforderung zu antworten, den Filmausschnitt (oder andere Daten) mit dem Delegationsschlüssel K zu verschlüsseln und dann die verschlüsselten Daten zurück zum Endgerät A zu senden. Das Endgerät B kann einen zusätzlichen Schritt durchführen, bevor es auf die Anforderung antwortet, zum Beispiel die Überprüfung der Anforderung auf eine Zugriffs- oder Sicherheitsstrategie, zum Beispiel unter Verwendung eines getrennten sicheren Kanals, wie etwa SSL (Secure Sockets Layer) mit PKI-Unterstützung, der für gegenseitige Authentifizierung, Vertraulichkeit und Integrität sorgt. Somit kann, zum Beispiel im Fall eines Filmausschnitts, das Endgerät B mit dem Netzwerkbetreiber prüfen, ob es dem Endgerät A erlaubt ist, den Ausschnitt zu empfangen. Die Fähigkeit des Endgeräts B, als Antwort auf eine Anforderung verschlüsselte Daten an das Endgerät A zu senden, kann somit separat von der Frage behandelt werden, ob das Endgerät B die Erlaubnis hat (im Gegensatz zur Vollmacht), auf die Anforderung zu antworten und die erwünschte Handlung durchzuführen.
    • 9. Wird in diesem Beispiel angenommen, daß das Endgerät B die Erlaubnis hat, dann verschlüsselt Endgerät B den Filmausschnitt unter Verwendung des Delegationsschlüssels und sendet die verschlüsselten Daten zurück an das Endgerät A. (Wenn eine Kette zwischen A und B besteht, können die verschlüsselten Daten entweder die Kette entlang oder direkt von B nach A gesendet zurück werden.)
    • 10. Das Endgerät A empfängt die verschlüsselten Filmausschnittdaten vom Endgerät B und ist imstande, diese Daten zu entschlüsseln. Wenn der Delegationsschlüssel K ein gemeinsam genutzter geheimer Schlüssel ist, entschlüsselt Endgerät A die Daten unter Verwendung eines symmetrischen kryptographischen Algorithmus. Wenn der Delegationsschlüssel K ein öffentlicher Schlüssel eines asymmetrischen kryptographischen Systems ist, bewahrt das Endgerät A den entsprechenden privaten Schlüssel auf und ist daher wieder imstande, die verschlüsselten Daten zu entschlüsseln.
  • Es wird ersichtlich, daß PKI verwendet wird, wenn asymmetrische Kryptographie eingesetzt wird, so daß zum Beispiel das Delegationstoken von A unter Verwendung des öffentlichen Schlüssels von A bestätigt werden kann. In einem praktischen System, wo das Endgerät A ein mobiles Endgerät ist, das eine SIM-Karte einschließt, kann die SIM-Karte ein digitales Zertifikat für jedes Endgerät in der Kette speichern und kann auch einen Prozessor einschließen, zum Beispiel zur Schlüsselerzeugung. Alternativ können alle Endgeräte eines Netzwerkbetreibers mit einem digitalen Zertifikat versorgt werden, das an einem zentralen, gegenseitig zugänglichen Aufbewahrungsort gespeichert ist, oder jegliche nötigen Zertifikate können in einer Nachricht an ein Endgerät gesendet werden.
  • Das oben beschriebene Protokoll behindert die Nachahmung des Delegationsschlüssels K und der Anforderung Γ. Allgemein gesagt erzeugt das Endgerät A ein Delegationstoken mit K und Γ, signiert dieses und verschlüsselt das Token und die Signatur mit dem öffentlichem Schlüssel von B, bevor es die Kombination an das Endgerät B sendet. Das Endgerät B ist imstande, das Token und die Signatur zu entschlüsseln, um den Schlüssel und die Anforderung zu extrahieren und dann den Schlüssel zu verwenden, um die Anforderung zu erfüllen, vorausgesetzt, daß die Signatur als richtig bestätigt wird.
  • Dieses Protokoll kann, wie oben beschrieben, auf den Fall erweitert werden, daß es eine dritte Instanz C in der Kette gibt. Im oben erwähnten Beispiel kann der Teilnehmer C einen Server des Netzwerkbetreibers für das Endgerät B 416 umfassen, so daß, wenn das Endgerät B den Filmausschnitt nicht besitzt, den das Endgerät A angefordert hat, das Endgerät B imstande ist, den Ausschnitt von seinem zugeordneten Netzwerkbetreiber abzurufen, bevor es den Ausschnitt an A weitergibt. In diesem Fall wird die oben erwähnte Prozedur nach Schritt 8 modifiziert, und zwar an dem Punkt, wo das Endgerät B die Nachricht M1 empfangen hat, den Wert des Delegationstokens DT bestimmt hat und bestätigt hat, daß die digitale Signatur oder der MAC die- bzw. derjenige des Endgeräts A ist. Die Prozedur geht dann folgendermaßen weiter:
    • 9. Das Endgerät B erzeugt ein neues Delegationstoken DT mit einem neuen Delegationsschlüssel K und einer neuen Anforderung Γ' auf eine ähnliche Weise wie die Erzeugung des Tokens DT durch das Endgerät A. Sowohl Γ als auch Γ' weisen Anforderungsdaten R für den erwünschten Filmausschnitt auf, aber Γ und Γ' haben im allgemeinen unterschiedliche Gültigkeitsdauern und daher unterschiedliche Nutzungsdauern L und L'. Die Schlüssel K und K sind unterschiedlich, so daß jede Verbindungsteilstrecke der Kette mit einem anderen Schlüssel verschlüsselt ist. Dies sorgt auch für Verantwortlichkeit, wie nachstehend zu sehen sein wird.
    • 10. Das Endgerät B baut eine neue Nachricht M2 auf, die es an das Endgerät C (den Server) sendet, als ob es Endgerät B wäre, das den erwünschten Filmausschnitt anfordert. Somit ist das Endgerät B eigentlich ein Agent für das Endgerät A geworden. Die Nachricht M2 wird aufgebaut, indem an den verschlüsselten Inhalt der Nachricht M1 Daten für das Delegationstoken DT und eine Signatur für das Endgerät B, zum Beispiel mit einer signierten Hash-Funktion von DT oder einem MAC von DT, angehängt werden, und dann das Ganze mit einem öffentlichen Schlüssel (oder einem gemeinsam genutzten geheimen Schlüssel) des Endgeräts C verschlüsselt wird. Optional kann eine Kennung für C und ein Zeitstempel bzw. eine Einmalzahl für B angehängt werden. Die Nachricht M2 wird dann an das Endgerät C gesendet.
    • 11. Das Endgerät C entschlüsselt den verschlüsselten Abschnitt der Nachricht M2 unter Verwendung seines privaten Schlüssels (oder des gemeinsam genutzten geheimen Schlüssels), wobei die entschlüsselten Daten DT und DT und Signaturen für das Endgerät A und das Endgerät B umfassen. (In einer Kette von Endgeräten hat das letzte Endgerät Delegationstoken und Signaturen für alle Endgeräte in der Kette.) Man wird anerkennen, daß es nicht nötig ist, daß das Endgerät B den privaten Schlüssel des Endgeräts A besitzt, um eine Nachricht für das Endgerät C zu erzeugen, die eine durch das Endgerät A signierte Hash-Funktion von DT aufweist, da diese signierte Hash-Funktion von DT durch das Endgerät B in der Nachricht M1 vom Endgerät A (verschlüsselt durch den öffentlichen Schlüssel von B) empfangen wurde. Somit hat das Endgerät C in diesem Beispiel Zugriff auf ein Delegationstoken und eine Signatur für das Token sowohl für das Endgerät B als auch für das Endgerät A (in einer Kette von Endgeräten, für jedes fortlaufende Endgerät in der Kette). Wie bereits erwähnt, ermöglicht PKI, daß jede Signatur jedes Endgeräts (A und B) in der Kette verifiziert wird, und ermöglicht somit, daß jedes Delegationstoken authentifiziert wird. Das Protokoll sorgt auch für Verantwortlichkeit, da jede Instanz in der Kette (in diesem Fall A und B) ihre(n) eigene(n) signierte(n) Anforderung und Schlüssel angefügt hat.
    • 12. Das Endgerät C verifiziert die Signatur jeder Instanz in der Kette (in diesem Fall A und B) und prüft, wenn erwünscht, die Erlaubnisse für die Anforderung oder die Anforderungen. Das Endgerät C kann dann entweder direkt dem Endgerät A antworten, wobei es den Schlüssel K des Delegationstokens DT verwendet, um Daten für A zu verschlüsseln, oder das Endgerät C kann dem Endgerät B antworten, insbesondere um Γ anzufordern, wobei es den Delegationsschlüssel K verwendet, um die Daten zu verschlüsseln, die an das Endgerät B gesendet werden, welches wiederum die Daten weiterleitet, wobei es den Schlüssel K verwendet, um auf eine Anforderung Γ des Endgeräts A zu antworten. Man wird anerkennen, daß, wenn K ein öffentlicher Schlüssel eines asymmetrischen kryptographischen Systems ist, Daten, die durch den Schlüssel K von A verschlüsselt wurden, nur durch das Endgerät A entschlüsselt werden können.
  • Es ist ersichtlich, daß auf diese Weise eine sichere und verantwortliche Delegationskette aufgebaut werden kann, indem die Delegationstoken und die entsprechenden Signaturen gestaffelt werden. Dies ermöglicht einem Endpunkt der Kette, verantwortliche Aktionen, die durch jede Instanz der Kette durchgeführt werden, zu registrieren. Dies sorgt für Verantwortlichkeit, so daß, wenn zum Beispiel das Endgerät B behauptet, daß die Kommunikation mißlungen ist und keine Nachricht vom Endgerät A empfangen wurde, das Endgerät C zu beweisen imstande ist, daß das Endgerät B unrecht hat, da das Delegationstoken und die Signatur des Endgeräts B in der durch das Endgerät C empfangenen und entschlüsselten Nachricht M2 sind. Die PKI-Infrastruktur versorgt das Endgerät C mit den öffentlichen Schlüsseln aller vorherigen Endgeräte in der Kette, und das Endgerät C ist imstande, auf alle dazwischenliegenden Delegationsschlüssel zuzugreifen. Jedoch kann, wenn Daten über die Kette zurückgesendet werden, grundsätzlich nur der Delegationsschlüssel von einem benachbarten (vorherigen) Endgerät zur Verschlüsselung der Daten verwendet werden, die über die Kette zurückzusenden sind, da nur das unmittelbar vorhergehende Endgerät in der Kette den entsprechenden privaten Schlüssel (oder gemeinsam genutzten geheimen Schlüssel) hat.
  • Wenn nur Unleugbarkeit und nicht Verschlüsselung erwünscht ist, kann ein mobiles Endgerät den Delegationsschlüssel, den es erzeugt, auch verwenden, um die Nachricht zu signieren, die es sendet, was die Infrastruktur vereinfacht, aber das Sicherheitsniveau verringert. Man wird anerkennen, daß die symmetrische Kryptographie zwar für eine Integritätsprüfung sorgt, aber nicht für Unleugbarkeit sorgt, wenngleich die symmetrische Kryptographie weniger Verarbeitungsleistung erfordert.
  • An diesem Punkt ist es hilfreich, um die Protokolle zu verstehen, daß eine Zusammenfassung über die Delegationsprozedur bereitgestellt wird, die sich auf die Kernelemente konzentriert. Für die Anfangsnachricht M1 (bei der asymmetrischen Version des Protokolls) umfassen die Kernelemente: M1: A → B : PB(KP-T-E ∥ Γ ∥ SA(h(DT))) (Gleichung 8)wobei DT = KP-T-E ∥ Γ
  • In der symmetrischen Version des Protokolls wird PB zu EK1 und SA(h(DT)) wird zu MACk1(DT).
  • In der zweiten Nachricht M2 (bei der asymmetrischen Version des Protokolls) umfassen die Kernelemente: M2: B → C : PC(KP-T-E ∥ Γ' ∥ SB(h(DT')) ∥ Γ ∥ KP-T-E ∥ SA(h(DT))) (Gleichung 9)wobei DT' = KP-T-E ∥ Γ'
  • Wiederum wird in der symmetrischen Version des Protokolls PC zu EK1 und SB(h(DT)) wird zu MACk2(DT).
  • Der Fachmann wird die Erweiterung dieses Protokolls auf M3: C → D und, allgemeiner, auf Mi: i → j ohne weiteres erkennen.
  • Optionale, aber erwünschte sicherheitsbezogene Aspekte der Protokolle werden als nächstes beschrieben.
  • Zeitstempel können verwendet werden, um Neuheits- und Einzigartigkeitsgarantien bereitzustellen und um eine Nachrichtenaufzeichnungswiedergabe zu ermitteln, und sind vorteilhaft, wenn die Sicherheit gegen Angriffe mit bekannten Schlüsseln erforderlich ist, da die Methode andernfalls wegen des einseitigen Schlüsselauthentifikationsprotokolls potentiell für Nachrichtenaufzeichnungswiedergabe-Angriffe anfällig ist. Die Sicherheit von zeitstempelgestützten Methoden beruht auf der Verwendung einer gemeinsamen Zeitreferenz. Das setzt voraus, daß Zentraltakte verfügbar sind, und Synchronisation ist erforderlich, um der Taktabweichung entgegenzuwirken, und muß für das akzeptable Zeitfenster ausgelegt sein, das verwendet wird. Das Risiko eines Dienstverweigerungsangriffs kann verringert werden, indem eine Nutzungsdauer für Γ festgelegt wird, wobei das Risiko um so niedriger ist, je kürzer die Nutzungsdauer ist.
  • Sowohl im asymmetrischen als auch im symmetrischen Kryptographieansatz bewahrt jede Instanz einen Schlüssel auf, den sie geheimhalten sollte, wenngleich der öffentliche Schlüssel beim asymmetrischen Ansatz offenbart werden kann. Wenn dieser Schlüssel gefährdet ist, kann das sichere Delegationsprotokoll nicht garantiert werden, und deshalb wird vorzugsweise jedem mobilen Teilnehmer sein eigener Schlüssel zur sicheren Verwaltung anvertraut. Ein Vorteil der Verwendung des Systems mit öffentlichem Schlüssel besteht darin, das es keinen Bedarf an einem vertrauenswürdigen geheimen Server gibt, aber durch Verwendung eines gemeinsamen symmetrischen Schlüssels kann eine größere Leistungsfähigkeit erreicht werden. Jedoch bieten beide Alternative eine Verantwortlichkeit der Delegation, da die DTs immer digital signiert sind. In einem asymmetrischen schlüsselgestützten Protokoll kann ein Endpunkt den Ursprung eines KP-T-E bestätigen, aber es gibt immer noch ein potentielles Risiko, das von einem Angreifer ausgeht, der sich als mobiler Teilnehmer ausgibt, wenn die öffentlichen Schlüssel, die zum Beispiel in einer Datenbasis gespeichert sein können, nicht sicher geschützt sind. In den symmetrischen schlüsselgestützten Protokollen wird dem Server stets vertraut, und darum darf er nicht gefährdet werden. Die Protokolle stellen zwar Revisionsmechanismen bereit, aber in der Praxis sind diese möglicherweise eher bei der Bereitstellung von Beweisen für das Lösen möglicher Auseinandersetzungen von Nutzen als zur Verhinderung von Angriffen.
  • Die oben beschriebenen Protokolle sind imstande, für eine durchgehende Verantwortlichkeit zwischen allen beteiligten mobilen Teilnehmern zu sorgen, und helfen somit, die Verantwortlichkeit und das Vertrauen zu erhöhen. Sie sind insbesondere für Internethandel-Anwendungen wichtig, zum Beispiel für den Kauf von Softwarekomponenten oder System- oder Anwendungssoftware, um die Arbeitsweise eines Endgeräts anzupassen, wobei in einer PAN-Umgebung ein begrenztes Ausmaß an Vertrauen zwischen mobilen Endgeräten, wie etwa Taschen-PCs, Mobiltelefonen und Laptops, bestehen kann. Die Methoden sind auch für den MExE-Standard für zukünftige programmierbare mobile Benutzerausrüstung geeignet. Die Protokolle ermöglichen das sichere Herunterladen von Software, Tickets, Coupons und Internethandelbezogenen Daten für jedes Endgerät bzw. für jede Client-Anforderung und sind relativ effizient (sowohl für die symmetrische als auch für die asymmetrische Version), da sie weniger Nachrichtendurchläufe haben als bisher. Die Staffeldelegationsprotokolle sind kompakt, effizient und für rekonfigurierbare Endgeräte gut geeignet.
  • Ausführungsformen der Erfindung sind im Zusammenhang mit einem Server und mobilen Endgeräten eines mobilen Kommunikationssystems beschrieben worden, aber Aspekte der Erfindung haben auch andere Anwendungen, zum Beispiel in vernetzten Computersystemen und in drahtgebundenen sowie drahtlosen Systemen. Man wird auch anerkennen, daß in den oben erwähnten Protokollen grundsätzlich jedes Endgerät oder ein Server den Absender der Anfangsnachricht bilden kann und daß jedes Endgerät oder ein Server den Endpunkt einer Kette bilden kann.
  • Es besteht kein Zweifel, daß dem Fachmann viele effektive Alternativen einfallen, und es ist verständlich, daß die Erfindung nicht auf die beschriebenen Ausführungsformen begrenzt ist, sondern Modifikationen innerhalb des Schutzbereichs der Ansprüche einschließt, die für den Fachmann offensichtlich sind.

Claims (24)

  1. Verfahren zur Initialisierung einer sicheren Kommunikationsverbindungsteilstrecke zwischen einem ersten, delegierenden Datenverarbeitungssystem (A) und einem zweiten Datenverarbeitungssystem (B), an das das erste System delegiert, wobei das Verfahren ein erstes Delegationstoken DT mit einem ersten Delegationsschlüssel KP-T-E und zugeordneten ersten Anforderungsdaten R verwendet, wobei die ersten Anforderungsdaten eine Anforderung des ersten Systems bezeichnen und der erste Delegationsschlüssel zur Verschlüsselung von Daten dient, die als Antwort auf die Anforderung an das erste System zurückgesendet werden sollen, wobei das Verfahren die folgenden Schritte umfaßt: Erzeugen, in dem ersten System, einer ersten Nachricht M1 mit dem ersten Delegationsschlüssel und zugeordneten ersten Anforderungsdaten und ersten Authentifikationsdaten SA zur Authentifizierung des ersten, delegierenden Systems, wobei die ersten Authentifikationsdaten durch Bearbeitung mindestens eines von folgendem, nämlich des ersten Delegationsschlüssels und/oder der ersten Anforderungsdaten mit einem geheimen Authentifikationsschlüssel des ersten Systems erzeugt werden; Verschlüsseln der ersten Nachricht unter Verwendung eines Verbindungsteilstrecken-Verschlüsselungsschlüssels PB, der sowohl dem ersten als auch dem zweiten Datenverarbeitungssystem bekannt ist, um eine verschlüsselte erste Nachricht zu bilden; und Senden der verschlüsselten ersten Nachricht von dem ersten System an das zweite System, um die sichere Kommunikationsverbindungsteilstrecke zu initialisieren.
  2. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: Empfangen, in dem ersten Datenverarbeitungssystem von einem vorigen Datenverarbeitungssystem, einer vorigen verschlüsselten Nachricht mit einem Delegationsschlüssel des vorigen Datenverarbeitungssystems und zugeordneten vorigen Anforderungsdaten, wobei die vorigen Anforderungsdaten eine Anforderung des vorigen Datenverarbeitungssystems bezeichnen, und mit vorigen Authentifikationsdaten, wobei der Delegationsschlüssel des vorigen Datenverarbeitungssystems und die zugeordneten vorigen Anforderungsdaten ein voriges Token bilden, wobei die vorigen Authentifikationsdaten Daten umfassen, die durch Bearbeitung mindestens eines von folgendem, nämlich des Delegationsschlüssels des vorigen Datenverarbeitungssystems und/oder der vorigen Anforderungsdaten mit einem geheimen Authentifikationsschlüssel des vorigen Systems erzeugt wurden; Entschlüsseln der vorigen verschlüsselten Nachricht unter Verwendung eines Verbindungsteilstrecken-Verschlüsselungsschlüssels, der sowohl dem ersten als auch dem vorigen Datenverarbeitungssystem bekannt ist; und Einbeziehen des vorigen Tokens und der vorigen Authentifikationsdaten in die erste Nachricht.
  3. Verfahren nach Anspruch 2, ferner mit dem folgenden Schritt: Überprüfen der vorigen Authentifikationsdaten; und wobei der Schritt des Sendens der verschlüsselten ersten Nachricht von einem Ergebnis der Überprüfung abhängt.
  4. Verfahren nach Anspruch 1, 2 oder 3, ferner mit dem folgenden Schritt: Einrichten einer sicheren Kommunikationsverbindungsteilstrecke zwischen dem ersten und dem zweiten Datenverarbeitungssystem unter Verwendung des ersten Delegationsschlüssels.
  5. Verfahren zur Initialisierung einer sicheren Kommunikationskette zwischen einem ersten, einem zweiten und einem dritten Datenverarbeitungssystem, wobei das Verfahren die folgenden Schritte umfaßt: Initialisieren einer sicheren Kommunikationsverbindungsteilstrecke zwischen einem ersten und einem zweiten Datenverarbeitungssystem (A, B) nach Anspruch 1 und ferner mit den folgenden Schritten: Entschlüsseln, in dem zweiten System (B), der verschlüsselten ersten Nachricht; Erzeugen, in dem zweiten System, einer zweiten Nachricht M2 mit dem ersten Delegationsschlüssel KP-T-E und zugeordneten ersten Anforderungsdaten R und den ersten Authentifikationsdaten SA, und eines zweiten Delegationsschlüssels KP-T-E, und zugeordneten zweiten Anforderungsdaten R1 und zweiten Authentifikationsdaten SB, wobei der zweite Schlüssel und die zugeordneten zweiten Anforderungsdaten ein zweites Delegationstoken DT1 bilden, wobei die zweiten Authentifikationsdaten Daten umfassen, die durch Bearbeitung mindestens eines von folgendem, nämlich des zweiten Delegationsschlüssels und/oder der zweiten Anforderungsdaten mit einem geheimen Authentifikationsschlüssel des zweiten Systems erzeugt wurden; Verschlüsseln der zweiten Nachricht unter Verwendung eines Verbindungsteilstrecken-Verschlüsselungsschlüssels PC, der mindestens sowohl dem zweiten (B) als auch dem dritten (C) Datenverarbeitungssystem bekannt ist, um eine verschlüsselte zweite Nachricht zu bilden; und Senden der verschlüsselten zweiten Nachricht von dem zweiten System an das dritte System.
  6. Verfahren zur Initialisierung einer sicheren Kommunikationskette für eine Kette von Datenverarbeitungssystemen, wobei die Kette folgendes umfaßt: Ein Anfangs-Datenverarbeitungssystem und ein End-Datenverarbeitungssystem, die über ein oder mehrere Zwischen-Datenverarbeitungssysteme miteinander verbunden sind, wobei das Verfahren den folgenden Schritt umfaßt: Initialisieren aufeinanderfolgender Glieder bzw. Teilstrecken der Kette durch aufeinanderfolgende Anwendungen des Verfahrens nach Anspruch 1.
  7. Verfahren nach Anspruch 6, wobei die verschlüsselten Nachrichtendaten, die bei jeder aufeinanderfolgenden Anwendung des Verfahrens nach Anspruch 1 an eine Teiltrecke gesendet werden, Schlüssel und zugeordnete Anforderungsdaten und Authentifikationsdaten für alle vorigen Datenverarbeitungssysteme in der Kette bis zu der Teilstrecke aufweisen.
  8. Verfahren nach einem der Ansprüche 1 bis 7, wobei der Verschlüsselungsschritt den folgenden Schritt umfaßt: Verschlüsseln unter Verwendung eines asymmetrischen kryptographischen Algorithmus.
  9. Verfahren nach einem der Ansprüche 1 bis 7, wobei der Verschlüsselungsschritt den folgenden Schritt umfaßt: Verschlüsseln unter Verwendung eines symmetrischen kryptographischen Algorithmus.
  10. Verfahren nach Anspruch 1 mit dem folgenden Schritt: Bearbeiten sowohl des ersten Schlüssels als auch der ersten Anforderungsdaten mit einem geheimen Schlüssel des ersten Systems.
  11. Verfahren nach Anspruch 1 mit dem folgenden Schritt: Verschlüsseln der ersten Nachricht unter Verwendung eines öffentlichen Schlüssels des zweiten Datenverarbeitungssystems.
  12. Verfahren nach Anspruch 1 oder 5, wobei das erste Token, und sofern von Anspruch 5 abhängig, das zweite Token zugeordnete Nutzungsdauerdaten hat.
  13. Verfahren nach Anspruch 1 oder 5, wobei der Sendeschritt ferner den folgenden Schritt umfaßt: Senden einer unverschlüsselten Kennung für den Empfänger.
  14. Verfahren nach Anspruch 1 oder 5, wobei der Sendeschritt ferner den folgenden Schritt umfaßt: Senden von Zeitstempel- und/oder einstweiligen Daten.
  15. Verfahren zur Einrichtung einer Kette von sicheren Kommunikationsverbindungsteilstrecken zwischen einer Vielzahl von Datenverarbeitungsmaschinen, so daß die Identität jeder nachfolgenden, die Kette bildenden Datenverarbeitungsmaschine mittels jeweiliger Authentifikationsdaten bestätigt werden kann, wobei das Verfahren den folgenden Schritt umfaßt: Durchführen, in jeder nachfolgenden Datenverarbeitungsmaschine in der Kette nach einer ersten Maschine, der folgenden Schritte: Empfangen, von einer vorigen Datenverarbeitungsmaschine (A) in der Kette, einer durch das Verfahren nach Anspruch 1 erzeugten verschlüsselten Nachricht mit den ersten Authentifikationsdaten SA und dem ersten Delegationstoken DT, das den ersten Delegationsschlüssel KP-T-E aufweist, wobei der erste Delegationsschlüssel zur Verschlüsselung von Daten dient, die an das erste System zurückgesendet werden sollen; Entschlüsseln der verschlüsselten Nachricht; Hinzufügen weiterer Delegationstoken-Daten DT1 und weiterer Authentifikationsdaten SB zur entschlüsselten Nachricht, damit die folgende Datenverarbeitungsmaschine eine erweiterte Nachricht M2 bildet; Verschlüsseln der erweiterten Nachricht; und Weiterleiten der verschlüsselten erweiterten Nachricht zur nächsten Maschine (C) in der Kette; bis eine End-Maschine in der Kette erreicht ist, wodurch die Kette sicherer Kommunikationsverbindungsteilstrecken eingerichtet ist.
  16. Verfahren nach Anspruch 15, wobei die Delegationstoken-Daten für jede Maschine einen Delegationsschlüssel aufweisen, wobei das Verfahren ferner den folgenden Schritt umfaßt: Zurücksenden von Daten von der End-Maschine an die erste Maschine der Kette, wobei die Daten unter Verwendung des Delegationsschlüssels der ersten Maschine verschlüsselt sind.
  17. Verfahren nach Anspruch 16, wobei der Sendeschritt die Daten von der End-Maschine über die Kette zur ersten Maschine sendet.
  18. Verfahren nach Anspruch 15, 16 oder 17, wobei die Delegationstoken-Daten für jede Maschine Anforderungsdaten für eine dem Delegationsschlüssel der Delegationstoken-Daten zugeordnete Anforderung aufweisen.
  19. Verfahren nach einem der Ansprüche 15 bis 18, ferner mit dem folgenden Schritt: Erzeugen der Authentifikationsdaten in jeder nachfolgenden Maschine, indem eine kryptographische Verarbeitung mit den Delegationstoken-Daten durchgeführt wird.
  20. Verfahren nach einem der Ansprüche 1 bis 19, wobei ein besagtes Datenverarbeitungssystem oder eine besagte Datenverarbeitungsmaschine ein mobiles Endgerät eines drahtlosen Mobilfunk-Kommunikationssystems umfaßt.
  21. Prozessorsteuerungscode, um in Betrieb das Verfahren nach Anspruch 1 oder die Verfahrensschritte nach Anspruch 15 durchzuführen.
  22. Träger, der den Prozessorsteuerungscode nach Anspruch 21 trägt.
  23. Datenverarbeitungssystem, das dafür konfiguriert ist, das Verfahren nach Anspruch 15 durchzuführen.
  24. Datenverarbeitungsvorrichtung zum Delegieren an eine zweite Datenverarbeitungsvorrichtung unter Verwendung eines Delegationstokens DT mit einem Delegationsschlüssel KP-T-E und zugeordneten Anforderungsdaten R, wobei die Anforderungsdaten eine Anforderung der Vorrichtung bezeichnen und der Delegationsschlüssel zur Verschlüsselung von Daten dient, die als Antwort auf die Anforderung an die Vorrichtung zurückgesendet werden sollen, wobei die Vorrichtung folgendes umfaßt: einen Datenspeicher, der betriebsfähig ist, Daten zu speichern, die verarbeitet werden sollen; einen Anweisungsspeicher, der Anweisungen speichert, die durch einen Prozessor implementiert werden können; und einen Prozessor, der mit dem Datenspeicher und dem Anweisungsspeicher gekoppelt und betriebsfähig ist, Daten gemäß den Anweisungen zu verarbeiten, wobei die Anweisungen Anweisungen zur Steuerung des Prozessors umfassen, um folgende Schritte durchzuführen: Erzeugen, in der Vorrichtung, einer Nachricht M1 mit dem Delegationsschlüssel und zugeordneten Anforderungsdaten und Authentifikationsdaten SA zur Authentifizierung der delegierenden Vorrichtung, wobei die Authentifikationsdaten durch Bearbeitung mindestens eines von folgendem, nämlich des Delegationsschlüssels und/oder der Anforderungsdaten, mit einem geheimen Authentifikationsschlüssel der Vorrichtung erzeugt werden; Verschlüsseln der Nachricht unter Verwendung eines Verbindungsteilstrecken-Verschlüsselungsschlüssels PB, der sowohl der besagten Vorrichtung als auch der zweiten Datenverarbeitungsvorrichtung bekannt ist, um eine verschlüsselte Nachricht zu bilden; und Senden der verschlüsselten Nachricht von der besagten Vorrichtung an die zweite Vorrichtung, um die sichere Kommunikationsverbindungsteilstrecke zu initialisieren.
DE60308971T 2002-08-30 2003-08-29 Verfahren und Vorrichtung für sichere Datenkommunikationsverbindungen Expired - Fee Related DE60308971T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0220203A GB2392590B (en) 2002-08-30 2002-08-30 Methods and apparatus for secure data communication links
GB0220203 2002-08-30

Publications (2)

Publication Number Publication Date
DE60308971D1 DE60308971D1 (de) 2006-11-23
DE60308971T2 true DE60308971T2 (de) 2007-06-14

Family

ID=9943244

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60308971T Expired - Fee Related DE60308971T2 (de) 2002-08-30 2003-08-29 Verfahren und Vorrichtung für sichere Datenkommunikationsverbindungen

Country Status (5)

Country Link
US (1) US20040117623A1 (de)
EP (1) EP1394982B1 (de)
JP (1) JP4199074B2 (de)
DE (1) DE60308971T2 (de)
GB (1) GB2392590B (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017219261A1 (de) * 2017-10-26 2019-05-02 Bundesdruckerei Gmbh Bereitstellen physiologischer Daten
DE102017219265A1 (de) * 2017-10-26 2019-05-02 Bundesdruckerei Gmbh Verhaltensbasierte Authentifizierung unter Berücksichtigung von Umweltparametern

Families Citing this family (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7058822B2 (en) 2000-03-30 2006-06-06 Finjan Software, Ltd. Malicious mobile code runtime monitoring system and methods
US9219755B2 (en) 1996-11-08 2015-12-22 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US8079086B1 (en) 1997-11-06 2011-12-13 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
GB2405566B (en) * 2002-10-14 2005-05-18 Toshiba Res Europ Ltd Methods and systems for flexible delegation
US6845338B1 (en) * 2003-02-25 2005-01-18 Symbol Technologies, Inc. Telemetric contextually based spatial audio system integrated into a mobile terminal wireless system
US7181726B2 (en) * 2003-03-07 2007-02-20 Benq Corporation Method for providing active protection to programming tools for programmable devices
TW595195B (en) * 2003-04-04 2004-06-21 Benq Corp Network lock method and related apparatus by ciphered network lock and inerasable deciphering key
WO2005028057A1 (en) * 2003-09-19 2005-03-31 Nokia Corporation Method and device for supporting wireless multi-player gaming with a multi-player game hub
US8190893B2 (en) 2003-10-27 2012-05-29 Jp Morgan Chase Bank Portable security transaction protocol
WO2005045649A1 (en) * 2003-11-07 2005-05-19 Telecom Italia S.P.A. Method and system for the authentication of a user of a data processing system
US7636844B2 (en) * 2003-11-17 2009-12-22 Intel Corporation Method and system to provide a trusted channel within a computer system for a SIM device
US20050138387A1 (en) * 2003-12-19 2005-06-23 Lam Wai T. System and method for authorizing software use
DE102004025734B4 (de) * 2004-05-26 2006-07-27 Siemens Ag Verfahren zur Optimierung von Rekonfigurationsprozessen in Mobilfunknetzwerken mit rekonfigurierbaren Endgeräten durch Sammlung und Bereitstellung geeigneter Messdaten sowie eine entsprechende Anordnung
EP1771827A1 (de) * 2004-06-30 2007-04-11 France Télécom Elektronisches mehrzweck-bezahlungsverfahren und -system
US20060068758A1 (en) * 2004-09-30 2006-03-30 Abhay Dharmadhikari Securing local and intra-platform links
US8627086B2 (en) * 2004-10-11 2014-01-07 Telefonaktiebolaget Lm Ericsson (Publ) Secure loading and storing of data in a data processing device
JP4704729B2 (ja) * 2004-10-20 2011-06-22 株式会社日立製作所 パケットデータ処理ノード装置
US20060089123A1 (en) * 2004-10-22 2006-04-27 Frank Edward H Use of information on smartcards for authentication and encryption
US20060130154A1 (en) * 2004-11-30 2006-06-15 Wai Lam Method and system for protecting and verifying stored data
KR20060087271A (ko) * 2005-01-28 2006-08-02 엘지전자 주식회사 이동통신 가입자 인증의 보안 전송 방법
US7468981B2 (en) * 2005-02-15 2008-12-23 Cisco Technology, Inc. Clock-based replay protection
US7676679B2 (en) * 2005-02-15 2010-03-09 Cisco Technology, Inc. Method for self-synchronizing time between communicating networked systems using timestamps
US8291224B2 (en) 2005-03-30 2012-10-16 Wells Fargo Bank, N.A. Distributed cryptographic management for computer systems
US20060282525A1 (en) * 2005-06-10 2006-12-14 Giles James R Method and apparatus for delegating responses to conditions in computing systems
US8015404B2 (en) * 2005-09-16 2011-09-06 Gm Global Technology Operations, Llc System and method for collecting traffic data using probe vehicles
US8788802B2 (en) * 2005-09-29 2014-07-22 Qualcomm Incorporated Constrained cryptographic keys
US7681239B2 (en) * 2005-09-30 2010-03-16 Microsoft Corporation Modularly constructing a software defined radio
DE102005050878A1 (de) * 2005-10-21 2007-04-26 Fiducia It Ag Verfahren zur datentechnisch gesicherten elektronischen Kommunikation sowie eine Vorrichtung zur Ausführung dieses Verfahrens
US8396041B2 (en) 2005-11-08 2013-03-12 Microsoft Corporation Adapting a communication network to varying conditions
US8381047B2 (en) 2005-11-30 2013-02-19 Microsoft Corporation Predicting degradation of a communication channel below a threshold based on data transmission errors
WO2007071009A1 (en) * 2005-12-23 2007-06-28 Bce Inc. Wireless device authentication between different networks
US7551915B1 (en) * 2006-04-24 2009-06-23 Sprint Spectrum L.P. Method of establishing route optimized communication in mobile IPv6 by securing messages sent between a mobile node and home agent
US20070297609A1 (en) * 2006-06-23 2007-12-27 Research In Motion Limited Secure Wireless HeartBeat
US20080005558A1 (en) * 2006-06-29 2008-01-03 Battelle Memorial Institute Methods and apparatuses for authentication and validation of computer-processable communications
US7570398B2 (en) * 2006-10-10 2009-08-04 Ricoh Company, Ltd. Secure scanning device
US8191146B2 (en) * 2006-10-31 2012-05-29 Tti Inventions C Llc Virus localization using cryptographic hashing
US8103247B2 (en) * 2006-10-31 2012-01-24 Microsoft Corporation Automated secure pairing for wireless devices
EP2095596B1 (de) * 2006-12-19 2010-03-10 Telefonaktiebolaget LM Ericsson (PUBL) Verwaltung des benutzerzugangs in einem kommunikationsnetz
CN101262342A (zh) * 2007-03-05 2008-09-10 松下电器产业株式会社 分布式授权与验证方法、装置及***
US7991152B2 (en) * 2007-03-28 2011-08-02 Intel Corporation Speeding up Galois Counter Mode (GCM) computations
US20100293379A1 (en) * 2007-05-31 2010-11-18 Beijing Transpacific Ip Technology Development Ltd method for secure data transmission in wireless sensor network
US8331989B2 (en) 2007-06-15 2012-12-11 Intel Corporation Field programming of a mobile station with subscriber identification and related information
JP5069348B2 (ja) * 2007-06-18 2012-11-07 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ソフトウェア無線端末のセキュリティ
US8316236B2 (en) * 2007-08-31 2012-11-20 Cisco Technology, Inc. Determining security states using binary output sequences
US8213923B1 (en) * 2007-11-02 2012-07-03 Trend Micro Incorporated Product update via voice call in mobile security
US8676998B2 (en) * 2007-11-29 2014-03-18 Red Hat, Inc. Reverse network authentication for nonstandard threat profiles
US8214298B2 (en) * 2008-02-26 2012-07-03 Rfinity Corporation Systems and methods for performing wireless financial transactions
EP2252957A1 (de) * 2008-03-04 2010-11-24 Apple Inc. Verwaltung von codeberechtigungen für software-entwickler in sicheren operationsumgebungen
US8565434B2 (en) * 2008-05-27 2013-10-22 Qualcomm Incorporated Methods and systems for maintaining security keys for wireless communication
US20100153709A1 (en) * 2008-12-10 2010-06-17 Qualcomm Incorporated Trust Establishment From Forward Link Only To Non-Forward Link Only Devices
DE102009005978B4 (de) 2009-01-23 2011-02-03 Gottfried Wilhelm Leibniz Universität Hannover Verfahren zur verteilten Erzeugung miteinander korrelierender Daten
US9059979B2 (en) * 2009-02-27 2015-06-16 Blackberry Limited Cookie verification methods and apparatus for use in providing application services to communication devices
US20100250949A1 (en) * 2009-03-31 2010-09-30 Torino Maria E Generation, requesting, and/or reception, at least in part, of token
US20100287402A1 (en) * 2009-05-11 2010-11-11 Electronics And Telecommunications Research Institute Timestamping apparatus and method
US8392699B2 (en) * 2009-10-31 2013-03-05 Cummings Engineering Consultants, Inc. Secure communication system for mobile devices
US8917625B2 (en) * 2009-11-10 2014-12-23 Broadcom Corporation Mapping quality of service (QOS) from a wireless network to a wired network
CN102656841B (zh) * 2009-12-18 2015-07-08 诺基亚公司 凭证转移
WO2011113873A1 (en) * 2010-03-17 2011-09-22 Telefonaktiebolaget L M Ericsson (Publ) Enhanced key management for srns relocation
US8571218B2 (en) 2010-06-01 2013-10-29 GreatCall, Inc. Short message service cipher
US8839357B2 (en) * 2010-12-22 2014-09-16 Canon U.S.A., Inc. Method, system, and computer-readable storage medium for authenticating a computing device
US20120189122A1 (en) * 2011-01-20 2012-07-26 Yi-Li Huang Method with dynamic keys for mutual authentication in wireless communication environments without prior authentication connection
KR101425711B1 (ko) * 2011-10-13 2014-08-04 (주) 아이씨티케이 스마트 모바일 환경에서의 정보 보안 시스템
CN102595405A (zh) * 2012-01-21 2012-07-18 华为技术有限公司 一种网络接入的认证方法、***和设备
JP5295408B1 (ja) * 2012-05-13 2013-09-18 淳也 榎本 セキュア通信方法、***作装置及び操作プログラム
WO2014069909A1 (en) * 2012-11-01 2014-05-08 Lg Electronics Inc. Method and apparatus of providing integrity protection for proximity-based service discovery with extended discovery range
US9270649B1 (en) * 2013-03-11 2016-02-23 Emc Corporation Secure software authenticator data transfer between processing devices
US9092778B2 (en) 2013-03-15 2015-07-28 Varsgen, Llc Bank account protection method utilizing a variable assigning request string generator and receiver algorithm
WO2014167389A1 (en) * 2013-04-12 2014-10-16 Nokia Siemens Networks Oy Secure radio information transfer over mobile radio bearer
US9401905B1 (en) * 2013-09-25 2016-07-26 Emc Corporation Transferring soft token authentication capabilities to a new device
US9225516B1 (en) * 2013-10-03 2015-12-29 Whatsapp Inc. Combined authentication and encryption
CN104883677B (zh) 2014-02-28 2018-09-18 阿里巴巴集团控股有限公司 一种近场通讯设备间通讯的连接方法、装置和***
US9544329B2 (en) 2014-03-18 2017-01-10 Shape Security, Inc. Client/server security by an intermediary executing instructions received from a server and rendering client application instructions
US9954848B1 (en) 2014-04-04 2018-04-24 Wells Fargo Bank, N.A. Central cryptographic management for computer systems
US9800602B2 (en) 2014-09-30 2017-10-24 Shape Security, Inc. Automated hardening of web page content
US9524158B2 (en) * 2015-02-23 2016-12-20 Apple Inc. Managing firmware updates for integrated components within mobile devices
NL2014743B1 (en) * 2015-04-30 2017-01-18 Ubiqu B V A first entity, a second entity, an intermediate node, methods for setting up a secure session between a first and second entity, and computer program products.
US10783506B2 (en) * 2015-08-28 2020-09-22 Transparent Wireless Systems, Llc Methods and systems for access control to secure facilities
JP6449131B2 (ja) * 2015-10-23 2019-01-09 Kddi株式会社 通信装置、通信方法、およびコンピュータプログラム
US9699655B1 (en) * 2016-02-23 2017-07-04 T-Mobile Usa, Inc. Cellular device authentication
JP6471112B2 (ja) 2016-02-29 2019-02-13 Kddi株式会社 通信システム、端末装置、通信方法、及びプログラム
US10567363B1 (en) * 2016-03-03 2020-02-18 Shape Security, Inc. Deterministic reproduction of system state using seeded pseudo-random number generators
US20180060989A1 (en) * 2016-08-30 2018-03-01 MaaS Global Oy System, method and device for digitally assisted personal mobility management
US10735425B2 (en) * 2017-01-31 2020-08-04 Pivotal Software, Inc. Invocation path security in distributed systems
JP6740545B2 (ja) * 2017-05-30 2020-08-19 日本電気株式会社 情報処理装置、検証装置、情報処理システム、情報処理方法、及び、プログラム
US11431511B2 (en) * 2019-06-03 2022-08-30 Intuit Inc. Centralized authentication and authorization with certificate management
US20220277089A1 (en) * 2019-09-02 2022-09-01 Grabtaxi Holdings Pte. Ltd. Communications server apparatus and method for determination of an abstention attack
CN112073187B (zh) * 2020-08-28 2023-03-28 江苏卓易信息科技股份有限公司 一种基于非阻塞方式加速***可信链构建的方法
US11265106B1 (en) 2020-12-29 2022-03-01 Imperva, Inc. Streaming-friendly technology for detection of data
CN113919005B (zh) * 2021-10-18 2024-06-14 北京理工大学 一种基于Schnorr聚合签名的数字证书颁发方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5224163A (en) * 1990-09-28 1993-06-29 Digital Equipment Corporation Method for delegating authorization from one entity to another through the use of session encryption keys
CN1192834A (zh) * 1995-06-05 1998-09-09 塞特科有限公司 多步数字签名方法和***
GB2357225B (en) * 1999-12-08 2003-07-16 Hewlett Packard Co Electronic certificate
US6734886B1 (en) * 1999-12-21 2004-05-11 Personalpath Systems, Inc. Method of customizing a browsing experience on a world-wide-web site
DE60124458D1 (de) * 2000-06-30 2006-12-28 Microsoft Corp Vorrichtungen und Verfahren für delegierte Zugangsberechtigung von Zusammenfassungsinformation
US20020138635A1 (en) * 2001-03-26 2002-09-26 Nec Usa, Inc. Multi-ISP controlled access to IP networks, based on third-party operated untrusted access stations
WO2002086675A2 (en) * 2001-04-25 2002-10-31 Probaris Technologies, Inc. Method and system for managing access to services
US7340438B2 (en) * 2001-05-21 2008-03-04 Nokia Corporation Method and apparatus for managing and enforcing user privacy
US7698381B2 (en) * 2001-06-20 2010-04-13 Microsoft Corporation Methods and systems for controlling the scope of delegation of authentication credentials

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017219261A1 (de) * 2017-10-26 2019-05-02 Bundesdruckerei Gmbh Bereitstellen physiologischer Daten
DE102017219265A1 (de) * 2017-10-26 2019-05-02 Bundesdruckerei Gmbh Verhaltensbasierte Authentifizierung unter Berücksichtigung von Umweltparametern

Also Published As

Publication number Publication date
GB2392590A (en) 2004-03-03
JP4199074B2 (ja) 2008-12-17
GB0220203D0 (en) 2002-10-09
GB2392590B (en) 2005-02-23
EP1394982A1 (de) 2004-03-03
EP1394982B1 (de) 2006-10-11
JP2004166238A (ja) 2004-06-10
US20040117623A1 (en) 2004-06-17
DE60308971D1 (de) 2006-11-23

Similar Documents

Publication Publication Date Title
DE60308971T2 (de) Verfahren und Vorrichtung für sichere Datenkommunikationsverbindungen
DE60029217T2 (de) Verfahren und vorrichtung zum initialisieren von sicheren verbindungen zwischen und nur zwischen zueinandergehörenden schnurlosen einrichtungen
CN110290094B (zh) 一种数据访问权限的控制方法和装置
DE602004000695T2 (de) Erzeugung von asymmetrischen Schlüsseln in einem Telekommunicationssystem
DE112005002651B4 (de) Verfahren und Vorrichtung zur Authentifikation von mobilen Vorrichtungen
DE19822795C2 (de) Verfahren und Anordnung zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer ersten Computereinheit und einer zweiten Computereinheit
DE60037593T2 (de) Gesichertes ad hoc netzwerk sowie verfahren zu dessen betreiben
DE69925920T2 (de) Sichere verarbeitung für die authentifizierung eines drahtlosen kommunikationsgeräts
DE60312911T2 (de) System für mobile Authentifizierung mit reduzierten Authentifizierungsverzögerung
DE60310968T2 (de) Sicherheits- und Privatsphärenverbesserungen für Sicherheitseinrichtungen
DE602004012233T2 (de) Verfahren zur Bereitstellung eines Signierungsschlüssels zur digitalen Signierung, Überprüfung oder Verschlüsselung von Daten
EP0872076B1 (de) Verfahren zum rechnergestützten austausch kryptographischer schlüssel zwischen einer ersten computereinheit und einer zweiten computereinheit
EP1449324B1 (de) Nutzung eines public-key-schlüsselpaares im endgerät zur authentisierung und autorisierung des telekommunikations-teilnehmers gegenüber dem netzbetreiber und geschäftspartnern
CN108683510A (zh) 一种加密传输的用户身份更新方法
DE112017000483T5 (de) System, gerät und verfahren für schlüsselbereitstellungsdelegation
DE112015000213T5 (de) Passwortgestützte Berechtigungsprüfung
DE10393847B4 (de) Verfahren und Vorrichtung zum Auffinden einer gemeinsam genutzten vertraulichen Information ohne Beeinträchtigung nicht-gemeinsam genutzter vertraulicher Informationen
US20050144144A1 (en) System and method for authenticating a terminal based upon at least one characteristic of the terminal located at a position within an organization
US20050149724A1 (en) System and method for authenticating a terminal based upon a position of the terminal within an organization
DE112008002860T5 (de) Verfahren und Vorrichtung für das Bereitstellen einer sicheren Verknüpfung mit einer Benutzeridentität in einem System für digitale Rechteverwaltung
DE60224391T2 (de) Sicherer Zugang zu einem Teilnehmermodul
DE19518546C1 (de) Verfahren zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer Benutzercomputereinheit U und einer Netzcomputereinheit N
EP1675298A1 (de) Verfahren zur Überprüfung der Identität einer ersten Entität gegenüber einer anderen Entität in einem System sowie System zum Durchführen des Verfahrens
DE19518544C1 (de) Verfahren zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer Benutzercomputereinheit und einer Netzcomputereinheit
DE19518545C1 (de) Verfahren zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer Benutzercomputereinheit und einer Netzcomputereinheit

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee