DE60124765T2 - Verfahren und vorrichtung zur verwaltung von sicherheitssensiblen kollaborativen transaktionen - Google Patents

Verfahren und vorrichtung zur verwaltung von sicherheitssensiblen kollaborativen transaktionen Download PDF

Info

Publication number
DE60124765T2
DE60124765T2 DE60124765T DE60124765T DE60124765T2 DE 60124765 T2 DE60124765 T2 DE 60124765T2 DE 60124765 T DE60124765 T DE 60124765T DE 60124765 T DE60124765 T DE 60124765T DE 60124765 T2 DE60124765 T2 DE 60124765T2
Authority
DE
Germany
Prior art keywords
message
key
invitation
invitee
information
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 - Lifetime
Application number
DE60124765T
Other languages
English (en)
Other versions
DE60124765D1 (de
Inventor
Walter Reading TUVELL
Nimisha Beverly ASTHAGIRI
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.)
Microsoft Corp
Original Assignee
Groove Networks Inc
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 Groove Networks Inc filed Critical Groove Networks Inc
Application granted granted Critical
Publication of DE60124765D1 publication Critical patent/DE60124765D1/de
Publication of DE60124765T2 publication Critical patent/DE60124765T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Storage Device Security (AREA)
  • Document Processing Apparatus (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Input From Keyboards Or The Like (AREA)
  • Stored Programmes (AREA)

Description

  • Die vorliegende Erfindung betrifft Verfahren und Vorrichtungen zum Bereitstellen von gesicherten Datenaustauschtransaktionen und insbesondere Verfahren und Vorrichtungen zum Bereitstellen von gesicherten Datenaustauschtransaktionen in einer Kollaborationsumgebung.
  • Heutige Computeranwendungen sind weitgehend Systeme für einzelne Nutzer. Herkömmliche Textverarbeitungsanwendungen gestatten es beispielsweise einem einzigen Nutzer, eine Datei zu öffnen und den Inhalt zu modifizieren. Wenn während die Datei geöffnet ist, ein zweiter Nutzer versucht, die Datei zu öffnen, wird der zweite Nutzer am Öffnen oder Modifizieren der Datei gehindert. Manchmal wird es dem zweiten Nutzer gestattet, eine Kopie der Datei zu erhalten. Die Kopie wird jedoch nicht mit irgendeiner der nachfolgenden Veränderungen, die der erste Nutzer an dem Originalexemplar vornimmt, aktualisiert. Somit ist der zweite Nutzer nicht in der Lage, an den sich als Änderungen an der Datei niederschlagenden Ideen des ersten Nutzers teilzuhaben. Außerdem wird der zweite Nutzer daran gehindert, den Inhalt der originalen Datei zu ändern und wird dadurch daran gehindert, seine sich als Änderungen an der Datei niederschlagenden Ideen anderen mitzuteilen. Kurz gefasst sind der erste und der zweite Nutzer nicht in der Lage, die Datei in Zusammenarbeit zu bearbeiten.
  • Der hierin verwendete Begriff Zusammenarbeit oder Kollaboration bedeutet eine Fähigkeit für mehrere Clients zur Teilhabe an Ideen. Diese Teilhabe umfasst die Fähigkeit, die eigenen Ideen automatisch gegenüber den anderen Mitgliedern auszudrücken, ohne den anderen Mitgliedern die Ideen explizit mitteilen zu müssen. Kollaboration umfasst außerdem die Fähigkeit für jedes Mitglied, Ideen von Mitgliedern, die Ideen senden, automatisch zu empfangen. Somit bedeutet Kollaboration mindestens die Kommunikation zwischen Mitgliedern, die Teilnehmer an den Kollaborationsbestrebungen sind. Diese Kommunikation/Kollaboration kann vielen Modellen folgen. Eine „Brainstorming"-Sitzung ist ein unbeschränktes Kollaborationsmodell. Andererseits handelt es sich bei einem „Ring"-Modell, in dem jedes Mitglied eine spezifische Runde hat, in der es Ideen ausdrücken kann, um ein beschränktes Kollaborationsmodell.
  • In einem in der US-Patentschrift Nr. 5,781,732 offenbarten Kollaborationssystem werden Datenänderungsanforderungen in Reaktion auf Nutzerinteraktionen generiert und an eine Antwortsendeeinheit, die mit allen Kollaborationsteilnehmern verbunden ist, gesendet. Die Antwortsendeeinheit sendet die Datenänderungsanforderungen an alle an einer Kollaboration teilnehmenden Nutzer rund. Jeder Nutzer verfügt über eine lokale Kopie der Kollaborationsdaten und einen Mechanismus, der die Datenänderungsanforderungen empfängt und die angeforderten Änderungen an der lokalen Datenkopie vornimmt. Da alle Datenänderungsanforderungen die Antwortsendeeinheit durchlaufen müssen, werden alle Datenänderungsanforderungen von jedem Kollaborationsteilnehmer in derselben Reihenfolge empfangen und somit wird Einheitlichkeit der Daten erhalten.
  • Zu Kollaboration kann es zwischen Nutzern kommen, die einen Computer oder Server betreiben oder sie kann über ein Netzwerk erfolgen, in dem sich jeder Nutzer an einem mit dem Netzwerk verbundenen Computer befindet. Das Internet ist ein solches Netzwerk, welches eine dynamische, öffentliche Umgebung für die Kommunikation und Interaktion unter ihren Millionen Nutzern geschaffen hat. In der Wirtschaft hat das Internet und insbesondere die im Internet betriebenen World-Wide-Web-Anwendungen die Beziehungen zwischen Vendoren-Herstellern, Herstellern-Verteilern, Verteilern-Kunden und andere Beziehungen neu definiert. Durch die Ausdehnung der Internettechnologie auf interne, gesicherte Netzwerke einzelner Unternehmen, das so genannte „Intranet" oder „privates Internet", sind neue Formen zur gemeinsamen Nutzung von Dokumenten und Informationen für einzelne Angestellte und Arbeitsgruppen unter Verwendung der Unternehmensverzeichnisse und der Netzwerkinfrastruktur möglich geworden.
  • Das World Wide Web (das „Web" oder „Netz") weist als Kern eine Server-Client-Architektur auf, in der einzelne Clients (d.h. Nutzer von Netzinhalten) über Browser als Schnittstelle über ein öffentliches Netzwerk mit Servern Verbindung aufnehmen, um Dokumente von Webseiten zu erhalten. Browser sind Softwareprogramme, die es Personal Computern ermöglichen, Internetdokumente anzufordern, zu erhalten (z.B. herunterzuladen), zu interpretieren und darzustellen und allgemein im Internet zu navigieren. Webseiten sind Sammlungen von Dokumenten, die in der Regel aus einer Homepage und verwandten, verlinkten Dokumenten bestehen, welche sich auf vom Client entfernten Servern befinden. Bei den Dokumenten kann es sich um Mischdokumente handeln, die Daten, Grafiken, Video, Ton und/oder andere Arten von Medien sowie Links zu anderen Dokumenten enthalten.
  • Dem Web und anderen Internettechnologien liegen Normierungsfortschritte zugrunde, einschließlich PC-Hardware, Software, Netzwerkprotokolle und Infrastrukturkonventionen (wie den „Uniform Resource Locator" oder „URL"). URLs stellen Ortsadressen für alle Dokumentenobjekte auf dem WWW bereit. Eine URL verweist eindeutig auf ein Dokumentenobjekt und definiert oftmals einen Zugriffsalgorithmus unter Verwendung von Internetprotokollen.
  • Um die Vorteile der Internetwerkzeuge nutzen zu können, sind Ressourcen in Übereinstimmung mit den Internetprotokollen entwickelt worden, einschließlich Anwendungen wie beispielsweise E-Mail. E-Mails ist eine elektronische Post, mittels derer Dokumente elektronisch gesendet und an ausgewählten Adressen empfangen werden. Es ist geschätzt worden, dass die überwiegende Mehrheit internetbasierter Interaktionen per E-Mail und andere browserbasierte Medien erfolgt, welche einem Modell „Dokument senden und empfangen" folgen. Möglicherweise ist dies der Grund dafür, dass die Nutzer das Internet als inhärent „Peer-to-Peer"-basiert ansehen, wobei Personen auf Dokumente zugreifen, die von anderen Personen bereitgestellt werden, ohne dass eine höhere Stelle eingreift.
  • In der Folge sind neue Kollaborationsmodelle entwickelt worden, die mehr auf eine „Peer-to-Peer"-Weise funktionieren. Diese letzteren Modelle stützen sich auf Direktverbindungen zwischen Nutzern in gemeinsam benutzten privaten Räumen, die „Telespaces" genannt werden. Jeder Nutzer verfügt über ein „Aktivität" genanntes Programm, das auf seinem Personal-Computer-System, Kommunikationsanwendung oder anderen netzwerkfähigen Vorrichtungen betrieben werden kann. Das Aktivitätsprogramm antwortet auf Nutzerinteraktionen durch Generieren von Datenänderungsanforderungen, die „Deltas" genannt werden. Die Aktivität weist auch eine Daten-Änderungs-Anordnung auf, die eine lokale Datenkopie führt und die durch die Deltas angeforderten Änderungen an den Daten vornimmt. Die Deltas werden über einen Dynamikverwalter von einem Nutzer zu einem anderen verteilt. Der letztere Typ von Kollaborationssystem wird ausführlich beschrieben in der US-Patentanmeldung Nr. 09/357,007 mit dem Titel „METHOD AND APPARATUS FOR ACTIVITY-BASED COLLABORATION BY A COMPUTER SYSTEM EQUIPPED WITH A COMMUNICATION MANAGER", eingereicht am 19. Juli 1999 durch Raymond E. Ozzie, Kenneth G. Moore, Robert H. Myhill und Brian M. Lambert; der US-Patentanmeldung Nr. 09/356,930 mit dem Titel „METHOD AND APPARATUS FOR ACTIVITY-BASED COLLABORATION BY A COMPUTER SYSTEM EQUIPPED WITH A DYNAMICS MANAGER", eingereicht am 19. Juli 1999 durch Raymond E. Ozzie und Jack E. Ozzie und US-Patentanmeldung Nr. 09/356,148 mit dem Titel „METHOD AND APPRATUS FOR PRIORITIZING DATA CHANGE REQUESTS AND MAINTAINING DATA CONSISTENCY IN A DISTRIBUTED COMPUTER SYSTEM EQUIPPED FOR ACTIVITY-BASED COLLABORATION", eingereicht am 19. Juli 1999 durch Raymond E. Ozzie und Jack E. Ozzie.
  • Das Internet ist bei der Versorgung von Nutzern mit Unterhaltung und nützlichen Kommunikationswege dynamisch und flexibel, aber es erfüllt nicht alle Bedürfnisse des Nutzers. Beispielsweise scheint das Internet für Kollaboration auf ideale Weise geeignet zu sein, da es die Fähigkeit aufweist, weit voneinander entfernte Nutzer mit verschiedener Hardware und Software zu verbinden. Die Sicherheit des Internets lässt jedoch viel zu wünschen übrig. Während Nachrichten über das Internet an verschiedene Mengen von Nutzern gesendet werden können, werden diese Nachrichten in der Regel auf Webseiten Dritter gefiltert, wo die Kommunikationen abgefangen und die Vertraulichkeit verletzt werden kann. Während Nutzer zunehmend über das Internet interagieren, kommunizieren sie in der Folge weiterhin „außerhalb" des Internets auf herkömmlicheren gesicherten Wegen, wie beispielsweise über Mittel mit mehreren Medien (Telefon, Fax, Weißwandtafel), Mittel mit mehreren Zeiten (Echtzeit, Über-Nacht-Post) und über andere informelle Kommunikationswege.
  • Es wäre wünschenswert, das Internet auf sichere Kollaborationskommunikationen und andere gemeinsame und wechselseitige Aktivitäten zwischen Personen und kleinen Gruppen in gemeinsam genutzten privaten Räumen auszudehnen. Derartige Interaktionen sollten vorzugsweise sofort, direkt und vertraulich zwischen den Personal Computer der Personen oder anderen netzwerkfähigen Vorrichtungen erfolgen. Es wäre außerdem wünschenswert, eine Technik bereitzustellen, die es Nutzern an verschiedenen entlegenen Stellen ermöglicht, gesichert zu kommunizieren, ohne die Nutzer an der Einrichtung einer gesicherten Kommunikationsstrecke und dem Aufrechterhalten des Sicherheitssystems extensiv zu beteiligen. Es ist außerdem wünschenswert, die „Zusatzkosten", die durch die Bereitstellung sicherer Transaktionen entstehen, auf ein Minimum zu reduzieren, um den Durchsatz und die Betriebsgeschwindigkeit zu erhöhen.
  • Aus US-A-6 052 787 ist ein Verfahren für gruppenbasierte kryptografische Codeverwaltung zwischen einer ersten Computereinheit und jeder erforderlichen Anzahl von anderen Computereinheiten bekannt. Gemäß diesem Verfahren wird eine erste Nachricht N1 durch die erste Computereinheit gebildet und an mindestens einige der Gruppencomputereinheiten gesendet. Die erste Nachricht enthält mindestens einen ersten Sicherheitsrichtlinienvorschlag und eine erste Identitätüberprüfungsvariable. Der Sicherheitsrichtlinienvorschlag enthält Sicherheitsdienste, -mechanismen und -algorithmen. Jede der Gruppencomputereinheiten prüft die Integrität des ersten Sicherheitsrichtlinienvorschlags unter Verwendung der ersten Identitätsüberprüfungsvariablen und durch Bilden einer zweiten Nachricht N2, die einen zweiten Sicherheitsrichtlinienvorschlag enthält und die unabhängig von den durch die anderen Gruppencomputereinheiten gebildeten zweiten Nachrichten ist. Die zweiten Nachrichten werden an die erste Gruppencomputereinheit gesendet, welche die einzelnen zweiten Sicherheitsrichtlinienvorschläge unter Verwendung der zweiten Identitätsüberprüfungsvariablen verifiziert und die eine dritte Nachricht N3 zum Senden an die Gruppencomputereinheiten bildet. Die Gruppencomputereinheiten verwenden die in der dritten Nachricht enthaltene dritte Identitätsüberprüfungsvariable, um die Integrität einer in der dritten Nachricht übertragenen Sicherheitsrichtlinie zu prüfen, welche die für die nachfolgende Kommunikation zu verwendende Sicherheitsrichtlinie festlegt.
  • Um Vertraulichkeit für die Nachrichten N1 und N3 bereitzustellen, werden diese Nachrichten unter Verwendung eines öffentlichen Schlüssels der jeweiligen Gruppencomputereinheit verschlüsselt und werden in der jeweiligen Gruppencomputereinheit unter Verwendung eines geheimen Codes der entsprechenden Gruppencomputereinheit entschlüsselt. Die zweite Nachricht N2 kann unter Verwendung eines geheimen Codes der jeweiligen Sender-Gruppencomputereinheit verschlüsselt werden und in der ersten Gruppencomputereinheit unter Verwendung des öffentlichen Schlüssels der ersten Gruppencomputereinheit entschlüsselt werden.
  • Durch dieses Verfahren bestimmt die erste Computereinheit auch, welche weiteren Gruppencomputereinheiten eingeladen werden, an einer nachfolgenden Kommunikation teilzunehmen. In den Nachrichten werden zu Authentifikationszwecken Zufallszahlen verwendet. Eine erste Zufallszahl wird in der ersten Computereinheit erzeugt und in der ersten Nachricht N1 an die Gruppencomputereinheiten gesendet. Die Authentifizierung wird dadurch durchgeführt, dass die erste Zufallszahl zu der zweiten Nachricht N2 zugefügt wird, welche in verschlüsselter Form von einer betreffenden Gruppencomputereinheit zu der ersten Computereinheit gesendet wird. Dies stellt für die erste Computereinheit sicher, dass die jeweilige Nachricht nur von einer Gruppencomputereinheit gesendet worden sein kann. Dieses Verfahren sieht ferner zweite Zufallsvariablen vor, die sich unter den einzelnen Gruppencomputereinheiten voneinander unterscheiden, damit sie unabhängig voneinander in den Gruppencomputereinheiten gebildet werden und zu den einzelnen Nachrichten N2 zugefügt werden.
  • Außerdem wird in ABADI, M. und NEEDHAM, R.: „Prudent Engineering Practice for Cryptographic Protocols", RESEARCH IN SECURITY AND PRIVACY, 16. Mai 1994-18. Mai 1994, IEEE Computer Society Symposium, Oakland, KA, USA, 1994, Seiten 122-136 die Verwendung von Einmaligkeitsmerkmalen in kryptografischen Protokollen beschrieben. Derartige Protokolle können sich auf zufällige oder vorhersagbare Einmaligkeitsmerkmale in Nachrichten stützen, um Angriffe auf die Kommunikationssicherheit abzuwehren. Die Veröffentlichung erörtert auch die Verwendung von Zeitstempeln als eine Art Einmaligkeitsmerkmal.
  • KURZE DARSTELLUNG DER ERFINDUNG
  • Die Aufgabe der Erfindung ist die Bereitstellung gesicherter Interaktionen in einer Gruppe von Teilnehmern eines verteilten kollaborativen Kommunikationssystems, welches auf andere Mitglieder ausgedehnt werden kann, während Wiederabspiel- und Verschachtelungsangriffe abgewehrt werden. Dementsprechend stellt die vorliegende Erfindung ein Verfahren zum Hinzufügen eines Eingeladenen, der über ein öffentlich/privates Schlüsselpaar verfügt, zu einer gesicherten Gruppe von Kollaborationsteilnehmern bereit, welche untereinander durch Nachrichten kommunizieren, welche mit Inter-Teilnehmer-Schlüssel einschließlich paarweiser Schlüssel (Kij/Lij) und Gruppenschlüssel (KG/LG), geschützt sind.
  • Das Verfahren, wie in den Ansprüchen definiert, umfasst die Schritte des Auswählens mindestens eines der Gruppenmitglieder als Vorsitz mit der Autorität zum Hinzufügen neuer Mitglieder zu der Gruppe und eines neuen öffentlich/privaten Schlüsselpaars, und das Senden einer Einladungsnachricht vom Vorsitz an den Eingeladenen, wobei die Einladungsnachricht ein unterzeichnetes Einladungs-Einmaligkeitsmerkmal, das zeitabhängig ist und Klartextinformation zur Identifizierung des Vorsitzes enthält, und die mit dem öffentlichen Schlüssel des Vorsitzes verschlüsselt wird und mit dem privaten Schlüssel des Vorsitzes unterzeichnet wird, enthält. Der Eingeladene antwortet mit einer Annahmenachricht, die das unterzeichnete Einladungs-Einmaligkeitsmerkmal und ein unterzeichnetes Annahme-Einmaligkeitsmerkmal enthält, das zeitabhängig ist und den Eingeladenen identifizierende Klartextinformation enthält. Das unterzeichnete Annahme-Einmaligkeitsmerkmal enthält auch das Zertifikat des Vorsitzes und den Namen oder die URL der gesicherten Gruppe und ist mit dem öffentlichen Schlüssel des Vorsitzes unterzeichnet. Der Vorsitz sendet an alle Mitglieder der gesicherten Gruppe von Kollaborationsteilnehmern eine Neuer-Teilnehmer-Nachricht, welche neue Inter-Teilnehmer-Schlüssel enthält, und sendet ferner an den Eingeladenen eine Gruppendatennachricht, die das unterzeichnete Annahme-Einmaligkeitsmerkmal und mit dem öffentlichen Schlüssel des Eingeladenen geschützte Gruppeninformation enthält.
  • Die Erfindung stellt auch eine Vorrichtung, ein Computerprogrammprodukt und ein Computerdatensignal wie in den entsprechenden Ansprüchen definiert bereit.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die obigen und weitere Vorteile der Erfindung können durch Bezugnahme auf die folgende Beschreibung in Verbindung mit den beigefügten Zeichnungen besser verstanden werden, in denen:
  • 1 ein Blockdiagramm einer veranschaulichenden Architektur eines herkömmlichen Computersystems ist;
  • 2 ein schematisches Blockdiagramm eines veranschaulichenden Kollaborationssystems ist, in dem lokale Datenkopien mittels Deltas aktualisiert werden;
  • 3 ein schematisches Blockdiagramm ist, das eine Gruppe, einen Stamm und die zu ihrem Schutz verwendeten Verschlüsselungs- und Authentifikationsschlüssel veranschaulicht;
  • 4 ein schematisches Diagramm ist, das den Inhalt eines Delta, das zwischen Teilnehmern in einer Gruppe in einem Sicherheitssystem niedriger Ebene gesendet wird, veranschaulicht;
  • 5 ein schematisches Diagramm ist, das den Inhalt eines Delta, das zwischen Teilnehmern in einer Gruppe in einem Sicherheitssystem mittlerer oder hoher Ebene, das in dem Authentifizierungs/Integritätsmodus betrieben wird, gesendet wird, veranschaulicht;
  • 6 ein schematisches Diagramm ist, das den Inhalt eines Delta, das zwischen Teilnehmern in einer Gruppe in einem Sicherheitssystem mittlerer oder hoher Ebene, das in dem Authentifizierungs/Integritäts/Vertraulichkeitsmodus betrieben wird, veranschaulicht;
  • 7 ein schematisches Diagramm ist, das den Inhalt eines Delta, das zwischen Teilnehmern in einer Gruppe in einem Sicherheitssystem hoher Ebene, das in dem Authentifizierungs/Integritätsmodus betrieben wird, veranschaulicht;
  • 8 ein schematisches Blockdiagramm ist, das die Schaffung und Verifizierung digitaler Unterschriften und Zertifikate veranschaulicht;
  • 9 ein schematisches Blockdiagramm ist, das das Hinzufügen eines neuen Teilnehmers (Eingeladener) zu einer existierenden Gruppe veranschaulicht;
  • 10 ein Flussdiagramm ist, das die Schritte in einer veranschaulichenden Routine zeigt, die ein Vorsitz verwenden könnte, um einen neuen Teilnehmer zu der existierenden Gruppe hinzuzufügen;
  • 11 ein schematisches Diagramm ist, das den Inhalt einer von dem Vorsitz an den Eingeladenen gesendeten Einladungsnachricht veranschaulicht;
  • 12 ein schematisches Diagramm ist, das den Inhalt einer durch einen Eingeladenen an den Vorsitz gesendeten Annahmenachricht veranschaulicht;
  • 13 ein schematisches Diagramm ist, das den Inhalt eines von dem Vorsitz an alle existierenden Teilnehmer einer Gruppe gesendeten Neuer-Teilnehmer-hinzugefügt-Deltas, welches die Gruppe informiert, dass ein neuer Teilnehmer hinzugefügt worden ist, veranschaulicht;
  • 14 ein schematisches Diagramm ist, das den Inhalt einer von dem Vorsitz an einen neu hinzugefügten Teilnehmer gesendeten Nachricht, die den Teilnehmer über die Telescape-Daten informiert, veranschaulicht;
  • 15 ein Flussdiagramm ist, das die Schritte in einer veranschaulichenden Routine, die ein Eingeladener verwenden könnte, um auf eine Einladung zu antworten, veranschaulicht;
  • 16 ein Flussdiagramm ist, das die Schritte einer veranschaulichenden Routine, die ein Vorsitz verwenden könnte, um auf eine Annahmenachricht von einem Eingeladenen zu antworten, veranschaulicht;
  • 17 ein Flussdiagramm ist, das die Schritte in einer veranschaulichenden Routine, die ein existierender Teilnehmer verwenden könnte, um auf ein Neuer-Teilnehmer-hinzugefügt-Delta zu antworten, veranschaulicht;
  • 18 ein Flussdiagramm ist, das die Schritte in einer veranschaulichenden Routine, die ein neu hinzugefügter Teilnehmer verwenden könnte, um auf eine Nachricht von dem Vorsitz zu antworten, mit der vertrauliche Informationen übertragen werden, veranschaulicht;
  • 19 ein schematisches Diagramm ist, das den Inhalt einer Deltanachricht, in der Wiederverschlüsselungsinformation im Huckepackverfahren übermittelt wurde, veranschaulicht;
  • 20 ein schematisches Blockdiagramm ist, das die Gesamtarchitektur einer bevorzugten Implementation des erfindungsgemäßen Sicherheitssystems veranschaulicht;
  • 21 ein schematisches Blockdiagramm ist, das die beispielhaften abstrakten Klassen in einer objektorientierten Implementation des erfindungsgemäßen Sicherheitssystems veranschaulicht;
  • 22 ein schematisches Blockdiagramm ist, das die beispielhaften konkreten Klassen in einer objekt orientierten Implementation des erfindungsgemäßen Sicherheitssystems veranschaulicht;
  • 23 ein schematisches Diagramm ist, das eine Bildschirmanzeige einer Dialogkasten, die Information zur visuellen Überprüfung anzeigt und von einem Nutzer erfordert, die Informationen anzunehmen oder abzulehnen, veranschaulicht.
  • AUSFÜHRLICHE BESCHREIBUNG
  • 1 veranschaulicht eine herkömmliche Systemarchitektur für ein beispielhaftes Computersystem 100, mit dem die offenbarte Erfindung implementiert werden kann. Das beispielhafte Computersystem aus 1 wird jedoch nur zu Beschreibungszwecken erörtert, und soll nicht als Einschränkung der Erfindung angesehen werden. Obwohl die folgende Beschreibung sich auf allgemein bei der Beschreibung von bestimmten Computersystemen verwendeten Begriffen beziehen kann, gelten die Konzepte gleichfalls für andere Computersysteme, einschließlich Systemen, die Architekturen aufweisen, welche sich von den in 1 gezeigten unterscheiden.
  • Das Computersystem 100 enthält eine Zentrale Verarbeitungseinheit (CPU) 105, die einen herkömmlichen Mikroprozessor, einen Direktzugriffsspeicher (RAM) 110 für temporäres Speichern von Informationen, und einen Nur-Lese-Speicher (ROM) 115 für das permanente Speichern von Informationen enthalten kann. Eine Speichersteuerung 120 ist zum Steuern eines System-RAMS 110 bereitgestellt. Eine Bussteuerung 125 ist zum Steuern eines Bus 130 bereitgestellt und eine Unterbrechungssteuerung 135 wird zum Empfang und Verarbeiten verschiedener Unterbrechungssignale von anderen Systemkomponenten verwendet.
  • Massenspeicherung kann durch Disketten 142, CD-ROM 147 oder Festplatte 152 bereitgestellt werden. Über ent fernbare Medien, wie Diskette 142 und CD-ROM 147, können Daten mit Clientcomputer 100 ausgetauscht werden. Die Diskette 142 kann in das Diskettenlaufwerk 141 eingeführt werden, welches über die Steuerung 140 mit dem Bus 130 verbunden ist. Analog kann eine CD-ROM 147 in das CD-ROM-Laufwerk 146 eingeführt werden, welches über Steuerung 145 mit dem Bus 130 verbunden ist. Schließlich ist die Festplatte 152 ein Teil eines festen Festplattenlaufwerks 151, welches über Steuerung 150 mit Bus 130 verbunden ist.
  • Durch eine Reihe von Vorrichtungen können Nutzereingaben in das Computersystem 100 bereitgestellt werden. Beispielsweise kann eine Tastatur 156 und eine Maus 157 mit dem Bus über die Tastatur- und Maussteuerung 155 verbunden sein. Ein Audiosignalgeber 196, der sowohl als Mikrofon als auch als Lautsprecher fungieren kann, ist durch eine Audiosteuerung 197 mit dem Bus 130 verbunden. Durchnittsfachleuten sollte klar sein, dass andere Eingabevorrichtungen, wie ein Stift und/oder eine Tafel und ein Mikrofon für die Spracheingabe über Bus 130 und eine entsprechende Steuerung mit dem Clientcomputersystem verbunden sein kann. Die DMA-Steuerung 160 wird zur Durchführung von direktem Speicherzugriff auf das RAM-System 110 bereitgestellt. Eine visuelle Anzeige wird durch eine Videosteuerung 165, welche eine Videoanzeige 170 steuert, bereitgestellt.
  • Das Computersystem 100 enthält außerdem einen Netzwerkadapter 190, der es dem Clientcomputer 100 ermöglicht, über einen Bus 191 an ein Netzwerk 195 angeschlossen zu werden. Das Netzwerk 195, bei dem es sich um ein Local Area Network (LAN), ein Wide Area Network (WAN) oder das Internet handeln kann, kann Allzweckkommunikationsleitungen verwenden, die mehrere Netzwerkvorrichtungen verbinden.
  • Das Computersystem 100 wird allgemein durch eine Betriebssystemsoftware betrieben und gesteuert. Unter anderen Computersystemsteuerfunktionen steuert das Betriebssystem die Zuweisung von Systemsressourcen und führt Aufgaben aus, wie die Prozessplanung, Speichermanagement, Netzwerkbildung und E/A-Dienste.
  • 2 zeigt in Form eines schematischen Blockdiagramms eine Konfiguration eines veranschaulichenden Kollaborationssystem. 2 zeigt zwei kollaborative Arbeitsstationen 200 und 202, die mit einem Netzwerk 216 verbunden sind. Jede der Arbeitsstationen 200 und 202 könnte ein Computersystem wie das in 1 gezeigte sein und das Netzwerk 216 könnte ein privates Computernetzwerk, wie ein LAN oder WAN, oder ein öffentliches Computernetzwerk, wie das Internet, sein. Alternativ könnten sich die Stationen 200 und 202 an demselben (nicht gezeigten) Computer befinden, wobei in diesem Fall die Kommunikation zwischen den beiden Endgeräten bezüglich dieses Computers lokal erfolgen würde.
  • In einer bevorzugten Ausführungsform führt jedes der Endgeräte 200 und 202 eine lokale Kopie, 204 bzw. 210 der Daten, an denen die Kollaborationsarbeit ausgeführt wird. Jede lokale Datenkopie, beispielsweise Datenkopie 204, wird durch ein entsprechendes Softwareprogramm verwaltet, welches „Dynamikverwalter" 206 genannt wird. Ebenso wird die Datenkopie 210 durch ihren entsprechenden Dynamikverwalter 212 verwaltet. Obwohl zu Veranschaulichungszwecken eine besondere Kollaborationsvorrichtung erörtert wird, ist es Fachleuten auf dem Gebiet ersichtlich, dass auch andere Kollaborationsvorrichtungen verwendet werden können, ohne in der Idee und dem Schutzumfang von den Grundsätzen der Erfindung abzuweichen.
  • Der Dynamikverwalter 206 ändert und aktualisiert seine lokale Datenkopie 204 in Reaktion auf den Empfang von selbständigen Dateneinheiten, die eine oder mehrere, „Delta" genannte Datenänderungsanforderungen enthalten. Die Datenänderungsanforderungen sind Benachrichtigungen oder Aufforderungen an den Dynamikverwalter und andere (nicht gezeigte) Komponenten hinsichtlich erwünschter Änderungen an den Daten. Deltas werden von einem Dynamikverwalter, wie Verwalter 206, in Reaktion auf Nutzerinteraktion erzeugt und werden verwendet, um sowohl die entsprechende lokale Datenkopie 204 als auch über das Netzwerk die lokalen Datenkopien in anderen Computern, welche zu den an derselben Kollaborationssitzung teilnehmenden Kollaborationsteilnehmern gehören, zu aktualisieren.
  • Ein Delta weist ein spezifisches Format auf, einschließlich eines Kopfteilabschnitts zur Bereitstellung von Steuerinformationen und einen Nutzlastabschnitt zum Bereitstellen von Informationen hinsichtlich der Daten, auf die sich die Anforderung bezieht. Ein einzelnes Delta kann eine oder mehrere Nutzlasten aufweisen. Wenn mehrere Nutzlasten eingesetzt werden, kann jede auf bestimmte Kollaborationsteilnehmer mit eindeutigen Vorrichtungsfähigkeiten oder Nutzerrollen, wie unten weiter beschrieben wird, gerichtet werden.
  • Wenn die von dem Dynamikverwalter 206 erzeugten Deltas an andere Kollaborationsteilnehmer gesendet werden sollen, interagiert der Dynamikverwalter 206 mit einem Kommunikationsverwalter 208. Analog interagiert der Dynamikverwalter 212 mit einem Kommunikationsverwalter 214. Der Kommunikationsverwalter 208 ist ein Mechanismus, der eingehende und ausgehende Deltas an geeignete Ziele leitet. In einer bevorzugten Ausführungsform kann der Kommunikationsverwalter als ein computerausführbares Programm implementiert sein, welches von Kommunikationsverwalter 206 initiierte Deltas zur Sendung über das Netzwerk 216 an einen anderen entfernten PC oder eine andere Art von netzwerkfähiger Vorrichtung leitet und welche entfernt erzeugte Deltas, die über das Netzwerk 216 erhalten werden, an den Dynamikverwalter 206 leitet.
  • Allgemein sind die Kommunikationsverwalter 208 und 214 so angeordnet, dass alle von den Dynamikverwaltern 206 und 212 erzeugten Deltas von allen an der Kollaboration teilnehmenden Nutzern empfangen werden. Jedes Delta enthält eine interne Sequenznummer, so dass der Dynamikverwalter jedes Kollaborationsteilnehmers bestimmen kann, wenn alle Deltas empfangen worden sind. Da die Deltas von unterschiedlichen Kollaborationsteilnehmern über eine Reihe unterschiedlicher Wege an jeden Kollaborationsteilnehmer gesendet werden können, kommen die Deltas möglicherweise nicht in derselben Reihenfolge an, wie sie erzeugt worden sind. Alle Deltas werden jedoch von jedem Kollaborationsteilnehmer empfangen und die interne Sequenznummer kann verwendet werden, um die Deltas in der richtigen Reihenfolge anzuwenden. Daher wird die lokale Datenkopie, die von jedem Kollaborationsteilnehmer geführt wird, wenn sie durch alle Deltas aktualisiert wird, die von den anderen Teilnehmern der Kollaboration geführten lokalen Datenkopien anpassen.
  • Es ist wünschenswert, unter den Kollaborationsteilnehmern, die an einer bestimmten Kollaboration teilnehmen, Vertraulichkeit zu halten. Dies gilt insbesondere, wenn Deltas über ein öffentliches Netz, wie dem Internet, gesendet werden. Es gibt drei Grundkonzepte, die für die Sicherheit der Information wichtig sind. Das erste ist die Authentifizierung, welche sicherstellt, dass ein Datenempfänger die Identität der Datenquelle kennt und ihr vertrauen kann. Das zweite Konzept ist die Integrität, welche sicherstellt, dass sich die Daten beim Transport nicht verändert haben. Die Integrität stellt effektiv sicher, dass die Daten nicht von anderen Parteien als der Datenquelle beschreibbar sind und dass sie von einer bekannten Quelle kommen. Datenintegrität verhindert den Angriff durch Dritte mittels Erzeugen oder „Verfälschen" nicht autorisierter Daten. Das letzte Sicherheitskonzept ist die Vertraulichkeit, welche sicherstellt, dass die Daten beim Transport nicht durch andere Parteien als der Datenquelle und dem Datenempfänger gelesen werden können. Vertraulichkeit verhindert den Angriff durch Dritte mittels Lesen oder „Abhören" der Daten.
  • Wie zuvor erwähnt, basiert die Sicherheit auf einem virtuellen Raum, in dem Kollaborationsteilnehmer an einer oder mehreren Aktivitäten teilnehmen und Gegenstände teilen, und in dem die Ergebnisse von Aktivitäten kontinuierlich auf dem Personal Computer eines Nutzers oder anderen Formen von netzwerkfähigen Vorrichtungen gespeichert werden. Der virtuelle Raum wird als „Telespace" oder „Gruppe" bezeichnet und wird mit der Vorrichtung jedes Nutzers synchron gehalten. In Übereinstimmung mit dem veranschaulichendem Sicherheitsmodell, ist die Sicherheit eines Telespaces das, was die meisten als „Gesamt"-Sicherheit erfahren werden, nachdem der Telespace gebildet, seine Teilnehmer zugelassen wurden und die Teilnehmerschaft stabil ist. Dies wird als das Festzustands-Deltaprotokoll bezeichnet und betrifft die Authentifizierung, Integrität und Vertraulichkeit von in Deltas enthaltener Information, welche zwischen Gruppenteilnehmern ausgetauscht werden. 3 ist ein schematisches Diagramm eines veranschaulichenden Telespaces oder Gruppe 300 mit fünf Mitgliedern: M0, M1, M2, M3, M4 (302-310). In jedem Telespace 300 können ein oder mehrere Stämme oder Untergruppen existieren. In 3 wird ein Stamm 312 aus drei Teilnehmern M2, M3, M4 (306, 308 und 310) veranschaulicht.
  • Jeder Teilnehmer 302-210 weist in ihm eine „Protokoll-Anordnung" (Anordnungen 303-312) auf, bei der es sich um ein Anwendungsprogramm handelt, das Sicherheitsnachrichten an andere Teilnehmer sendet und Sicherheitsinformation manipuliert.
  • Informationen in Telespaces 300 und Stämmen 312 sind durch einen oder mehrere Schlüssel geschützt: einen als K bezeichneten Verschlüsselungsschlüssel und ein Nachrichten-Authentifizierungs-/Integritätscode-(MAC)-Schlüssel, der als L bezeichnet wird. Der K- und der L-Schlüssel sind herkömmliche Schlüssel für eine symmetrische Chiffre und weisen Telespace auf. Das erfindungsgemäße System kann sowohl Blockchiffren als auch Stromchiffren verwenden, aber zwischen den Nachrichten wird kein Status erhalten. Somit sind keine Kommunikationsendpunkte notwendig, um den Sicherheitszustand der Stromchiffre von einer Nachricht zu der nächsten zu halten. Auf diese Weise ist keine Neusynchronisation notwendig, wenn es zu einer vorübergehenden Kommunikationsunterbrechung kommt.
  • Blockchiffren werden im Zählermodus mit einem Initialisierungsvektor verwendet, der immer, wenn er verwendet wird, zufallsmäßig neu erzeugt wird. Der Initialisierungsvektor weist eine Länge auf, die gleich der Blocklänge der Chiffre ist und wird verwendet, um einen stereotypischen Kopfteilangriff auf herkömmliche Weise abzuwehren. Stromchiffren werden im Blockmodus durch Kombination eines Initialisierungsvektors mit dem Schlüssel, wie durch einen Exklusiv-ODER-Vorgang, und dann durch Reinitialisieren des Schlüsselstroms für jede Nachricht verwendet. In diesem Fall weist der Initialisierungsvektor eine Länge auf, die gleich der Schlüssellänge ist. Die Initialisierungsvektoren sind im Allgemeinen nicht hinsichtlich Vertraulichkeit oder Authentifizierung/Integrität geschützt.
  • Es wird ferner angenommen, dass allen Schlüssel eine Art Veraltungsmechanismus zugeordnet ist, so wie ein Time-out, oder eine feste Anzahl von geschützten Nachrichten oder Bytes. Dieser Mechanismus unterliegt der lokalen Richtlinie, welche durch den Telespace bestimmt wird, und muss in keinem der unten beschriebenen Protokolle übertragen werden.
  • Gruppenschlüssel, die als KG/LG bezeichnet sind (jeweils) Verschlüsselung/MAC-Schlüssel, welche von allen Teilnehmern der Gruppe 300 gemeinsam verwendet werden. Diese Schlüssel werden verwendet, um (jeweils) die Vertraulichkeit/Integrität von in den Deltas enthaltener Information vor Angriffen durch dritte (nicht-Gruppen-)Parteien zu schützen. Analog sind die als KT/LT bezeichneten Stammschlüssel Verschlüsselungs/MAC-Schlüssel, die von allen Teilnehmern des Stamms 312 gemeinsam genutzt werden. Diese Schlüssel werden verwendet, um (jeweils) die Vertraulichkeit/Integrität von in den Deltas enthaltenen Informationen vor Angriffen von (nicht-Gruppen-)Parteien zu schützen.
  • Außerdem sind als K01/L01 bezeichnete paarweise Schlüssel (jeweils) Verschlüsselungs/MAC-Schlüssels, die gemeinsam von den Teilnehmern M0 und M1 und nicht von anderen Gruppenteilnehmern verwendet werden, und es sind bidirektionale Schlüssel, die zum Schutz der Vertraulichkeit in beiden Richtungen zwischen M0 und M1 verwendet werden. Diese Schlüssel werden verwendet, um (jeweils) die Vertraulichkeit/Integrität in Deltas vor Angriffen von Gruppenteilnehmern M2, M3 und M4 zu schützen. Ähnliche paarweise Schlüssel, Kij/Lij, können verwendet werden, um die zwischen anderen Kombinationen von Teilnehmern, Mi und Mj, ausgetauschten Informationen vor Angriffen von anderen Gruppenteilnehmern zu schützen.
  • In einem Telespace gehört die Festzustandssicherheit zu einer von fünf Ebenen, von denen eine durch den Schaffer des Telespace 300 zu der Zeit der Schaffung des Telespace gewählt werden kann. Zu den fünf Ebenen gehört die Sicherheit niedriger Ebene, die keine Verwendung von Schlüsseln erfordert. Diese Ebene stellt überhaupt keine kryptografische Sicherheit bereit. Die nächste Ebene ist die Sicherheit mittlerer Ebene, die ein einziges Schlüsselpaar (KG/LG) für alle Teilnehmer der Gruppe verwendet. In dieser Ebene kann die Authentifizierung/Integrität durch Verwendung nur des MAC-Schlüssels LG des KG/LG-Paars zum Schutz von Deltas bereitgestellt werden. Analog kann die Authentifizierung/Integrität und Vertraulichkeit durch Verwendung sowohl des KG- als auch des LG-Schlüssels zum Schutz von Deltas verwendet werden.
  • Die nächste Ebene ist die Sicherheit hoher Ebene, welche eine Kombination der Gruppenschlüssel KG/LG und die paarweisen Schlüssel Kij/Lij verwendet. Wenn nur die Authentifizierung/Integrität erforderlich ist, werden nur die paarweisen MAC-Schlüssel (Lij) verwendet, um die Deltas zu schützen; der Gruppenschlüssel (KG) wird nicht verwendet. Wenn Authentifizierung/Integrität/Vertraulichkeit erforderlich ist, werden alternativ sowohl der Verschlüsselungsschlüssel KG und die paarweisen MAC-Schlüssel Lij, zum Schutz der Deltas verwendet.
  • Sowohl bei der Sicherheit mittlerer Ebene als auch der hohen Ebene werden die paarweisen Verschlüsselungsschlüssel (Kij) und die MAC-Schlüssel (Lij) verwendet, um die Gruppen- oder Stammschlüssel (KG/LG oder KT/LT) neu zu verschlüsseln.
  • Die obigen Ebenen und Modelle können auf die Gruppe (Telespace) insgesamt angewendet werden und lassen sich auch auf alle Stämme (Untergruppen) anwenden. Alle Stämme in einem Telespace weisen dieselbe „Gesamtsicherheit" wie der Telespace selbst auf, daher können die oben erörterten Ebenen und Modelle für Gruppen auf Stämme angewendet werden, indem die Gruppenschlüssel KG/LG durch die Stammschlüssel KT/LT, überall wo sie oben auftreten, ersetzt werden.
  • 4 veranschaulicht den Inhalt eines „Deltas", das verwendet wird, um Information zwischen Gruppenteilnehmern zu übermitteln. Jedes Delta besteht aus einem Nachrichtenkopf 400, welcher Information enthält, die von der spezifischen Implementation des Sicherheitssystems abhängt. Diese Information kann eine Protokollversionsnummer enthalten, die wiederum Versionsnummern sowohl für das Kollaborationssystem als auch für das Sicherheitsuntersystem enthalten kann. Der Nachrichtenkopf 400 kann auch eine Art Nachrichtenfahne oder Tag-Kennung enthalten, bei der es sich um eine Kennung handelt, die sich für jede verschiedene Nachrichtenart unterscheidet. Andere Information, die in der Nachricht enthalten sein kann, kann eine strukturierte Sequenznummer sein. Diese letztere Nummer ist eine zum Teil geordnete Sequenznummer, welche Telespace aufweist, und in diesem Raum identifiziert sie sowohl den Sender der Nachricht und den spezifischen Moment der Nachricht selbst.
  • Der Kopfteil 400 kann hinsichtlich Vertraulichkeit nie geschützt sein, sondern kann, abhängig von der erforderlichen Sicherheitsebene, hinsichtlich Authentifizierung/Integrität geschützt sein, genau wie die Anwendungsdaten 402, welche die Nutzlast oder die Information enthalten, die tatsächlich zwischen Gruppenteilnehmern gesendet werden. Die Art der Codierung der Deltas, wie in 4 gezeigt, hängt von der gewünschten Sicherheitsebene ab. Bei einem Sicherheitsmodus „niedriger Ebene", der keine Sicherheit im kryptografischen Sinne gewährleistet, wird das Delta beispielsweise wie in 4 gezeigt gesendet, wobei vorzugsweise die Kopfteilinformationen 400 zuerst gesendet werden, gefolgt von der Nutzlast 402, obwohl die Reihenfolge von Kopfteil und Nutzlast für die Funktionsweise der Erfindung nicht erheblich ist. In diesem Fall können dritte (nicht Gruppen-)Parteien die Deltainformationen 402 lesen oder abhören und können unpersönliche oder „verfälschte" Deltas schreiben.
  • Im Fall eines Sicherheitssystems „mittlerer Ebene", das in dem vorgenannten Authentizitäts/Integritäts-Modus betrieben wird, wird die Deltainformation wie in 5 gezeigt geschützt. Insbesondere wird für jedes Delta die Kopfteilinformation 500 gesendet, gefolgt von einer Schlüsselversionsnummer 502, den Klartextdaten 504 und einem Authentifizierer 506. Wieder ist die Reihenfolge dieser Elemente nicht entscheidend. Bei dem Authentifizierer kann es sich um einen MAC-Code 506 handelt, der die Authentifizierung/Integrität der Daten 504 schützt und nachweist, dass die Nachricht an einen Gruppenteilnehmer gesendet worden ist, da nur Gruppenteilnehmer den Gruppenauthentifizierungsschlüssel LG kennen. In einer alternativen Ausführungsform kann ein Authentifizierer aus einer öffentlichen Schlüsselunterschrift auch als Nachrichtenauthentifizierer verwendet werden. In diesem Fall besteht der Nachrichtenauthentifizierer 506 aus der öffentlichen Schlüsselunterschrift der gehashten aneinandergeketteten Daten und Kopfteile.
  • In einer bevorzugten Ausführungsform weist eine Schlüsselversionsnummer zwei Teile auf: einen Telespacebreiten eindeutigen String, der „Keyidentifier" oder „Schlüsselkennzeichnung" genannt wird und eine inkrementelle Sequenznummer, die „Schlüsselversion" genannt wird. Die Schlüsselkennzeichnung wird benötigt, um zwischen Schlüsseln zu unterscheiden, die unabhängig voneinander von verschiedenen Teilnehmern des Telespace erzeugt werden können. Da ein Teilnehmer nicht weiß, dass ein anderer Teilnehmer ebenfalls einen neuen Schlüssel generiert, ermöglicht die Schlüsselkennzeichnung die eindeutige Identifizierung der Schlüssel. Die SchlüsselVersion wird benötigt, um zwischen alten, aktuellen und neuen Schlüsseln zu unterscheiden. In einem Festzustand verwenden Teilnehmer eine Gruppe von Schlüsseln, die dieselben SchlüsselVersions-Werte aufweisen. Die Teilnehmer könnten „alte" Schlüssel mit geringeren SchlüsselVersions-Werten als den aktuellen SchlüsselVersions-Wert entfernen.
  • In einer bevorzugten Implementation wird ein MAC-Code 506 konstruiert, indem zuerst die aneinandergeketteten Daten 504 und der Kopfteil 500 gehasht werden und das gehashte Ergebnis dann in Übereinstimmung mit einem herkömmlichen Nachrichtenauthentifizierungsalgorithmus geschützt wird. Die Zwischen-Hash-Funktion wird verwendet, um einen MAC-Code auf eine Weise zu konstruieren, die parallel zu der unten erläuterten Version hoher Sicherheit ist. Es ist auch möglich, diesen Modus ohne Verwendung der Zwischen-Hash-Funktion zu implementieren, indem der Kopfteil und die Daten in dem Gruppen-Authentifikationsschlüssel LG unter Verwendung wiederum eines herkömmlichen MAC-Algorithmus geschützt wird. Wie zuvor erwähnt erzeugt das in dem Authentifizierungs/Integritäts-Modus betriebene Sicherheitssystem mittlerer Ebene ein Sicherheitssystem, in dem dritte Parteien lesen oder abhören können, aber nur Gruppenteilnehmer Deltas anderer Teilnehmer schreiben, inpersonalisieren oder verfälschen können.
  • Ein in dem Authentifizierung/Integritäts/Vertraulichkeits-Modus betriebenes Sicherheitssystem mittlerer Ebene schützt die Deltadaten wie in 6 gezeigt. Insbesondere wird ein Delta durch Senden des Kopfteils mit der Schlüsselversionsnummer 602 und einem Initialisierungsvektor 603, den Daten 604 und dem Nachrichtenauthentifizierungscode 606 gesendet. In diesem Fall sind die Daten 604 jedoch verschlüsselt worden. Dieses Protokoll schützt die Vertraulichkeit der Deltadaten durch ihre Verschlüsselung in dem Gruppenverschlüsselungsschlüssel KG und schützt weiter die Integrität und Authentizität mit dem Gruppenauthentifizierer 606. Die Daten 604 werden mit dem Gruppenverschlüsselungsschlüssel KG mittels herkömmlicher Verschlüsselungsalgorithmen verschlüsselt und die verschlüsselten Daten sind mit einem Initialisierungsvektor verbunden. Der Authentifizierungs- oder MAC-Code wird wiederum in einer bevorzugten Ausführungsform durch Hashen der Verkettung des Kopfteils und der Klartextdaten und dann Codieren der gehashten Informationen mit dem Gruppenauthentifikatorschlüssel LG gebildet. Es ist auch möglich, diesen Modus durch Verschlüsselung der Verkettung der Daten plus einem Hash des Kopfteils und Daten mit einem einzigen Verschlüsselungsschlüssel KG zu verschlüsseln und das Ergebnis dann mit dem Kopfteil, der Schlüsselversionsnummer und dem Initialisierungsvektor zu verketten. Diese letzte Verschlüsselung stellt sowohl die Vertraulichkeit als auch Authentifizierung/Integrität sicher, ohne dass ein separater MAC-Abschnitt verwendet wird, der die Verantwortlichkeiten für die Vertraulichkeit und die Authentifizierung/Integrität zwischen zwei Schlüsseln KG und LG aufteilt. Die in 6 gezeigte Implementation wird eigentlich dazu verwendet, die Implementation zu dem unten erörterten Sicherheitsmodus hoher Ebene parallel zu machen.
  • In einem in dem Authentifizierung/Integritätsmodus betriebenen Sicherheitssystem „hoher Ebene" können die Deltadaten unter Verwendung entweder der in 5 gezeigten Konfiguration oder der in 7 gezeigten Konfigurationen geschützt werden. Das in diesem System verwendete Protokoll sendet Klartextdateninformationen, aber um Authentifizierung/Integrität sicherzustellen, verwendet es entweder einen einzeln ausgerichteten, Geheimschlüssel-Mehrfachauthentifizierer oder einen Authentifizierer der öffentlichen Schlüsselunterschrift.
  • In dem Fall eines einfach ausgerichteten Geheimschlüssel-Mehrfachauthentifizierers wird die in 5 gezeigte Konfiguration verwendet. Insbesondere wird die Kopfteilinformation 500 mit der Schlüsselversionsnummer 502, die unverschlüsselten Daten 504 und dem Nachrichtenauthentifizierer 506 gesendet. In diesem Fall jedoch besteht die Schlüsselversionsnummer 502 aus einer Verkettung aller Schlüsselversionen zwischen dem Sender und allen Empfängern. Auch der Nachrichtenauthentifizierer 506 besteht aus einer Verkettung der einzelnen Nachrichtenauthentifizierer zwischen dem Sender und jedem Empfänger. Jeder Nachrichtenauthentifizierer ist mit einem Authentifzierungsschlüssel geschützt, der nur zwischen dem Sender und jedem Empfänger (einer der Lij-Schlüssel) verwendet wird.
  • In einer bevorzugten Ausführungsform wird wieder ein Zwischenhash in dem Authentifizierungscode verwendet. Insbesondere werden der Kopfteil und die Daten verkettet, gehasht und dann mit dem geeigneten Authentifizierungsschlüssel geschützt. In diesem Fall wird der Zwischenhash verwendet, um das erneute Hashen des gesamten Kopfteils und Deltas für jeden der Authentifizierungsschlüssel zu vermeiden. Sobald der Kopfteil und das Delta gehasht worden sind, kann der Hash mehrfach verwendet werden, indem einfach die gehashten Informationen in dem geeigneten Authentifizierungsschlüssel geschützt werden.
  • In einer alternativen Ausführungsform wird ein Authentifizierer der öffentlichen Schlüsselunterschrift als Nachrichtenauthentifizierungscode verwendet. Diese Konfiguration wird in 7 veranschaulicht. In dieser Anordnung folgen auf die gesendete Kopfteilinformation 700 zuerst die unverschlüsselten (A/I-Modus) oder die verschlüsselten (A/I/V-Modus) Daten 702. Der Nachrichtenauthentifizierungscode 704 besteht aus der öffentlichen Schlüsselunterschrift des gehashten verketteten Kopfteils und der Daten.
  • Ein in dem Authentifizierungs/Integritäts/Vertraulichkeitsmodus betriebenes System hoher Ebene schützt Daten mit den in 6 und 7 veranschaulichten Deltakonfigurationen. Dies ist im Wesentlichen derselbe wie der in 5 und 7 gezeigte Authentifizierungs/Integritäts/Vertraulichkeitsmodus mit der Ausnahme, dass die Deltadaten mit dem Gruppenverschlüsselungsschlüssel KG verschlüsselt und im Fall von 6 mit einem Initialisierungsvektor verkettet sind.
  • In 8 wird ein Mechanismus zum Generieren und Verwenden einer digitalen Unterschrift oder eines digitalen Zertifikats veranschaulicht. Um eine digitale Unterschrift der Daten 800 zu erzeugen, wird ein gehashter Wert der Daten 800 unter Verwendung eines einer Reihe allgemein bekannter Hash-Algorithmen wie bei Schritt 802 angezeigt, berechnet. Die gehashten Daten werden (in einem verschlüsselungsartigem Vorgang) wie bei Schritt 804 angezeigt, unter Verwendung des privaten Schlüssels eines öffentlichen/privaten Schlüsselpaars 804 unterzeichnet. Das Ergebnis ist eine digitale Unterschrift 806. Wenn die Daten außerdem die Identität oder den öffentlichen Schlüssel eines Nutzers betreffen, werden die Daten (nicht die Unterschrift) ein digitales „Zertifikat" genannt.
  • Zur Verwendung der digitalen Unterschrift wird eine Validierungsprozedur, wie unterhalb der gestrichelten Linie in 8 angezeigt, ausgeführt. Insbesondere wird die digitale Unterschrift wie durch Pfeil 812 angezeigt bereitgestellt und ein Zertifikat wird wie durch Pfeil 818 angezeigt einem Unterschriftverifizierungsalgorithmus 814 bereitgestellt, der den öffentlichen Schlüssel des öffentlichen/privaten Schlüsselpaars zum Verifizieren (ein entschlüsselungsartiger Vorgang) der gehashten Daten verwendet. Die Daten 800 selbst werden wie durch Pfeil 808 angezeigt an einen Hash-Algorithmus bereitgestellt. Dieser Hash-Algorithmus ist derselbe wie der zum Erzeugen der digitalen Unterschrift verwendete Hash-Algorithmus. Das erneute Hashen der Daten wird dann mit den verifizierten gehashten Daten wie in Kasten 816 angezeigt verglichen. Wenn die Ergebnisse dieselben sind, sind die verifizierten gehashten Daten korrekt, d.h. die Daten sind authentisch der Unterschrift zugeordnet.
  • Die Prozedur, mit der eine gesicherte Gruppe gebildet wird, wird schematisch in 9 gezeigt und die Schritte werden in 10 veranschaulicht. Wie in 9 gezeigt, besteht die Gruppe aus einem Vorsitz 902 und N-1 anderen Teilnehmern, von denen drei als Teilnehmer 906, 908 und 910 gezeigt werden. Die Bildung der Gruppe 900 wird durch einen Vorsitz 902 gesteuert, bei dem es sich um einen Teilnehmer handelt, der mit der Autorität betraut ist, einen neuen Teilnehmer einzuladen und hinzuzufügen. In Übereinstimmung mit der veranschaulichenden Prozedur wird ein Eingeladener 904 zu der Gruppe 900 nach einer Anfangsauthentifizierung zugeführt. Die folgende Erörterung fokussiert auf den Modus mit der höchsten Sicherheit mit Authentifizierung und Integrität. Die anderen vorgesehenen Moden können aus diesem Modus abgeleitet werden.
  • Die Zusammenfügeprozedur beginnt bei Schritt 1000 und schreitet zu Schritt 1002 fort. In Schritt 1002 sendet der Vorsitz 902 eine Einladungsnachricht an den potenziellen Eingeladenen 904. Diese Nachricht wird schematisch durch den Pfeil 912 in 9 veranschaulicht. Der Inhalt dieser Nachricht wird in 11 veranschaulicht. Die Nachricht besteht aus einem Kopfteil 1100, gefolgt von dem Namen des Eingeladenen 1102, bei dem es sich um eine URL oder eine andere identifizierende Information handeln kann. Die Reihenfolge des Kopfteils könnte auch umgekehrt werden, ohne von den Grundsätzen der Erfindung abzuweichen. Auf den Namen des Eingeladenen folgt ein unterzeichnetes Einladungs-„Einmaligkeitsmerkmal” 1104.
  • Bei einem unterzeichneten Einmaligkeitsmerkmal handelt es sich um unterzeichnete Daten, zu denen ein Hash des durch den Vorsitz erzeugten Zeitstempels, der Name/die URL des Vorsitzes 902, das Zertifikat des Eingeladenen 904 (wenn verfügbar), der Name/die URL des Telespace; und einen Einlade-„OpCode” gehören, bei dem es sich um ein zur Unterscheidung der verschiedenen Kontexte, in denen unterzeichnete Einmaligkeitsmerkmale auftreten, verwendetes Tag handelt.
  • Allgemein ausgedruckt ist ein Einmaligkeitsmerkmal ein zeitlich veränderlicher Parameter, der durch einen Prinzipal A erzeugt und an einen Prinzipal B gesendet wird, der nur einmal in einem gegebenen Kontext (z.B. ein Beispiel, in dem A B über das hier spezifizierte Einleitungsprotokoll einlädt) verwendet wird. Tatsächlich definiert das Einmaligkeitsmerkmal den Kontext, es wird nämlich dazu verwendet sicherzustellen, dass ein Protokoll zeitgerecht läuft, um Wiederabspiel- und Verschachtelungsangriffe abzuwehren. Ein Einmaligkeitsmerkmal muss nicht geheim sein, sondern einmalig-eindeutig. Typische Beispiele von Einmaligkeitsmerkmalen, die in verschiedenen Systemen verwendet werden, sind: kollisionsfreie Zufallszahlen, Zeitstempel (die für Systeme mit zuverlässigen Uhren nahezu ideal sind, insbesondere bei Vorhandensein eines gesicherten verteilten Zeitsynchronisationsprotokolls) und Sequenzzahlen. In einer bevorzugten Ausführungsform werden Zeitstempel verwendet.
  • In dem vorliegenden Zusammenhang ist es wichtig, dass die Einmaligkeitsmerkmale für alle Durchläufe des Protokolls niemals (innerhalb einer kryptografischen Sicherheit) wiederholt werden können (innerhalb eines bestimmten, durch eine lokale Richtlinie festgelegten Zeitfensters). Dies könnte beispielsweise dadurch erfolgen, dass ein Teilnehmer seine ausstehenden Einmaligkeitswerte/Einladungen (zusammen mit anderen Informationen über den Protokolldurchlauf) in einem nicht-flüchtigen Speicher für eine Zeitdauer (abhängig von der lokalen Richtlinie) gemäß der lokalen Uhr speichert, und die Einmaligkeitsmerkmalsinformation nach Ablauf dieser Zeit verworfen werden und der Protokolldurchlauf abgebrochen werden muss.
  • Auf das unterzeichnete Einmaligkeitsmerkmal 1104 folgen kryptografische Daten 1106, bei denen es sich um die mit dieser Nachricht verwendete Sicherheitskontextinformation handelt. Diese Information wird durch den Vorsitz ausgewählt und sie sind dafür erforderlich, dass der Empfänger die Nachricht richtig interpretieren kann. Sie enthält insbesondere den Stringnamen des zur Verschlüsselung der Information mit dem Einmal-Schlüssel verwendeten Algorithmus, wie unten erörtert. Sie enthält auch etwaige andere Informationen, die der Empfänger zur Verarbeitung der Nachricht benötigt, beispielsweise die Schlüssellänge, die Anzahl von Runden, die Namen der verwendeten Hash-Algorithmen, die Namen der Schlüsselgeneratoralgorithmen usw.
  • Auf die kryptografischen Daten 1106 folgen die mit dem öffentlichen Schlüssel des Eingeladenen gemäß eines vorher vereinbarten öffentlichen Schlüssel Verschlüsselungsalgorithmus verschlüsselten Einmalschlüsselinformationen 1108. Bei dem Einmalschlüssel handelt es sich um einen Schlüssel für eine symmetrische Chiffre, die nur einmal zum Verschlüsseln der Einladungsinformationen wie unten erörtert verwendet werden.
  • Auf die Schlüsselinformation folgt Einladungsinformation 1110, die mit dem Einmalschlüssel verschlüsselt ist. Die Einladungsinformation enthält auch den von dem Vorsitz erzeugten Zeitstempel, der oben erörtert wird, und kann mit einem Initialisierungsvektor verkettet werden. Bei der Einladungsinformation handelt es sich um Anwendungsdaten einschließlich des Telespace-Namens/URL, die den Eingeladenen 904 über die Art der Aktivität informiert, für die die Einladung ausgegeben wird. Sie kann unter anderem die kryptografischen Information enthalten, die in dem Telespace, wie durch den Vorsitz 902 festgelegt, verwendet werden müssen (z.B. niedrige/mittlere/hohe Ebene, A/I/C-Moden wie oben erläutert). Auf diese Weise wird der Eingeladene über die Sicherheitsmerkmale des Telespace, in den er eingeladen wird, informiert und kann sich beispielsweise entscheiden, nicht daran teilzunehmen. Wenn das Zertifikat des Eingeladenen nicht bekannt ist, wird der verschlüsselte Einmalschlüssel 1108 ausgelassen und der Zeitstempel und die Einladungsinformation 1110 werden unverschlüsselt gesendet.
  • Auf die Einladungsinformation 1110 folgt die Unterschrift des Vorsitzes auf einem Hash der Kopfteilinformation 1110, des Einladungs-Einmaligkeitsmerkmals 1104, des unverschlüsselten Einmalschlüssels (wenn er in der Nachricht enthalten ist), der kryptografischen Daten 1106 und der unverschlüsselten Einladungsinformationen (ohne den Zeitstempel). Diese Unterschrift bindet alle angezeigten Informationen an das Zertifikat des Vorsitzes, welches wiederum über die lokale Validierungsrichtlinie der öffentlichen Schlüsselzertifikate an den Vorsitz gebunden ist.
  • Die letzte gesendete Information 1114 ist das Zertifikat des Vorsitzes, welches den Namen (URL/Person) des Vorsitzes, den Verifikationsschlüssel der öffentlichen Unterschrift des Vorsitzes und andere Informationen, wie die Kennzeichnung des öffentlichen Schlüsselalgorithmus (s), den öffentlichen Verschlüsselungsschlüssel usw. enthält, alle über (eine oder mehrere) Unterschriften von „gesicherten" Zertifizierungsstellen miteinander verbunden. Das Zertifikat wird in ein Zertifikatformat formatiert, das entweder wohlbekannt oder mindestens durch den Eingeladenen wiedererkennbar ist. Dieses Format kann ein auf dem öffentlichen Schlüssel basierendes Zertifikat sein (wobei die Zertifizierungsstelle in einer wohlbekannten Hierarchie von Zertifizierungsstellen eingeordnet ist), oder ein „Vertrauensnetz-Zertifikat", beispielsweise unter Verwendung von PGP oder SDSI oder sogar lediglich ein selbst unterzeichnetes Zertifikat, das ad hoc nur für diesen Zweck konstruiert wird. Der Grad von „Vertrauen", den der Eingeladene in das Zertifikat legt, hängt von der lokalen Validierungsrichtlinie für öffentliche Schlüssel des Eingeladenen ab.
  • Bei Empfang dieser Nachricht führt der Eingeladene die in 15 veranschaulichten Schritte aus. Die Prozedur des Eingeladenen beginnt in Schritt 1500 und schreitet zu Schritt 1502 fort, in dem der Eingeladene die kryptografischen Daten 1106 untersucht, um den beim Verschlüsseln der Nachricht verwendeten Algorithmus zu lernen. In Schritt 1504 untersucht der Eingeladene dann den Namen, um sicherzugehen, dass diese Einladung für ihn bestimmt ist.
  • Als nächstes validiert der Eingeladene in Schritt 1506 die Zertifikation des Vorsitzes, die den Namen/URL gemäß der lokalen Validierungsrichtlinie des öffentlichen Schlüssels des Eingeladenen enthält. Der Eingeladene tut dies durch Aufrufen eines geeigneten Zertifikatvalidierungsproviders (der den trivialen/voreingestellten „Jedem-selbst-unterzeichneten-Zertifikat-vertrauen"-Validierungsalgorithmus implementieren kann, wenn dies die lokale Regelung des Eingeladenen ist).
  • In Schritt 1508 verifiziert der Eingeladene die Unterschrift des Vorsitzes, um sicherzustellen, dass diese Einladung wirklich von dem Vorsitz 902 kam, und dass der Eingeladene 904 wirklich die eingeladene Partei war.
  • In Schritt 1510 entschlüsselt der Eingeladene die Einladungsinformation und untersucht sie, um zu entscheiden, ob der Eingeladene die Einladung des Vorsitzes annehmen will. Die Prozedur endet dann in Schritt 1512.
  • Wieder unter Bezugnahme auf 10 antwortet der Eingeladene 904 in Schritt 1004, wenn der Eingeladene 904 sich entscheidet, die Einladung anzunehmen, durch Senden einer Annahmenachricht an den Vorsitz 902, welche Nachricht in 9 schematisch als Pfeil 914 dargestellt wird. Wenn sich der Eingeladene entscheidet, die Einladung nicht anzunehmen, wird alternativ von dem Eingeladenen 904 an den Vorsitz 902 eine Fehlernachricht gesendet.
  • Der Inhalt der Annahmenachricht wird in 12 veranschaulicht. Die Nachricht besteht aus einem Kopfteil 1200, gefolgt von dem unterzeichneten Einladungs-„Einmaligkeitsmerkmal" 1202, das von dem Vorsitz an den Eingeladenen in der Einladungsnachricht gesendet wurde. Dies wird so verwendet, dass der Vorsitz erkennen kann, dass diese Annahmenachricht in Reaktion auf die Einladung erfolgt. Auf das unterzeichnete Einmaligkeitsmerkmal 1202 folgt ein unterzeichnetes Annahme-Einmaligkeitsmerkmal 1204. Das unterzeichnete Annahme-Einmaligkeitsmerkmal enthält einen durch den Eingeladenen erzeugten Zeitstempel, den Namen/URL des Telespace und einen Annahme-OpCode.
  • Auf das Einmaligkeitsmerkmal 1204 folgen die kryptografischen Sicherheitskontextdaten 1206, die ähnlich den kryptografischen Daten 1106 sind.
  • Als nächstes wird die Verschlüsselung mit öffentlichem Schlüssel eines neu erzeugten Einmalschlüssels 1208 von dem Vorsitz 902 unter Verwendung des öffentlichen Verschlüsselungsmechanismus, Parametern, Informationen und öffentlichem Verschlüsselungsschlüssel an den Eingeladenen gesendet (z.B. einen öffentlichen RSA-Verschlüsselungsschlüssel).
  • Auf den verschlüsselten Einmalschlüssel 1208 folgen die Anwendungsdaten 1210 einschließlich der beiden Zeitstempel und Annahmedaten, die unter Verwendung des Einmalschlüssels verschlüsselt werden. Diese Information 1210 informiert den Vorsitz 902 über die Annahme des Eingeladenen 904.
  • Danach wird die Unterschrift des Eingeladenen 904 gesendet. Diese Unterschrift befindet sich in dem Hash der Kopfteilinformation 1202, dem Namen des Vorsitzes und dem Einladungs-Einmaligkeitsmerkmal 1202, das mit dem Annahme-Einmaligkeitsmerkmal 1204 verkettet ist, dem unverschlüsselten Einmalschlüssel, den kryptografischen Daten 1206 und den unverschlüsselten Annahmeinformationen (ohne den Zeitstempel). Diese Unterschrift bindet alle angezeigten Informationen an das Zertifikat des Eingeladenen (welches wiederum über die Validierungsrichtlinie des öffentlichen Schlüsselzertifikats des Vorsitzes an den Eingeladenen 904 gebunden ist). Es sei darauf hingewiesen, dass der Name des Vorsitzes 902 in dem Umfang dieser Unterschrift enthalten sein muss, um zu verhindern, dass der Vorsitz den vom Eingeladenen unterzeichneten Einmalschlüssel, der dem Vorsitz bekannt ist, an eine dritte Partei sendet, wodurch der Eingeladene entpersonalisiert wird. Schließlich wird das Zertifikat 1214 des Eingeladenen gesendet.
  • Bei Empfang dieser Nachricht führt der Vorsitz 902 die in dem Flussdiagramm von 16 dargestellte Prozedur aus. Diese Prozedur beginnt bei Schritt 1600 und schreitet zu Schritt 1602 fort, in dem der Vorsitz 902 den verschlüsselten Einmalschlüssel entschlüsselt, wodurch er den Schlüssel erfährt.
  • Als nächstes verwendet der Vorsitz 902 in Schritt 1604 zum Entschlüsseln der verschlüsselten Annahmeinformation den Einmalschlüssel. In Schritt 1606 untersucht der Vorsitz das Zertifikat des Eingeladenen, um den Namen des Eingeladenen zu laden.
  • In Schritt 1608 berechnet der Vorsitz 902 das Einladungs-Einmaligkeitsmerkmal neu und prüft das neu berechnete Einmaligkeitsmerkmal gegenüber dem empfangenen Einladungs-Einmaligkeitsmerkmal, um zu bestimmen, auf welche Einladung die Annahmeantwort reagiert. Es sei darauf hingewiesen, dass in Übereinstimmung mit einem Aspekt der Erfindung, das Einladungs-Einmaligkeitsmerkmal (1104 in 11) „zustandslos" ist, das heißt, es kann unabhängig von der involvierten Zeitgebung interpretiert werden. Es sei beispielsweise angenommen, dass ein Teilnehmer A eine Einladung an einen Eingeladenen B von Vorrichtung 1 ausgibt, die Annahmenachricht von B aber später an Vorrichtung 2 empfängt. Auch wenn das Einmaligkeitsmerkmal in der Originaleinladungsnachricht über ein Delta an alle Vorrichtungen gesendet wurde, die A verwenden könnte, kann die Annahmenachricht von dem Eingeladenen B vor dem Einmaligkeitsmerkmal tragenden Delta an Vorrichtung 2 ankommen, so dass an Vorrichtung 2 kein Softwarevergleich durchgeführt werden kann. Zur Verhinderung dieses Problems wird Information hinsichtlich des Einmaligkeitsmerkmals sichtbar an Teilnehmer A an allen seinen Vorrichtungen angezeigt, einschließlich Vorrichtung 2. Ein Beispiel dieser Anzeige wird in 23 angezeigt, und die Anzeige kann beispielsweise über eine Nutzerschnittstellen-Dialogkasten 2300 oder einen ähnlichen Mechanismus erfolgen. Wie in 23 gezeigt, werden in der Dialogkasten 2300 drei Informationen angezeigt: den Subjektnamen des Eingeladenen B 2302, den Nachrichtenextrakt des Zertifikats des Eingeladenen 2304 und einen Zeitstempel von dem unterzeichneten Einladungsnachricht-Einmaligkeitsmerkmal 2305.
  • Das „Zertifikat" eines Senders ist ein Paket, das zwei wichtige Informationen trägt: einen „Subjektname" des Nachrichtensenders und seinen „öffentlichen Schlüssel". In diesem Fall wird der Subjektname durch die Protokollanordnung in Vorrichtung 2 extrahiert und in Dialogkasten 2300 in Textkasten 2302 angezeigt. Ein Beispiel dieses Namens könnte „wtuvell@groove.net" sein. A kann dann verifizieren, dass die Annahmenachricht der Einladung entspricht.
  • Da A den Subjektnamen des Eingeladenen B bereits kennt, muss A, um die Annahme zu validieren, das Nachrichtenextrakt-Zertifikats über eine andere Route als das erfindungsgemäße Kollaborationssystem senden. Ein typischer Weg, diese Information zu empfangen, ist für A beispielsweise, B über Telefon anzurufen und zu fragen, welches das Nachrichtenextrakt-Zertifikat sein soll. Beispielsweise kann diese berechnete Nachricht etwas wie „0a, 1b, 2c, 3d; 4e, 5f, 6a, 7b; 8c, 9d, ae, cf; c1, d2, e3, f4; 05, 16, 27, 38; 49, 5a, 6b, 7c" sein.
  • Wenn A das Zertifikat von B über die Annahmenachricht empfängt, kann der Nachrichtenextrakt (oder „Fingerabdruck"-Zertifikat) algorithmisch aus dem Zertifikat von B 1214 in der Annahmenachricht durch die in 21 und 22 dargestellte sichere Dienstarchitektur unter Verwendung eines herkömmlichen Nachrichtenextrakt-Algorithmus (wie MD5 oder SHA1) berechnet werden. Dieser neu berechnete Nachrichtenextrakt wird in Kasten 2304 angezeigt. Wenn der neu berechnete Nachrichtenextrakt mit dem bekannten korrekten Nachrichtenextrakt übereinstimmt, kann A das übermittelte Zertifikat als authentisch akzeptieren, ansonsten wird es zurückgewiesen. Dieser Vorgang wird „Zertifikatvalidierung" genannt.
  • Dem „unterzeichneten Einmaligkeitsmerkmal" wird die Unterschrift einer Nachricht gegeben. Somit verbindet es die Nachrichtenzeitstempel mit Informationen, die das Zertifikat eines Senders enthalten. Um einen „Wiederabspielangriff" (ein erneutes Senden einer authentischen Nachricht, die vorher gesendet worden ist), ist es auch notwendig zu verifizieren, dass der Zeitstempel in dem Einladungs-Einmaligkeitsmerkmal 1202, der in der Annahmenachricht enthalten ist, sich in einem akzeptablen Bereich befindet. Die Zeitstempelinformation wird aus dem Einmaligkeitsmerkmal extrahiert und in Kasten 2305 des Dialogkastens 2300 angezeigt. Diese Information kann beispielsweise „Einladungsnachricht an nashgirl@groove.net an 20000407121124Z" sein. Da A den Zeitstempel etwas früher erzeugt hat, hat A vermutlich Kenntnis über diese Zeit. Der Teilnehmer A kann dann den Zeitstempel interpretieren und entscheiden, ob die Information akzeptabel ist. Wenn der Teilnehmer A die Information akzeptiert, klickt er auf den OK-Schalter 2306, wenn nicht wird der ABBRECHEN-Schalter 2308 geklickt.
  • Zu einem ähnlichen Problem kommt es, wenn der Eingeladene B die Telespacedaten an einer von der Vorrichtung, von der die Annahme gesendet worden ist, verschiedenen Vorrichtung empfängt. Dieses letztere Problem wird auf dieselbe Art gehandhabt.
  • Als nächstes validiert der Vorsitz 902 in Schritt 1610 das Zertifikat des Eingeladenen gemäß der lokalen Richtlinie des öffentlichen Schlüssels des Vorsitzes. Dieser Schritt kann ausgelassen werden, wenn der Vorsitz bereits zu der Zeit der Einladungsnachricht oben über das Zertifikat des Eingeladenen verfügte und mit der Validierung, die zu der Zeit vorgenommen wurde, immer noch zufrieden ist. Der Vorsitz führt diese Validierung durch, indem ein geeigneter Zertifikatvalidierungsprovider angerufen wird.
  • Als nächstes verifiziert der Vorsitz 902 in Schritt 1612 die Unterschrift des Eingeladenen, welche wiederum die Authentizität/Integrität der Annahmenachricht verifiziert, um sicherzugehen, dass diese Annahmenachricht wirklich von dem Eingeladenen 904 kam.
  • In Schritt 1614 untersucht der Vorsitz dann die verschlüsselte Annahmeinformation, um sicherzugehen, dass sie zu der Einladungsinformation passt und um zu entscheiden, ob der Vorsitz die Annahme durch den Eingeladenen anerkennt oder nicht.
  • In Schritt 1616 kann der Vorsitz schließlich gegebenenfalls seine eigene Unterschrift zu dem Zertifikat des Eingeladenen als zusätzliche Unterschrift hinzufügen. Diese zusätzliche Unterschrift ermöglicht eine Richtlinie, mit der Gruppenteilnehmer das Zertifikat des Eingeladenen validieren können, vorausgesetzt, sie vertrauen dem Zertifikat von dem Vorsitz 902.
  • Die Prozedur endet dann in Schritt 1618 und, wenn die Information authentisch ist, wird der Eingeladene daraufhin zu einem „Teilnehmer des Telespace". Unter Bezugnahme wieder auf 10 sendet der Vorsitz 902 dann „Neuen Teilnehmer hinzugefügt"-Deltas an alle in der Gruppe 900 existierende Teilnehmer, wie in Schritt 1006 dargelegt. Diese Neuer-Teilnehmer-Nachrichten werden in 9 schematisch als Pfeile 916, 918 und 920 veranschaulicht.
  • Der Inhalt der Neuer-Teilnehmer-hinzugefügt-Nachricht, die der Vorsitz an die anderen vorher existierenden Teilnehmer sendet, wird in 13 veranschaulicht. Die Delta-Nachricht umfasst einen Kopfteil 1300 gefolgt von Aggregat-Schlüsselversionsinformationen, bei denen es sich um die Verkettung aller Schlüsselversionsnummern für den Gruppenschlüssel und alle paarweisen Authentifizierungs/Integritätsschlüssel handelt.
  • Auf die Aggregatschlüsselversion 1302 folgt die Aggregat-Wiederverschlüsselungsinformation 1304, die aus der Verkettung verschlüsselter neuer Gruppenverschlüsselung und Authentifizierungsschlüssel besteht. Für jedes Teilnehmerpaar werden die Verschlüsselungs- und Authentifizierungsschlüssel der Verkettungsgruppe unter Verwendung paarweiser Schlüssel für das Teilnehmerpaar verschlüsselt und das Ergebnis wird mit einem Initialisierungsvektor verkettet. Diese verketteten Schlüssel werden dann verkettet, um die Aggregat-Wiederverschlüsselungsinformation 1304 zu bilden. Die neuen Schlüssel ersetzen die alten/aktuellen Gruppenschlüssel KG/LG. Der neu hinzugefügte Teilnehmer erfährt die alten/aktuellen Gruppenschlüssel nie. Diese Neuverschlüsselung ist notwendig, um zu verhindern, dass der neue Teilnehmer die vorherige Telespace-Kommunikationen aufzeichnet und liest.
  • Als nächstes wird die Zusammenfügeninformation, die mit dem Verschlüsselungsschlüssel der neuen Gruppe verschlüsselt und mit dem Initialisierungsvektor 1306 verkettet ist, gesendet. Der Inhalt dieses Delta ist der Name des Eingeladenen, der mit dem Zertifikat des Eingeladenen und der Zusamenfügeninformation verkettet ist. Bei der Zusammenfügeninformation handelt es sich um Anwendungsdaten, die durch den Vorsitz 902 erzeugt werden, und sie bezieht sich auf Informationen hinsichtlich des neuen Teilnehmers, den die anderen Teilnehmer kennen müssen, einschließlich der Teilnehmerverwaltungsinformation. Sie kann auch eine Liste von Telespace-Teilnehmern und verschiedene andere Informationen, wie die Rollenzuweisungen des Eingeladenen, enthalten.
  • Schließlich wird ein Nachrichten-Mehrfach-Authentifizierungscode 1308 gesendet. Dies kann eine Verkettung von Authentifizierern zwischen dem Vorsitz und jedem Teilnehmer sein. Bei jedem Authentifizierer handelt es sich um gehashte Information, die in dem paarweisen Authentifizierungsschlüssel L01 von dem Vorsitz zu dem Teilnehmer geschützt ist. Die gehashte Information enthält den Kopfteil 1300, neue Aggregatgruppenschlüsselinformation 1304 und die unverschlüsselten Deltainformationen. Alternativ kann es sich bei dem Nachrichtenauthentifikationscode um die Signatur eines Vorsitzes der vorhergehenden gehashten Information handeln.
  • Bei Empfang der in 13 veranschaulichten Nachricht führt jeder Teilnehmer 906-910 die in dem Flussdiagramm aus 17 veranschaulichten Schritte aus. Diese Prozedur beginnt mit Schritt 1700 und schreitet zu Schritt 1702 fort, in dem der Teilnehmer die verschlüsselten Gruppenschlüssel verschlüsselt, wodurch er die neuen Gruppenschlüssel KG/LG erfährt. Jeder Teilnehmer muss jedoch so lange wie möglich die Kenntnis über die alten/aktuellen Gruppenschlüssel KG/LG aufrechterhalten, um sicherzustellen, dass keine alten in KG/LG geschützten Deltas mehr existieren. Danach muss jeder Teilnehmer die alten Schlüssel KG/LG verwerfen und alle Spuren von ihnen zerstören.
  • Als nächstes entschüsselt in Schritt 1704 jeder Teilnehmer die verschlüsselte Deltainformation, wodurch er die Information im Delta erfährt. In Schritt 1706 verifiziert der Teilnehmer die Authentifizierung/Integrität der Nachricht über das Stück des Mehrfachauthentifizierers, das mit ihrem Authentifizierungsschlüssel verschlüsselt ist.
  • Als nächstes prüft der Teilnehmer in Schritt 1708, um sicherzustellen, dass der Vorsitz 902 (dessen Identität als Kopfteilinformation gesendet wird) ein Vorsitz und autorisiert ist, einen neuen Teilnehmer hinzuzufügen.
  • In Schritt 1710 führt der Teilnehmer die Deltainformation aus. Im Verlauf dessen erfährt der Teilnehmer von den Neuer-Teilnehmer-Manager-Informationen, einschließlich des Namen des Eingeladenen, des Zertifikats und der Zusammenfügeinformation. Die Prozedur wird dann in Schritt 1712 abgeschlossen.
  • Unter Bezugnahme auf 10 sendet der Vorsitz 902 schließlich die Telespace-Information an den Eingeladenen 904, wie schematisch durch Pfeil 922 gezeigt. Die Prozedur endet dann in Schritt 1010. Die Telespace-Information wird an den Eingeladenen 904 mit der in 14 veranschaulichten Nachricht gesendet. Diese Information beginnt mit einem Kopfteil 1400, gefolgt von dem unterzeichneten Annahme-Einmaligkeitsmerkmal, welches dasselbe wie Einmaligkeitsmerkmal 1204 ist. Darauf folgen die kryptografischen Daten 1404 und der verschlüsselte Einmalschlüssel 1408 (der neu erzeugt wurde), wie unter Bezug auf die in 12 dargestellte Annahmenachricht beschrieben.
  • Auf den verschlüsselten Einmalschlüssel 1406 folgen die mit dem Einmalschlüssel in dem unmittelbar vorangehenden Nachrichtenabschnitt verschlüsselten Telespace-(TSP)-Daten. Zu diesen Daten gehört ein mit einer mit dem Einmalschlüssel verschlüsselten Nutzlast verketteter Initialisierungsvektor. Die Nutzlast ist der durch den Eingeladenen erzeugte Zeitstempel, die verketteten Gruppenverschlüsselungs- und Authentifikationsschlüssel KG/LG und die TSP-Daten. Bei den TSP-Daten handelt es sich um Anwendungsdaten, welche die Version des Teilnehmers der TSP-Daten enthalten, für deren Empfang von dem Teilnehmer der Eingeladene autorisiert ist.
  • Auf die verschlüsselten TSP-Daten 1408 folgt die Unterschrift des Vorsitzes 1410 auf den gehashten Informationen, einschließlich dem Kopfteil, 1400, der Name des Eingeladenen, das unterzeichnete Einmaligkeitsmerkmal 1402, die verketteten Gruppenverschlüsselungs- und Authentifizierungsschlüssel, der unverschlüsselte Einmalschlüssel, die kryptografische Information 1404 und die unverschlüsselten TSP-Daten. Schließlich folgt das Zertifikat des Vorsitzes 1412.
  • Bei Empfang dieser Nachricht führt der Eingeladene 904 die in 18 dargestellte Prozedur aus, die bei Schritt 1800 beginnt und zu Schritt 1802 fortschreitet, in dem der Eingeladene 904 den verschlüsselten Einmalschlüssel entschlüsselt, um auf den Einmalschlüssel zuzugreifen.
  • Als nächstes verwendet der Eingeladene in Schritt 1804 den Einmalschlüssel, um die verschlüsselten TSP-Daten zu entschlüsseln und auf die TSP-Information zuzugreifen. In Schritt 1806 berechnet der Eingeladene 904 das unterzeichnete Annahme-Einmaligkeitsmerkmal neu und vergleicht es mit dem empfangenen Einmaligkeitsmerkmal, um sicherzustellen, dass es akzeptabel ist. Wie zuvor erwähnt, könnte dieser. Vergleich zur Software oder visuelle Untersuchung erfolgen. Da dieses Einmaligkeitsmerkmal das Zertifikat des Vorsitzes enthält, muss der Eingeladene dieses Zertifikat nicht neu validieren.
  • In Schritt 1806 verifiziert der Eingeladene 904 die Unterschrift des Vorsitzes und in Schritt 1808 besetzt der Eingeladene sein anfängliches „Telescape im Aufbau" durch die entschlüsselten TSP-Daten. Das einzige, was zu tun übrig bleibt, ist der Austausch paarweiser Schlüssel mit allen Teilnehmern des Telespace; danach ist der Eingeladene ein vollständiges Mitglied des Telespace.
  • Paarweise Schlüssel können ausgetauscht werden durch eine Wiederverschlüsselungsprozedur, in der Wiederverschlüsselungsinformation im „Huckepack"-Verfahren in das andere Informationen tragende Delta eingeführt wird. Ein Protokoll zur Ausführung dieser Wiederverschlüsselung wird oben bezüglich der Neuer-Teilnehmer-hinzugefügt-Delta-Nachricht erörtert, die in 13 veranschaulicht ist. Wiederverschlüsselungsinformation kann auch in andere Deltanachrichten eingeführt werden. Eine solche Huckepack-Delta-Nachricht ist eine normale Deltanachricht, außer, dass eine Schlüsseländerung (einschließlich gleichzeitig jeder Kombination aus Gruppen-/Telespaceschlüsseln (KG/LG), Stamm-/Untergruppenschlüsseln (KT1/LT1, KTn/LTn für die Stämme T1, Tn) und/oder paarweise Schlüssel (Kij/Lij) per Huckepack-Verfahren zusammen mit der Deltanachricht übermittelt wird. Das Delta selbst wird gleichzeitig mit dem neuen Schlüssel gemäß dem Stamm TK verschlüsselt. Die neuen (wiederverschlüsselten) Schlüssel werden durch diese Nachricht transportiert. Wenn paarweise Schlüssel per Huckepack-Verfahren zusammen mit der Nachricht übermittelt werden, wird die Nachricht durch einen Authentifizierer für die öffentliche-Schlüssel-Unterschrift geschützt. Andernfalls wird die Nachricht durch einen Mehrfach-Authentifizierungs-Code unter Verwendung der aktuellen paarweisen Schlüssel geschützt.
  • Ein Beispiel einer solchen Nachricht wird in 19 dargestellt. Die Deltanachricht umfasst einen Kopfteil 900 gefolgt von Aggregat-Schlüsselversionsinformation 1902, bei der es sich um die Verkettung aller Schlüsselversionsnummern für den neuen Gruppenschlüssel und alle neuen Stamm-Authentifizierungs/Integritätsschlüsselhandelt.
  • Auf die Aggregat-Schlüsselversionsinformation 1902 folgt ein zweiter Abschnitt 1904, der ebenfalls Aggregat-Schlüsselversionsinformationen enthält. Wenn paarweise Schlüsseländerungen gesendet werden, enthält diese Information die Verkettung aller Schlüsselversionsnummern für die neuen paarweisen Schlüssel. Alternativ, wenn nur Gruppen- und Stammschlüssel wiederverschlüsselt werden, enthält die Information 1904 die Aggregat-Schlüssel versionsinformation für die alten oder aktuellen paarweisen Schlüssel.
  • Auf die Aggregat-Schlüsselversionsinformation 1904 folgt die Aggregat-Schlüsselversionsinformation 1906, die aus der Verkettung von neuen Gruppen- und Stammschlüsseln (KG/LG und KT/LT) besteht. Für jedes Teilnehmerpaar werden die verketteten Gruppenverschlüsselungs- und Authentifizierungsschlüssel unter Verwendung der paarweisen Schlüssel für ein Teilnehmerpaar verschlüsselt und das Ergebnis wird mit einem Initialisierungsvektor verkettet. Diese verketteten Schlüssel werden dann ihrerseits verkettet, um die Aggregat-Wiederverschlüsselungsinformation 1906 zu bilden. Die neuen Schlüssel ersetzen die alten/aktuellen Gruppenschlüssel KG/LG. Wenn neue paarweise Schlüssel transportiert werden, folgt auf die Gruppenwiederverschlüsselungsinformation die Aggregatwiederverschlüsselungsinformation für die neuen paarweisen Schlüssel. Die K/L-Schlüssel für jeden Teilnehmer werden verkettet und unter Verwendung des öffentlichen Schlüssels des Teilnehmers verschlüsselt. Diese verschlüsselten Schlüssel werden dann verkettet, um die paarweise Aggregat-Wiederverschlüsselungsinformation zu bilden.
  • Als nächstes wird die mit dem neuen Gruppenverschlüsselungsschlüssel verschlüsselte und mit einem Initialisierungsvektor entsprechend dem neuen Schlüssel 1908 verkettete Deltainformation gesendet. Der Inhalt dieses Delta kann jede herkömmliche Deltanachricht sein.
  • Schließlich wird ein Nachrichten-Mehrfachauthentifikationscode 1910 gesendet. Dies kann eine Verkettung von Authentifizierern zwischen den Teilnehmern sein. Jeder Authentifizierer ist gehashte Information, die in dem paarweisen Authentifikationsschlüssel Lij von dem sendenden Teilnehmer an den empfangenden Teilnehmer geschützt ist. Die gehashte Information enthält den Kopfteil 1900, die Aggregat-Neue-Gruppenschlüsselinformation 1904 (und die Aggregat-Neue-Paarweise-Schlüsselinformation, wenn diese gesendet wird) und die unverschlüsselte Deltainformation. Wenn paarweise Schlüssel per Huckepack-Verfahren mit der Nachricht übermittelt werden, wird anstelle eines Mehrfach-Authentifikationscodes ein Authentifizierer für die öffentliche-Schlüssel-Unterschrift gesendet.
  • Das oben genannte Sicherheitssystem kann auf eine Vielzahl von Wegen implementiert werden. In einer bevorzugten Ausführungsform wir die schematisch in 20 gezeigte Providerarchitektur verwendet. Eine solche Architektur wird bevorzugt, da das oben erörterte Sicherheitsprotokoll „Algorithmus-neutral" ist; das heißt, es hängt nicht von spezifischen Verschlüsselungs- und Schutzalgorithmen ab. Dieses Protokoll kann von einer Algorithmus-neutralen Infrastruktur, wie die in 20 gezeigte, profitieren. 20 zeigt eine zweidimensionale Struktur, die aus einer vertikalen Dimension und einer horizontalen Dimension besteht. Die vertikale Dimension besteht aus verschiedenen Abstraktionsebenen und die horizontale Dimension besteht aus verschiedenen Anwendungen und Diensten umfassend die vertikalen Schichten. Die oberste Schicht ist eine Anwendungsschicht, die eine Gruppe von Anwendungen enthält, von denen Anwendung 2000 und 2002 gezeigt werden. Diese Anwendungen können verteilte Kommunikations- und Kollaborationssysteme, wie das oben erörterte Kollaborationssystem; geschützten Datenspeicher; Verfügbarkeit (Nicht-Verweigerung von Diensten); Systemverwaltung; medizinische Informationssystem; Luftverkehrssteuersysteme; Kernkraftwerke; militärische Geheimdienst-, Befehls- und Steuersystem umfassen, sind aber nicht darauf beschränkt.
  • Die Anwendungen 2000 und 2002 greifen auf einen oder mehrere Sicherheitsdienste zu, von denen Dienst 2004 und 2006 gezeigt ist. Diese Dienste könnten zum Beispiel Dienste für Identifikation, Authentifizierung, Integrität, Vertraulichkeit, Datenschutz, Autorisation, Delegierung von Autorisation, Rechenschaft und Nicht-Ablehnung, Zeitstempeln, Benachrichtigung, Prüfung, Vertrauensrichtlinienverwaltung, Eingriffsdetektion und -wiederherstellung umfassen.
  • Die Sicherheitsdienste werden durch eine Kombination aus abstrakten (oder Algorithmus-neutralen) primitiven Diensten implementiert, einschließlich abstrakten primitiven Diensten 2008 und 2010. Die abstrakten primitiven Dienste werden eigentlich durch eine Gruppe konkrete (oder Algorithmus-spezifische) primitive Dienste implementiert. Beispielsweise kann der abstrakte primitive Dienst 2008 durch die konkreten primitiven Dienste 2012, 2014 und 2016 implementiert werden, während der abstrakte primitive Dienst durch die konkreten primitiven Dienste 2018, 2020 und 2022 implementiert werden kann. Diese konkreten primitiven Dienste enthalten Dienste, wie besondere kryptografische Dienste und Protokolle.
  • Jede Abstraktionsschicht erzeugt Dienste, die durch die höhere Abstraktionsschicht oder -schichten verbraucht werden. In einer bevorzugten Implementation handelt es sich bei der Zuordnung zwischen den Anwendungen 2000, 2002 und den Sicherheitsdiensten 2004, 2006, sowie bei der Zuordnung zwischen den Sicherheitsdiensten 2004, 2006 und den abstrakten primitiven Diensten 2008, 2010 um herkömmliche Zuordnungen, welche statische kompilierte Zeitbindungen zwischen ihren Schichten sind. Die Verbindung zwischen den abstrakten primitiven Diensten 2008, 2010 und den konkreten primitiven Diensten (2012, 2014, 2016 und 2018, 2020, 2022) ist vorzugsweise eine dynamische Laufzeitverbindung, die auf beschränkte Weise einen abstrakten primitiven Dienst einem oder mehreren konkreten primitiven Dienste zuordnet. Diese dynamische Verbindung wird als „Providerarchitektur" bezeichnet und ist ein Mechanismus, durch den abstrakte oder Algorithmus-neutrale primitive Dienste implementiert werden können, indem sie mit jeder konkreten, oder Algorithmus-spezifischen Implementation ausgeführt werden, welche zufällig zu einer gegebenen Zeit in ihrer Umgebung aktiv ist.
  • 21 und 22 veranschaulichen schematisch eine spezifische Implementation der Providerarchitektur. Obwohl in dieser Implementation objektorientierte Programmiertechniken verwendet wurden, ist es einem Fachmann ersichtlich, dass sie auch mit anderen gleichwertigen Techniken und Programmiersprachen implementiert werden könnte. Insbesondere verwendet die gezeigte Implementation dynamisch verbundene Bibliotheken (DLLs) um die verschiedenen Dienste bereitzustellen.
  • Eine DLL wird jeweils in den 21 und 22 dargestellt. Die in 11 gezeigte DLL wird der Sicherheitsdienst-Verwalter (SMM), und die in 22 gezeigte DLL wird ein Sicherheitsdienst-Provider (SSP, oder nur Provider) genannt. Es wird immer exakt eine SMM-DLL in jede Laufzeitumschreibung des Sicherheitsuntersystems geladen. Andererseits kann jede Anzahl von SSP-DLL geladen werden, abhängig nur von der Einschränkung, dass sie alle getrennt sein müssen (in dem Sinne, dass sie alle getrennte LIBIDs und Dateinamen aufweisen müssen, die in einer Datei, wie einem Systemverzeichnis aufgezeichnet sind). Die Namen der SSP-DLL werden durch ihre Entwickler ausgewählt. Die gezeigte Beispiel-SSP-DLL kann mit einem Namen wie SecProvXXX.dll vorgestellt werden, andere DLL können zum Beispiel SecYYYProv.dll oder ZZZSecProv.dll genannt werden.
  • Die Kästen in 21 und 22 bezeichnen COM-Klassen, die mit dem Microsoft Common Object Model übereinstimmen. Diese Klassen teilen sich in zwei Gruppen: Anordnungsklassen (rechts gezeigt) und Nicht-Anordnungsklassen (links gezeigt). Jede der COM-Anordnungklassen implementiert und exportiert exakt eine IDL-Schnittstelle. Beispielsweise exportiert die Anordnungsklasse 2106 (NachrichtenExtrakt) die Schnittstelle 2104 (INachrichtenExtrakt); die Anordnungsklasse 2118 (SchlüsselGenerator) exportiert Schnittstelle 2116 (ISchlüsselGenerator); und die Anordnungsklasse 2126 (Chiffre) exportiert Schnittstelle 2124 (IChiffre). Dies gilt auch für die Sicherheitsklasse 2102, welche die Schnittstelle 2100 exportiert. Dasselbe gilt für die in 22 gezeigten konkreten Klassen. Beispielsweise exportiert die konkrete Anordnungsklasse 2204 (XXXNachrichtenExtraktSpi) die Schnittstelle 2206 (INachrichtenExtraktSpi); die Anordnungsklasse 2208 (XXXSchlüsselGeneratorSpi) exportiert die Schnittstelle 2206 (ISchlüsselGeneratorSpi) und die Anordnungsklasse 2210 (XXXChiffreSpi) exportiert die Schnittstelle 2212 (IChiffreSpi).
  • Dies gilt auch für die aus den abstrakten Providerklassen 2122 und den konkreten XXProvider-Klassen (22) gebildeten „gemischten Klasse" Provider/XXXProvider. Insbesondere unterstützt die Providerklasse 2122 die IProvider-Schnittstelle 2120 und die XXXX-Providerklasse 2200 unterstützt eine IProviderCtor-Schnittstelle (in 22 nicht gezeigt). Die Providerklasse 2122 ist jedoch nur in der XXXProviderklasse 220 aggregierbar und kann somit nicht unabhängig instantiert werden. Somit werden sowohl die IProvider-Schnittstelle 2120 und die IProviderCtor-Schnittstelle durch die Mischklasse Provider/XXXProvider 2122/220 „exportiert".
  • Die Mischklasse Provider/XXXProvider und alle in 21 gezeigten Anordnungsklassen werden mit einer anderen Klasse als Partner versehen (obwohl es sich dabei um eine facettenreiche Beziehung handeln kann, da es viele konfigurierte SSP geben kann, die jeweils viele Algorithmen unterstützen), wie in 22 gezeigt. Der Partner in der SSM-DLL (21) wird als abstrakter Partner bezeichnet und der Partner in der SSP-DLL (22) wird als der konkrete Partner bezeichnet. Auf der linken Seite der 21, 22 gibt es zwei Arten von COM-Klassen, die die „Master"-Klassen genannt werden, nämlich die Sicherheitsklasse 2102 und die Provider/XXXProvider-Mischklasse 2122/2200. Die Sicherheitsklasse 210 ist insofern eine „Master"-Klasse, als dass sie die verschiedenen „Slave"-Provider/XXXProviderklassen steuert. Die verschiedenen Provider/XXXProviderklassen sind wiederum insofern „Master"-Klassen, als dass sie die verschiedenen „Slave"-Anordnungsklassen niedriger Ebene und/oder die verschiedenen konkreten „Slave"-Anordnungsklassen steuern. Die Masterklassen sind meist intern zu dem Sicherheitsuntersystem und für die meisten Anwendungen nicht sichtbar.
  • Rechts in den 21 und 22 werden zwei Arten von COM-Klassen gezeigt, die Anordnungsklassen genannt werden, nämlich die in 21 gezeigten abstrakten Anordnungsklassen und die in 22 gezeigten konkreten Anordnungsklassen. Eine abstrakte Anordnungsklasse wird rein abstrakt genannt, wenn ihr m_Anordnungs-Feld einen Nullwert enthält. Zu Veranschaulichungszwecken werden drei Arten von Anordnungsklassen (NachrichtenExtrakt, SchlüsselGenerator und Chiffre) gezeigt, obwohl ihre Anzahl grundsätzlich nicht beschränkt ist. Diese Anordnungsklassen treten in Paaren auf, wie in den 21 und 22 gezeigt, wobei die Klassen niedriger Ebene in den Klassen hoher Ebene eingekapselt oder enthalten sind (über das m_Anordnungselement). Die Funktion der Anordnungsklassen hoher Ebene ist es, die Anwendungsprogrammierschnittstellen (APIs) zu exportieren, welche durch die Verbraucher der Sicherheitsdienste aufgerufen werden. Das Suffix „Spi", das bei Anordnungsklassen niedriger Ebene auftritt, steht für Server Provider Interface (Server Provider Schnittstelle) (oder, im Sicherheitskontext, Sicherheits providerschnittstelle, oder in anderen Zusammenhängen manchmal Systemprogrammierschnittstelle), deren einzige Verbraucher die Anordnungsklassen hoher Ebene sind. In diesen Anordnungsklassen hoher Ebene befindet sich der eigentliche Algorithmus-spezifische Implementationscode und dies ist die eigentliche Funktionalität, welche die ,SSP-DLL' eigentlich „bereitstellt". Diese Trennung der Anordnungsklassen in zwei Teile wird in der Namensgebungsstruktur der Dienste, die sie unterstützen, reflektiert: ein voll qualifizierter Dienstname strukturiert sich in ein abstrakt/konkret-Präfix und ein konkret/Algorithmus-Suffix, wie beispielsweise NachichtenExtrakt.MD5.
  • Jeder konkrete SSP (XXProviderklasse 2200) enthält statische Informationen, die seinen Namen (s_MeinName, ein String), Version (s_MeineVersion, eine Zahl), Klassen-ID (S_MeineClsid, ein binärer 16-Bit-Wert), Information (S_MeineInfo, ein String) und die Liste der in seine DLL gebündelten Dienste (s_MeineSvcMap [], eine Liste von Stringpaaren) enthält. In jedem Eintrag von s_MeineSvcMap [] bedeutet ein String den Namen des Algorithmus, den der Dienst implementiert, und der andere ist die COM CLSID (Klassen-ID) der konkreten Anordnungsklasse (in SecProvXXX.dll gebündelt), die diesen Algorithmus implementiert.
  • Zusätzlich zu den Anordnungsklassen enthält das Sicherheitsuntersystem eine Anzahl von Nicht-Anordnungsklassen. In 21 werden zwei typische, Schlüssel und SchlüsselPaar, gezeigt. Wie die Darstellung zeigt, handelt es sich bei solchen Nicht-Anordnungsklassen um verhältnis mäßig normale COM-Klassen, deren einziges ungewöhnliches Merkmal ist, dass die (abstrakte) Schnittstellenklasse und die (konkrete) Implementationsklasse zwischen der SSM-DLL (21) und der SSP-DLL (22) gegebenenfalls aufgeteilt werden kann. In dem Fall der Schlüsselklasse 2110 verfügt nur der SSM über allgemeine a priori (Schnittstellen-)Kenntnis darüber, wie ein Schlüssel eines gegebenen SSP aussehen sollte, aber der SSP selbst muss eine detaillierte Implementation der Schlüsselklasse, die beispielsweise mit der durch den SSM definierten Schlüsselklasse übereinstimmt, durch die XXXSchlüsselklasse 2210 bereitstellen. In dem Fall der SchlüsselPaar-Klasse 2114 verfügt der SSM bereits über ausführliche Informationen seiner Implementation – er besteht aus einem Paar von Schüssel (welche auch immer).
  • Wenn das Sicherheitsuntersystem gebootet wird, beispielsweise, wenn die Sicherheitsklasse 2102 die erste CoCreated in einer Laufzeit ist, führt die Sicherheitsklasse 2102 das Folgenden in dem Sicherheitsklassen-FinalConstruct()-Verfahren. Zuerst liest die Sicherheitsklasse 2102 die Konfigurationsinformationen, die beispielsweise in einem Register gespeichert sein können.
  • Als nächstes führt die Sicherheitsklasse auf der Basis von ProgIO (oder CLSID) jedes konfigurierten konkreten Providers XXProvider (der gerade aus dem Register gelesen wurde) einen CoCreate-Vorgang eines Beispiels des XXXProviders 2200 aus, wodurch ein Zeiger auf die IProviderCtor-Schnittstelle des XXXProviders erhalten wird (Ctor steht für Konstrukteur). Dieser CoCreate-Vorgang einer XXXProviderklasse führt ferner einen CoCreate- und Aggregat-Vorgang an dem Endkonstrukt() eines XXXProviders aus, welches eine Aufgabe des Insider-XXXProviders 220 der abstrakten Providerklasse ist.
  • Als nächstes ruft die Sicherheitsklasse 2102 unter Verwendung der IProviderCtor-Schnittstelle des XXXProviders, die gerade CoCreated wurde, das no-arg-Ctor()-Verfahren des XXXProviders von der IProviderCtor-Schnittstelle auf. Dieses spezielle no-arg-Ctor()-Verfahren „lädt" die Namen/Versions/Info/Clsid/Dienstdaten des XXXProviders aus ihren „fest verdrahteten" statischen nummervariablen Positionen in nicht-statische Mitgliedsvariablen in dem aggregierten Providerobjekt hoch (das no-arg-Ctor()-Verfahren führt dies durch Aufrufen bestimmter durch das aggregierte Provider Unterobjekt des XXXProviders exportierte Verfahren aus).
  • Viertens konstruiert die Sicherheitsklasse 2102 ihre statische interne Konfigurationsliste s_ProvList[] durch das Zeigen des IProviders auf die verschiedenen konfigurierten konkreten Provider. Die Sicherheitsklasse konstruiert jeden IProvider durch Aufrufen des Anfrage-Schnittstellen-Verfahrens in der IProviderCtor-Schnittstelle des XXXProviders, die von der Sicherheitsklasse 2102 bis zu diesem Zeitpunkt verwendet worden ist. Die Liste sProvList[] der konfigurierten SSP wird über das holeProvider()-Verfahren der Sicherheitsklasse 2102 den Clients verfügbar gemacht.
  • Anwendungen verwenden die Providerarchitektur eigentlich auf folgende Weise. Es sei eine Anwendung angenommen, die ein Extrakt()-Verfahren an einem NachrichtenExtrakt-Objekt aufrufen möchte, um den Extrakt einer spezifischen Nachricht zu berechnen. Diese Anwendung kennt die abstrakten Anordnungsklassen in dem SSM (d.h. die SLSIDs der Klassen in der SicherheitsSvcs.dll), da sie während der Erstellung mit dieser Information verbunden war, aber sie hat keine a-priori-Kenntnis von den konkreten Anordnungsklassen in den SSPs (d.h. den CLSIDs der Klassen in SecProvXXX.dll), wo sich die wirkliche Algorithmusimplementation eigentlich befindet). Daher kann die Anwendung ein CoCreate-Vorgang direkt an dem abstrakten Anordnungsobjekt ausführen, aber sie kann kein konkretes Anordnungsobjekt durch CoCreate erstellen. In Übereinstimmung mit einer bevorzugten Ausführungsform wird ein abstraktes Anordnungselement jedoch als ein Klassen-Factory-Objekt mit einem Factory-Verfahren behandelt, das holeBeispiel() heißt, um ein konkretes Anordnungsobjekt wie folgt indirekt zu schaffen.
  • Die Anwendung beginnt durch CoCreating eines reinen abstrakten NachrichtenExtrakt-Objekts aus der Nachrichten-Extraktklasse 2106. Ein solches Objekt kann nicht verwendet werden, um einen Extrakt zu schaffen, da es nicht mit einem konkreten Anordnungsobjekt verbunden ist, das heißt, seine Hauptstatusvariable, m_Anordnung, weist einen Nullerwert auf (wie seine Nebenstatusvariablen m_AlgName und m_ProvName). Unter Verwendung der InachrichtenExtrakt-Schnittstelle 2104, die es gerade CoCreated hat, ruft die Anwendung dann das holeBeispiel()-Verfahren des NachrichtenExtrakts auf, wobei der wohlbekannte Name des Nachrichtenextraktalgorithmus spezifiziert wird, die es verwenden will. Das holeBeispiel()-Verfahren ist ein Factory-Verfahren, das die folgenden Schritte ausführt. Zuerst ruft das holeBeispiel()-Verfahren das holeProvider()-Verfahren in dem Sicherheitsobjekt aus, um eine Liste von Provider, die gegenwärtig konfiguriert sind, zu holen. Als nächstes verwendet das holeBeispiel()-Verfahren die gerade geholte Liste von SSP, um das hole()Verfahren jedes SSP aufzurufen, bevorzugt nach Rangfolge, bis es den ersten SSP findet, der den angefragten Algorithmus unterstützt. Das hole()-Verfahren des SSP bildet Algorithmusnamen auf konkrete Anordnungsklassen-ProgIDs ab unter Verwendung des m_SvcMap[] des SSP. Somit gibt das hole()-Verfahren in Klasse 2022 in diesem Beispiel die ProgID eines NachrichtenExtraktSpi einer konkreten Anwendungsklasse zurück, die den angeforderten Algorithmus unterstützt.
  • Als nächstes schafft das holeBeispiel()-Verfahren ein neues abstraktes NachrichtenExtrakt-Objekt durch CoCreate, das sich von dem NachrichtenExtrakt-Objekt unterscheidet, aus dem das holeBeispiel()-Verfahren aufgerufen wird. Anfangs handelt es sich bei dem NachrichtenExtrakt- Objekt um ein weiteres reines abstraktes Anordnungsobjekt, aber in dem nächsten Schritt wird das holeBeispiel()-Verfahren es in eine vollständiges/verbundenes Anordnungsobjekt formen (d.h. ein „nicht-reines" abstraktes Anordnungsobjekt zusammen mit einer konkreten Anordnung, die in ihm enthalten ist über sein m_Anordnungsfeld).
  • Schließlich ruft das holeBeispiel()-Verfahren das Konstruktions()-Verfahren des neuen NachrichtenExtrakt-Objekts auf, wobei als Parameter die CLISID (oder ProgID) des NachrichtenExtraktSpi weitergegeben wird, die es von dem obigen hole()-Verfahren-Aufruf erhalten hat. Dieses Konstruktions()-Verfahren schafft ein Beispiel des NachrichtenExtraktSpi-Objekts von Klasse 2104 durch CoCreate und besetzt das m_Anordnungsfeld des neuen NachrichtenExtrakts mit dem sich ergebenden InachrichtenExtraktSpi-Zeiger.
  • Somit gibt das holeBeispiel()-Verfahren an die Anwendung ein vollständiges/verbundenes NachrichtenExtrakt-Anordnungsobjekt zurück. Zu diesem Zeitpunkt kann die Anwendung das Extrakt()-Verfahren des Anordnungsobjekts aufrufen, um den Extrakt einer Nachricht aufzurufen. Das (abstrakte) Extrakt()-Verfahren des Anordnungsobjekts delegiert oder leitet den Aufruf dann an sein Extrakt()-Verfahren des konkreten Anordnungsobjekt, um die eigentliche Arbeit auszuführen.
  • Eine Softwareimplementation der oben beschriebenen Ausführungsform kann eine Reihe von Computeranweisungen umfassen, die entweder auf einem greifbaren Medium wie einem computerlesbaren Medium z.B. eine Diskette, eine CD-ROM, einen RAM-Speicher, oder eine Festplatte, fixiert sind oder an ein Computersystem über ein Modem oder eine andere Schnittstellenvorrichtung über ein Medium übertragbar sind. Das Medium kann entweder ein greifbares Medium sein, einschließlich, aber nicht darauf beschränkt, optische oder analoge Kommunikationsleitungen, oder kann mit drahtloser Technik implementiert sein, einschließlich, aber nicht beschränkt auf, Mikrowellentechnik, Infrarot oder andere Sendetechniken. Es kann sich auch um das Internet handeln. Die Reihe von Computeranweisungen verkörpert einen Teil oder die gesamten hier oben unter Bezug auf die Erfindung beschriebenen Funktionalitäten. Fachleuten wird klar sein, dass solche Computeranweisungen in einer Vielzahl von Programmiersprachen zur Verwendung mit mehreren Computerarchitekturen oder Betriebssystemen geschrieben werden kann. Ferner können solche Anweisungen unter Verwendung von heutiger oder zukünftiger Speichertechnologie gespeichert werden, einschließlich, aber nicht beschränkt auf Halbleiter, magnetische, optische oder andere Vorrichtungen, oder unter Verwendung einer heutigen oder zukünftigen Kommunikationstechnologie gesendet werden, einschließlich, aber nicht beschränkt auf, optische, Infrarot-, Mikrowellen- oder sonstige Sendetechnologien. Es wird berücksichtigt, dass ein solches Computerprogrammprodukt als entfernbares Medium mit einer begleitenden gedruckten oder elektronischen Dokumentation, z.B. verpackter Software, die in einem Computersystem vorgeladen ist, z.B. auf einem System-ROM oder Festplatte, oder von einem Server in oder einer Elektronische-Bulletin-Stelle über ein Netzwerk, beispielsweise dem Internet oder World Wide Web, verteilt wird.
  • Obwohl eine beispielhafte Ausführungsform der Erfindung offenbart wurde, wird es Fachleuten klar sein, dass zahlreiche Änderungen und Modifikationen daran vorgenommen werden können, welche einige Vorteile der Erfindung wie beansprucht erzielen werden. Beispielsweise wird es Durchschnittsfachleuten klar sein, dass, obwohl sich die Beschreibung auf ein bestimmtes Hardware- und Betriebssystem gerichtet war, andere Hardware- und Betriebssysteme auf dieselbe Weise wie beschrieben verwendet werden könnten.

Claims (27)

  1. Ein Verfahren zum Hinzufügen eines Eingeladenen, der ein öffentlich/privates Schlüsselpaar aufweist, zu einer existierenden gesicherten Gruppe (telespace 300, 900) von Kollaborationsteilnehmern (302, 304, 306, 308, 310, 902, 906, 908, 910), die untereinander durch Nachrichten kommunizieren, die durch Inter-Teilnehmer-Schlüssel geschützt sind, welche paarweise Schlüssel (Ki,j/Li,j) und Gruppenschlüssel (KGLG) enthalten, das Verfahren umfasst: (a) Auswahl von wenigstens einem Teilnehmer der Gruppe von Kollaborationsteilnehmern als ein Vorsitz (902) mit der Autorität zum Hinzufügen neuer Teilnehmer zu der Gruppe und eines neuen öffentlich/privaten Schlüsselpaares; (b) Senden einer Einladungsnachricht (912) vom Vorsitz (902) an den Eingeladenen (904, 1002); die Einladungsnachricht umfasst ein unterzeichnetes Einladungs-Einmaligkeitsmerkmal (1104), das zeitabhängig ist und Klartextinformation zur Identifizierung des Vorsitzes enthält, Einladungsinformation, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt und mit dem privaten Schlüssel (1110) des Vorsitzes unterzeichnet ist; (c) Senden einer Annahmenachricht (914) vom Eingeladenen zum Vorsitz (1004), die Annahmenachricht enthält das unterzeichnete Einladungs-Einmaligkeitsmerkmal (1202), ein unterzeichnetes Annahme-Einmaligkeitsmerkmal (1204), das zeitabhängig ist und Klartextinformation enthält zur Identifizierung des Eingeladenen, das Zertifikat des Vorsitzes und den Namen oder URL der gesicherten Gruppe (telespace 300, 900), wobei die Annahmeinformation mit dem öffentlichen Schlüssel (1210) des Vorsitzes verschlüsselt ist; (d) Senden einer Neuer-Teilnehmer-Nachricht (916, 918, 920) vom Vorsitz an alle Teilnehmer (906, 908, 910) der gesicherten Gruppe von Kollaborationsteilnehmern (1006), die neue Nachricht enthält neue Inter-Teilnehmer-Schlüssel (1304), die paarweise Schlüssel und Gruppenschlüssel enthalten; und (e) Senden einer Gruppendatennachricht (922) vom Vorsitz zum Eingeladenen (1108), die Gruppendatennachricht enthält das unterzeichnete Annahme-Einmaligkeitsmerkmal (1402) und Gruppeninformation, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt ist.
  2. Das Verfahren gemäß Anspruch 1, worin Schritt (b) umfasst: einen ersten Einmalschlüssel (1108), verschlüsseln der Einladungsinformation mit dem ersten Einmalschlüssel und Verschlüsseln des ersten Einmalschlüssel mit dem öffentlichen Schlüssel des Eingeladenen und Aufnehmen des verschlüsselten ersten Einmalschlüssels und der verschlüsselten Einladungsinformation in die Einladungsnachricht (1110).
  3. Das Verfahren gemäß Anspruch 1, worin Schritt (c) umfasst: Erzeugen eines zweiten Einmalschlüssels, Verschlüsseln der Annahmeinformation mit dem zweiten Einmalschlüssel (1208) und Verschlüsseln des zweiten Einmalschlüssels mit dem öffentlichen Schlüssel des Vorsitzes und Aufnehmen des verschlüsselten zweiten Einmalschlüssels und der verschlüsselten Annahmeinformation in die Annahmenachricht (1210).
  4. Das Verfahren gemäß Anspruch 1, worin Schritt (e) umfasst: Erzeugen eines dritten Einmalschlüssels, Verschlüsseln der Gruppendateninformation mit dem dritten Einmalschlüssel (1406) und Verschlüsseln des dritten Einmalschlüssels mit dem öffentlichen Schlüssel des Eingeladenen und Aufnehmen des verschlüsselten dritten Einmalschlüssels und der verschlüsselten Gruppendateninformation in die Einladungsnachricht (1408).
  5. Das Verfahren gemäß Anspruch 1, worin die Einladungsnachricht weiter einen Kopfteil (1100) und eine digitale Signatur enthält, die aus einem Hash des Kopfsteils (1112), des Einladungs-Einmaligkeitsmerkmals, des ersten Einmalschlüssels und der Einladungsinformation (1110) besteht.
  6. Das Verfahren gemäß Anspruch 1, worin die Einladungsnachricht weiter ein digitales Zertifikat (1114) des Vorsitzes enthält, das den Namen des Vorsitzes, den öffentlichen Signatur-Überprüfungsschlüssel des Vorsitzes und den öffentlichen Schlüssel des Vorsitzes umfasst.
  7. Das Verfahren gemäß Anspruch 1, worin die Annahmenachricht weiterhin einen Kopfteil (1200) und eine digitale Signatur enthält, die aus einem Hash des Kopfsteils (1212), des Namens des Vorsitzes, des Einladungs-Einmaligkeitsmerkmals, des Annahme-Einmaligkeitsmerkmals, des zweiten Einmalschlüssels (1208) und der Annahmeinformation (1210) besteht.
  8. Das Verfahren gemäß Anspruch 1, worin die Annahmenachricht weiterhin ein digitales Zertifikat (1214) des Eingeladenen enthält, das den Namen des Eingeladenen, den öffentlichen Signatur-Überprüfungsschlüssel des Eingeladenen und den öffentlichen Schlüssel des Eingeladenen umfasst.
  9. Das Verfahren gemäß Anspruch 1, worin Schritt (c) eine Überprüfung des unterzeichneten Einladungs-Einmaligkeits merkmals umfasst, das vom Vorsitz in der Annahmenachricht empfangen wurde.
  10. Das Verfahren gemäß Anspruch 9, worin die Überprüfung des unterzeichneten Einladungs-Einmaligkeitsmerkmal (1202), das vom Vorsitz in der Annahmenachricht empfangen wurde, eine Neuberechnung des unterzeichneten Einladungs-Einmaligkeitsmerkmals durch den Vorsitz und einen Softwarevergleich des neuberechneten unterzeichneten Einladungs-Einmaligkeitsmerkmals mit dem unterzeichneten Einladungs-Einmaligkeitsmerkmals umfasst, das in der Annahmenachricht empfangen wurde.
  11. Das Verfahren gemäß Anspruch 9, worin die Überprüfung des unterzeichneten Einladungs-Einmaligkeitsmerkmal (1202), das vom Vorsitz in der Annahmenachricht empfangen wurde, eine visuelle Anzeige des unterzeichneten Einladungs-Einmaligkeitsmerkmals umfasst, das vom Vorsitz in der Annahmenachricht zum Vorsitz für eine manuelle Überprüfung empfangen wurde (2304, 2305).
  12. Einrichtung zum Hinzufügen eines Eingeladenen, der ein öffentlich/privates Schlüsselpaar aufweist, zu einer existierenden gesicherten Gruppe (telespace 300, 900) von Kollaborationsteilnehmern (302, 304, 306, 308, 310, 902, 906, 908, 910), die untereinander durch Nachrichten kommunizieren, die durch Inter-Teilnehmer-Schlüssel geschützt sind, welche paarweise Schlüssel (Ki ,j/Li,j) und Gruppenschlüssel (KG/LG) enthalten, die Einrichtung umfasst: einen Mechanismus, der wenigstens einen Teilnehmer der Gruppe von Kollaborationsteilnehmern als Vorsitz (902) mit der Autorität zum Hinzufügen neuer Teilnehmer zu der Gruppe und eines neuen öffentlich/privaten Schlüsselpaares auswählt; eine Vorsitz-Protkoll-Anordnung (1002), die eine Einladungsnachricht (912) vom Vorsitz an den Eingeladenen sendet; die Einladungsnachricht umfasst ein unterzeichnetes Einladungs-Einmaligkeitsmerkmal (1102), das zeitabhängig ist und Klartextinformation zur Identifizierung des Vorsitzes enthält, sowie Einladungsinformation, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt und mit dem privaten Schlüssel des Vorsitzes unterzeichnet ist (1110); eine Eingeladener-Protkoll-Anordnung (303, 1004), die eine Annahmenachricht (914) vom Eingeladenen an den Vorsitz sendet, die Annahmenachricht enthält das unterzeichnete Einladungs-Einmaligkeitsmerkmal, ein unterzeichnetes Annahme-Einmaligkeitsmerkmal (1204), das zeitabhängig ist und Klartextinformation enthält zur Identifizierung des Eingeladenen, das Zertifikat des Vorsitzes und den Namen oder URL der gesicherten Gruppe (telespace 300, 900), wobei die Annahmeinformation mit dem öffentlichen Schlüssel des Vorsitzes verschlüsselt ist (1210); einen Vorsitz-Delta-Mechnismus (1006), der eine Neuer-Teilnehmer-Nachricht (916, 918, 920) vom Vorsitz an alle Teilnehmer (906, 908, 910) der gesicherten Gruppe von Kollaborationsteilnehmern sendet, die neue Nachricht enthält neue Inter-Teilnehmer-Schlüssel (1304), die paarweise Schlüssel und einen Gruppenschlüssel enthalten; und einen Vorsitz-Zusammenfügen-Mechanismus (1008), der eine Gruppendatennachricht (922) vom Vorsitz an den Eingeladenen sendet, die Gruppendatennachricht enthält das unterzeichnete Annahme-Einmaligkeitsmerkmal und Gruppeninformation, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt ist.
  13. Die Einrichtung gemäß Anspruch 12, worin die Vorsitz-Protkoll-Anordnung einen ersten Einmalschlüssel erzeugt (1108), die Einladungsinformation mit dem ersten Einmalschlüssel verschlüsselt und den ersten Einmalschlüssel mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt und den verschlüsselten ersten Einmalschlüssel und die verschlüsselte Einladungsinformation in die Einladungsnachricht (1110) einschließt (1110).
  14. Die Einrichtung gemäß Anspruch 12, worin die Eingeladener-Protkoll-Anordnung einen zweiten Einmalschlüssel erzeugt (1208), die Annahmeinformation mit dem zweiten Einmalschlüssel verschlüsselt, den zweiten Einmalschlüssel mit dem öffentlichen Schlüssel des Vorsitzes verschlüsselt und den verschlüsselten zweiten Einmalschlüssels und die verschlüsselte Annahmeinformation in die Annahmenachricht einschließt (1210).
  15. Die Einrichtung gemäß Anspruch 12, worin der Vorsitz-Zusammenfügen-Mechanismus einen dritten Einmalschlüssel (1406) erzeugt, die Gruppendateninformation mit dem dritten Einmalschlüssel verschlüsselt und den dritten Einmalschlüssel mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt und den verschlüsselten dritten Einmalschlüssel und die verschlüsselten Gruppendateninformation in die Einladungsnachricht einschließt (1408).
  16. Die Einrichtung gemäß Anspruch 12, worin die Einladungsnachricht weiter einen Kopfteil (1100) und eine digitale Signatur enthält, die aus einem Hash des Kopfsteils (1112), des Einladungs-Einmaligkeitsmerkmals, des ersten Einmalschlüssels und der Einladungsinformation (1110) besteht.
  17. Die Einrichtung gemäß Anspruch 12, worin die Einladungsnachricht weiter ein digitales Zertifikat (1114) des Vorsitzes enthält, das den öffentlichen Signatur-Überprüfungsschlüssel des Vorsitzes und den öffentlichen Schlüssel des Vorsitzes umfasst.
  18. Die Einrichtung gemäß Anspruch 12, worin die Annahmenachricht weiterhin einen Kopfteil (1200) und eine digitale Signatur enthält, die aus einem Hash des Kopfsteils (1212), des Namens des Vorsitzes, des Einladungs-Einmaligkeitsmerkmals (1202), des Annahme-Einmaligkeitsmerkmals (1204), des zweiten Einmalschlüssels (1208) und der Annahmeinformation (1210) besteht.
  19. Die Einrichtung gemäß Anspruch 12, worin die Annahmenachricht weiterhin ein digitales Zertifikat (1214) des Eingeladenen enthält, das den Namen des Eingeladenen, den öffentlichen Signatur-Überprüfungsschlüssel des Eingeladenen und den öffentlichen Schlüssel des Eingeladenen umfasst.
  20. Die Einrichtung gemäß Anspruch 12, worin Vorsitz-Protkoll-Anordnung das unterzeichnete Einladungs-Einmaligkeitsmerkmal überprüft, das vom Vorsitz in der Annahmenachricht empfangen wurde.
  21. Die Einrichtung gemäß Anspruch 20, worin die Überprüfung des unterzeichneten Einladungs-Einmaligkeitsmerkmal (1202), das vom Vorsitz in der Annahmenachricht empfangen wurde, eine Neuberechnung des unterzeichneten Einladungs-Einmaligkeitsmerkmals durch den Vorsitz und einen Softwarevergleich des neuberechneten unterzeichneten Einladungs-Einmaligkeitsmerkmals mit dem unterzeichneten Einladungs-Einmaligkeitsmerkmals umfasst, das in der Annahmenachricht empfangen wurde.
  22. Die Einrichtung gemäß Anspruch 20, worin die Überprüfung des unterzeichneten Einladungs-Einmaligkeitsmerkmal, das vom Vorsitz in der Annahmenachricht empfangen wurde, eine visuelle Anzeige des unterzeichneten Einladungs-Einmaligkeitsmerkmals umfasst, das vom Vorsitz in der Annahmenachricht zum Vorsitz für eine manuelle Überprüfung empfangen wurde (2304, 2305).
  23. Ein Computerprogrammprodukt zum Hinzufügen eines Eingeladenen, der ein öffentlich/privaten Schlüsselpaar aufweist, zu einer existierenden gesicherten Gruppe (telespace 300, 900) von Kollaborationsteilnehmern (302, 304, 306, 308, 310, 902, 906, 908, 910), die untereinander durch Nachrichten kommunizieren, die durch Inter-Teilnehmer-Schlüssel geschützt sind, welche paarweise Schlüssel (Ki,j/Li,j) und Gruppenschlüssel (KG/LG) enthalten, das Computerprogrammprodukt umfasst ein computernutzbares Medium, auf dem sich computerlesbarer Programmcode befindet, und enthält: Programmcode zur Auswahl von wenigstens einem Teilnehmer der Gruppe von Kollaborationsteilnehmern als Vorsitz (902) mit der Autorität zum Hinzufügen neuer Teilnehmer zu der Gruppe und eines neuen öffentlich/privaten Schlüsselpaares; Programmcode zum Senden einer Einladungsnachricht (912) vom Vorsitz an den Eingeladenen (904, 1002); die Einladungsnachricht umfasst ein unterzeichnetes Einladungs-Einmaligkeitsmerkmal (1102), das zeitabhängig ist und Klartextinformation zur Identifizierung des Vorsitzes und Einladungsinformation enthält, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt und mit dem privaten Schlüssel (1110) des Vorsitzes unterzeichnet ist; Programmcode zum Senden einer Annahmenachricht (914) vom Eingeladenen zum Vorsitz (914, 1004), die Annahmenachricht enthält das unterzeichnete Einladungs-Einmaligkeitsmerkmal (1202), ein unterzeichnetes Annahme-Einmaligkeitsmerkmal (1204), das zeitabhängig ist und Klartextinformation enthält zur Identifizierung des Eingeladenen, das Zertifikat des Vorsitzes und den Namen oder URL der gesicherten Gruppe (telespace 300, 900), wobei die Annahmeinformation mit dem öffentlichen Schlüssel des Vorsitzes verschlüsselt ist; Programmcode zum Senden einer Neuer-Teilnehmer-Nachricht (916, 918, 920) vom Vorsitz an alle Teilnehmers (906, 908, 910) der gesicherten Gruppe von Kollaborationsteilnehmern (1006), die neue Nachricht enthält neue Inter-Teilnehmer-Schlüssel (1304), die paarweise Schlüssel und einen Gruppenschlüssel enthalten; und Programmcode zum Senden einer Gruppendatennachricht (922) vom Vorsitz an den Eingeladenen (1108), die Gruppendatennachricht enthält das unterzeichnete Annahme-Einmaligkeitsmerkmal (1402) und Gruppeninformation, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt ist.
  24. Das Computerprogramprodukt gemäß Anspruch 23, worin der Programmcode für das Senden einer Einladungsnachricht vom Vorsitz an den Eingeladenen (1002) Programmcode umfasst zum Erzeugen eines ersten Einmalschlüssels, zum Verschlüsseln der Einladungsinformation mit dem ersten Einmalschlüssel (1108) und zum Verschlüsseln des ersten Einmalschlüssels mit dem öffentlichen Schlüssel des Eingeladenen und zur Aufnahme des verschlüsselten ersten Einmalschlüssels und der verschlüsselten Einladungsinformation in die Einladungsnachricht (1110).
  25. Das Computerprogramprodukt gemäß Anspruch 23, worin der Programmcode für das Senden einer Annahmenachricht vom Eingeladenen zum Vorsitz (1004) Programmcode umfasst zum Erzeugen eines zweiten Einmalschlüssels (1108), zum Verschlüsseln der Annahmeinformation mit dem zweiten Einmalschlüssel und zum Verschlüsseln des zweiten Einmalschlüssels mit dem öffentlichen Schlüssel des Vorsitzes sowie zur Aufnahme des verschlüsselten zweiten Einmalschlüssels und der verschlüsselten Annahmeinformation in die Annahmenachricht (1110).
  26. Das Computerprogramprodukt gemäß Anspruch 23, worin der Progammcode für das Senden einer Gruppendatennachricht vom Vorsitz zum Eingeladenen (922, 1108) Programmcode umfasst zum Erzeugen eines dritten Einmalschlüssels (1406), zum Verschlüsseln der Gruppendateninformation mit dem dritten Einmalschlüssel und zum Verschlüsseln des dritten Einmalschlüssels mit dem öffentlichen Schlüssel des Eingeladenen sowie zur Aufnahme des verschlüsselten dritten Einmalschlüssels und der verschlüsselten Gruppendateninformation in die Einladungsnachricht (1408).
  27. Ein Computerdatensignal, verkörpert in einer Trägerwelle, zum Hinzufügen eines Eingeladenen, der ein öffentlich/privaten Schlüsselpaar aufweist, zu einer existierenden gesicherten Gruppe (telespace 300, 900) von Kollaborationsteilnehmern (302, 304, 306, 308, 310, 902, 906, 908, 910), die untereinander durch Nachrichten kommunizieren, die durch Inter-Teilnehmer-Schlüssel geschützt sind, welche paarweise Schlüssel (Ki,j/Li , j) und Gruppenschlüssel (KG/LG) enthalten, das Computerdatensignal umfasst: Programmcode zur Auswahl von wenigstens einem Teilnehmer der Gruppe von Kollaborationsteilnehmern als Vorsitz (902) mit der Autorität zum Hinzufügen neuer Teilnehmer zu der Gruppe und eines neuen öffentlich/privaten Schlüsselpaares; Programmcode zum Senden einer Einladungsnachricht (912) vom Vorsitz an den Eingeladenen (904, 1002); die Einladungsnachricht umfasst ein unterzeichnetes Einladungs-Einmaligkeitsmerkmal (1104), das zeitabhängig ist und Klartextinformation zur Identifizierung des Vorsitzes und Einladungsinformation enthält, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt und mit dem privaten Schlüssel des Vorsitzes unterzeichnet ist (1110); Programmcode zum Senden einer Annahmenachricht (914) vom Eingeladenen an den Vorsitz (1004), die Annahmenachricht enthält das unterzeichnete Einladungs-Einmaligkeitsmerkmal, ein unterzeichnetes Annahme-Einmaligkeitsmerkmal (1204), das zeitabhängig ist und Klartextinformation enthält zur Identifizierung des Eingeladenen, das Zertifikat des Vorsitzes und den Namen oder URL der gesicherten Gruppe (telespace 300, 900), wobei die Annahmeinformation mit dem öffentlichen Schlüssel des Vorsitzes verschlüsselt ist (1210); Programmcode zum Senden einer Neuer-Teilnehmer-Nachricht (916, 918, 920) vom Vorsitz an alle Teilnehmer (906, 908, 910) der gesicherten Gruppe von Kollaborationsteilnehmern (1006), die neue Nachricht enthält neue Inter-Teilnehmer-Schlüssel (1304), die paarweise Schlüssel und einen Gruppenschlüssel enthalten; und Programmcode zum Senden einer Gruppendatennachricht (922) vom Vorsitz an den Eingeladenen (1108), die Gruppendatennachricht enthält das unterzeichnete Annahme-Einmaligkeitsmerkmal und Gruppeninformation, die mit dem öffentlichen Schlüssel des Eingeladenen verschlüsselt ist.
DE60124765T 2000-05-12 2001-05-02 Verfahren und vorrichtung zur verwaltung von sicherheitssensiblen kollaborativen transaktionen Expired - Lifetime DE60124765T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/571,851 US6986046B1 (en) 2000-05-12 2000-05-12 Method and apparatus for managing secure collaborative transactions
US571851 2000-05-12
PCT/US2001/014093 WO2001088674A2 (en) 2000-05-12 2001-05-02 Method and apparatus for managing secure collaborative transactions

Publications (2)

Publication Number Publication Date
DE60124765D1 DE60124765D1 (de) 2007-01-04
DE60124765T2 true DE60124765T2 (de) 2008-02-14

Family

ID=24285327

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60124765T Expired - Lifetime DE60124765T2 (de) 2000-05-12 2001-05-02 Verfahren und vorrichtung zur verwaltung von sicherheitssensiblen kollaborativen transaktionen

Country Status (10)

Country Link
US (4) US6986046B1 (de)
EP (4) EP1708406A3 (de)
JP (2) JP4955181B2 (de)
KR (1) KR100905141B1 (de)
AT (1) ATE346333T1 (de)
AU (1) AU2001261117A1 (de)
CA (1) CA2408437C (de)
DE (1) DE60124765T2 (de)
IL (2) IL152351A0 (de)
WO (1) WO2001088674A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10063501B2 (en) 2015-05-22 2018-08-28 Microsoft Technology Licensing, Llc Unified messaging platform for displaying attached content in-line with e-mail messages
US10216709B2 (en) 2015-05-22 2019-02-26 Microsoft Technology Licensing, Llc Unified messaging platform and interface for providing inline replies

Families Citing this family (179)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8086508B2 (en) 2000-07-24 2011-12-27 Cashedge, Inc. Method and apparatus for delegating authority
US7797207B1 (en) 2000-07-24 2010-09-14 Cashedge, Inc. Method and apparatus for analyzing financial data
US7536340B2 (en) 2000-07-24 2009-05-19 Cashedge, Inc. Compliance monitoring method and apparatus
US7013310B2 (en) 2002-01-03 2006-03-14 Cashedge, Inc. Method and apparatus for retrieving and processing data
US7146338B2 (en) 2001-06-28 2006-12-05 Checkfree Services Corporation Inter-network financial service
US7383223B1 (en) 2000-09-20 2008-06-03 Cashedge, Inc. Method and apparatus for managing multiple accounts
FR2823928B1 (fr) * 2001-04-19 2003-08-22 Canal Plus Technologies Procede pour une communication securisee entre deux dispositifs
JP4604422B2 (ja) 2001-07-31 2011-01-05 ソニー株式会社 通信システム、通信装置及び通信方法
US7203845B2 (en) 2002-01-11 2007-04-10 Cashedge, Inc. Multiple trust modes for handling data
US7627753B2 (en) * 2002-03-19 2009-12-01 Microsoft Corporation Secure digital data format and code enforced policy
US7120797B2 (en) * 2002-04-24 2006-10-10 Microsoft Corporation Methods for authenticating potential members invited to join a group
US20040006705A1 (en) * 2002-07-05 2004-01-08 Walker Jesse R. Secure two-message synchronization in wireless networks
US7515569B2 (en) * 2002-11-27 2009-04-07 Agere Systems, Inc. Access control for wireless systems
US7730446B2 (en) * 2003-03-12 2010-06-01 Microsoft Corporation Software business process model
US7577934B2 (en) * 2003-03-12 2009-08-18 Microsoft Corporation Framework for modeling and providing runtime behavior for business software applications
US7376834B2 (en) * 2003-07-18 2008-05-20 Palo Alto Research Center Incorporated System and method for securely controlling communications
US7103779B2 (en) 2003-09-18 2006-09-05 Apple Computer, Inc. Method and apparatus for incremental code signing
US8190893B2 (en) 2003-10-27 2012-05-29 Jp Morgan Chase Bank Portable security transaction protocol
US7302060B2 (en) * 2003-11-10 2007-11-27 Qualcomm Incorporated Method and application for authentication of a wireless communication using an expiration marker
US8060743B2 (en) * 2003-11-14 2011-11-15 Certicom Corp. Cryptographic method and apparatus
US7783769B2 (en) * 2004-03-31 2010-08-24 Intel Corporation Accelerated TCP (Transport Control Protocol) stack processing
WO2005106619A1 (en) * 2004-04-29 2005-11-10 Koninklijke Philips Electronics, N.V. Intrusion detection during program execution in a computer
US20060010205A1 (en) * 2004-05-21 2006-01-12 Bea Systems, Inc. Systems and methods for collaboration impersonation
US20050262075A1 (en) * 2004-05-21 2005-11-24 Bea Systems, Inc. Systems and methods for collaboration shared state management
US20060010125A1 (en) * 2004-05-21 2006-01-12 Bea Systems, Inc. Systems and methods for collaborative shared workspaces
JP2006018430A (ja) * 2004-06-30 2006-01-19 Ricoh Co Ltd 情報処理装置、ネットワークシステム、プログラム、データ構造及び記憶媒体
US7480803B1 (en) * 2004-07-23 2009-01-20 Sprint Communications Company L.P. System and method for securing system content by automated device authentication
US7636841B2 (en) * 2004-07-26 2009-12-22 Intercall, Inc. Systems and methods for secure data exchange in a distributed collaborative application
JP2008508806A (ja) * 2004-07-29 2008-03-21 ヴァディアム テクノロジー インコーポレイテッド ワンタイムパスワード暗号化を強化するための技術
US8656161B2 (en) * 2004-11-30 2014-02-18 Nec Corporation Information sharing system, information sharing method, group management program and compartment management program
JP4701706B2 (ja) * 2004-12-22 2011-06-15 富士ゼロックス株式会社 情報処理装置、方法、及びプログラム
US7752253B2 (en) * 2005-04-25 2010-07-06 Microsoft Corporation Collaborative invitation system and method
JP4900891B2 (ja) 2005-04-27 2012-03-21 キヤノン株式会社 通信装置及び通信方法
US7890220B2 (en) * 2005-05-03 2011-02-15 Mks Instruments, Inc. Low overhead closed loop control system
US7647508B2 (en) * 2005-06-16 2010-01-12 Intel Corporation Methods and apparatus for providing integrity protection for management and control traffic of wireless communication networks
US20070076709A1 (en) * 2005-07-01 2007-04-05 Geoffrey Mattson Apparatus and method for facilitating a virtual private local area network service with realm specific addresses
US20070086456A1 (en) * 2005-08-12 2007-04-19 Electronics And Telecommunications Research Institute Integrated layer frame processing device including variable protocol header
US8306918B2 (en) 2005-10-11 2012-11-06 Apple Inc. Use of media storage structure with multiple pieces of content in a content-distribution system
US20070101400A1 (en) * 2005-10-31 2007-05-03 Overcow Corporation Method of providing secure access to computer resources
US20070157281A1 (en) * 2005-12-23 2007-07-05 United Video Properties, Inc. Interactive media guidance system having multiple devices
US20070157266A1 (en) * 2005-12-23 2007-07-05 United Video Properties, Inc. Interactive media guidance system having multiple devices
US8364965B2 (en) * 2006-03-15 2013-01-29 Apple Inc. Optimized integrity verification procedures
TWI338489B (en) * 2006-03-22 2011-03-01 Lg Electronics Inc Asymmetric cryptography for wireless systems
US8224751B2 (en) 2006-05-03 2012-07-17 Apple Inc. Device-independent management of cryptographic information
US7945053B2 (en) * 2006-05-15 2011-05-17 Intel Corporation Methods and apparatus for a keying mechanism for end-to-end service control protection
US7940926B2 (en) * 2006-06-08 2011-05-10 Novell, Inc. Cooperative encoding of data by pluralities of parties
US8301753B1 (en) 2006-06-27 2012-10-30 Nosadia Pass Nv, Limited Liability Company Endpoint activity logging
US7668954B1 (en) 2006-06-27 2010-02-23 Stephen Waller Melvin Unique identifier validation
GB0612775D0 (en) * 2006-06-28 2006-08-09 Ibm An apparatus for securing a communications exchange between computers
US20080005558A1 (en) * 2006-06-29 2008-01-03 Battelle Memorial Institute Methods and apparatuses for authentication and validation of computer-processable communications
US8127135B2 (en) * 2006-09-28 2012-02-28 Hewlett-Packard Development Company, L.P. Changing of shared encryption key
JP4886463B2 (ja) 2006-10-20 2012-02-29 キヤノン株式会社 通信パラメータ設定方法、通信装置及び通信パラメータを管理する管理装置
KR101365603B1 (ko) * 2006-12-04 2014-02-20 삼성전자주식회사 조건부 인증 코드 삽입 방법 및 그 장치, 인증을 통한조건부 데이터 사용 방법 및 그 장치
US10416838B2 (en) * 2006-12-11 2019-09-17 Oath Inc. Graphical messages
US8627211B2 (en) * 2007-03-30 2014-01-07 Uranus International Limited Method, apparatus, system, medium, and signals for supporting pointer display in a multiple-party communication
US7765266B2 (en) * 2007-03-30 2010-07-27 Uranus International Limited Method, apparatus, system, medium, and signals for publishing content created during a communication
US8702505B2 (en) 2007-03-30 2014-04-22 Uranus International Limited Method, apparatus, system, medium, and signals for supporting game piece movement in a multiple-party communication
WO2008119149A1 (en) * 2007-03-30 2008-10-09 Uranus International Limited Method, apparatus, system, and medium for supporting multiple-party communications
US7950046B2 (en) * 2007-03-30 2011-05-24 Uranus International Limited Method, apparatus, system, medium, and signals for intercepting a multiple-party communication
US8060887B2 (en) * 2007-03-30 2011-11-15 Uranus International Limited Method, apparatus, system, and medium for supporting multiple-party communications
US7765261B2 (en) * 2007-03-30 2010-07-27 Uranus International Limited Method, apparatus, system, medium and signals for supporting a multiple-party communication on a plurality of computer servers
US8705348B2 (en) * 2007-04-18 2014-04-22 Cisco Technology, Inc. Use of metadata for time based anti-replay
EP1986151A1 (de) * 2007-04-23 2008-10-29 Hewlett-Packard Development Company, L.P. Datenverarbeitungssystem, Verfahren und Computerprogrammprodukt zur Bereitstellung eines Dienstes für einen Dienstanforderer
US20080288376A1 (en) 2007-04-27 2008-11-20 Cashedge, Inc. Centralized payment hub method and system
US9311492B2 (en) 2007-05-22 2016-04-12 Apple Inc. Media storage structures for storing content, devices for using such structures, systems for distributing such structures
US8347098B2 (en) * 2007-05-22 2013-01-01 Apple Inc. Media storage structures for storing content, devices for using such structures, systems for distributing such structures
US20090034734A1 (en) * 2007-07-31 2009-02-05 Viasat, Inc. Multi-Level Key Manager
TWI378702B (en) * 2007-08-24 2012-12-01 Ind Tech Res Inst Group authentication method
WO2009033248A1 (en) * 2007-09-10 2009-03-19 Novell, Inc. A method for efficient thread usage for hierarchically structured tasks
KR100959074B1 (ko) * 2007-12-12 2010-05-20 한국전자통신연구원 Ｐ２ｐ 네트워크 상에서의 보안 그룹 생성 방법, 생성장치, 인증 방법, 인증 장치
US9043603B2 (en) * 2008-01-28 2015-05-26 Seagate Technology Llc Security threshold enforcement in anchor point-based digital rights management
US8533474B2 (en) * 2008-02-27 2013-09-10 Red Hat, Inc. Generating session keys
US8688975B2 (en) * 2008-03-25 2014-04-01 International Business Machines Corporation Certifying a virtual entity in a virtual universe
CN101547443B (zh) * 2008-03-28 2011-12-21 上海华为技术有限公司 信令的传输方法及通信装置
EP2272236B1 (de) * 2008-04-30 2017-07-26 NEC Corporation Vorrichtung und verfahren zur identitätsüberprüfung eines kommunikationspartners
CN102100030B (zh) * 2008-05-29 2014-03-19 Lg电子株式会社 加密控制信号的方法
CN101321209B (zh) * 2008-06-19 2011-11-16 上海软中信息技术有限公司 基于pstn的安全通信分布式数据提取方法及实现系统
US8230217B2 (en) * 2008-10-13 2012-07-24 International Business Machines Corporation Method and system for secure collaboration using slepian-wolf codes
US7899056B2 (en) * 2009-01-13 2011-03-01 Fujitsu Limited Device and method for reducing overhead in a wireless network
US8023513B2 (en) * 2009-02-24 2011-09-20 Fujitsu Limited System and method for reducing overhead in a wireless network
US8812854B2 (en) * 2009-10-13 2014-08-19 Google Inc. Firmware verified boot
US8806190B1 (en) 2010-04-19 2014-08-12 Amaani Munshi Method of transmission of encrypted documents from an email application
WO2011145353A1 (ja) * 2010-05-19 2011-11-24 三洋電機株式会社 基地局装置
WO2012003504A2 (en) * 2010-07-02 2012-01-05 Air Computing, Inc. A system and method for cloud file management
WO2012099617A1 (en) 2011-01-20 2012-07-26 Box.Net, Inc. Real time notification of activities that occur in a web-based collaboration environment
US8751777B2 (en) 2011-01-28 2014-06-10 Honeywell International Inc. Methods and reconfigurable systems to optimize the performance of a condition based health maintenance system
US8990770B2 (en) 2011-05-25 2015-03-24 Honeywell International Inc. Systems and methods to configure condition based health maintenance systems
US8880886B2 (en) 2011-05-26 2014-11-04 First Data Corporation Systems and methods for authenticating mobile devices
US9652741B2 (en) 2011-07-08 2017-05-16 Box, Inc. Desktop application for access and interaction with workspaces in a cloud-based content management system and synchronization mechanisms thereof
US8856530B2 (en) 2011-09-21 2014-10-07 Onyx Privacy, Inc. Data storage incorporating cryptographically enhanced data protection
US20130080768A1 (en) * 2011-09-26 2013-03-28 Erik Lagerway Systems and methods for secure communications using an open peer protocol
GB2507935B (en) * 2011-10-12 2014-07-30 Ibm Method, system, mediation server, client, and computer program for deleting information in order to maintain security level
US8726084B2 (en) 2011-10-14 2014-05-13 Honeywell International Inc. Methods and systems for distributed diagnostic reasoning
US9098474B2 (en) 2011-10-26 2015-08-04 Box, Inc. Preview pre-generation based on heuristics and algorithmic prediction/assessment of predicted user behavior for enhancement of user experience
WO2013062599A1 (en) 2011-10-26 2013-05-02 Box, Inc. Enhanced multimedia content preview rendering in a cloud content management system
US9773051B2 (en) 2011-11-29 2017-09-26 Box, Inc. Mobile platform file and folder selection functionalities for offline access and synchronization
US9904435B2 (en) 2012-01-06 2018-02-27 Box, Inc. System and method for actionable event generation for task delegation and management via a discussion forum in a web-based collaboration environment
US20130191629A1 (en) * 2012-01-19 2013-07-25 Laconic Security, Llc Secure group-based data storage in the cloud
US11232481B2 (en) 2012-01-30 2022-01-25 Box, Inc. Extended applications of multimedia content previews in the cloud-based content management system
US9965745B2 (en) 2012-02-24 2018-05-08 Box, Inc. System and method for promoting enterprise adoption of a web-based collaboration environment
US9575981B2 (en) 2012-04-11 2017-02-21 Box, Inc. Cloud service enabled to handle a set of files depicted to a user as a single file in a native operating system
US9413587B2 (en) 2012-05-02 2016-08-09 Box, Inc. System and method for a third-party application to access content within a cloud-based platform
WO2013166520A1 (en) 2012-05-04 2013-11-07 Box, Inc. Repository redundancy implementation of a system which incrementally updates clients with events that occurred via cloud-enabled platform
CN102708192B (zh) 2012-05-15 2017-11-28 华为技术有限公司 一种文档共享的方法及系统、设备
US9691051B2 (en) 2012-05-21 2017-06-27 Box, Inc. Security enhancement through application access control
US8832649B2 (en) * 2012-05-22 2014-09-09 Honeywell International Inc. Systems and methods for augmenting the functionality of a monitoring node without recompiling
US8914900B2 (en) 2012-05-23 2014-12-16 Box, Inc. Methods, architectures and security mechanisms for a third-party application to access content in a cloud-based platform
GB2505072A (en) 2012-07-06 2014-02-19 Box Inc Identifying users and collaborators as search results in a cloud-based system
US9712510B2 (en) 2012-07-06 2017-07-18 Box, Inc. Systems and methods for securely submitting comments among users via external messaging applications in a cloud-based platform
US9081953B2 (en) 2012-07-17 2015-07-14 Oracle International Corporation Defense against search engine tracking
US9654968B2 (en) * 2012-07-17 2017-05-16 Texas Instruments Incorporated Certified-based control unit-key fob pairing
US9794256B2 (en) 2012-07-30 2017-10-17 Box, Inc. System and method for advanced control tools for administrators in a cloud-based service
US8832716B2 (en) 2012-08-10 2014-09-09 Honeywell International Inc. Systems and methods for limiting user customization of task workflow in a condition based health maintenance system
GB2513671A (en) 2012-08-27 2014-11-05 Box Inc Server side techniques for reducing database workload in implementing selective subfolder synchronization in a cloud-based environment
US9135462B2 (en) 2012-08-29 2015-09-15 Box, Inc. Upload and download streaming encryption to/from a cloud-based platform
US9195519B2 (en) 2012-09-06 2015-11-24 Box, Inc. Disabling the self-referential appearance of a mobile application in an intent via a background registration
US9117087B2 (en) 2012-09-06 2015-08-25 Box, Inc. System and method for creating a secure channel for inter-application communication based on intents
US9292833B2 (en) 2012-09-14 2016-03-22 Box, Inc. Batching notifications of activities that occur in a web-based collaboration environment
US10915492B2 (en) 2012-09-19 2021-02-09 Box, Inc. Cloud-based platform enabled with media content indexed for text-based searches and/or metadata extraction
US9037920B2 (en) 2012-09-28 2015-05-19 Honeywell International Inc. Method for performing condition based data acquisition in a hierarchically distributed condition based maintenance system
US9959420B2 (en) 2012-10-02 2018-05-01 Box, Inc. System and method for enhanced security and management mechanisms for enterprise administrators in a cloud-based environment
US9495364B2 (en) 2012-10-04 2016-11-15 Box, Inc. Enhanced quick search features, low-barrier commenting/interactive features in a collaboration platform
US9665349B2 (en) 2012-10-05 2017-05-30 Box, Inc. System and method for generating embeddable widgets which enable access to a cloud-based collaboration platform
KR101659113B1 (ko) * 2012-10-09 2016-09-23 엘에스산전 주식회사 전력시스템을 위한 클라우드 서비스 제공 시스템
US10235383B2 (en) 2012-12-19 2019-03-19 Box, Inc. Method and apparatus for synchronization of items with read-only permissions in a cloud-based environment
CN103067156B (zh) * 2012-12-28 2016-01-20 北京移数通电讯有限公司 移动互联网用户资源访问的url加密、验证方法和装置
US20140188728A1 (en) 2012-12-31 2014-07-03 Fiserv, Inc. Systems and methods for performing financial transactions
US9396245B2 (en) 2013-01-02 2016-07-19 Box, Inc. Race condition handling in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US9953036B2 (en) 2013-01-09 2018-04-24 Box, Inc. File system monitoring in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
EP2755151A3 (de) 2013-01-11 2014-09-24 Box, Inc. Funktionalitäten, Merkmale und der Benutzeroberfläche eines Synchronisationsclient zu einer Cloud-basierten Umgebung
US10599671B2 (en) 2013-01-17 2020-03-24 Box, Inc. Conflict resolution, retry condition management, and handling of problem files for the synchronization client to a cloud-based platform
US10725968B2 (en) 2013-05-10 2020-07-28 Box, Inc. Top down delete or unsynchronization on delete of and depiction of item synchronization with a synchronization client to a cloud-based platform
US10846074B2 (en) 2013-05-10 2020-11-24 Box, Inc. Identification and handling of items to be ignored for synchronization with a cloud-based platform by a synchronization client
GB2515192B (en) 2013-06-13 2016-12-14 Box Inc Systems and methods for synchronization event building and/or collapsing by a synchronization component of a cloud-based platform
US9805050B2 (en) 2013-06-21 2017-10-31 Box, Inc. Maintaining and updating file system shadows on a local device by a synchronization client of a cloud-based platform
US9467283B2 (en) * 2013-06-24 2016-10-11 Blackberry Limited Securing method for lawful interception
US9535924B2 (en) 2013-07-30 2017-01-03 Box, Inc. Scalability improvement in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform
US9584313B2 (en) * 2013-08-09 2017-02-28 Introspective Power, Inc. Streaming one time pad cipher using rotating ports for data encryption
US9584488B2 (en) 2013-08-09 2017-02-28 Introspective Power, Inc. Data encryption cipher using rotating ports
US9535909B2 (en) 2013-09-13 2017-01-03 Box, Inc. Configurable event-based automation architecture for cloud-based collaboration platforms
US10509527B2 (en) 2013-09-13 2019-12-17 Box, Inc. Systems and methods for configuring event-based automation in cloud-based collaboration platforms
KR101524743B1 (ko) * 2013-11-15 2015-06-24 주식회사 날리지큐브 버츄얼 클러스터
GB2517844B (en) 2014-02-25 2015-09-09 Cambridge Silicon Radio Ltd Thwarting traffic analysis
GB2515853B (en) 2014-02-25 2015-08-19 Cambridge Silicon Radio Ltd Latency mitigation
US9762395B2 (en) 2014-04-30 2017-09-12 International Business Machines Corporation Adjusting a number of dispersed storage units
EP3127300B1 (de) * 2014-05-12 2019-09-04 Google LLC Verwaltung von nic-verschlüsselten strömen zur migration von gästen oder aufgaben
US10530854B2 (en) 2014-05-30 2020-01-07 Box, Inc. Synchronization of permissioned content in cloud-based environments
US10038731B2 (en) 2014-08-29 2018-07-31 Box, Inc. Managing flow-based interactions with cloud-based shared content
US9894119B2 (en) 2014-08-29 2018-02-13 Box, Inc. Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms
US9942211B1 (en) * 2014-12-11 2018-04-10 Amazon Technologies, Inc. Efficient use of keystreams
US10185946B2 (en) 2014-12-31 2019-01-22 Fiserv, Inc. Facilitating presentation of content relating to a financial transaction
EP3248360B1 (de) 2015-01-19 2020-05-06 Inauth, Inc. Systeme und verfahren für sichere kommunikation mit sicherem weg
WO2016132719A1 (ja) * 2015-02-16 2016-08-25 日本電気株式会社 通信システム、ノード装置、通信端末、キー管理方法及びプログラムが格納された非一時的なコンピュータ可読媒体
US9509709B2 (en) * 2015-03-19 2016-11-29 International Business Machines Corporation Mechanism to augment IPS/SIEM evidence information with process history snapshot and application window capture history
US10104047B2 (en) * 2015-04-08 2018-10-16 Microsemi Solutions (U.S.), Inc. Method and system for encrypting/decrypting payload content of an OTN frame
US9432340B1 (en) * 2015-05-07 2016-08-30 Bogart Associates System and method for secure end-to-end chat system
EP3381166B1 (de) 2015-11-25 2021-04-28 Inauth, Inc. Systeme und verfahren zur kanalübergreifenden vorrichtungsbindung
US10009328B2 (en) * 2015-12-07 2018-06-26 Mcafee, Llc System, apparatus and method for providing privacy preserving interaction with a computing system
US9590956B1 (en) 2015-12-18 2017-03-07 Wickr Inc. Decentralized authoritative messaging
US10334062B2 (en) 2016-02-25 2019-06-25 InAuth, Inc. Systems and methods for recognizing a device
US9591479B1 (en) 2016-04-14 2017-03-07 Wickr Inc. Secure telecommunications
US20180012190A1 (en) * 2016-07-06 2018-01-11 International Business Machines Corporation Automatic inference of meeting attendance
FR3054905B1 (fr) * 2016-08-04 2019-10-18 Safran Identity & Security Procede de generation de cle et procede de controle d'acces
US11093852B2 (en) 2016-10-19 2021-08-17 Accertify, Inc. Systems and methods for recognizing a device and/or an instance of an app invoked on a device
US11403563B2 (en) 2016-10-19 2022-08-02 Accertify, Inc. Systems and methods for facilitating recognition of a device and/or an instance of an app invoked on a device
US10778432B2 (en) 2017-11-08 2020-09-15 Wickr Inc. End-to-end encryption during a secure communication session
US11101999B2 (en) 2017-11-08 2021-08-24 Amazon Technologies, Inc. Two-way handshake for key establishment for secure communications
US10541814B2 (en) 2017-11-08 2020-01-21 Wickr Inc. End-to-end encryption during a secure communication session
US10855440B1 (en) 2017-11-08 2020-12-01 Wickr Inc. Generating new encryption keys during a secure communication session
US11310078B2 (en) * 2018-01-11 2022-04-19 Wesley Rogers Cipher stream based secure packet communications with key stream transmission over diverse paths
US10754972B2 (en) 2018-01-30 2020-08-25 Salesforce.Com, Inc. Multi-factor administrator action verification system
US10635939B2 (en) * 2018-07-06 2020-04-28 Capital One Services, Llc System, method, and computer-accessible medium for evaluating multi-dimensional synthetic data using integrated variants analysis
US11222311B2 (en) * 2018-12-18 2022-01-11 The Toronto-Dominion Bank System and method for secure data transfer
JP2022184560A (ja) * 2021-06-01 2022-12-13 富士フイルムビジネスイノベーション株式会社 情報処理装置及び情報処理プログラム
US11804970B2 (en) * 2021-10-15 2023-10-31 Lenovo Global Technology (United States) Inc. Baseboard management controller group administration
US12437052B2 (en) * 2022-06-03 2025-10-07 Apple Inc. Proving membership using cryptographic identities
US12368589B2 (en) * 2022-11-23 2025-07-22 International Business Machines Corporation Method to validate ownership and authentication of a digital asset
KR20250045818A (ko) * 2023-09-26 2025-04-02 삼성에스디에스 주식회사 메시징 암호화 방법 및 그 시스템
US20250252482A1 (en) * 2024-02-02 2025-08-07 Locker 2.0, Inc. Systems and methods for enhancing mobile shopping experience

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07235921A (ja) * 1994-02-23 1995-09-05 Nippon Telegr & Teleph Corp <Ntt> 情報通信のセキュリティ管理方法及び装置
GB9502182D0 (en) * 1995-02-03 1995-03-22 Plessey Telecomm Telecommunications service interactions
JP3982848B2 (ja) * 1995-10-19 2007-09-26 富士通株式会社 セキュリティレベル制御装置及びネットワーク通信システム
US5787175A (en) 1995-10-23 1998-07-28 Novell, Inc. Method and apparatus for collaborative document control
FR2743235B1 (fr) * 1995-12-27 1998-01-23 Alsthom Cge Alcatel Methode pour securiser les collaborations entre objets d'un programme oriente objet
JP3562134B2 (ja) * 1996-04-19 2004-09-08 富士ゼロックス株式会社 協調設計支援システム及び方法
JPH09319673A (ja) * 1996-05-27 1997-12-12 Matsushita Electric Works Ltd 暗号鍵更新方法およびそのシステム
DE19622630C1 (de) * 1996-06-05 1997-11-20 Siemens Ag Verfahren zum gruppenbasierten kryptographischen Schlüsselmanagement zwischen einer ersten Computereinheit und Gruppencomputereinheiten
US6453327B1 (en) * 1996-06-10 2002-09-17 Sun Microsystems, Inc. Method and apparatus for identifying and discarding junk electronic mail
US6272639B1 (en) * 1996-07-30 2001-08-07 Micron Technology, Inc. Mixed enclave operation in a computer network
JPH10111825A (ja) * 1996-10-04 1998-04-28 Kokusai Denshin Denwa Co Ltd <Kdd> 複数データベース一致化更新方法および装置
JP3512311B2 (ja) * 1997-03-27 2004-03-29 日立ソフトウエアエンジニアリング株式会社 情報リンク管理方法および情報提供システム
JPH1115373A (ja) * 1997-06-20 1999-01-22 Fuji Xerox Co Ltd 公開鍵暗号方式
US6775382B1 (en) 1997-06-30 2004-08-10 Sun Microsystems, Inc. Method and apparatus for recovering encryption session keys
JPH11150554A (ja) * 1997-11-14 1999-06-02 Casio Comput Co Ltd データ通信装置、データ通信方法及び記憶媒体
US6049878A (en) * 1998-01-20 2000-04-11 Sun Microsystems, Inc. Efficient, secure multicasting with global knowledge
US6195751B1 (en) 1998-01-20 2001-02-27 Sun Microsystems, Inc. Efficient, secure multicasting with minimal knowledge
US6334146B1 (en) * 1998-06-05 2001-12-25 I2 Technologies Us, Inc. System and method for remotely accessing data
US6295361B1 (en) * 1998-06-30 2001-09-25 Sun Microsystems, Inc. Method and apparatus for multicast indication of group key change
JP2000066941A (ja) * 1998-08-25 2000-03-03 Nec Corp 分散ファイル更新方法及びそのシステム
US6584566B1 (en) * 1998-08-27 2003-06-24 Nortel Networks Limited Distributed group key management for multicast security
US6606706B1 (en) * 1999-02-08 2003-08-12 Nortel Networks Limited Hierarchical multicast traffic security system in an internetwork
US6542993B1 (en) * 1999-03-12 2003-04-01 Lucent Technologies Inc. Security management system and method
US6961855B1 (en) * 1999-12-16 2005-11-01 International Business Machines Corporation Notification of modifications to a trusted computing base

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10063501B2 (en) 2015-05-22 2018-08-28 Microsoft Technology Licensing, Llc Unified messaging platform for displaying attached content in-line with e-mail messages
US10216709B2 (en) 2015-05-22 2019-02-26 Microsoft Technology Licensing, Llc Unified messaging platform and interface for providing inline replies
US10360287B2 (en) 2015-05-22 2019-07-23 Microsoft Technology Licensing, Llc Unified messaging platform and interface for providing user callouts

Also Published As

Publication number Publication date
ATE346333T1 (de) 2006-12-15
EP1348152A2 (de) 2003-10-01
IL152351A (en) 2009-08-03
EP1698959A1 (de) 2006-09-06
US6986046B1 (en) 2006-01-10
EP1708406A3 (de) 2006-11-22
CA2408437C (en) 2010-11-30
JP2012019534A (ja) 2012-01-26
US7171001B2 (en) 2007-01-30
IL152351A0 (en) 2003-05-29
WO2001088674A3 (en) 2003-07-24
US20060036862A1 (en) 2006-02-16
US20060041752A1 (en) 2006-02-23
JP2004501547A (ja) 2004-01-15
EP1708406A2 (de) 2006-10-04
EP1705599A2 (de) 2006-09-27
US7213147B2 (en) 2007-05-01
CA2408437A1 (en) 2001-11-22
EP1348152B1 (de) 2006-11-22
KR20030010620A (ko) 2003-02-05
WO2001088674A2 (en) 2001-11-22
AU2001261117A1 (en) 2001-11-26
US20060050869A1 (en) 2006-03-09
DE60124765D1 (de) 2007-01-04
JP4955181B2 (ja) 2012-06-20
KR100905141B1 (ko) 2009-06-29
US7415606B2 (en) 2008-08-19
EP1705599A3 (de) 2006-11-22

Similar Documents

Publication Publication Date Title
DE60124765T2 (de) Verfahren und vorrichtung zur verwaltung von sicherheitssensiblen kollaborativen transaktionen
DE60037593T2 (de) Gesichertes ad hoc netzwerk sowie verfahren zu dessen betreiben
DE60028645T2 (de) Vorrichtung und Verfahren zur Verteilung von Dokumenten
DE69902414T2 (de) Effiziente sichere Mehrfachübertragung mit minimaler Kenntnis
DE60315914T2 (de) Ad hoc Sicherheitszugriff auf Dokumente und Dienste
DE60304744T2 (de) Verfahren,vorrichtung und computerprogramme zur erzeugung und/oder verwendungkonditionaler elektronischer signaturen zur meldung von statusänderungen
DE112010003149B4 (de) Gemeinschaftliche Verschlüsselung und Entschlüsselung durch Agenten
EP3854022B1 (de) Verfahren und vorrichtung zum übertragen von daten in einem publish-subscribe-system
DE19622630C1 (de) Verfahren zum gruppenbasierten kryptographischen Schlüsselmanagement zwischen einer ersten Computereinheit und Gruppencomputereinheiten
EP3955511B1 (de) Gesicherte datenübertragung innerhalb eines qkd-netzwerkknotens
DE102024128803B3 (de) Verfahren und System zum standardkonformen, vertraulichen Empfangen von Daten für eine verschlüsselte Datenverarbeitung
DE102016218758A1 (de) Vorrichtung und verfahren zur durchgängigen und medienübergreifenden übertragung von kommunikationsprotokollen ohne protokollumsetzung
DE102014212219A1 (de) Verfahren zur Authentifizierung und Anbindung eines Geräts an ein Netzwerk sowie hierzu eingerichteter Teilnehmer des Netzwerks
EP1286494B1 (de) Verfahren zur Erzeugung eines asymmetrischen kryptografischen Gruppenschlüsselpaares
DE19548387C1 (de) Verfahren zur kryptographischen Sicherung der rechnergestützten digitalen Kommunikation zwischen einem Programm und mindestens einer Benutzereinheit
WO2005074189A1 (de) Schaltungsanordnung und verfahren zur kommunikationssicherheit innerhalb von kommunikationsnetzen
EP3669508B1 (de) Geschützte nachrichtenübertragung
DE102024124790A1 (de) Digitales zertifikat
DE10325816B4 (de) Infrastruktur für öffentliche Schlüssel für Netzwerk-Management
DE10202456A1 (de) Verfahren zum elektronischen Übertragen elektronischer Daten in einem dezentralen Netzwerk sowie dezentrales Netzwerk

Legal Events

Date Code Title Description
8328 Change in the person/name/address of the agent

Representative=s name: BOEHMERT & BOEHMERT, 28209 BREMEN

8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: MICROSOFT CORP., REDMOND, WASH., US