DE60027046T2

DE60027046T2 - Synchronisierung von sitzungsschlüsseln

Info

Publication number: DE60027046T2
Application number: DE60027046T
Authority: DE
Inventors: A. Antonius STARING
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 1999-12-10
Filing date: 2000-12-05
Publication date: 2006-11-16
Anticipated expiration: 2020-12-06
Also published as: TW545023B; WO2001043335A2; BR0008094A; EP1188270B1; US20010007127A1; US7110546B2; CN1421080A; EP1188270A2; KR20010102046A; DE60027046D1; CN1224211C; WO2001043335A3; JP2003516658A

Description

Die Erfindung betrifft ein sicheres Kommunikationssystem und -verfahren, wobei Information zwischen einem Source- und mindestens einem Sink-Gerät in einer Kommunikationssitzung übertragen wird, umfassend die Übertragung einer Vielzahl von Paketen vom Source-Gerät zum Sink-Gerät, wobei Daten in den Paketen unter der Kontrolle dynamisch veränderter Sitzungsschlüssel verschlüsselt werden. Die Erfindung betrifft ferner ein Sink-Gerät zur Verwendung in solch einem System, und Software, die vom Sink-Gerät ausgeführt werden kann.
Protokolle, die zum Datenschutz während der Übertragung über einen Übertragungskanal verwendet werden, bestehen allgemein aus einer Anzahl von Einzelphasen. Zum Beispiel kann das Protokoll aus den folgenden fünf Phasen bestehen. Während der ersten Phase, der Authentifizierungsphase, authentifizieren die Source- und Sink-Geräte sich gegenseitig. In der zweiten Phase, der Schlüsselaustauschphase, werden Zufallszahlen und Schlüsselmaterial erzeugt, verschlüsselt und ausgetauscht. Während der dritten Phase, der Schlüsselgenerierungssphase, wird ein Sitzungsschlüssel mit Hilfe des ausgetauschten Schlüsselmaterials erzeugt. Im der vierten Phase, dem Informationsübertragungsschritt, wird der Inhalt mit Hilfe des Sitzungsschlüssels verschlüsselt, vom Source- zum Sink-Gerät übertragen und vom Sink-Gerät mit Hilfe desselben Sitzungsschlüssels entschlüsselt. In der fünften Phase, der Schlüsselaktualisierungsphase, wird schliesslich der Sitzungsschlüssel aktualisiert. Die Schlüsselaktualisierungsphase wird während der vierten Phase periodisch ausgeführt. Der Hauptzweck der Schlüsselaktualisierungsphase ist es, sicherzustellen, dass das Knacken eines einzelnen Sitzungsschlüssels nur eine begrenzte Preisgabe des Inhalts zur Folge hat.
In vielen Systemen wird eine Folge von Sitzungsschlüsseln mit einem Algorithmus erzeugt, der sowohl dem Source- als auch dem Sink-Gerät bekannt ist. Dieser Algorithmus wird mit dem Schlüsselmaterial initialisiert, das beide Geräts während der Schlüsselaustauschphase ausgetauscht haben. Allgemein steuert das Source-Gerät, wann der Sitzungsschlüssel aktualisiert wird. Dadurch kommt das Problem der Synchronisierung der Schlüsselaktualisierungen im Source- und Sink-Gerät auf.
Die meisten digitalen Kommunikationssysteme, wie z.B. IEEE 1394 und USB, übertragen Daten in einer Paketfolge. In einigen Systemen kann im unverschlüsselten Paketkopf ein spezielles Feld zur Synchronisierung von Sitzungsschlüsselaktualisierungen vorgesehen sein. Das Source-Gerät kann dann in diesem Feld ein Update-Flag setzen, um eine Änderung des Sitzungsschlüssels zu signalisieren. Wenn aber ein bestehendes System mit einem Inhaltsschutzmechanismus nachgerüstet werden soll, ist es allgemein nicht möglich, dem Paketkopf Felder hinzuzufügen. In diesem Fall kann im (unverschlüsselten Teil des) Datenfelds (auch Payload-Feld bzw. Nutzinformationsfeld genannt) des Pakets ein spezielles Feld zugewiesen werden. In beiden Fällen liegen die Update-Flags in Klartext vor, was Angreifer mit Information versorgt.
Es ist bekannt, diesen Mangel abzustellen, indem das Datenfeld des Pakets mit dem aktuellen Sitzungsschlüssel entschlüsselt wird; sowie mit dem nächsten Schlüssel in der Schlüsselfolge, und der Schlüssel gewählt wird, für den die entschlüsselten Daten einen Sinn ergeben. Mit diesem Verfahren wird ein Wechsel von einem Sitzungsschlüssel zum nächsten automatisch erkannt. Doch die Bestimmung, ob die entschlüsselten Daten einen Sinn ergeben, erfordert ein Wissen über die Information, die gerade übertragen wird. Dies ist nicht immer der Fall, was die Anwendung dieses Verfahrens einschränkt.
US 5 574 785 offenbart ein chiffriertes Kommunikationssystem, das angehängte Daten verwendet, die der zu dechiffrierenden Information hinzugefügt werden, um einen korrekten Chiffrierschlüssel auf der Empfängerseite zu bestimmen.
Eine Aufgabe der Erfindung ist die Bereitstellung eines sicheren Kommunikationssystems, Sink-Geräts und sicheren Kommunikationsverfahrens, die den oben genannten Nachteil abstellen.
Um die Aufgabe der Erfindung zu erfüllen, umfasst ein sicheres Kommunikationssystem ein Source-Gerät und mindestens ein Sink-Gerät, wobei Information vom Source-Gerät zum Sink-Gerät in einer Kommunikationssitzung übertragen wird, umfassend die Übertragung einer Vielzahl von Paketen vom Source-Gerät zum Sink-Gerät; jedes Paket ein Datenfeld einschliesst, um einen Teil der Information zu übertragen;
wobei das Source-Gerät umfasst:
einen Schlüsselgenerator, um auf die Initiative des Source-Geräts hin einen aktiven Source-Sitzungsschlüssel in einer vorgegebenen Folge von Source-Sitzungsschlüsseln Ksource_i zu generieren;
einen Verschlüsseler, um mindestens einen Teil des Datenfelds eines Pakets unter der Kontrolle des aktiven Source-Sitzungsschlüssels zu verschlüsseln; wobei der verschlüsselte Teil des Datenfelds ein Subfeld einschliesst, das als Schlüsselprüfblockfeld bezeichnet wird;
wobei das Sink-Gerät umfasst:
einen Schlüsselgenerator, um eine Vielzahl von in Frage kommenden Sink-Sitzungsschlüsseln in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i zu generieren, wobei für jeden Index i in der Folge der jeweilige Sink-Sitzungsschlüssel Ksink_i dem jeweiligen Source-Sitzungsschlüssel Ksource_i entspricht;
einen Entschlüsseler, um mindestens einen Teil des Datenfelds eines empfangenen Pakets unter der Kontrolle eines Sink-Sitzungsschlüssels zu entschlüsseln;
einen Schlüssel-Resolver, der betrieben werden kann, um zu bestimmen, welcher der in Frage kommenden Sink-Sitzungsschlüssel dem Source-Sitzungsschlüssel entspricht, der benutzt wurde, um den verschlüsselten Teil eines empfangenen Pakets zu verschlüsseln, indem er den Entschlüsseler veranlasst, die Daten im Schlüsselprüfblockfeld des empfangenen Pakets unter der Kontrolle jedes mal eines anderen von der Vielzahl der in Frage kommenden Sink-Sitzungsschlüssel zu entschlüsseln, bis ein gültiges Entschlüsselungsergebnis gefunden wird,; und den Entschlüsseler veranlasst, einen restlichen verschlüsselten Teil des Datenfelds des Pakets unter der Kontrolle des in Frage kommenden Sink-Sitzungsschlüssels zu entschlüsseln, der das gültige Entschlüsselungsergebnis erzeugt hat.
Durch Einschluss eines separaten Schlüsselprüfblocks, der von den anderen Daten im Paket unabhängig ist, kann das Sink-Gerät leicht prüfen, welcher der in Frage kommenden Sink-Sitzungsschlüssel zum Entschlüsseln der Daten verwendet werden sollte. Dadurch benötigt das Sink-Gerät kein A-priori-Wissen über die verschlüsselten Daten, die übertragen werden. Zudem kann der Schlüsselprüfblock relativ kurz sein, (z.B. die Grösse eines Blocks für ein CBC-Cipher), so dass nur ein kleiner Teil der verschlüsselten Information unter der Kontrolle von mehr als einem Schlüssel entschlüsselt zu werden braucht. Der Grossteil der verschlüsselten Daten braucht nur unter der Kontrolle des erkannten Sink-Sitzungsschlüssels entschlüsselt zu werden. Normalerweise werden nur zwei in Frage kommende Sitzungsschlüssel verwendet. Es können auch mehr in Frage kommende Schlüssel getestet werden, zum Beispiel, um einen Paketverlust während der Übertragung zu überwinden. Bevorzugt wird der Sitzungsschlüssel nicht bei jedem aufeinanderfolgenden Paket geändert, um den Schlüsselgenerierungsaufwand zu reduzieren. In diesem Fall schliesst der Satz der in Frage kommenden Sink-Sitzungsschlüssel den aktuell gewählten Sink-Sitzungsschlüssel Ksink_i und mindestens einen Sink-Sitzungsschlüssel Ksink_i+1 ein, der der nächste in der Folge ist, wobei der aktuell gewählte Sink-Sitzungsschlüssel Ksink_i dem Source-Sitzungsschlüssel Ksource_i entspricht, der zur Verschlüsselung des verschlüsselten Teils eine zuvor empfangenen Pakets verwendet wurde. Es ist hervorzuheben, dass, wann immer das Sink-Gerät eine Änderung des Sitzungsschlüssels erkennt, das Sink-Gerät normalerweise einen nächsten in Frage kommenden Sink-Sitzungsschlüssel generiert, um ihn in den Satz der in Frage kommenden Schlüssel aufzunehmen, die für das nächste Paket getestet werden.
Wie in der Massnahme des abhängigen Anspruchs 2 definiert, kann der Inhalt des Schlüsselprüfblocks öffentlich sein. Dies macht die Prüfung der in Frage kommenden Schlüssel sehr einfach. Die Entschlüsselungsergebnisse für jeden der in Frage kommenden Schlüssel können einfach mit dem öffentlichen Schlüsselprüfblock verglichen werden; die Übereinstimmung zeigt den Sink-Sitzungsschlüssel an, der dem Source-Sitzungsschlüssel entspricht, der zum Verschlüsseln der verschlüsselten Daten im Paket verwendet wurde.
Wie in der Massnahme des abhängigen Anspruchs 3 definiert, wird der Datenblock für die ganze Kommunikationssitzung vereinbart. Die Vereinbarung kann als Teil der Schlüsselgenerierungsphase erfolgen, wo das ausgetauschte Schlüsselmaterial verwendet wird, um einen Schlüsselprüfblock zu erzeugen. Mit einem Schlüsselprüfblock, der für die gesamte Sitzung feststehend bleibt, bleibt der Schlüsselaktualisierungsvorgang einfach. Wenn ein Blockcipher im CBC-Modus verwendet wird, um die Daten des Pakets zu verschlüsseln, wird bevorzugt, dass der Schlüsselprüfblock die gleiche Länge wie die Blockgrösse des Verschlüsselungsalgorithmus hat (oder ein Mehrfaches davon). Dies hat leider eine Schwäche des Systems zur Folge, da der verschlüsselte Schlüsselprüfblock (der gewöhnlich ein Block an einer vorgegebenen Position im Datenfeld des Pakets ist) in Verbindung mit dem (öffentlich) bekannten Schlüsselprüfblock die Information für eine erschöpfende Schlüsselsuche bereitstellt. Wenn kein öffentlicher Schlüsselprüfblock benutzt wird, wird die Sicherheit erhöht.
Wie in der Massnahme des abhängigen Anspruchs 4 definiert, ändert sich der Schlüsselprüfblock während der Sitzung. Dies erhöht die Sicherheit und verringert die Chancen einer erfolgreichen erschöpfende Suche während einer Kommunikationssitzung.
Wie in der Massnahme des abhängigen Anspruchs 5 definiert, wird ein vorgegebener Algorithmus verwendet, um den Schlüsselprüfblock zu generieren und eine Änderung des Blocks durchzuführen. Der Schlüsselprüfblockgenerator kann sehr einfach sein, wie z.B. das Erzeugen einer zyklischen Zahlenfolge. Auch komplexere Algorithmen können verwendet werden, wie die zum Generieren der Sitzungsschlüssel. Zum Beispiel kann ein Zufallszahlengenerator verwendet werden, der durch Schlüsselmaterial initialisiert wird, das während der Schlüsselaustauschphase ausgetauscht wurde. Der Änderungszeitpunkt der des Schlüsselprüfblocks kann vorgegeben sein (z.B. bei jedem 100. Paket, oder bei jedem Paket). Vorteilhafterweise hängt der Änderungszeitpunkt vom Änderungszeitpunkt des Sitzungsschlüssels ab. Wenn zum Beispiel eine Änderung des Sitzungsschlüssels erkannt wird, zeigt dies auch eine Änderung des Schlüsselprüfblocks an.
Wie in der Massnahme des abhängigen Anspruchs 6 definiert, ist der Schlüsselprüfblock von Daten eines vorherigen Pakets abhängig, wie z.B. des unmittelbar vorhergehenden Pakets. Der Schlüsselprüfblock kann durch einen geeigneten Algorithmus von Daten in einem vorherigen Paket abgeleitet werden. Da die Daten selbst normalerweise auf erheblich variieren, kann ein relativ einfacher Algorithmus verwendet werden, um den Schlüsselprüfblock zu generieren. Wenn erwünscht, kann auch ein starker Algorithmus wie z.B. ein Hashing-Algorithmus verwendet werden.
Wie in der Massnahme des abhängigen Anspruchs 8 definiert, ist der Schlüsselprüfblock eine direkte „Kopie" eines Teils der Daten in einem vorherigen Paket. In diesem Fall wird solch eine Datenteil bevorzugt in verschlüsselter Form übertragen, wobei der Schlüsselprüfblock, der verwendet wird, um den Schlüssel eines nächsten Pakets zu prüfen, durch die Klartextform dieses Datenteils im vorhergehenden Paket geformt wird. Da Daten sich normalerweise in aufeinanderfolgenden Paketen ändern, verändert sich auch der Schlüsselprüfblock. Aufgrund der Verwendung dieser veränderlichen Daten werden weder Algorithmen benötigt, um eine Folge von Schlüsselprüfblöcken zu generieren, noch muss eine Zusatzinformation hinzugefügt werden, um eine Änderung im Schlüsselprüfblock zu signalisieren. In einer bevorzugten Ausführungsform ist der Schlüsselprüfblock am Anfang des verschlüsselten Teils des Datenfelds angeordnet, was eine schnelle Erkennung erlaubt; Bevorzugt ist der Datenblock, der die (verschlüsselten) Daten für den nächsten Schlüsselprüfblock enthält, im zweiten oder letzten Block des verschlüsselten Teils des Datenfeld angeordnet.
Um die Aufgabe der Erfindung zu erfüllen, wird ein Verfahren zur sicheren Kommunikation zwischen einem Source-Gerät und mindestens einem Sink-Gerät bereitgestellt, wobei Information vom Source-Gerät zum Sink-Gerät in einer Kommunikationssitzung übertragen wird, umfassend die Übertragung einer Vielzahl von Paketen vom Source-Gerät zum Sink-Gerät; wobei jedes Paket ein Datenfeld einschliesst, um einen Teil der Information zu übertragen; wobei das Verfahren umfasst:
das Generieren, auf die Initiative des Source-Geräts hin, eines aktiven Source-Sitzungsschlüssels in einer vorgegebenen Folge von Source-Sitzungsschlüsseln Ksource_i;
das Verschlüsseln mindestens eines Teils des Datenfelds eines Pakets unter der Kontrolle des aktiven Source-Sitzungsschlüssels; wobei der verschlüsselte Teil des Datenfelds ein Subfeld einschliesst, das als Schlüsselprüfblockfeld bezeichnet wird;
das Übertragen des Pakets vom Source-Gerät zum Sink-Gerät;
das Generieren einer Vielzahl von in Frage kommenden Sink-Sitzungsschlüsseln in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i, wobei für jeden Index i in der Folge der jeweilige Sink-Sitzungsschlüssel Ksink_i dem jeweiligen Source-Sitzungsschlüssel Ksource_i entspricht;
das Bestimmen, welcher der in Frage kommenden Sink-Sitzungsschlüssel dem Source-Sitzungsschlüssel entspricht, der benutzt wurde, um den verschlüsselten Teil eines empfangenen Pakets zu verschlüsseln, durch Entschlüsseln der Daten im Schlüsselprüfblockfeld des empfangenen Pakets unter der Kontrolle jedes mal eines anderen von der Vielzahl der in Frage kommenden Sink-Sitzungsschlüssel, bis ein gültiges Entschlüsselungsergebnis gefunden wird;
das Entschlüsseln eines restlichen verschlüsselten Teils des Datenfelds des Pakets unter der Kontrolle des in Frage kommenden Sink-Sitzungsschlüssels, der das gültige Entschlüsselungsergebnis erzeugt hat.
Diese und andere Aspekte der Erfindung gehen aus den Ausführungsformen hervor, die Bezug nehmend auf die Zeichnungen erläutert werden.
1 zeigt ein Blockdiagramm des erfindungsgemässen Systems 100;
2 zeigt eine beispielhafte Paketstruktur;
3 zeigt ein Blockdiagramm einer Ausführungsform, in welcher der Bezugsschlüsselprüfblock sich dynamisch verändert;
4 zeigt eine bevorzugte Ausführungsform, um einen sich dynamisch verändernden Bezugsschlüsselprüfblock zu erreichen;
5 zeigt eine bevorzugte Paketstruktur;
6 veranschaulicht das Cipher Text Stealing-Verfahren; und
7 zeigt die Protokollschritte in einer bevorzugten Ausführungsform.
1 zeigt ein Blockdiagramm des erfindungsgemässen Systems 100. Das System 100 umfasst mindestens ein Source-Gerät, wobei Geräte 110 und 120 gezeigt werden, und mindestens ein Sink-Gerät; wobei Geräte 130 und 140 gezeigt werden. Die Geräte können über ein Kommunikationsmedium 150 miteinander kommunizieren. Dies kann jedes geeignete Kommunikationsmedium sein, verdrahtet oder drahtlos. Die Kommunikation kann zu lokalen Zwecken sein, z.B. im ganzen Haus oder in einer kleineren Gerätegruppe, wie z.B. eine Gruppe von Audio-/Videogeräten oder eine Gruppe aus einem Computer mit Peripheriegeräten. Die Kommunikation kann auch in einem großräumigen Bereich sein, z.B. durch das Internet mit Zugang über Telefonleitungen oder ein Kabelnetz, oder eine Form von Stallitenübertragung. Normalerweise ist die Übertragung bidirektional. 1 zeigt Details des Source-Geräts 110 und des Sink-Geräts 130. In der Beschreibung wird angenommen, dass Information (d.h. die tatsächlichen Daten, wie z.B. ein Videoprogramm oder eine Audiotitel) von einem Source-Gerät zu einem Sink-Gerät gesendet wird. In der Praxis kann mehr als ein Sink-Gerät die Information empfangen (z.B. mit separaten Übertragungskanälen oder Broadcasting-/Multicastingverfahren). Die Geräte umfassen konventionelle Mittel zum Senden und Empfangen von Paketen über das Medium 150. Je nach Medium können diese Mittel aus einem Telefon- oder Kabelmodem bestehen, oder aus einer Busschnittstelle.
2 zeigt eine beispielhafte Paketstruktur 200 zur Übertragung eines Teils der Information vom Source-Gerät zum Sink-Gerät. Normalerweise wird die Information in einer Sitzung übertragen, die eine Folge von Paketen einschliesst; wobei die Pakete einen Teil der zu übertragenden Information befördern. Das Source- und Sink-Gerät führen eine Anzahl von Vorgängen nur einmal in jeder Sitzung durch, wie die Einrichtung eines Übertragungskanals und den Austausch des zugrundeliegenden Schlüsselmaterials. Normalerweise umfasst das Paket 200 ein Kopffeld 210, das eine Low-Level-Synchronisierung des Empfängers im Sink-Gerät erlauben kann, und das normalerweise Information zur Kennung des Sink-Geräts (und optional des Source-Geräts) und/oder eines Übertragungskanals enthält. Der Kopf 210 kann auch Information wie z.B. einen Pakettyp enthalten. Der Kopf selbst ist nicht Bestandteil der Erfindung. Das Paket 200 kann auch ein Endfeld 220 umfassen, das das Ende des Pakets anzeigen kann und Information wie z.B. eine Prüfsumme (z.B. in Form einer CRC) enthalten kann. Auch das Endfeld 220 ist nicht Bestandteil der Erfindung. Das Paket schließt ein Datenfeld 230 ein (auch als Nutzdatenfeld bezeichnet), um Datenbytes zu fassen, die vom Source-Gerät zum Sink-Gerät übertragen werden sollen. Gewöhnlich werden zu Beginn einer Sitzung Anweisungen und spezifische Daten im Datenfeld befördert, um die Sitzung zu starten (üblicherweise mit asynchronen Paketen). Sobald die Sitzung tatsächlich begonnen hat, wird das Datenfeld normalerweise hauptsächlich verwendet, um Teile der zu übertragenden Information zu befördern (entweder mit asynchronen oder isochronen Paketen, je nach Anwendung und Kommunikationssystem. Für die Erfindung ist es nicht relevant, ob die auf sichere Weise zu übertragende Information mit einem asynchronen Pakettyp oder mit einer isochronen Form der Übertragung (oder selbst einer Mischung aus beiden) ausgetauscht wird. Wie in 2 gezeigt, enthält das Datenfeld ein Schlüsselprüfblock (KCB)-Subfeld 232. Das KCB-Feld wird vom Source-Gerät (oder unter der Kontrolle des Source-Geräts) mit einem von Source-Gerät gewählten Sitzungsschlüssel verschlüsselt. Normalerweise wird während des Informationsaustauschs auch der Rest des Datenfelds 230 mit demselben Sitzungsschlüssel verschlüsselt. In gewissen Situationen kann es nicht erforderlich sein, sämtliche Daten zu verschlüsseln. In solch einem Fall weist das Datenfeld zusätzlich zum KCB-Subfeld 232 ein Subfeld mit verschlüsselten Daten (ED) 234 und ein Subfeld mit Klartextdaten (PD) 236 auf. Dadurch werden sowohl das KCB- als auch das ED-Subfeld verschlüsselt, wie mit 238 angegeben. Im folgenden wird angenommen, dass alle Daten im Datenfeld 230 verschlüsselt sind.
Bezug nehmend auf 1, umfasst das Source-Gerät 110 einen Schlüsselgenerator 112, um einen Source-Sitzungsschlüssel in einer bestimmten Folge von Source-Sitzungsschlüsseln Ksource_i zu erzeugen. Der Schlüsselgenerator muss nur einen Schlüssel auf einmal erzeugen. Für die Beschreibung wird angenommen, dass die Daten in einem Paket unter der Kontrolle nur eines Schlüssels verschlüsselt werden. Wenn erwünscht, kann ein Fachmann das System leicht modifizieren, um verschiedene Teile der Daten in einem Paket mit verschiedenen Algorithmen und/oder verschiedenen Schlüsseln zu verschlüsseln. Jeder geeignete Schlüsselgenerierungsalgorithmus kann verwendet werden. Zum Beispiel kann ein Zufallszahlengenerator benutzt werden, der mit der anfängliche Schlüsselin formation gespeist wird, die zwischen dem Source- und Sink-Gerät ausgetauscht wurde. Ein Schlüsseländerer 114 löst den Schlüsselgenerator 112 aus, um einen Source-Sitzungsschlüssel zu generieren, der für mindestens ein Paket, das als nächstes zu verschlüsseln ist, als der aktive Source-Sitzungsschlüssel verwendet wird. Der Algorithmus zur Steuerung der Schlüsseländerung kann sehr einfach sein, z.B. kann jedes aufeinanderfolgende Paket mit einem nächsten Sitzungsschlüssel verschlüsselt werden, oder in regelmässigen Zeitintervallen wie jede Sekunde (z.B. von einem Zeitgeber gesteuert) kann ein nächster Sitzungsschlüssel verwendet werden. Ein Verschlüsseler 116 wird verwendet, um mindestens einen Teil des Datenfelds des Pakets unter der Kontrolle des aktiven Source-Sitzungsschlüssels zu verschlüsseln. Wie in 2 beschrieben, schließt der verschlüsselte Teil des Datenfelds ein Subfeld ein, das dazu bestimmt ist, einen Schlüsselprüfblock zu fassen. Jeder geeignete Verschlüsselungsalgorithmus kann verwendet werden, wie DES im CBC-Modus.
Das Sink-Gerät 130 umfasst einen Schlüsselgenerator 132, um einen Sink-Sitzungsschlüssel in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i zu erzeugen. Die Folge der Source- und Sink-Schlüssel entsprechen sich. So entspricht für jeden Index i in der Folge der jeweilige Sink-Sitzungsschlüssel Ksink_i dem jeweiligen Source-Sitzungsschlüssel Ksource_i. Die Details der Entsprechung zwischen den Schlüssel werden vom verwendeten Verschlüsselungs-/Entschlüsselungsalgorithmus bestimmt. Bei einem symmetrischen Verschlüsselungsalgorithmus wie DES zum Beispiel ist der Entschlüsselungsschlüssel derselbe wie der Verschlüsselungsschlüssel. Bei einem asymmetrischen Algorithmus wie RSA besteht eine bestimmte Beziehung zwischen dem Verschlüsselungs- und Entschlüsselungsschlüssel, die gewährleistet, dass der Entschlüsselungsvorgangs umkehrt wie der Verschlüsselungsvorgang wirkt. Das Sink-Gerät 130 umfasst auch einen Entschlüsseler 134, um mindestens einen Teil des Datenfelds eines empfangenen Pakets unter der Kontrolle eines Sink-Sitzungsschlüssels zu entschlüsseln. Der Entschlüsseler 134 arbeitet „umgekehrt" wie der Verschlüsseler 116, vorausgesetzt, dass entsprechende Schlüssel verwendet werden. Das Sink-Gerät umfasst auch einen Schlüssel-Resolver 136, der eine Vielzahl von in Frage kommenden Sink-Sitzungsschlüsseln testet, indem er prüft, welcher dieser Schlüssel den Schlüsselprüfblock erfolgreich entschlüsselt. Zu diesem Zweck ist der Schlüssel-Resolver 136 betreibbar, um den Entschlüsseler 134 zu veranlassen, die Daten im Schlüsselprüfblockfeld eines empfangenen Pakets unter der Kontrolle einer Vielzahl von in Frage kommenden Sink- Sitzungsschlüsseln zu entschlüsseln. Bevorzugt prüft der Schlüssel-Resolver 136 nach jeder Entschlüsselung, ob der getestete in Frage kommende Sink-Sitzungsschlüssel ein korrektes Entschlüsselungsergebnis des Schlüsselprüfblocks ergeben hat, der durch das Schlüsselprüfblockfeld übertragen wurde. Dies wird wiederholt, bis der Schlüssel gefunden worden ist. Der in Frage kommende Schlüssel, der ein korrektes Entschlüsselungsergebnis ergeben hat, wird dann zur Weiterverwendung gewählt. Der Entschlüsseler 134 wird verwendet, um einen restlichen verschlüsselten Teil des Datenfelds des Pakets unter der Kontrolle des gewählten Sink-Sitzungsschlüssels zu entschlüsseln. Der Schlüssel-Resolver 136 kann auch gewährleisten, dass die Liste der in Frage kommenden Sink-Sitzungsschlüssel auf den neusten Stand gehalten wird. So wird mindestens ein neuer Kandidat zum Satz der in Frage kommenden Sink-Sitzungsschlüssel hinzugefügt, wenn eine Schlüsseländerung erkannt wird. Zu diesem Zweck gewährleistet der Schlüssel-Resolver 136, dass der Schlüsselgenerator 132 einen nächsten Sink-Sitzungsschlüssel als in in Frage kommenden Sink-Sitzungsschlüssel erzeugt, wenn ein anderer in Frage kommenden Sink-Sitzungsschlüssel als der aktuell gewählte Sink-Sitzungsschlüssel Ksink_i ein korrektes Entschlüsselungsergebnis des Schlüsselprüfblocks erzeugt hat. Wenn das System das „Überspringen" von Sitzungsschlüsseln unterstützt (z.B., um den Verlust eines oder mehrerer Pakete während der Übertragung zu überwinden), erkennt der Schlüssel-Resolver 136 bevorzugt, dass der korrekte Sink-Sitzungsschlüssel nicht der nächste in der Folge war, sondern ein Sitzungsschlüssel eine oder mehrere Stellen weiter in der Folge, und sorgt dafür, dass alle übersprungenen Schlüssel aus dem Satz der in Frage kommenden Sink-Sitzungsschlüssel entfernt werden, und dass der der Satz mit der erforderlichen neuen Zahl von in Frage kommenden Schlüsseln aktualisiert wird. Wie der Schlüsselgenerator prüft, dass die Entschlüsselung der Daten im Schlüsselprüfblock gültig ist, hängt von der Art und Weise ab, wie der Schlüsselprüfblock definiert wird. Verschiedene alternative Weisen sind weiter unten definiert.
In einer Ausführungsform ist die Klartextform des Schlüsselprüfblocks (d.h., der Bezugsschlüsselprüfblock), der im Schlüsselprüfblockfeld übertragen wird, ein öffentlicher Datenblock. Dies macht die Prüfung, welcher der in Frage kommenden Sink-Sitzungsschlüssel dem Sink-Sitzungsschlüssel entspricht, der zur Verschlüsselung verwendet wurde, sehr einfach. Zum Beispiel kann der erste in Frage kommende Sink-Sitzungsschlüssel verwendet werden, um die Daten im Schlüsselprüfblockfeld zu entschlüsseln. Wenn die entschlüsselten Daten mit dem Bezugsschlüsselprüfblock übereinstimmen, ist dieser in Frage kommende Schlüssel der gewünschte Schlüssel. Wenn nicht, kann der nächste Sitzungsschlüssel verwendet werden, bis eine Übereinstimmung gefunden wurde. Der Bezugsschlüsselprüfblock (öffentlicher Datenblock) kann im Permanentspeicher gespeichert sein, z.B. ein ROM.
In einer Ausführungsform ist die Klartextform des Schlüsselprüfblocks, der im Schlüsselprüfblockfeld übertragen wird, ein Datenblock, der vor Beginn der Übertragung der Information zwischen dem Source- und Sink-Gerät vereinbart wird und für die ganze Kommunikationssitzung verwendet wird. Der Datenblock, der als die Klartextform des Schlüsselprüfblocks verwendet wird (d.h., der Bezugsschlüsselprüfblock), wird bevorzugt mit einem sicheren Verfahren vereinbart. Jedes geeignete Verfahren kann verwendet werden, zum Beispiel auf der Basis der Public-Key-Verschlüsselung. Bevorzugt wird der Bezugsschlüsselprüfblock aus dem Schlüsselmaterial abgeleitet, das zu Beginn der Sitzung ausgetauscht wurde, wodurch der es nicht notwendig ist, einen weiteren geheimen Datenaustausch hinzuzufügen. Das Verfahren zur Prüfung des in Frage kommenden Schlüssels ist dasselbe wie oben beschrieben. Doch in diesem Fall wird der Bezugsschlüsselprüfblock bevorzugt in einem wiederbeschreibbaren Speicher gespeichert. Bevorzugt ist solch ein Speicher sicher vor dem Zugriff durch Hacker.
In einer Ausführungsform ändert sich die Klartextform des Schlüsselprüfblocks (der Bezugsschlüsselprüfblock) während der Kommunikationssitzung mindestens einmal. 3 zeigt eine Methode, um eine dynamische Änderung des Bezugsschlüsselprüfblocks zu erreichen. In dieser Ausführungsform umfasst das Source-Gerät 110 einen Schlüsselprüfblockgenerator 118, um die Klartextform des Schlüsselprüfblocks zu generieren. Bevorzugt führt der Schlüsselprüfblockgenerator 118 auch die Änderung des Bezugsschlüsselprüfblocks durch (z.B., nachdem eine vorgegebene Zahl von Paketen gesendet wurde, oder nachdem eine vorgegebene Zeit abgelaufen ist). Das Sink-Gerät 130 umfasst einen entsprechenden Schlüsselprüfblockgenerator 138. Das Source-Gerät kann eine Änderung des Schlüsselprüfblocks auslösen, zum Beispiel, indem es ein Flag in einem Paket setzt (das bevorzugt in verschlüsselter Form übertragen wird), oder in Verbindung mit einer Änderung des Sitzungsschlüssels. Alternativ dazu kann das Sink-Gerät denselben Algorithmus wie das Source-Gerät verwenden, um eine Änderung des Bezugsschlüsselprüfblocks auszulösen.
4 veranschaulicht eine bevorzugte Ausführungsform, um einen sich dynamisch verändernden Bezugsschlüsselprüfblock zu erreichen. In dieser Ausführungsform wird die Änderung des Bezugsschlüsselprüfblocks erreicht, indem der Bezugsschlüsselprüfblock aus Information abgeleitet wird, die in einem Paket vor dem speziellen Paket übertragen wurde, für das der Schlüsselprüfblock tatsächlich verwendet wird. Zu diesem Zweck werden die Daten eines vorhergehenden Pakets den Schlüsselprüfblockgeneratoren 118 und 138 zugeführt, wie in der Zeichnung gezeigt. Die Schlüsselprüfblockgeneratoren können einen geeigneten Algorithmus verwenden, um den Bezugsschlüsselprüfblock aus Daten in einem vorhergehenden Paket abzuleiten. Da die Daten selbst erheblich variieren, kann ein relativ einfacher Algorithmus verwendet werden, um den Schlüsselprüfblock zu generieren. Wenn erwünscht, können auch starke Algorithmen verwendet werden, wie z.B. ein Hashing-Algorithmus. Es wird bevorzugt, den Bezugsschlüsselprüfblock aus einem unmittelbar vorhergehenden Paket abzuleiten.
In einer bevorzugten Ausführungsform ist die Klartextform des Schlüsselprüfblocks eines speziellen Pakets identisch mit der Klartextform eines vorgegebenen Datenblocks, der ein anderer ist als der Schlüsselprüfblock, in einem verschlüsselten Teil des Datenfelds eines Pakets vor dem speziellen Paket. Dies wird in 5 veranschaulicht. Paket 500 stellt das N. Paket der Paketfolge dar. Paket 510 stellt das N + 1. Paket der Paketfolge dar. Nur die verschlüsselten Teile der Pakete werden gezeigt. Der Schlüsselprüfblock KCB_N im Feld 232 des Pakets 500 wird benutzt, um zu prüfen, welcher Schlüssel verwendet wurde, um das Paket 500 zu verschlüsseln. Das Paket 500 schließt auch den Bezugsschlüsselprüfblock KCB_N+1 502 ein, der benutzt wird, um zu prüfen, welcher Schlüssel verwendet wurde, um das nächste Paket 510 zu verschlüsseln. In der Zeichnung formt der Bezugsschlüsselprüfblock KCB_N+1 502 den letzten Block des verschlüsselten Datenfelds 234 und enthält die normalen Daten, die vom Source- zum Sink-Gerät übertragen werden (KCB_N+1 502 wird also nicht eigens generiert). Es ist hervorzuheben, dass KCB_N+1 502 im Beispiel mit dem gleichen Source-Sitzungsschlüssel verschlüsselt wurde wie die anderen Daten im Feld 234 des Pakets 500. Die Klartextform von KCB_N+1 502 wird als der Bezugsschlüsselprüfblock zur Prüfung des Pakets 510 verwendet. Zu diesem Zweck schliesst das Paket im Bezugsschlüsselprüfblock-Subfeld 232 den Bezugsschlüsselprüfblock KCB_N+1 ein, der aber nun mit dem für dieses Paket verwendeten Sitzungsschlüssel verschlüsselt wird (der dem für das vorherige Paket verwendeten entsprechen kann). Es ist anzumerken, dass dadurch kein Informationsleck auftritt, da beide Blöcke verschlüsselt sind. Mit einem geeigneten Algorithmus wie einem mit einem Feedback Modus, wie z.B. der CBC-Verschlüsselungsmodus, ist die verschlüsselte Form von KCB_N+1 502 im Paket 500 nicht die gleiche wie die verschlüsselte Form von KCB_N+1 im Feld 232 des Pakets 510, selbst wenn derselbe Sitzungsschlüssel verwendet wurde, wodurch gewährleistet ist, dass es nicht möglich ist, eine Änderung von Sitzungsschlüsseln durch Vergleichen dieser Blöcke zu erkennen. Deshalb treten keine Informationslecks in Bezug auf eine mögliche Aktualisierung des Sitzungsschlüssels auf. Da jedes Paket mit einem anderen Schlüsselprüfblock anfängt und ein geeigneter Algorithmus, wie z.B. der CBC-Verschlüsselungsmodus, im Paket verwendet wird, werden zudem auch mögliche Informationslecks vermieden, die auf das Vorhandensein allgemein bekannter Datenblöcke am Anfang des Pakets zurückzuführen sind (z.B. MPEG-Header, die in bestimmten zu übertragenden Informationen häufig auftreten). Mit dem Mechanismus von 5 wird der erste Schlüsselprüfblock (der für das erste Paket in der Folge verwendet wird) bevorzugt aus der Information bestimmt, die in der Schlüsselaustauschphase zwischen dem Source- und Sink-Gerät ausgetauscht wurde.
Um zu prüfen, welcher Sitzungsschlüssel für das aktuelle Paket zu verwenden ist, muss nur der erste Block mit dem aktuellen Sitzungsschlüssel sowie dem nächsten Sitzungsschlüssel entschlüsselt werden. Wenn die Größe des Schlüsselprüfblocks der Blockgröße des Ciphers entspricht, wobei das Ergebnis den korrekten Sitzungsschlüssel eindeutig bestimmt, da bekannt ist, welcher Schlüsselprüfblock zu erwarten ist. Wenn der Schlüsselprüfblock kürzer als die Cipher-Blockgröße ist, besteht die Wahrscheinlichkeit, dass das Ergebnis nicht eindeutig wird.
Es ist hervorzuheben, dass die oben beschriebenen Konzepte leicht erweitert werden können, indem der Schlüsselprüfblock, entweder der vordere oder der hintere Schlüsselprüfblock, oder eine Kombination von beiden, verwendet wird, um den Sitzungsschlüssel abzuleiten oder den Initialisierungsvektor, der im CBC-Mode zur Verwendung eines Block-Cyphers erforderlich ist.
Es ist anzumerken, dass ein Paketverlust (und dadurch der Verlust des Schlüsselprüfblocks, der zur Prüfung des Sitzungsschlüssels des nächsten Blocks zu verwenden ist) überwunden werden kann. Bezug nehmend auf die in 5 gezeigte Situation, und angenommen, das Paket N + 1 wurde verloren, kann das Sink-Gerät versuchen, KCB_N+2 im Feld 232 des Pakets N + 2 mit beiden möglichen in Frage kommenden Sink-Sitzungsschlüsseln zu entschlüsseln, und das Ergebnis mit der Klartextform von KCB_N+1 502 von Paket N vergleichen. Selbst wenn einer der in Frage kommenden Schlüssel korrekt ist, wird keine Übereinstimmung gefunden, das KCB_N+1 502 nicht hätte verwendet werden sollen (stattdessen hätte der verlorene KCB_N+1 512 verwendet werden sollen). Als nächstes sollte der letzte Datenblock des Pakets N + 2, der den Schlüsselprüfblock fasst, der für das Paket N + 3 zu verwenden ist, mit beiden in Frage kommenden Schlüsseln entschlüsselt werden. Eine der Entschlüsselungen wird den gültigen Bezugsschlüsselprüfblock KCB_N+3 ergeben. Als nächstes wird das Schlüsselprüfblockfeld 232 des Pakets N + 3 mit allen in Frage kommenden Schlüsseln entschlüsselt (wenn der Schlüssel sich zwischen jedem Paket verändern kann, kann der Satz der in Frage kommenden Schlüssel nun drei Schlüssel enthalten). Durch Vergleich der Entschlüsselungsergebnisse mit den zwei in Frage kommenden Klartextformen von KCB_N+3 wird mit hoher Wahrscheinlichkeit nur eine Übereinstimmung gefunden. Diese Übereinstimmung kennzeichnet den Schlüssel, der für das Paket N + 2 zu verwenden ist (nämlich den Schlüssel, der die korrekte Entschlüsselung von KCB_N+3 im Paket N + 3 ergeben hat). Ein Fachmann kann dieses Prinzip leicht ausweiten, um einen Verlust von mehr als einem Paket zu überwinden.
Bevorzugte Ausführungsform
Der Blockcypher ist bevorzugt der Digital Encryption Standard (DES) im Cypher Block Chaining (CBC)-Mode. Um die Data Payloads (Nutzdaten) zu wahren und den Data Payload-Overhead zu minimieren, wird bevorzugt Cipher Text Stealing (CTS) angewandt. Der DES-Algorithmus verwendet eine 8-Byte-Blocklänge. Wann immer die Data-Payload nicht ein Mehrfaches von acht Bytes ist, sind daher Maßnahmen zu ergreifen, um den letzten Datenblock zu verschlüsseln, der weniger als acht Bytes enthält. Eine Alternative ist der Zusatz von Auffüllbytes, damit die Blocklänge wieder acht Bytes beträgt. Doch dies erhöht die Data Payload-Größe, und darüber hinaus muss die Zahl der Aufgefüllbytes zur Entschlüsselungsseite gesendet werden, damit die Auffüllbytes korrekt entfernt werden. Ein besseres Verfahren ist die Verwendung von Cipher Text Stealing. Alle 8-Byte-Blöcke werden sequentiell verschlüsselt, mit Ausnahme des letzten 8-Byte-Blocks und der restlichen Bytes im letzten „unvollständigen" Datenblock. Diese Bytes werden zu einem erweiterten Block verkettet und separat behandelt. Die erweiterte Blocklänge liegt daher zwischen 9 und 15 Bytes. Zuerst werden die letzten acht Bytes im erweiterten Block vor Ort verschlüsselt. Als nächstes werden die ersten acht Bytes im erweiterten Block verschlüsselt. Dies bedeutet, dass einige Bytes zweifach verschlüsselt werden. 6 veranschaulicht die Arbeitsweise des CTS-Verfahrens. Angenommen sei als Beispiel eine Data Payload-Größe von 26 Bytes. Dies ergibt drei 8-Byte-Datenblöcke und einen zusätzlichen 2-Byte-Datenblock. Block 1 und 2 können auf ganz normale Weise verschlüsselt werden. Doch statt als nächstes Bock 3 zu verschlüsseln, werden die letzten acht Bytes der Verkettung von Block 3 und 4 verschlüsselt. Schließlich wird Block 3 verschlüsselt. Es ist anzumerken, dass ein Teil von Block 3 bereits im vorigen Schritt verschlüsselt wurde und im letzten Schritt erneut verschlüsselt wird. Bei der Entschlüsselung wird der Vorgang einfach umgekehrt. Block 1 und 2 werden entschlüsselt. Dann wird Block 3 entschlüsselt, was den ersten Teil ergibt, der voll entschlüsselt ist, und den zweiten Teil, der noch verschlüsselt ist. Schließlich werden die letzten acht Bytes der Gesamt-Data Payload entschlüsselt. Diese Technik lässt die Gesamt-Data Payload unverändert. Doch sie kann nur angewandt werden, wenn die Data Payload-Gesamtgröße größer als acht ist.
Ein anderes geeignetes Cipher Text Stealing-Verfahren wird in „Applied Cryptography" zweite Ausgabe, von Bruce Schneier, auf Seiten 195–196 und in 9.5 beschrieben. Bezug nehmend auf das Beispiel in 6, werden die ersten zwei Klartextblöcke P₁ und P₂ auf konventionelle Weise mit einem Cipher Block Chaining-Mode verschlüsselt. P₂ wird dadurch mit dem Ciphertext C₁ des Verschlüsselungsergebnisses für den ersten Block kombiniert (XOR-verknüpft) und verschlüsselt, was E_k(P₂ ⨁ C₁) = C₂ ergibt. Auch der dritte Block P₂ wird konventionell verschlüsselt, was E_k(P₃ ⨁ C₂) ergibt. Im Beispiel enthält der letzte Klartextblock P₄ nur 2 Bytes. Diese Bytezahl wird vom Anfang des Verschlüsselungsergebnisses genommen und als Ciphertext für Block 4 benutzt. Dies kann ausgedrückt werden als: E_k(P₃ ⨁ C₂) + C₄|C' (wobei „|" eine Verkettung darstellt). C' wird nicht übertragen. Der letzte Block P₄ wird aufgefüllt (in diesem Beispiel werden sechs Bytes hinzugefügt), was durch P₄|PAD ausgedrückt wird (für die Auffüllbits kann ein beliebiger Bitwert verwendet werden). Dies wird auf normale Weise mit dem vorherigen Verschlüsselungsergebnis kombiniert und verschlüsselt, das den dritten Ciphertextblock C₃ = E₄((P₄|PAD) ⨁ (C₄|C')) ergibt. C₃ und C₄ werden übertragen. Im Empfangssystem wird zuerst C₃ entschlüsselt, was (P₄|PAD) ⨁ (C₄|C') ergibt. Als nächstes wird C₄ mit den gleichen PAD-Bits aufgefüllt. Das Ergebnis wird mit dem Entschlüsselungsergebnis XOR-verknüpft, was ergibt: (C₄|PAD) ⨁ ((P₄|PAD) ⨁ (C₄|C')) = (P₄|C'). Dadurch werden Pa und C' erhalten. Als nächstes wird C₄ mit C' aufgefüllt und entschlüsselt, was P₃ ⨁ C₂ ergibt. Wenn dies mit C₂ XOR-verknüpft wird, wird P₃ erhalten.
Das bevorzugte Verfahren basiert auf Schlüsseländerungssignalisierung innerhalb des Bands und ermöglicht daher eine hochpräzise Synchronisierung zwischen dem Host (Source-Gerät) und dem Gerät (Sink-Gerät). Sitzungsschlüsseländerungen sind nur zwischen Paketen zulässig, so dass eine Schlüsseländerung niemals in der Mitte eines Pakets auftreten kann. Ferner vereinbaren der Host und das Gerät denselben Algorithmus zur Berechnung von Sitzungsschlüsseln, so dass, sobald dieser initialisiert wurde, der Host und das Gerät nachfolgende Sitzungsschlüssel selbstständig berechnen können. Ein nächster Sitzungsschlüssel wird berechnet, direkt nachdem der zuvor berechnete Sitzungsschlüssel verbraucht wurde, so dass er für die nächste Sitzungsschlüsseländerung bereit ist.
Der Sender merkt sich die letzten acht Klartextbytes vom vorherigen Paket, Schlüsselprüfblock genannt, und verschlüsselt diesen Block mit dem aktuellen Sitzungsschlüssel. Der Host kann zwischen dem vorigen Paket und dem aktuellen Paket die Änderung des Sitzungsschlüssels entschieden haben. In diesem Fall wird der Schlüsselprüfblock mit einem anderen Sitzungsschlüssel verschlüsselt als dem, der zur Verschlüsselung der letzten acht Bytes vom vorherigen Paket verwendet wurde. Der Schlüsselprüfblock wird als ein Kopfsatz der aktuell verschlüsselten Data Payload an den Empfänger gesendet. Auch der Empfänger merkt sich die letzten acht Bytes des vorherigen Pakets (nach der Entschlüsselung). Wenn er das aktuelle Paket empfängt, entschlüsselt er die ersten acht Bytes (den Schlüsselprüfblock) und vergleicht das Ergebnis mit den gemerkten letzten acht Bytes des vorherigen Pakets. Wenn eine Übereinstimmung vorliegt, hat sich der Sitzungsschlüssel zwischen den Paketen nicht geändert, und die Entschlüsselung kann fortgesetzt werden. Wenn keine Übereinstimmung vorliegt, schaltet der Empfänger auf den nächsten Sitzungsschlüssel um und entschlüsselt den Schlüsselprüfblock erneut. Wenn eine Übereinstimmung vorliegt, ist eine Änderung des Sitzungsschlüssels aufgetreten, und der Empfänger setzt die Entschlüsselung mit diesem neuen Sitzungsschlüssel fort. Wenn keine Übereinstimmung vorliegt, ist ein Fehler aufgetreten, und der Empfänger ergreift eine geeignete Maßnahme. Es ist anzumerken, dass die tatsächliche Data Payload des Pakets wegen des Zusatzes des 8-Byte-Schlüsselprüfblocks immer größer ist als 8 Bytes und das Cipher Text Stealing-Verfahren stets angewandt werden kann. Wenn die tatsächliche Data Payload kleiner ist als acht Bytes (Gesamt-Data Payload kleiner als 16 Bytes), muss der Empfänger wegen CTS das ganze Paket voll entschlüsseln, um den Schlüsselprüfblock wiederzugewinnen. Der Vorteil dieses Verfahrens ist, dass es die Sitzungsschlüssel- Änderungsereignisse in den verschlüsselten Daten verbirgt. Der Schlüsselprüfblock muss entschlüsselt sein, bevor Sitzungsschlüssel-Änderungsereignisse bestimmt werden können.
Das bevorzugte Protokoll weist vier Phasen auf. Die erste Phase ist die Authentifizierungsphase, in der Host und das Gerät sich gegenseitig authentifizieren. Die zweite Phase ist die Schlüsselaustauschphase, in der Zufallszahlen und Schlüsselmaterial erzeugt, verschlüsselt und ausgetauscht werden. Die dritte Phase ist die Schlüsselgenerierungsphase, in der das Schlüsselmaterial verwendet wird, um einen Sitzungsschlüssel zu erzeugen. Nach der Initialisierung kann diese Phase mehrmals ausgeführt werden, um neue Sitzungsschlüssel zu generieren. Die vierte Phase ist die Informationsaustauschphase, wo der Inhalt zwischen dem Host und dem Gerät mit Sitzungsschlüsseln, die in der dritten Phase generiert wurden, sicher ausgetauscht wird. Für eine komplette Implementierung werden die oben definierten Phasen dem in 7 gezeigten Schema entsprechend ausgeführt und wiederholt. Bevor jeder Inhalt ausgetauscht werden kann, leitet das System in Schritt 510 die Phase 1 ein, die Authentifizierungsphase. Eine vertraute Verbindung wird während dieser Phase hergestellt. Sobald dies erfolgt ist, wird in Schritt 520 die zweite Phase eingeleitet, in der Schlüsselmaterial auf sichere Weise ausgetauscht wird. Auch ein Anfangsschlüsselprüfblock (IKCB) wird auf sichere Weise vom Host zum Gerät gesendet. Dieser Block muss sowohl vom Host als auch vom Gerät während der Gesamtdauer der vertrauten Verbindung gemerkt werden.
Bevor in Schritt 530 zum ersten mal die dritte Phase eingeleitet wird, wird in Schritt 540 ein 32-Bit-Zähler C mit einer Zufallszahl initialisiert. Der Host sendet diese Zahl durch eine Anforderung Init_C an das Gerät. Sowohl der Host als auch das Gerät berechnen einen Anfangssitzungsschlüssel (C). Dann wird die Informationsübertragungsphase eingeleitet, und die tatsächliche Datenübertragung beginnt. Gleichzeitig, direkt nach dem Einleiten der Phase 4 in Schritt 550, berechnen der Host und das Gerät in Schritt 560 den nächsten Sitzungsschlüssel (C + 1). Während der Informationsübertragungsphase läuft, kann der Sender die Aktualisierung des aktuellen Sitzungsschlüssels entscheiden. An einem bestimmten Zeitpunkt startet er die Verwendung des Sitzungsschlüssels (C + 1), der zuvor berechnet wurde. Sowohl der Host als auch das Gerät leiten dann wieder die Phase 3 ein, nachdem der Zähler C in Schritt 570 inkrementiert wurde. Dies hat die Generierung eines neuen Sitzungsschlüssels (C + 1) zur Folge, der bereit ist, um bei der nächsten Sitzungsschlüsseländerung verwendet zu werden. Dieser Vorgang wird wiederholt, bis alle Daten übertragen worden sind. Es liegt im alleinigen Ermessen des Senders, zu entscheiden, wann Phase 3 wieder eingeleitet wird, um den Sitzungsschlüssel zu aktualisieren.
Allgemein sind zwei Fälle zu unterscheiden:

– Das Protokoll wird verwendet, um Datenstrominhalt zu schützen. In diesem Fall kann der Sender entscheiden, den Sitzungsschlüssel auf der Basis einen Zeitgeberereignisses zu aktualisieren, das periodisch auftritt und das Sitzungsschlüssel-Änderungsereignis auslöst.
– Das Protokoll wird verwendet, um die Übertragung eines Blocks mit Inhalt zu schützen. Dieser Block kann entweder den Inhalt selbst (eine Datei) oder Schlüssel enthalten, die zum Entschlüsseln des verschlüsselten Inhalts benötigt werden. In diesem Fall kann der Sender die Aktualisierung des Sitzungsschlüssels vor dem Start jeder Blockübertragung entscheiden, wodurch jeder Block mit einem anderen Sitzungsschlüssel verschlüsselt wird.

Der Host- und Geräte-Sitzungsschlüsselgenerierungsvorgang können die Synchronisation verlieren. Insbesondere bei Datenstrom-Inhalten können Pakete verloren gehen oder beschädigt werden, so dass Sitzungsschlüssel-Änderungsereignisse nicht mehr zuverlässig erkannt werden können. Wann immer eine Unterbrechung im Datenstrom auftritt, benachrichtigt der Empfänger den Sender. Dabei stellen sowohl der Host als auch das Gerät fest, dass eine potentielle Störung der Sitzungsschlüsselsynchronisation vorliegt. Der Host resynchronisiert dann den Sitzungsschlüsselgenerierungsvorgang, indem er eine Anforderung Init_C ausgibt. Nach erfolgreichem Abschluss sind sowohl der Host als auch das Gerät wieder synchronisiert und die Informationsübertragungsphase kann fortgesetzt werden.
Es ist anzumerken, dass je nach Anwendung nicht alle Phasen implementiert werden müssen. Zum Beispiel kann es genügen, nur die Authentifizierungsphase zu durchlaufen, um eine vertraute Verbindung zwischen Host und Gerät herzustellen. Jedes Content Security Method (CSM)-Deskriptor enthält ausreichend Information für den Host, um zu bestimmen, welche Phasen er zu durchlaufen hat.
Viele der Funktionen, die oben für das Source- und Sink-Gerät beschrieben wurden, werden normalerweise von einem Prozessor durchgeführt, der mit geeigneter Software geladen wird. Aus Leistungsgründen können bestimmte Funktionen, wie die Verschlüsselung/Entschlüsselung, von dedizierter Hardware ausgeführt werden. Dabei wird gewöhnlich auch Hardware, wie zum Beispiel eine integrierte Kommunikationsschaltung, zur Datenübertragung über das Kommunikationsmedium verwendet. Der Prozessor, wie z.B. ein Prozessor vom PC-Typ, Microcontroller oder DSP-artiger Prozessor, kann mit einem Programm geladen werden, um die erfindungsgemäßen Schritte auszuführen. Das Programm wird gewöhnlich von einem Hintergrundspeicher geladen, wie z.B. einer Festplatte oder einem ROM. Ein Computerprogramm-Produkt kann zum Beispiel verwendet werden, um das Programm anfangs in den Hintergrundspeicher zu speichern. Solch ein Computerprogramm-Produkt kann auf einem Speichermedium wie z.B. einer CD-ROM oder über ein Netz wie das öffentliche Internet verteilt werden.
LEGENDE
1, 3–4

Data Daten

6

26 Bytes Nutzdaten
Dieser Abschnitt wird zweifach verschlüsselt.

Claims

Sicheres Kommunikationssystem (100), umfassend ein Source-Gerät (110, 120) und mindestens ein Sink-Gerät (130, 140), wobei Information vom Source-Gerät zum Sink-Gerät in einer Kommunikationssitzung übertragen wird, umfassend die Übertragung einer Vielzahl von Paketen vom Source-Gerät zum Sink-Gerät; wobei jedes Paket ein Datenfeld einschließt, um einen Teil der Information zu übertragen; wobei das Source-Gerät (110, 120) umfasst: einen Schlüsselgenerator (112), um, auf die Initiative des Source-Geräts hin, einen aktiven Source-Sitzungsschlüssel in einer vorgegebenen Folge von Source-Sitzungsschlüsseln Ksourcei zu generieren; einen Verschlüsseler (116), um mindestens einen Teil des Datenfelds eines Pakets unter der Kontrolle des aktiven Source-Sitzungsschlüssels zu verschlüsseln; wobei der verschlüsselte Teil des Datenfelds ein Subfeld einschließt, das als Schlüsselprüfblockfeld bezeichnet wird; wobei das Sink-Gerät (130, 140) umfasst: einen Schlüsselgenerator (132), um eine Vielzahl von in Frage kommenden Sink-Sitzungsschlüsseln in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i zu generieren, wobei für jeden Index i in der Folge der jeweilige Sink-Sitzungsschlüssel Ksink_i dem jeweiligen Source-Sitzungsschlüssel Ksource_i entspricht; einen Entschlüsseler (134), um mindestens einen Teil des Datenfelds eines empfangenen Pakets unter der Kontrolle eines Sink-Sitzungsschlüssels zu entschlüsseln; einen Schlüssel-Resolver (136), der betreibbar ist, um zu bestimmen, welcher der in Frage kommenden Sink-Sitzungsschlüssel dem Source-Sitzungsschlüssel entspricht, der verwendet wurde, um den verschlüsselten Teil eines empfangenen Pakets zu verschlüsseln, indem er den Entschlüsseler veranlasst, die Daten im Schlüsselprüfblockfeld des empfangenen Pakets unter der Kontrolle jedes mal eines anderen von der Vielzahl der in Frage kommenden Sink-Sitzungsschlüssel zu entschlüsseln, bis ein gültiges Entschlüsselungsergebnis gefunden wird; und den Entschlüsseler veranlasst, einen restlichen verschlüsselten Teil des Datenfelds des Pakets unter der Kontrolle des in Frage kommenden Sink-Sitzungsschlüssels zu entschlüsseln, der das gültige Entschlüsselungsergebnis erzeugt hat.
Sicheres Kommunikationssystem nach Anspruch 1, wobei die Klartextform des Schlüsselprüfblocks im Schlüsselprüfblockfeld ein öffentlicher Datenblock ist.
Sicheres Kommunikationssystem nach Anspruch 1, wobei die Klartextform des Schlüsselprüfblocks im Schlüsselprüfblockfeld ein Datenblock ist, der zwischen dem Source- und Sink-Gerät vereinbart wird, bevor die Übertragung der Information gestartet wird, und für die gesamte Kommunikationssitzung verwendet wird.
Sicheres Kommunikationssystem nach Anspruch 1, wobei die Klartextform des Schlüsselprüfblocks im Schlüsselprüfblockfeld sich während der Kommunikationssitzung mindestens einmal ändert.
Sicheres Kommunikationssystem nach Anspruch 4, wobei das Source- und Sink-Gerät entsprechende Schlüsselprüfblockgeneratoren umfassen, um die Klartextform des Schlüsselprüfblocks zu erzeugen und die Änderung der Klartextform des Schlüsselprüfblocks durchzuführen.
Sicheres Kommunikationssystem nach Anspruch 4, wobei die Klartextform des Schlüsselprüfblocks eines speziellen Pakets von Information abgeleitet wird, die in einem Paket vor dem speziellen Paket übertragen wurde.
Sicheres Kommunikationssystem nach Anspruch 6, wobei die Klartextform des Schlüsselprüfblocks aus der Information abgeleitet wird, die in einem Paket unmittelbar vor diesem bestimmten Paket übertragen wurde.
Sicheres Kommunikationssystem nach Anspruch 6 oder 7, wobei die Klartextform des Schlüsselprüfblocks eines speziellen Pakets identisch ist mit der Klartextform eines bestimmten Datenblocks, der ein anderer ist als der Schlüsselprüfblock, in einem verschlüsselten Teil des Datenfelds eines Pakets vor dem speziellen Paket.
Sink-Gerät (130, 140) zur Verwendung in einem sicheren Kommunikationssystem (100), wobei ein Source-Gerät (110, 120) selbstständig einen Source-Sitzungsschlüssel ändern kann, der zur Verschlüsselung mindestens eines Teils des Datenfelds eines Pakets verwendet wird, der vom Source-Gerät an das Sink-Gerät übertragen wird; wobei der verschlüsselte Teil des Datenfelds ein Subfeld einschließt, das als Schlüsselprüfblockfeld bezeichnet wird; wobei das Sink-Gerät (130, 140) umfasst: einen Schlüsselgenerator (132); um eine Vielzahl von in Frage kommenden Sink-Sitzungsschlüsseln in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i zu generieren, wobei für jeden Index i in der Folge der jeweilige Sink-Sitzungsschlüssel Ksink_i dem jeweiligen Source-Sitzungsschlüssel Ksource_i entspricht; einen Entschlüsseler (134), um mindestens einen Teil des Datenfelds eines empfangenen Pakets unter der Kontrolle eines Sink-Sitzungsschlüssels zu entschlüsseln; einen Schlüssel-Resolver (136), der betreibbar ist, um zu bestimmen, welcher der in Frage kommenden Sink-Sitzungsschlüssel dem Source-Sitzungsschlüssel entspricht, der verwendet wurde, um den verschlüsselten Teil eines empfangenen Pakets zu verschlüsseln, indem er den Entschlüsseler veranlasst, die Daten im Schlüsselprüfblockfeld des empfangenen Pakets unter der Kontrolle jedes mal eines anderen von der Vielzahl der in Frage kommenden Sink-Sitzungsschlüssel zu entschlüsseln, bis ein gültiges Entschlüsselungsergebnis gefunden wird; und den Entschlüsseler veranlasst, einen restlichen verschlüsselten Teil des Datenfelds des Pakets unter der Kontrolle des in Frage kommenden Sink-Sitzungsschlüssels zu entschlüsseln, der das gültige Entschlüsselungsergebnis erzeugt hat.
Verfahren zur sicheren Kommunikation zwischen einem Source-Gerät und mindestens einem Sink-Gerät, wobei Information vom Source-Gerät zum Sink-Gerät in einer Kommunikationssitzung übertragen wird, umfassend die Übertragung einer Vielzahl von Paketen vom Source-Gerät zum Sink-Gerät; wobei jedes Paket ein Datenfeld einschließt, um einen Teil der Information zu übertragen; wobei das Verfahren umfasst: das Generieren, auf die Initiative des Source-Geräts hin, eines aktiven Source-Sitzungsschlüssels in einer vorgegebenen Folge von Source-Sitzungsschlüsseln Ksource_i; das Verschlüsseln mindestens eines Teils des Datenfelds eines Pakets unter der Kontrolle des aktiven Source-Sitzungsschlüssels; wobei der verschlüsselte Teil des Datenfelds ein Subfeld einschliesst, das als Schlüsselprüfblockfeld bezeichnet wird; das Übertragen des Pakets vom Source-Gerät an das Sink-Gerät; das Generieren einer Vielzahl von in Frage kommenden Sink-Sitzungsschlüsseln in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i, wobei für jeden Index i in der Folge der jeweilige Sink-Sitzungsschlüssel Ksink_i dem jeweiligen Source-Sitzungsschlüssel Ksource_i entspricht; das Bestimmen, welcher der in Frage kommenden Sink-Sitzungsschlüssel dem Source-Sitzungsschlüssel entspricht, der benutzt wurde, um den verschlüsselten Teil eines empfangenen Pakets zu verschlüsseln, durch Entschlüsseln der Daten im Schlüsselprüfblockfeld des empfangenen Pakets unter der Kontrolle jedes mal eines anderen von der Vielzahl der in Frage kommenden Sink-Sitzungsschlüssel, bis ein gültiges Entschlüsselungsergebnis gefunden wird; das Entschlüsseln eines restlichen verschlüsselten Teils des Datenfelds des Pakets unter der Kontrolle des in Frage kommenden Sink-Sitzungsschlüssels, der das gültige Entschlüsselungsergebnis erzeugt hat
Verfahren zur Synchronisierung von Sitzungsschlüsseln in einem Sink-Gerät in einem sicheren Kommunikationssystem, das eine Änderung eines Sitzungsschlüssels erkennt, die von einem Source-Gerät im System durchgeführt wurde; wobei Information von einem Source-Gerät zum Sink-Gerät in einer Kommunikationssitzung übertragen wird, umfassend die Übertragung einer Vielzahl von Paketen vom Source-Gerät zum Sink-Gerät; wobei jedes Paket ein Datenfeld einschließt, um einen Teil der Information zu übertragen; mindestens ein Teil des Datenfelds eines Pakets unter der Kontrolle eines aktiven Source-Sitzungsschlüssels in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i verschlüsselt wird; der verschlüsselte Teil des Datenfelds ein Subfeld einschließt, das als Schlüsselprüfblockfeld bezeichnet wird; wobei das Verfahren umfasst: das Generieren einer Vielzahl von in Frage kommenden Sink-Sitzungsschlüsseln in einer vorgegebenen Folge von Sink-Sitzungsschlüsseln Ksink_i, wobei für jeden Index i in der Folge der jeweilige Sink-Sitzungsschlüssel Ksink_i dem jeweiligen Source-Sitzungsschlüssel Ksource_i entspricht; das Bestimmen, welcher der in Frage kommenden Sink-Sitzungsschlüssel dem Source-Sitzungsschlüssel entspricht, der benutzt wurde, um den verschlüsselten Teil eines empfangenen Pakets zu verschlüsseln, durch Entschlüsseln der Daten im Schlüsselprüfblockfeld des empfangenen Pakets unter der Kontrolle jedes mal eines anderen von der Vielzahl der in Frage kommenden Sink-Sitzungsschlüssel, bis ein gültiges Entschlüsselungsergebnis gefunden wird; und das Entschlüsseln eines restlichen verschlüsselten Teils des Datenfelds des Pakets unter der Kontrolle des in Frage kommenden Sink-Sitzungsschlüssels, der das gültige Entschlüsselungsergebnis erzeugt hat.
Computerprogramm-Produkt, umfassend ein auf einem Datenträger gespeichertes Programm, das, wenn es in einen Universalcomputer geladen wird, diesen veranlasst, alle Schritte des Verfahrens nach Anspruch 11 auszuführen.