-
TECHNISCHER
ANWENDUNGSBEREICH
-
Die
vorliegende Erfindung bezieht sich auf eine Kommunikationsvorrichtung
und ein Verfahren, die durch Verschlüsselung und Authentifizierung
der Übertragungsdaten
Datensicherheit gegen Abhören und
Verfälschung
gewährleisten.
-
STAND DER
TECHNIK
-
IP-(Internet
Protokoll)-Netzwerke, wofür
das Internet ein typisches Beispiel ist, sind nicht schon an sich
mit Sicherheitsmerkmalen ausgestattet. Wenn keine Vorsichtsmaßnahmen
ergriffen werden, wäre es
möglich,
den Inhalt der Kommunikation durch die Beschaffung oder Veränderung
des IP-Paketes während
der Übertragung
abzuhören
und zu verändern, ohne
dass die an der Kommunikation beteiligten Parteien davon Notiz nehmen.
Deshalb ist der Sicherheitsschutz entscheidend für die Übertragung und den Empfang
von wichtiger Information über
geschäftliche
Transaktionen oder Ähnliches
im IP-Netzwerk.
-
Beispielsweise
stellen bei Inhaltanbieter-Dienstleistern, die Musik oder Videos über das
Internet anbieten, die zu liefernden Musik- und Videodaten wertvolle
und wichtige Information dar und müssen gegen Mithören und
Verfälschung
während der Übertragung
geschützt
werden. Und im VoIP-System, das Telefondienste über das IP-Netzwerk anbietet,
ist es notwendig, illegalem Abhören des
Inhalts der Kommunikation vorzubeugen.
-
Im
VoIP-System und in einem Inhaltlieferungssystem, das über Streaming
arbeitet, wird für die
geforderte Übertragung
von Daten in Echtzeit gewöhnlich
das in 1A gezeigte RTP/UDP benutzt. RTP
(Real Time Transport Protokoll) ist ein Protokoll, das in einer
Anwendungsschicht 11 benutzt wird und das für Echtzeitverarbeitung
verwendbar ist. UDP (User Datagram Protocol) ist ein verbindungsloses Protokoll,
das in einer Transportschicht 12 benutzt wird, die eine
Schnittstelle, zwischen der Anwendungsschicht 11 und einer
Netzwerkschicht 13 ist.
-
Wie
in 2 gezeigt, beinhaltet ein diesem System entsprechendes
Datenpaket beispielsweise einen IP-Header 13H, einen UDP-Header 12H,
einen RTP-Header 11H und eine RTP-Nutzinformation 11PL.
Da RTP/UDP eher für
Echtzeit-Paketübertragung
als für
die Absicherung der Paketübertragung wie
TCP (Transmission Control Protocol, ein Verbindungsprotokoll, das
in der Transportschicht benutzt wird) vorgesehen ist, besteht die
Möglichkeit,
dass ein Paketverlust während
der Übertragung
vorkommt. Aus diesem Grund sollten für den Fall der Untersuchung
des Sicherheitsschemas zur Anwendung auf RTP/UDP Maßnahmen
gegen den Paketverlust in Betracht gezogen werden.
-
Weiterhin
ist es ebenso wichtig, Sicherheitstechniken auf die sich nun schnell
verbreitende mobile Kommunikation anzuwenden. Für RTP/UDP Paketübertragung
in einem mobilen Kommunikations-Netzwerk,
werden die Header sowohl des RTP-Paketes (RTP Neader + RTP Nutzinformation) als
auch des UDP-Paketes (UDP Header + RTP-Paket) in einem Funkübertragungsweg
mit Hinblick auf eine effizientere Nutzung des Funkübentragungsbandes
komprimiert. Entsprechend ist es wünschenswert, dass das Sicherheitsschema,
speziell das Verschlüsselungssystem,
Header-Expandierung/-Komprimierung des RTP/UDP-Paketes in Verbindungen
auf halbem Weg der Übertragung
erlaubt.
-
Als
ein sicheres RTP-Paketübertragungssystem
zur Anwendung in mobilen Kommunikationsnetzwerken wurde von der
IETF (Internet Engineering Task Force) Secure RTP (SRTP, siehe: draft-ietf-avt-srtp-00.txt) vorgeschlagen.
In SRTP wurden ein selektives Verschlüsselungssystem, das eine Header-Komprimierung erlaubt
und ein Verschlüsselungssystem,
das den Einfluss des Paketverlusts oder eines Bit-Fehlers verringert,
eingeführt. D.
h., das RTP-Paket wird, wie in 3 dargestellt, nur
durch Verschlüsselung
der Nutzinformation 11PL und durch Generierung und Hinzufügung eines
Daten-Authentifizierungscodes
(Authentifizierer) 11A zur verschlüsselten RTP-Nutzinformation 11PL und dem
RTP-Header 11H verarbeitet, so dass die Gültigkeit
der Daten des RTP-Headers 11H und der verschlüsselten
RTP-Nutzinformation 11 PL verifiziert werden kann. Diese
Technik erlaubt einen effizienten, jedoch RTP-spezifischen Schutz.
-
Das
bedeutet, dass Secure RTP die Benutzung eines RTP-spezifischen Verschlüsselungsalgorithmus
und RTP-spezifischer Verschlüsselungsparameter
notwendig macht, wodurch es nicht für Anwendungen und Transportprotokolle
in anderen UDP-Systemen benutzt werden kann. Da sein selektiver
Verschlüsselungsparameter
und Verschlüsselungsalgorithmus
fest sind, kann Secure RTP nicht mit neuen Protokollen umgehen und
ist deshalb nicht für
die Inhaltslieferung geeignet, die schnelle Fortschritte macht.
Eine auf eine bestimmte Anwendung spezialisierte Sicherheitstechnik
ist, wie oben erwähnt,
nicht vorzuziehen, da es notwendig ist, sich jedes Mal, wenn eine
neue Anwendung entwickelt wird, mit einer individuellen Sicherheitstechnik
zu befassen. Weiterhin hat Secure RTP, obwohl die Sicherheitstechnik
nicht starr ist, seinen festen Verschlüsselungsalgorithmus, so dass
ein Sicherheitsproblem auftaucht.
-
Andererseits
wird SSL (Secure Socket Layer) im Internet inzwischen weithin als
Sicherheitstechnik benutzt. Wie in 4A gezeigt,
sind Anwendungen im Schicht 11 wie HTTP (Hypertext Transfer Protokol),
FTP (File Transfer Protokol) und Telnet (remote log-in) direkt mit
einer TCP- oder UDP-Transportschicht 12 verbunden,
wenn SSL (TSL) nicht benutzt wird. Wie in 4B gezeigt,
ist SSL im Gegensatz dazu ein Sicherheitsprotokoll, das zwischen
der TCP- oder UDP-Schicht 12 und der Anwendungsschicht 11 liegt.
SSL stellt durch die Durchführung
einiger Sicherheitsverarbeitungen der Daten, die durch Benutzung
der von TCP oder UDP angebotenen Datenübertragungsfunktion gesendet
und empfangen werden, einen sicheren Datenübertragungsdienst für die Anwendungsschicht
zur Verfügung.
Deshalb gibt es keine Begrenzung für die benutzte Anwendung und
den benutzten Verschlüsselungsalgorithmus. SSL
wird speziell für
eine HTTP-Sitzung in einem Web-Zugriff weithin benutzt, jedoch kann
es vielseitig für
andere Anwendungen von FTP und Telnet benutzt werden.
-
Darüber hinaus
wird als eine modifizierte Version von SSL ein im WAP (Wireless
Application Protocol)-Forum
standardisiertes WTLS (Wireless Transport Level Security) zur Benutzung
in der mobilen Kommunikation vorgeschlagen.
-
Wie
in 5 dargestellt, besitzen SSL und WTLS einen Zwei-Schichten-Aufbau.
Das Protokoll, das in der unteren Schicht 11S2 des Zwei-Schichten-Aufbaus
benutzt wird, wird Aufzeichnungs- oder Satz-Protokoll genannt, und es bietet Möglichkeiten zur
Verschlüsselung
von Protokolldaten der oberen Schicht 11S1 und zum Hinzufügen eines
Daten-Authentifizierungscodes (MAC). Die obere Schicht 11S1 im
Zwei-Schichtenaufbau von SSL enthält vier Arten von Protokollen,
ein Handshake-Protokoll HSP (Handshake Protocol), ein Alarm-Protokoll
ALP (Alert Protocol), ein Schlüssel-Änderungs-Protokoll CCP (Change
Cipher Protocol) und ein Anwendungsdaten-Protokoll ADP (Application
Data Protocol). Das Handshake-Protokoll HSP bietet die Möglichkeit
eines Verschlüsselungs-/Daten-Authentifizierungs-Schemas
und einer Terminal-/Server-Authentifizierung; das Alarm-Protokoll
ALP die Möglichkeit der
Anzeige von Ereignissen und Fehlern; und das Schlüssel-Änderungs-Protokoll
CCP bietet die Möglichkeit,
ein ausgehandeltes Verschlüsselungs-/Authentifizierungs-Schema
zu bestätigen.
Das Anwendungsdaten-Protokoll zur Anzeige des Beginns der verschlüsselten
Kommunikation für
die andere Partei soll Anwendungsdaten der oberen Schicht transparent
senden; HTTP- oder FTP-Daten
in der Anwendungsschicht 11 werden über dieses Protokoll dem Satz-Protokoll
(Record Protocol) 11S2 zur Verfügung gestellt.
-
6 zeigt
ein Beispiel des Datenaufbaus, der zwischen Satz-Protokollen der
sendenden und der empfangenden Seite gesendet und empfangen wird.
In einem Header 20H sind ein die Arten der Protokolle der
oberen Schicht (wie Handshake, Alarm und Anwendungsdaten) anzeigender
Bezeichner (Protokoll-Typ), eine SSL-Version (Große Version, Kleine
Version) 22 und die Datenlänge (Länge (hoch), Länge (niedrig)) 23A und 23B enthalten.
Eine Nutzinformation 24 sind verschlüsselte Daten der oberen Protokollschicht;
die verschlüsselten
Daten 24 enthalten einen Dateninhalt (Content) 24A und
einen Authentifizierer MAC 24B zur Verifizierung der Gültigkeit
des Dateninhalts und des Headers. Dieser Aufbau wird auf alle Protokolle
angewendet, die das Satz-Protokoll 11S2 benutzen, einschließlich des
Anwendungsdaten-Protokolls. Entsprechend sind im Falle der Übertragung
des RTP-Paketes durch Benutzung von SSL der Header und die Nutzinformation in
ihrer Gesamtheit verschlüsselt
und in die Nutzinformation 24 der Satz-Protokoll-Daten
abgebildet.
-
Wenn
der Header des Satz-Protokolls zu solch einer verschlüsselten
Version des ganzen RTP-Paketes oder des RTP-Paketes hinzugefügt wird,
ist es unmöglich,
eine RTP-Header-Kompression während
der Übertragung
durchzuführen.
Das bedeutet, dass, wenn ein Satz-Protokoll-Header 20H zwischen
den RTP-Header und den UDP-Header eingefügt wird, sie nicht gemeinsam
komprimiert werden können,
da die Header-Komprimierung für
den RTP-Header, den UDP-Header und den IP-Header, die einer nach
dem anderen angeordnet sind, gemeinsam durchgeführt wird. Aus diesem Grund
ist die Anwendung von SSL/WTSL auf den RTP-Paketschutz in der mobilen
Kommunikation nicht wünschenswert.
-
Das
Dokument WO 00/31964 offenbart ein Verfahren zur Verschlüsselung
von Bilddaten, wobei eine hochaufgelöste Bilddatei in unabhängig kodierbare
Teile unterteilt wird. In einem Beispiel gibt es einen ersten, einen
zweiten und einen dritten Teil. Der erste Teil ist ohne Verschlüsselung
kodiert und könnte
durch jedermann dekodiert werden. Das Ergebnis ist eine niedrig
aufgelöste
Kopie des originalen, hochaufgelösten
Bildes. Der zweite Teil ist kodiert und verschlüsselt und kann nur durch diejenigen,
die den passenden Schlüssel
zur Entschlüsselung
besitzen, wiederhergestellt werden. Dasselbe gilt für den dritten
Teil, wo sich der Schlüssel
von dem des zweiten Teils unterscheiden kann. Die kombinierten entschlüsselten
Versionen des ersten und des zweiten Teils ergeben eine Kopie des
originalen, hochaufgelösten
Bildes mit mittlerer Auflösung.
Die kombinierten entschlüsselten
Versionen aller drei Teile ergeben das originale, hochaufgelöste Bild.
Diese verschiedenen Teile sollten in Abhängigkeit von einer Anfrage
eines Empfängers
getrennt von einem Server zu dem Empfänger übertragen werden; daher sind,
wenn der erste Teil übertragen
wird, keine Übertragungsdaten
gesichert, jedoch sind bei der Übertragung
des zweiten und des dritten Teils alle Übertragungsdaten gesichert.
-
Auch
in der gewöhnlichen
Datenübertragung könnte es
günstig
sein, wenn nur ein bestimmter, zu schützender Teil durch Verschlüsselung
oder Authentifizierung zur Überprüfung seiner
Gültigkeit
gesichert werden könnte,
jedoch war es bisher schwierig, Sicherheit in angepasster Weise
zur Verfügung zu
stellen.
-
Ein
Ziel der vorliegenden Erfindung ist es, eine Daten sichernde Kommunikationsvorrichtung und
ein Datensicherungsverfahren zur Verfügung zu stellen, die eine Kommunikation
erlauben, bei der nur ein Teil der Eingangsdaten selektiv gesichert
ist.
-
OFFENBARUNG
DER ERFINDUNG
-
Dieses
Ziel wird erreicht durch eine für
das Senden geeignete Daten sichernde Kommunikationsvorrichtung,
wie in Anspruch 1 beansprucht, eine Daten sichernde Kommunikationsvorrichtung
für den Empfang,
wie in Anspruch 8 beansprucht, und ein Verfahren, wie in Anspruch
9 beansprucht. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand
der abhängigen
Ansprüche.
-
Gemäß vorliegenden
Erfindung nutzt die Kommunikationsvorrichtung auf der Sendeseite
Parameter, welche einen Teil der Eingangsdaten bezeichnen, gemeinsam
mit einer Daten sichernden Kommunikationsvorrichtung auf der Empfangsseite über einen
Kommunikationskanal und sichert gemäß der gemeinsam genutzten Parameter
selektiv diesen Teil der Eingangsdaten, wonach die Daten ausgegeben
werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1A ist
ein Schaubild, das eine Verarbeitung ohne Benutzung von Secure RTP
zeigt.
-
1B ist
ein Schaubild, das eine Verarbeitung unter Benutzung von Secure
RTP zeigt.
-
2 ist
ein Schaubild, das ein Beispiel des Paketaufbaus darstellt.
-
3 ist
ein Schaubild, das den Datenaufbau eines selektiv verschlüsselten
Paketes darstellt.
-
4A ist
ein Schaubild, das eine Anwendungsdatenverarbeitung, die kein SSL/WTLS
benutzt, zeigt.
-
4B ist
ein Schaubild, das eine Anwendungsdatenverarbeitung, die SSL/WTLS
benutzt, zeigt.
-
5 ist
ein Schaubild, das Einzelheiten der SSL/WTLS-Schicht zeigt.
-
6 ist
ein Schaubild, das den Aufbau der Satz-Protokoll-Datenverarbeitung
durch SSL/WTLS zeigt.
-
7 ist
ein Schaubild, das den funktionellen Aufbau einer Ausgestaltung
der erfindungsgemäßen Vorrichtung
und ein Beispiel des Systemaufbaus, in dem diese erfindungsgemäße Vorrichtung benutzt
wird, darstellt.
-
8 ist
ein Schaubild, das Beispiele von Verschlüsselungsparametern zeigt.
-
9 ist
ein Flussdiagramm, das ein Beispiel einer Arbeitsweise zur gemeinsamen
Nutzung eines Verschlüsselungsbereichs
auf der Sendeseite zeigt.
-
10 ist
ein Flussdiagramm, das ein Beispiel einer Arbeitsweise zur gemeinsamen
Nutzung eines Verschlüsselungsbereichs
auf der Empfangsseite zeigt.
-
11 ist
ein Flussdiagramm, das ein Beispiel der Arbeitsweise eines Verschlüsselung/Authentifizierer
hinzufügenden
Teils 33 in 7 zeigt.
-
12 ist
ein Schaubild, das ein Beispiel des Datenaufbaus des vom Verschlüsselung/Authentifizierer
hinzufügenden
Teil 33 ausgegebenen Paketes zeigt.
-
13 Ist
ein Flussdiagramm, das ein anderes Beispiel der Arbeitsweise des
Verschlüsselung/Authentifzierer
hinzufügenden
Teils 33 zeigt.
-
14 ist
ein Flussdiagramm, das ein Beispiel der Arbeitsweise der erfindungsgemäßen Verfahrens
zeigt.
-
15 ist
ein Schaubild, das den funktionellen Aufbau einer zweiten Ausgestaltung
der erfindungsgemäßen Vorrichtung
zeigt.
-
16 ist
ein Schaubild, das den funktionellen Aufbau einer dritten Ausgestaltung
der erfindungsgemäßen Vorrichtung
zeigt.
-
DIE BESTE ART, DIESE ERFINDUNG
AUSZUFÜHREN
-
Erste Ausgestaltung
-
7 stellt
eine erste Ausgestaltung der vorliegenden Erfindung und das generelle
Konzept eines Datenübertragungssystems,
das diese Ausgestaltung benutzt, dar.
-
Beispielsweise
können
eine Daten sichernde Kommunikationsvorrichtung 30 der vorliegenden
Erfindung an einer Sendeseite, wie etwa ein Server oder ein Datenterminal,
und eine entsprechende Daten sichernde Kommunikationsvorrichtung 40 der vorliegenden
Erfindung an einer Empfangsseite, wie etwa ein Server oder ein Datenterminal, über ein Kommunikationsnetzwerk 50 verbunden
sein. Das Kommunikationsnetzwerk 50 ist als ein Netzwerk
gezeigt, jedoch kann es ebenso aus einer Mehrzahl von Netzwerken,
etwa einer Kombination eines öffentlichen
Kommunikationsnetzwerkes und des Internets, bestehen.
-
Die
Daten sichernde Kommunikationsvorrichtung 30 in dieser
Ausgestaltung hat als Sicherungsmittel ein Verschlüsselungs-/Authentifiziererhinzufügungsteil 33 zwischen
einem Anwendungsteil 31 und einem Transportteil 32.
Das Transportteil 32 hat eine TCP- oder UDP-Funktion und
ist beispielsweise mit einem mit einer IP-Funktion ausgestatteten Netzwerkteil 35 verbunden,
und das Netzwerkteil 35 ist mit einem Sende-/Empfangsteil 36,
das eine physikalische Schicht ist, verbunden, und das Sende-/Empfangsteil 36 ist
mit dem Kommunikationsnetzwerk 50 verbunden.
-
Die
Daten sichernde Kommunikationsvorrichtung 40 ist im Aufbau
im Wesentlichen identisch mit der Daten sichernden Kommunikationsvorrichtung 30;
das bedeutet, dass sie mit einem Anwendungsteil 41, einem
Transportteil 42, einem Netzwerkteil 45 und einem
Sende-/Empfangsteil 46 ausgestattet ist und dass in dieser
Ausgestaltung ein Dekodierungs-/Verifizierungsteil 43 als
Sicherungsmittel zur Verfügung
steht und ein Parametergemeinsamnutzungsteil 44 als eine
obere Schicht des Transport-Teils 42 zur
Verfügung
steht.
-
Vor
der Übertragung
der Anwendungsdaten vom Anwendungsteil 31 verhandelt die
Kommunikationsvorrichtung 30 mit der Gegenvorrichtung 40 über für die Datensicherheit
notwendige Parameter, d. h. über
die Parameter, die für
den Verschlüsselungsvorgang/Daten-Authentifizierungs(Code)-Generierungsvorgang
notwendig sind, und nutzt diese Parameter gemeinsam mit der Gegenvorrichtung 40. Diese
Parameter sind: Information zur Festlegung, welcher der Algorithmen
Null, DES, 3DES, RC4, usw. benutzt wird; geheime Information zur
Schlüsselgenerierung;
Zufallswerte zur Verschlüsselung/Entschlüsselung
oder Authentifizierung/Verifizierung in der Kommunikationsvorrichtung 30 (beispielsweise eine
Servervorrichtung) und in der Kommunikationsvorrichtung 40 (beispielsweise
eine Client-Vorrichtung); der Bereich, über den Übertragungsdaten zu verschlüsseln sind;
und der Bereich der Daten-Authentifizierung.
-
In
dieser Ausgestaltung ist es insbesondere wichtig, dass die Parameter
zur Festlegung des Verschlüsselungsbereichs
und des Bereichs der Daten-Authentifizierung neu als gemeinsame
Parameter zur Verfügung
gestellt werden und die anderen gemeinsamen Parameter werden auf
die gleiche Weise gemeinsam genutzt, wie das für gemeinsam genutzte Parameter
in Sicherungsprotokollen nach dem herkömmlichen SSL- (TSL-) Schema
der Fall ist; die gemeinsame Nutzung dieser Parameter erfolgt, wie
im Falle des herkömmlichen
SSL-Schemas, durch Kommunikation zwischen den Kommunikationsvorrichtungen 30 und 40 über den
Kommunikationskanal.
-
In
diesem Fall enthalten die neuen gemeinsamen Parameter, welche das
Sicherungsziel der zu übertragenden
Daten angeben – in
diesem Beispiel den Bereich der Verschlüsselung und den Bereich der
Daten-Authentifizierung – Information
zur Bestimmung des Bereichs, über
den das Eingangsdaten-Paket
(in diesem Beispiel das Datenpaket des Anwendungsteils 31)
verschlüsselt
und authentifiziert wird, und zur Festlegung des Bereichs sind verschiedene
Verfahren möglich;
zum Beispiel wird die Information „Beginne die Verschlüsselung
bei dem und dem Byte vom Anfang des Paketes aus" zur Festlegung des Bereichs benutzt.
-
Weiterhin
werden der Bereich der Verschlüsselung
und der Bereich der Daten-Authentifizierung entsprechend der Art
der Eingangsdaten, d. h. in diesem Beispiel entsprechend der Anwendung,
bestimmt oder entsprechend der Übertragungscharakteristiken
(wie die Übertragungsrate,
die Verzögerungscharakteristik,
die Übertragungsfehlercharakteristik,
die Dämpfungscharakteristik,
die Frequenzcharakteristik und die Verzerrungscharakteristik) des Kommunikationsnetzwerkes 50,
mit dem die Kommunikationsvorrichtung 30 verbunden ist.
-
Das
Parametergemeinsamnutzungsteil 34 der Kommunikationsvorrichtung 30 bestimmt
die gemeinsame Nutzung der das Sicherungsziel anzeigenden Parameter,
beispielsweise durch das in 9 gezeigte
Verfahren. Beim Empfang einer Aufforderung zur verschlüsselten
Kommunikation (S1) prüft
das Parametergemeinsamnutzungsteil, ob das Eingangs-Anwendungsdatenpaket
ein RTP-Paket (S2) ist; wenn es ein RTP-Paket ist, prüft es, ob
das Kommunikationsnetzwerk 50, mit dem die Vorrichtung 30 verbunden
ist, ein Netzwerk mit niedriger Übertragungsrate,
beispielsweise ein mobiles Kommunikationsnetzwerk (S3), ist; und
wenn es ein mobiles Kommunikationsnetzwerk ist, überträgt es zur anderen Kommunikationsvorrichtung 40 Verschlüsselungs-/Authentifizierungs-Parameter,
die eine selektive Verschlüsselung
des RTP-Pakets anzeigen (beispielsweise anzeigen, dass der RTP-Header
zu Beginn der Eingangsdaten von der Verschlüsselung ausgenommen ist)(S4).
Zu diesem Zeitpunkt werden ebenso andere Parameter, wie Verschlüsselungs-Algorithmus
und der Daten-Authentifizierer generierende Algorithmus gesendet.
-
Wie
beispielsweise in 10 gezeigt, prüft andererseits
das Parametergemeinsamnutzungsteil 44 der Kommunikationsvorrichtung 40 beim
Empfang der Verschlüsselungs-/Authentifizierungs-Parameter von
der Kommunikationsvorrichtung 30 (S1), ob die empfangenen
Verschlüsselungs-/Authentifizierungs-Parameter diejenigen
zur selektiven Verschlüsselung
des RTP-Pakets (S2) sind; wenn ja, bestimmt es, dass die Verschlüsselungs-/Authentifizierungs-Parameter
im Parametergemeinsamnutzungsteil 44 diejenigen zur selektiven
Verschlüsselung
des RTP-Pakets sind; und sendet die bestimmten Verschlüsselungs-/Authentifizierungs-Parameter
zur Kommunikationsvorrichtung 30 (S4).
-
Wenn
das Parametergemeinsamnutzungsteil 34 der Kommunikationsvorrichtung 30 von
der Kommunikationsvorrichtung 40 die Verschlüsselungs-/Authentifizierungs-Parameter
empfängt,
welche die selektive Verschlüsselung
des RTP-Pakets angeben, wie in 9 gezeigt,
(S5), bestimmt sie die Verschlüsselungs-/Authentifizierungs-Parameter
als das Ziel der selektiven Verschlüsselung des RTP-Pakets (S6). Auf
diesem Weg nutzen die beiden Parametergemeinsamnutzungsteile 34 und 44 gemeinsam
die selektive RTP-Verschlüsselung
als die Verschlüsselungs-/Authentifizierungs-Parameter über den
Kommunikationskanal. Auf die gleiche Weise werden zur selben Zeit
der Verschlüsselungsalgorithmus
und andere Parameter bestimmt. In diesem Beispiel, werden, wie beispielsweise
im Falle des herkömmlichen
SSL, mehrere Kandidaten für
jeden Parameter zur Vorrichtung 40 zur Bestimmung gesendet.
-
Wenn
in 9 in Schritt S2 entschieden wird, dass die Eingangsdaten
kein RTP-Paket sind, oder wenn in Schritt S3 entschieden wird, dass
die Übertragungsrate
des Kommunikationsnetzwerks 50, mit dem die Kommunikationsvorrichtung 30 verbunden
ist, hoch ist, sendet die Kommunikationsvorrichtung zum Gegenüber 40 Verschlüsselungs-/Authentifizierungs-Parameter,
welche die Verschlüsselung
der gesamten Eingangsdaten (Paket), d. h. eine nicht-selektive Verschlüsselung,
anzeigen (S7).
-
Wenn,
wie in 10 dargestellt, in Schritt S2 entschieden
wird, dass die Verschlüsselungs-/Authentifizierungs-Parameter
Parameter nicht zur selektiven RTP-Paket-Verschlüsselung sind, entscheidet das
Parametergemeinsamnutzungsteil 44 der Kommunikationsvorrichtung 40,
ob die Eingangsdaten (Anwendung) vom Anwendungsteil 41 der
Kommunikationsvorrichtung 40 ein RTP-Paket sind (S5); wenn sie ein RTP-Paket
sind, prüft
sie, ob das Kommunikationsnetzwerk 50, mit dem die Kommunikationsvorrichtung 40 verbunden
ist, beispielsweise ein mobiles Kommunikationsnetzwerk mit niedriger Übertragungsrate
ist (S6); wenn ja, geht sie zu Schritt S3, in dem sie die Verschlüsselungs-/Authentifizierungs-Parameter
festlegt, welche die selektive Paketverschlüsselung anzeigen, und sendet
sie zur Kommunikationsvorrichtung 30 (S4). Wenn in Schritt S5
entschieden wird, dass die Eingangsdaten kein RTP-Paket sind, oder
wenn in Schritt S6 entschieden wird, dass das Kommunikationsnetzwerk 50 kein
mobiles Kommunikationsnetzwerk mit niedriger Übertragungsrate ist, legt das
Parametergemeinsamnutzungsteil Verschlüsselungs-/Authentifizierungs-Parameter
fest, die eine nicht-selektive
Verschlüsselung anzeigen
(S7), und sendet die Parameter zur Kommunikationsvorrichtung 30 (S4).
-
Wie
in 9 dargestellt, prüft das Parametergemeinsamnutzungsteil 34 der
Kommunikationsvorrichtung 30 nach der Übertragung in Schritt S7, beim
Empfang der Verschlüsselungs-/
Authentifizierungs-Parameter
von der Kommunikationsvorrichtung 40 (S8), ob die Verschlüsselungs-/
Authentifizierungs-Parameter
diejenigen für
die selektive RTP-Paket-Verschlüsselung
sind (S9); wenn ja, geht sie zu Schritt S6, in dem das Parametergemeinsamnutzungsteil
als Verschlüsselungs-/Authentifizierungs-Parameter diejenigen
für die
selektive RTP-Paket-Verschlüsselung,
und wenn nicht für
die selektive RTP-Paket-Verschlüsselung,
dann als Verschlüsselungs-/Authentifizierungs-Parameter
diejenigen für
die nicht-selektive Verschlüsselung
(S10) festlegt.
-
Auf
diesem Weg können
die Parametergemeinsamnutzungsteile 34 und 44 den
Bereich der Verschlüsselung über den
Kommunikationskanal vereinheitlichen. Die gesamten Eingangsdaten
werden ungeachtet der Eingangsdaten (Anwendung) und unabhängig von
der Übertragungscharakteristik des
Kommunikationsnetzwerks 50, mit dem die Kommunikationsvorrichtungen 30 und 40 verbunden
sind, als der Bereich der Authentifizierung gesetzt. Der Bereich
der Verschlüsselung
kann nicht nur insoweit spezifiziert werden, dass der Header ausgeschlossen
wird, sondern nach Wunsch. Wenn beispielsweise die Eingangsdaten
Bild- oder Audio-Daten sind, ist es genauso möglich, den Bereich der Verschlüsselung
speziell auf einen begrenzten Bereich zu beschränken, dessen Verlust eine Dekodierung
unmöglich
machen würde.
In jedem Fall werden der Verschlüsselungsalgorithmus
und andere Parameter gleichzeitig mit dem Bereich der Verschlüsselung dem
Vereinheitlichungsprozess unterzogen.
-
Wenn
die Parameter wie oben beschrieben vereinheitlicht sind, werden
sie vom Parametervereinheitlichungsteil 34 bzw. 44 dem
Verschlüsselungs-/Authentifiziererhinzufügungsteil 33 und
dem Dekodierungs-/Verifizierungsteil 43 zur Verfügung gestellt.
-
Das
Verschlüsselungs-/Authentifiziererhinzufügungsteil 33 führt die
Verschlüsselung-/Authentifizierer-Hinzufügung durch.
In 11 wird ein Beispiel für hierfür gezeigt. Nach Einspeisung
durch das obere Anwendungsteil 31 (S1) wird ein Datenpaket transparent
durch ein Anwendungsdaten-Protokoll in das Verschlüsselung-/Authentifiziererhinzufügungsteil 33 eingespeist
(S2) und unter Benutzung des dem Authentifizierungsbereichs-Parameter
entsprechend selektierten Teils des Datenpakets durch einen gemeinsamen
Authentifizierer-Generator-Algorithmus/Authentifizierer-Generator-Schlüssel ein
Authentifizierer generiert (S3). Das den Authentifizierer generierende
Verfahren wird beispielsweise in IMAI Hideki, "Lecture on Cryptography", Abschnitt 4.7 im Detail
beschrieben. Der Authentifizierer wird zum Beispiel durch Kompression
der Authentifikationsbereichs-Daten durch eine Hash-Funktion und
Verschlüsselung
der komprimierten Daten durch den gemeinsamen Schlüssel generiert.
Der Authentifizierer wird dem Eingangsdatenpaket hinzugefügt (S4),
und der Teil des mit dem Authentifizierer versehenen Datenpakets,
der laut Verschlüsselungsbereichs-Parameter
selektiert ist, wird unter Benutzung des gemeinsamen Verschlüsselungs-Algorithmus
und Verschlüsselungs-Schlüssels verschlüsselt (S5).
Im Fall der Block-Verschlüsselung
wird in Erwartung des Mangels an Daten für die feste Blocklänge ein
Auffüllen
(Padding) vor der Verschlüsselung
ausgeführt (S6).
-
In 12 wird
ein Beispiel des Aufbaus von solchermaßen verschlüsselten Daten gezeigt. In diesem
Beispiel wird der Authentifizierer MAC zu den Eingangs-Anwendungsdaten 11D hinzugefügt und der
Teil (Nutzinformation) der Anwendungsdaten, mit Ausnahme des Headers 11DH,
und der Authentifizierer MAC werden verschlüsselt. Die selektiv verschlüsselten
Daten werden dem unteren Transportteil 32 zur Verfügung gestellt,
von wo sie zur anderen Kommunikationsvorrichtung 40 gesendet
werden.
-
Die
Kommunikationsvorrichtung 40 der Empfangsseite dekodiert,
dem zum oben beschrieben umgekehrten Verfahren folgend, die verschlüsselten Daten,
und unter Benutzung des Daten-Authentifierers (Code) wird die Gültigkeit
der Empfangsdaten verifiziert. Das bedeutet, dass in der Kommunikationsvorrichtung 40 in 7 das
von der Kommunikationsvorrichtung 30 empfangene Paket vom
Transportteil 42 in das Dekodierungs-/Verifizierungs-Teil 43 eingespeist
wird und das Dekodierungs-/Verifizierungs-Teil 43 den verschlüsselten
Teil entsprechend dem gemeinsamen Verschlüsselungs-Algorithmus, Verschlüsselungs-Schlüssel und
Verschlüsselungs-Bereich
dekodiert, und der Daten-Authentifizierer
(Code) MAC in den dekodierten Daten wird benutzt, um die Gültigkeit
des Headers und der dekodierten Nutzinformation, d.h. der Anwendungsdaten in 12,
zu bestätigen.
Wenn gültig,
werden die Anwendungsdaten dem Anwendungsteil 41 geliefert.
-
Durch
gemeinsame Nutzung/Vereinheitlichung des Verschlüsselungsbereichs ist es möglich, Teile
der Eingangsdaten selektiv zu verschlüsseln; beispielsweise macht
die Verschlüsselung
nur des Teils der Eingangsdaten, deren Sicherheit zur Debatte steht,
die Belastung geringer, als im Fall der Verschlüsselung der gesamten Eingangsdaten
und befriedigt die Sicherheitsbelange. Der Verschlüsselungsbereich
kann gleichzeitig mit der Vereinheitlichung der anderen Verschlüsselungsparameter
vereinheitlicht werden, und ein dadurch bedingter Anstieg der Arbeitsbelastung
ist sehr gering.
-
Insbesondere
wenn wie oben erwähnt
die Eingangsdaten (Anwendung) ein RTP-Paket sind, wird, falls der
Header-Teil des RTP-Pakets nicht verschlüsselt ist, ein UDP-Paket-Header
und ein IP-Paket-Header
zu obigem Header hinzugefügt – dies ermöglicht eine
Header-Komprimierung, inklusive des RTP-Pakets, während der Übertragung,
wie im Fall von Secure RTP. Da weiterhin, anders als im Fall von Secure
RTP, der Bereich der Verschlüsselung
zu Beginn der Sitzung durch Aushandeln mit der Empfangsseite gesetzt
werden kann, kann dieses Schema außerdem vielfältig auf
andere Anwendungen als das RTP-Paket angewandt werden.
-
Obwohl
in 11 der Hinzufügung
des Authentifizierers die Verschlüsselung folgt, ist es auch möglich, den
Authentifizierer nach der Verschlüsselung zu generieren (S5)
und den Authentifizierer, wie in 13 gezeigt,
zum verschlüsselten
Paket hinzuzufügen.
In diesem Fall folgt auf der Empfangsseite der Verifikation der
Gültigkeit
der Empfangsdaten die Dekodierung. Wenn ein Auffüllen (S3) notwendig ist, geht
dieses der Verschlüsselung
(S5) voraus.
-
Der
Fluss der oben beschriebenen selektiven Sicherheits-Verarbeitung
ist in 14 gezeigt, in der bei Eingabe
von Daten darin (S1) die übertragungsseitige
Kommunikationsvorrichtung: die das Sicherungsziel der Eingangsdaten
anzeigenden Parameter über
den Kommunikationskanal mit der empfangsseitigen Kommunikationsvorrichtung
vereinheitlicht (S2); die Sicherheits-Verarbeitung des Teils der
Eingangsdaten basierend auf den vereinheitlichten Parametern für das Sicherungsziel
durchführt (S3);
und die Eingangsdaten überträgt (S4).
-
Zweite Ausgestaltung
-
15 stellt
eine zweite Ausgestaltung der vorliegenden Erfindung dar. Diese
Ausgestaltung ist angepasst um durch Erweiterung des in 5 dargestellten
SSL-Schemas selektive Verschlüsselung
zu unterstützen.
Das Parametergemeinsamnutzungsteil 34 in der ersten Ausgestaltung
beinhaltet ferner: ein Handshake-Teil 34a zur Verhandlung
mit der empfangsseitigen Kommunikationsvorrichtung 40 über Authentifizierungsverfahren
und Verschlüsselung/Datenauthentifizierungsparameter;
ein Schlüsseländerungsteil 34b zur
Bestätigung
der Verschlüsselungs-/Datenauthentifizierungsparameter;
ein Alarm(Alert)-Teil 34c zur Anzeige eines Fehler-Ereignisses;
ein erstes Anwendungsdatenteil 34d zur transparenten Versendung
und zum transparenten Empfang von Anwendungsdaten der oberen Schicht; und
ein erstes Aufzeichnungsteil 34e zur Versendung und zum
Empfang von Protokollen der oben erwähnten vier Teile 34a, 34b, 34c und 34d über das
Untere-Schicht-Teil (Transportteil) 32.
-
Das
erste Aufzeichnungsteil 34e benutzt als sein Protokoll-Daten-Format
das gleiche Format wie dasjenige des in 6 gezeigten
SSL-Aufzeichnungsteils. Das Handshake-Teil 34a verhandelt
mit der empfangsseitigen Kommunikationsvorrichtung 40 über die
Verschlüsselungs-/Daten-Authentifizierungs-Parameter, die im
ersten Aufzeichnungsteil 34b und im zweiten Aufzeichnungsteil
(Verschlüsselungs-/Daten-Authentifiziererhinzufügungsteil) 33 benutzt
werden. Und das Schlüsseländerungs-(Change Cipher)-teil 34b bestätigt die
Verschlüsselungs-/Datenauthentifizierungsparameter
des ersten Aufzeichnungsteils 34e und des zweiten Aufzeichnungsteils 33.
Das bedeutet, es beginnt und zeigt der Empfangsseite die Verschlüsselung
an. In das erste Anwendungsdaten-Aufzeichnungsteil 34e werden
eine Protokollnachricht des ersten Handshake-Teils 34a und
Anwendungsdaten, die im ersten Anwendungsdatenteil 34d keine
selektive Verschlüsselung
notwendig machen, eingespeist.
-
Die Übertragung
und der Empfang von Anwendungsdaten, welche die Durchführung einer
selektiven Verschlüsselung
notwendig machen, werden unabhängig
von den oben erwähnten
Protokolldaten durch ein zweites Aufzeichnungsteil, das bedeutet durch
das Verschlüsselungs-/Datenauthentifiziererhinzufügungsteil,
durchgeführt.
Ein zweites Anwendungsdaten(teil) 37 sendet und empfängt das
Datenpaket eines Anwendungsteils 31b hoher Ordnung an das
und von dem zweiten Aufzeichnungsteil 33. Weiterhin fügt das zweite
Aufzeichnungsteil, d. h. das Verschlüsselungs-/Datenauthentifiziererhinzufügungsteil,
anders als das erste Aufzeichnungsteil 34e, zu den Eingangsdaten
keinen neuen Header hinzu, sondern führt die Verschlüsselungs-/Authentifizierer-Generierungs-Verarbeitung allein
durch. Die mit dem ersten Aufzeichnungsteil 34e gemeinsam genutzten
Parameter werden zur Durchführung
der Verschlüsselungs-/Datenauthentifizierungsverarbeitung
im ersten Aufzeichnungsteil 33 benutzt. Die Verschlüsselungs-/Datenauthentifizierungsverarbeitung ist
die gleiche wie in der ersten Ausgestaltung.
-
Das
Handshake-Teil 34a beginnt die Parametervereinheitlichungsprozedur
unter Benutzung einer klartextlichen Kommunikation mit der empfangsseitigen
Kommunikationsvorrichtung 40 und kann die Kommunikation
schützen,
indem es auf halbem Weg durch das Verfahren zwischen den Anwendungen
gemeinsame Verschlüsselungs-/Authentifizierungsparameter
verwendet. Ein Anwendungsdatenpaket, von dem nicht die Echtzeiteigenschaft
gefordert ist und das nicht häufig
gesendet wird, wie HTTP, FTP, Telnet oder RTSP (ein Protokoll zur
Eröffnung
der RTP-Sitzung), wird von einem ersten Anwendungsteil 31 über das
erste Anwendungsdatenteil 34d in das erste Aufzeichnungsteil 34e eingegeben,
welches das eingegebene Paket basierend auf den gemeinsamen Parametern
als Ganzes verschlüsselt
und zu dem verschlüsselten
Paket den Header 20H des Aufzeichnungsteils hinzufügt, wie
in 6 dargestellt, und danach das Paket als ein Satz-Protokollpaket
dem Transportteil 32 zur Verfügung wird. Im Übrigen hat
die empfangsseitige Kommunikationsvorrichtung 40 den gleichen
Aufbau wie in 15 dargestellt, mit der Ausnahme,
dass das Verschlüsselungs-/Datenauthentifiziererhinzufügungsteil 33,
was das zweite Aufzeichnungsteil ist, ein Dekodierungs-/Verifizierungsteil
ist.
-
Dritte Ausgestaltung
-
16 stellt
eine dritte Ausgestaltung der vorliegenden Erfindung dar. Diese
Ausgestaltung verhandelt mit der Empfangsseite wie RTSP oder HTTP
mit Hilfe des ersten Anwendungsteils 31a über die
Vereinheitlichung/gemeinsame Nutzung der Verschlüsselungs-/Authentifiziererhinzufügungsparameter,
die auf die Anwendungsdaten des zweiten Anwendungsteils 31b angewandt
werden. Beispielsweise können
die Verschlüsselungsparameter
in 8 zur empfangsseitigen Vorrichtung 40 durch
Verschlüsselung
mittels des öffentlichen
Schlüssels
der empfangsseitigen Kommunikationsvorrichtung 40 und Einbettung
der verschlüsselten
Parameter in den Protokoll-Nachrichtenkörper übertragen werden.
-
Es
ist ebenso möglich,
sowohl das Verschlüsselungs-/Authentifiziererhinzufügungsteil
als auch das Dekodierungs-/Verifizierungsteil in einer Kommunikationsvorrichtung
zur Verfügung
zu stellen. Während
obige Ausgestaltung zur Datensicherheit sowohl die Verschlüsselung
als auch die Hinzufügung
des Datenauthentifizierers durchführt, kann ebenso nur eins davon
benutzt werden. Die entsprechenden Teile der Kommunikationsvorrichtungen 30 und 40 können durch
Ausführen
von Programmen auf einem Computer implementiert sein.
-
Wirkung der
Erfindung
-
Wie
oben beschrieben, bietet die vorliegende Erfindung Sicherheit für einen
ausgewählten
Teil von Daten, erlaubt einen vielseitigen, von einer speziellen
Anwendung unabhängigen
Datenschutz und ermöglicht
insbesondere bei der Benutzung in der mobilen Kommunikation die
Header-Kompression.