-
Die Erfindung betrifft ein Verfahren zur Implementierung einer verschlüsselten Client-Server-Kommunikation und ein Client-Server-System.
-
Üblicherweise authentifiziert ein Client, wie zum Beispiel ein Fahrzeug mit Onlinediensten, einen Server, wie zum Beispiel ein IT-Backend, als ganzes System, nicht jedoch die dahinter liegenden Systeme im Einzelnen. In der Regel endet die Authentifizierung eines Backendsystems am Eingangspunkt in das Backend, zum Beispiel über eine Zertifikatsverifizierung mit Protokollen wie TLS. Solche Verfahren sind in der heutigen IT-Welt üblich.
-
Werden zum Beispiel Jobs im Backend für ein Fahrzeug erzeugt, dann werden diese meist in einer Jobliste für das Fahrzeug hinterlegt und der Ursprung dieser Jobs ist nicht authentisch nachvollziehbar. Es genügt also für einen Angreifer, diese Liste manipulativ zu verlängern indem eine der Schnittstellen bedient oder die Daten direkt manipuliert werden.
-
Wie beschrieben enden die üblichen Verfahren am Eintrittspunkt ins Backend. Eine Weiterführung in dahinter liegende Systeme ist aufwendig oder aus Sicherheitssicht nicht sinnvoll: Man kann zum Beispiel über den etablierten, geschützten Kanal zum Eingangspunkt einen weiteren geschützten Kanal bis in das Endsystem erzeugen, das heißt eine Kapselung, die erheblichen Overhead erzeugt und nicht immer möglich ist. Alternativ wird nur ein Kanal bis zum Endsystem aufgebaut und der Eingangspunkt ist nur ein Gateway. Dies macht die Netzwerkarchitektur jedoch unsicher.
-
US 2010/0287375 A1 offenbart den Betrieb eines Ende-zu-Ende Sicherheitskanals zwischen einer IC-Karte und einem Server basierend auf Zufallszahlen und einem asymmetrischen Verschlüsselungsverfahren.
-
DE 60310 814 T2 Verschlüsselungsschlüsselverwaltungsverfahren für ein mobiles Kommunikationssystem, wobei einem Anwenderendgerät ein Verschlüsselungsmodul hinzugefügt wird.
-
DE 10 2008 050 406 A1 offenbart ein Verfahren zur Übertragung von Daten zwischen einem Rechner eines Kraftfahrzeugs und einem zentralen Rechner eines Rechnernetzwerks, bei dem der Verbindungsaufbau einer Kommunikationsverbindung durch ein Challenge-Response-Verfahren abgesichert erfolgt, wobei nur im Falle eines erfolgreichen Verbindungsaufbaus die Datenübertragung aufgenommen wird.
-
EP 1 257 106 A1 offenbart ein Verfahren für einen sicheren Zugriff auf ein Teilnehmermodul in einem Mobilfunksystem. Das Teilnehmermodul ist in einem Server angeordnet und stellt Dienste, Dateien und einen Verschlüsselungsmechanismus für die Verbindung zur Verfügung.
-
Der Erfindung liegt nun die Aufgabe zugrunde, die Sicherheit bei der Kommunikation mit einem Server mit mehreren Dienstsystemen zu verbessern.
-
Diese Aufgabe wird gelöst durch ein Verfahren gemäß Anspruch 1 beziehungsweise ein Client-Server-System gemäß Anspruch 6.
-
Das erfindungsgemäße Verfahren zur Implementierung einer verschlüsselten Client-Server-Kommunikation, wobei der Server einen Eingangspunkt, mehrere hinter dem Eingangspunkt angeordnete Dienstsysteme und ein sicheres System umfasst und wobei die mehreren Dienstsysteme als getrennte Systeme ausgebildet sind und jedes der Dienstsysteme mit dem sicheren System in Verbindung steht, sieht die Schritte vor:
- – Einbringen von gemeinsamen kryptographischem Material in den Client und in das sichere System;
- – Ableiten von Schlüsselmaterial aus dem gemeinsamen kryptographischem Material in dem Client für eine verschlüsselte Kommunikation zwischen dem Client und einem Dienstsystem;
- – Ableiten von Schlüsselmaterial aus dem gemeinsamen kryptographischem Material in dem sicheren System für eine verschlüsselte Kommunikation zwischen dem Client und einem Dienstsystem; und
- – Übertragen des Schlüsselmaterials in das Dienstsystem; oder
- – Behalten des Schlüsselmaterials in dem sicheren System.
-
Das erfindungsgemäße Verfahren hat den Vorteil, dass eine Ende-zu-Ende Sicherheit vom ausführenden Dienstsystem im Server zum ausführenden Client ermöglicht wird und zwar durch einen Eingangspunkt des Servers hindurch. Dies ermöglicht eine robuste Unterteilung im Server oder Backend in mehrere getrennte Systeme. Das Brechen eines Systems führt nicht zur vollständigen Kompromittierung des Servers oder Backends und äquivalent des Clients. Die dadurch verhinderte Beeinflussung von Systemen untereinander ist eine Eigenschaft, auf der die meisten komplexeren Angriffe basieren, insbesondere wenn diese sich automatisch weiter verbreiten. Somit kann die Sicherheit der Kommunikation zwischen Server und einem oder mehreren Clients verbessert werden. Dabei ist die Sicherheit der geschützten Funktion unabhängig von Eingangspunkten in den Client oder in den Server, was eine Unabhängigkeit von weiteren Absicherungskonzepten in dem Client und in dem Server bietet. Es existiert genau ein Schlüssel pro Anwendungsfall, durch eindeutige Ableitungsfunktionen könnten sogar unterschiedliche Schlüssel pro Aufruf verwendet werden.
-
Das gemeinsame kryptographische Material kann ein symmetrischer Schlüssel oder ein asymmetrisches Schlüsselpaar sein. Die Verwendung symmetrischer kryptografischer Verfahren erlaubt einen Einsatz auch für wenig leistungsstarke Clients, wie zum Beispiel einige Steuergeräte in Fahrzeugen. Alternative kann asymmetrische Kryptografie eingesetzt werden.
-
Es kann vorgesehen sein, dass das Schlüsselmaterial in dem Client und in dem Dienstsystem oder dem sicheren System auf zu übertragende Daten angewandt wird. Dieser Schritt geht über die reine Implementierung hinaus und beschreibt eine gesicherte Client-Server-Kommunikation. Der Client kann für jedes Dienstsystem des Servers einen Schlüssel besitzen, so dass jeweils dedizierte, gesicherte Kommunikationskanäle geschaffen werden.
-
Es kann weiter vorgesehen sein, dass sich der Client und der Eingangspunkt gegenseitig über asymmetrische Schlüssel authentifizieren. Dies erlaubt die Verwendung von Standardprotokollen, wie zum Beispiel TLS 1.2, mit durch eine PKI (Public-Key-Infrastruktur) signierte Schlüssel.
-
Es kann vorgesehen sein, dass im Client ein weiterer Eingangspunkt für den Client vorgesehen ist und dass für hinter dem weiteren Eingangspunkt vorgesehene Systeme des Clients die folgenden Schritte ausgeführt werden:
- – Einbringen von gemeinsamen kryptographischem Material in die Systeme des Clients und in das sichere System;
- – Ableiten von Schlüsselmaterial aus dem gemeinsamen kryptographischem Material in den Systemen des Clients für eine verschlüsselte Kommunikation zwischen dem jeweiligen System des Clients und einem Dienstsystem.
-
Damit wird die Struktur in dem Server gewissermaßen spiegelbildlich in dem Client abgebildet, so dass auch mehrere einzelne Systeme in dem Client zu einer dedizierten Kommunikation verholfen wird. Dies ermöglicht dass ein einzelnes System im Client eine verschlüsselte Ende-zu-Ende Verbindung beziehungsweise Kommunikation zu einem bestimmten Dienstsystem im Server aufbauen kann.
-
Das erfindungsgemäße Client-Server-System, wobei der Server einen Eingangspunkt, mehrere hinter dem Eingangspunkt angeordnete Dienstsysteme und ein sicheres System umfasst, sieht vor, dass die mehreren Dienstsysteme als getrennte Systeme ausgebildet sind, dass jedes der Dienstsysteme mit dem sicheren System in Verbindung steht, dass gemeinsames kryptographisches Material in dem Client und in dem sicheren System vorgesehen ist, dass aus dem gemeinsamen kryptographischem Material abgeleitetes Schlüsselmaterial in dem Client für eine verschlüsselte Kommunikation zwischen dem Client und einem Dienstsystem vorgesehen ist, und dass aus dem gemeinsamen kryptographischen Material abgeleitetes Schlüsselmaterial in den Dienstsystemen für eine verschlüsselte Kommunikation zwischen dem Client und dem jeweiligen Dienstsystem vorgesehen ist. Es gelten die gleichen Vorteile und Modifikationen wie zuvor beschrieben. Wenn ein Hersteller gleichzeitig Endprodukte und Backendfunktionalität dieser Endprodukte zur Verfügung stellt und er weiterhin einen Weg findet, Schlüssel einzubringen, die auch im Backend repräsentiert sind und für die er durch eine eindeutig definierte Ableitungsfunktion dedizierte Schlüssel auf beiden Seiten berechnen kann, ist das vorgeschlagene Client-Server-System hilfreich. Insbesondere wird dadurch eine deutliche Erhöhung der Komplexität für den Angreifer erreicht. Es genügt nicht mehr, eine Absicherungsmaßnahme zu umgehen. Eine Schwachstelle auf einem Rechner mit Zugriffsrechten auf das Backend reicht noch nicht aus, um Aktionen auf dem Endprodukt auszulösen.
-
Das gemeinsame kryptographische Material kann ein symmetrischer Schlüssel oder eine asymmetrische Verschlüsselung sein. Die Verwendung symmetrischer Schlüssel erlaubt einen Einsatz auch für wenig leistungsstarke Clients, wie zum Beispiel einige Steuergeräte in Fahrzeugen. Alternative kann asymmetrische Kryptografie eingesetzt werden.
-
Es kann vorgesehen sein, dass im Client ein weiterer Eingangspunkt für den Client vorgesehen ist und dass hinter dem weiteren Eingangspunkt Systeme des Clients vorgesehen sind, dass gemeinsames kryptographisches Material in den Systemen des Clients und in dem sicheren System vorgesehen ist, und dass aus dem gemeinsamen kryptographischem Material abgeleitetes Schlüsselmaterial in den Systemen des Clients für eine verschlüsselte Kommunikation zwischen dem jeweiligen System und einem Dienstsystem vorgesehen ist. Damit wird die Struktur in dem Server gewissermaßen spiegelbildlich in dem Client abgebildet, so dass auch mehrere einzelne Systeme in dem Client zu einer dedizierten Kommunikation verholfen wird. Dies ermöglicht dass ein einzelnes System im Client eine verschlüsselte Ende-zu-Ende Verbindung beziehungsweise Kommunikation zu einem bestimmten Dienstsystem im Server aufbauen kann.
-
Es kann weiter vorgesehen sein, dass der Client ein Fahrzeug ist und dass der Server ein Backend eines Herstellers des Fahrzeugs und/oder eines Dienstanbieters ist. Das vorgeschlagene System bietet sich insbesondere für Architekturen mit zahlreichen Clients, wie zum Beispiel Fahrzeuge, Haushaltsgeräte, Smart-Home-Installationen, und einem Server oder Backend mit zahlreichen Diensten an. Für einzelne sicherheitskritische Dienste, wie zum Beispiel Tür öffnen, Fahrzeug starten, Fahrzeugposition einsehen, wird hier eine solche Trennung der Authentifizierung von Systemen im Backend ermöglicht, um die Sicherheit zu verbessern und klare Rollentrennung zu ermöglichen. Diese Trennung muss im Fahrzeug verifizierbar sein.
-
Es kann vorgesehen sein, dass die Systeme des Clients Steuergeräte sind. In Fahrzeugen oder Haushaltsgeräten sind derartige Steuergeräte weit verbreitet, was eine Implementierung erleichtert und eine Vielzahl von Anwendungsmöglichkeiten eröffnet.
-
Es kann weiter vorgesehen sein, dass der weitere Eingangspunkt ein Online-Steuergerät ist. Oftmals übernimmt das Online-Steuergerät die Online- oder Kommunikationsfunktionalität für die weiteren dahinterliegenden Steuergeräte, was eine Implementierung erleichtert und eine Vielzahl von Anwendungsmöglichkeiten eröffnet.
-
Weitere bevorzugte Ausgestaltungen der Erfindung ergeben sich aus den übrigen, in den Unteransprüchen genannten Merkmalen.
-
Die verschiedenen in dieser Anmeldung genannten Ausführungsformen der Erfindung sind, sofern im Einzelfall nicht anders ausgeführt, mit Vorteil miteinander kombinierbar.
-
Die Erfindung wird nachfolgend in Ausführungsbeispielen anhand der zugehörigen Zeichnungen erläutert. Es zeigen:
-
1 eine schematische Darstellung einer Kommunikationsarchitektur eines Client-Server-Systems;
-
2 eine schematische Darstellung einer Schlüsselverteilung des Client-Server-Systems;
-
3 eine schematische Darstellung einer Ende-zu-Ende Verschlüsselung des Client-Server-Systems; und
-
4 eine schematische Darstellung einer weiteren Kommunikationsarchitektur eines Client-Server-Systems.
-
1 zeigt ein Client-Server-System 10 mit einem Client 12, der sich in einem öffentlichen Bereich beziehungsweise Netz 14, wie dem Internet, befindet. Das Client-Server-System 10 umfasst weiterhin einen Server 16, wie zum Beispiel ein Backend für Online-Dienste oder Services. Über einen Eingangspunkt 18 des Servers 16 kann der Client 12 eine Kommunikationsverbindung mit dem Server 16 herstellen. Die Verbindung kann drahtlos, drahtgebunden oder aus einer Kombination von beiden erfolgen.
-
Der Client 12 kann zum Beispiel ein Steuergerät von einem Fahrzeug wie ein PKW, LKW, Bus, Motorrad oder ein Schienen-, Luft- oder Wasserfahrzeug sein. In anderen Beispielen kann der Client 12 ein mobiles oder stationäres Gerät oder dessen Steuergerät wie zum Beispiel ein Haushaltgerät oder ein Bestandteil einer Smart-Home Installation sein. Der Server 16 kann zum Beispiel ein Backend des Herstellers des Clients 12 sein, durch das der Hersteller Online-Dienste für seine Geräte anbietet. Der Server 16 kann auch einem externen Dienstanbieter zugeordnet sein.
-
Üblicherweise ist ein Backend oder Server 16, der auch aus mehreren verteilten Servern oder Recheneinheiten bestehen kann, für eine Vielzahl von Clients 12 zuständig. In dem Server 16 sind mehrere Dienstsysteme 20, 22, 24 vorgesehen, von denen drei beispielhaft dargestellt sind. Die Dienstsysteme 20, 22, 24 können in Hardware, Software oder einer Mischung aus beiden realisiert sein. Die Dienstsysteme 20, 22, 24 stehen in Kommunikation mit dem Eingangspunkt 18.
-
Im Bereich von Automobildiensten können dies zum Beispiel ein Navigationsdienst, ein Ortungsdienst, ein Dienst zum Tür Öffnen oder ein Dienst zum Starten des Fahrzeugs sein. In einer Smart-Home Umgebung kann zum Beispiel ein Dienst zum Tür Öffnen oder ein Dienst zum Starten eines Geräts wie einer Waschmaschine vorgesehen sein. Ruft der Client 12 eines der Dienstsysteme 20, 22, 24 beziehungsweise einen der von ihnen angebotenen Services auf oder initiiert der Server 16 eines der Dienstsysteme 20, 22, 24, wird eine Verbindung zwischen dem Client 12 und dem jeweiligen Dienstsystem 20, 22 oder 24 aufgebaut. Dies kann eine zumindest für die Dienstdauer gehaltene Verbindung sein oder eine temporäre gegebenenfalls periodische Nachrichten- oder Datenübertragung sein.
-
Diese Dienstsysteme 20, 22, 24 liegen in dem Server 16 hinter dem Eingangspunkt 18. Das heißt dass der Client 12 über den Eingangspunkt 18 auf eines der Dienstsysteme 20, 22, 24, einige oder alle zugreifen kann. Die Verbindung vom Client 12 zu dem Eintritts- oder Eingangspunkt ist vorzugsweise durch eine asymmetrische Kryptographie geschützt.
-
Der Server 16 umfasst ferner ein sicheres System 26, das zum Beispiel die Schlüsselerzeugung und -verwaltung des Herstellers oder Dienstanbieters ausführt. Jedes der Dienstsysteme 20, 22, 24 steht mit dem sicheren System 26 in Verbindung. Jedes dieser Dienstsysteme 20, 22, 24 verfügt über eine beidseitig authentifizierte und vertrauliche Verbindung zu dem sicheren System 26.
-
Das sichere System 26, die Dienstsysteme 20, 22, 24 und der Eingangspunkt 18 können in einer Servereinheit oder verteilt zum Beispiel in einem Intranet angeordnet sein. Der Begriff Server, wie er hier verwendet wird, umfasst beide Varianten.
-
2 zeigt eine Schlüsselverteilung für das Client-Server-System 10. Das sichere System 26 und der Client 12 enthalten gemeinsames kryptographisches Material, wie zum Beispiel einen symmetrischen Schlüssel 28. Bei der Herstellung des Clients 12 kann der symmetrische Schlüssel 28 von dem sicheren System 26 in den Client 12 eingebracht werden.
-
Zur geschützten Kommunikation mit dem Client 12 erfragt zum Beispiel das Dienstsystem 20 von dem sicheren System 26 einen Schlüssel. Das sichere System 26 generiert daraufhin in einer Schlüsselableitung 30 einen spezifischen Schlüssel 32. Dieser spezifische Schlüssel 32 wird von dem sicheren System 26 aus dem symmetrischen Schlüssel 28 bezogen auf den Dienst, den das Dienstsystem 20 bereitstellt, hergeleitet. Analog wird ein spezifischer Schlüssel 34 für das Dienstsystem 22 und ein weiterer spezifischer Schlüssel 36 für das Dienstsystem 24 generiert.
-
Der spezifische Schlüssel 32 wird an das Dienstsystem 20 übertragen. Dies geschieht per geschützter Kommunikation. Ebenso wird der spezifische Schlüssel 34 an das Dienstsystem 22 übertragen und der spezifische Schlüssel 36 wird an das Dienstsystem 24 übertragen. Jedes der Dienstsysteme 20, 22 und 24 verwendet nun den jeweiligen spezifischen Schlüssel 32, 34 oder 36 in der Kommunikation mit dem Client 12, um seine Daten für den Client 12 zu schützen, zum Beispiel mittels Signierung und Verschlüsselung.
-
Beim Empfang der Daten von dem Dienstsystem 20, 22 oder 24 kann der Client 12 in einer Schlüsselableitung 30 ebenfalls aus dem symmetrischen Schlüssel 28 den jeweiligen spezifischen Schlüssel 32, 34, 36 herleiten. Alternativ kann vorgesehen sein, dass die spezifischen Schlüssel 32, 34 und 36 auch schon in den Client 12 eingebracht worden sein können, beispielsweise bei dessen Herstellung. Die Ableitung im Client 12 spart hier Speicherplatz und Übertragungsaufwand. Das gleiche gilt auch für das sichere System 26. Die spezifischen Schlüssel 32, 34 und 36 können dort prinzipiell auch alle einzeln gespeichert sein, was jedoch zum Beispiel bei einer Fahrzeugflotte mit Millionen von Teilnehmern erheblichen Aufwand erzeugt: Für jeden Dienst muss ein Schlüssel vorliegen, also hat man eine Anzahl von Fahrzeugen mal Diensten Schlüssel.
-
Der spezifische Schlüssel 32, 34 oder 36 im Client 12 ist identisch zu dem entsprechenden Schlüssel in dem Dienstsystem 20, 22 oder 24. Mit dem spezifischen Schlüssel 32, 34 oder 36 kann der Client 12 die Daten verifizieren oder entschlüsseln.
-
Der Client 12 kann dann sicher sein, dass die Daten wirklich von dem bestimmten Dienstsystem 20 erzeugt wurden und nicht von dem Eingangspunkt 18 oder einem anderen Dienstsystem 22 oder 24. Das sichere System 26 könnte theoretisch die Daten erzeugen, jedoch wird das sichere System 26 als sicher vorausgesetzt. Diese Sicherheit zu erzielen ist einfach, da der Aufgabenbereich des sicheren Systems 26 üblicherweise beschränkt ist und daher insbesondere in sicherer Hardware abgebildet werden kann. Diese geschützte Kommunikation funktioniert auch in die andere Richtung von dem Client 12 zu dem Dienstsystem 20 mit dem gleichen Schlüssel und analog zu den anderen Dienstsystemen 22 und 24.
-
Anstelle die spezifischen Schlüssel 32, 34 und 36 auszuhändigen, könnte das sichere System 26 auch die Daten oder eine Repräsentation wie einen Hashwert von den Dienstsystemen 20, 22 und 24 erhalten und selbst den jeweiligen spezifischen Schlüssel auf die entsprechenden Daten anwenden. Dies hat den sicherheitstechnischen Vorteil, dass die spezifischen Schlüssel 32, 34 und 36 nur im sicheren System 26 verbleiben. Das könnte jedoch die Komplexität des sicheren Systems erhöhen.
-
3 zeigt eine schematische Darstellung einer Ende-zu-Ende Verschlüsselung des Client-Server-Systems 10. Wie dargestellt ist, existiert ein geschützter Kommunikationskanal 38 zwischen dem Client 12 und dem Dienstsystem 20. Die Verschlüsselung des Kommunikationskanals 38 basiert auf dem spezifischen Schlüssel 32, der sowohl im Client 12 als auch im Dienstsystem 20 vorhanden ist. Zwar verläuft der Kommunikationskanal 38 durch den Eingangspunkt 18, dieser Durchgang ist jedoch gewissermaßen gekapselt, da der Eingangspunkt 18 den spezifischen Schlüssel 32 nicht kennt. Somit kann der Eingangspunkt 18 nicht auf den Kommunikationskanal 38 und damit nicht auf die über ihn versendeten Nachrichten und Daten zugreifen. Es wird eine geschützte Ende-zu-Ende Verbindung und Verschlüsselung zur Verfügung gestellt, wobei die Endpunkte der Client 12 und das Dienstsystem 20 sind.
-
Analog zu dem zuvor beschriebenen Kommunikationskanal 38 zwischen dem Client 12 und dem Dienstsystem 20 sind weitere Kommunikationskanäle 40 beziehungsweise 42 zwischen dem Client 12 und dem Dienstsystem 22 beziehungsweise 24 vorhanden. Die einzelnen Kommunikationskanäle 38, 40 und 42 sind strikt getrennt, so dass kein Zugriff zwischen den Kommunikationskanälen möglich ist.
-
4 zeigt eine schematische Darstellung einer weiteren Kommunikationsarchitektur eines Client-Server-Systems 110. Serverseitig entspricht das Client-Server-System 110 dem Client-Server-System 10 aus den vorherigen Figuren. Der Client 112 unterscheidet sich dahingehend von dem Client 10 aus den vorherigen Figuren, dass der Client 112 analog zu dem Server 16 aufgebaut ist.
-
In dem Client 112 ist ein weiterer Eingangspunkt 144 für den Client 112 vorgesehen, so dass die beiden Eingangspunkte 18 und 144 über das öffentliche Netz 114 miteinander kommunizieren. Die Kommunikation zwischen den beiden Eingangspunkten 18 und 144 ist beispielsweise über asymmetrische Kryptographie geschützt. Der Eingangspunkt 144 kann zum Beispiel ein Online-Steuergerät sein.
-
Hinter dem weiteren Eingangspunkt 144, das heißt innerhalb des Clients 112 sind Systeme 146, 148 wie in diesem Beispiel Steuergeräte des Clients 112 vorgesehen. Die Steuergeräte 146, 148 sind jeweils spezifischen Funktionen wie zum Beispiel Navigation oder Zugangskontrolle zugeordnet. In diesem Beispiel ist das Steuergerät 146 ein Steuergerät für Navigation und das Steuergerät 148 ist ein Steuergerät für die Zugangskontrolle zu dem Fahrzeug, in dem sich das Steuergerät 148 befindet.
-
Für die Implementierung der Kommunikationsverbindungen wird zunächst, analog zu den zuvor beschriebenen Figuren, gemeinsames kryptographisches Material in die Systeme 146, 148 des Clients 112 und in das sichere System 26 eingebracht. Aus Gründen der Übersichtlichkeit ist dies hier nicht dargestellt. Für Details wird auf die in 2 dargestellt Schlüsselableitung verwiesen, die hier analog ausgeführt wird. Entsprechend wird Schlüsselmaterial 32, 34, 36 aus dem gemeinsamen kryptographischem Material in den Systemen 146, 148 des Clients 112 für eine verschlüsselte Kommunikation zwischen dem jeweiligen System 146, 148 des Clients 112 und einem Dienstsystem 20, 22, 24 des Servers 16 abgeleitet. Es ist auch möglich, dass die Einbringung des gemeinsamen kryptographischen Materials und die Schlüsselableitung nicht direkt in den entsprechenden Systemen 146 und 148 erfolgt, sondern in einem weiteren hier nicht dargestellten System des Clients 112, wie zum Beispiel einem weiteren sicheren System. Dann werden die dort erzeugten spezifischen Schlüssel 32, 34 und 36 in das jeweilige System 146 und 148 übertragen.
-
Unabhängig von der Erzeugung der spezifischen Schlüssel 32, 34 und 36 ist in 4 der Zustand nach der eigentlichen Erzeugung dargestellt, in dem die spezifischen Schlüssel 32, 34 und 36 bereits verteilt sind. In diesem Beispiel ist ein spezifischen Schlüssel 32 in dem System 146 vorhanden und die anderen beiden spezifischen Schlüssel 34 und 36 sind in dem anderen System 148 vorhanden.
-
Somit ergibt sich ein Kommunikationskanal 138 zwischen dem System 146 des Clients 112 und dem Dienstsystem 20 des Servers 16. Dies kann zum Beispiel ein Navigationsdienst sein. Zwischen dem System 148 des Clients 112 und den Dienstsystemen 22 und 24 des Servers 16 sind Kommunikationskanäle 140 und 142 vorhanden. Zum Beispiel stellt das Dienstsystem 22 eine Tür Öffnen Funktionalität zu Verfügung und das Dienstsystem 24 stellt einen Zugangsweg per Smartphone zur Verfügung.
-
Es ist zu sehen, dass ein System 148 auf mehrere Dienstsysteme 22 und 24 des Servers 16 zugreifen kann. Auch hier sind die Kommunikationskanäle 140 und 142 strikt getrennt, was die Sicherheit erhöht. Ebenso sind die Kommunikationskanäle 138 einerseits und 140 und 142 andererseits, das heißt die Kommunikationskanäle der beiden System 146 und 148, klar voneinander getrennt. Die Kommunikationskanäle 138, 140 und 142 bilden geschützte Ende-zu-Ende Verbindungen zwischen den Systemen 146 und 148 und den Dienstsystemen 20, 22 und 24. Die Kommunikationskanäle 138, 140 und 142 verlaufen durch die beiden Eingangspunkte 144 und 18, da dort die spezifischen Schlüssel 32, 34 und 26 jedoch nicht bekannt sind, kann dort kein Zugriff auf die Kommunikation erfolgen.
-
Das hier vorgeschlagene Vorgehen erlaubt eine saubere und sichere Trennung der Dienstsysteme 20, 22 und 24 je nach Aufgabengebiet, was die Sicherheit des Backends und der Kommunikation erhöht.
-
Bezugszeichenliste
-
- 10
- Client-Server-System
- 12
- Client
- 14
- öffentliches Netz
- 16
- Server
- 18
- Eingangspunkt
- 20
- Dienstsystem
- 22
- Dienstsystem
- 24
- Dienstsystem
- 26
- sicheres System
- 28
- symmetrischer Schlüssel
- 30
- Schlüsselableitung
- 32
- spezifischer Schlüssel
- 34
- spezifischer Schlüssel
- 36
- spezifischer Schlüssel
- 38
- Kommunikationskanal
- 40
- Kommunikationskanal
- 42
- Kommunikationskanal
- 110
- Client-Server-System
- 112
- Client
- 114
- öffentliches Netz
- 138
- Kommunikationskanal
- 140
- Kommunikationskanal
- 142
- Kommunikationskanal
- 144
- weiterer Eingangspunkt
- 146
- System
- 148
- System
