DE102018201958A1

DE102018201958A1 - Verfahren zum Kontrollieren eines Zugriffs zumindest einer Anwendung auf eine digitale Dienstfunktion eines Geräts sowie Gerät und Kraftfahrzeug

Info

Publication number: DE102018201958A1
Application number: DE102018201958.4A
Authority: DE
Inventors: Patrick Bartsch; Markus Klein
Original assignee: Audi AG
Current assignee: Audi AG
Priority date: 2018-02-08
Filing date: 2018-02-08
Publication date: 2019-08-08

Abstract

Die Erfindung betrifft ein Verfahren zum Kontrollieren eines Zugriffs zumindest einer gerätefremden Anwendung (20) auf eine digitale Dienstfunktion (18) an einer digitalen Schnittstelle (17) eines Geräts (10), wobei durch eine Autorisierungseinheit (23) des Geräts (10) aus der jeweiligen Anwendung (20) ein ID-Token (26, 27) mit Kennungsdaten (14) der Anwendung (20) empfangen wird und jeweils geprüft wird, ob der ID-Token (26, 27) ein vorbestimmtes Ausstattungskriterium für eine automatische Zugriffsautorisierung erfüllt. Die Erfindung sieht vor, dass für den Fall, dass das Ausstattungskriterium verletzt ist, einem aktuellen Benutzer (15) des Geräts (10) über eine Ausgabeeinrichtung (12) die Kennungsdaten (14) ausgegeben werden und von dem Benutzer (15) über eine Eingabeeinrichtung (13) eine Zulassungsentscheidung (16) empfangen wird und durch die Autorisierungseinheit (23) in Abhängigkeit von der Zulassungsentscheidung (16) des Benutzers (15) der Zugriff bestätigt oder abgelehnt wird.

Description

Die Erfindung betrifft ein Verfahren zum Kontrollieren eines Zugriffs zumindest einer Anwendung auf eine digitale Dienstfunktion an einer digitalen Schnittstelle eines Geräts. Die Anwendung kann dabei geräteextern oder gerätefremd sein, d.h. sie muss also nicht Bestandteil des Geräts sein. Eine digitale Dienstfunktion kann beispielsweise vorsehen, dass aktuelle Geokoordinaten des Geräts an der Schnittstelle bereitgestellt oder ausgegeben werden. Durch das Verfahren wird kontrolliert, ob die gerätefremde Anwendung diese Geokoordinaten, oder allgemein die Dienstfunktion, überhaupt abrufen darf. Zu der Erfindung gehören auch ein solches Gerät sowie ein Kraftfahrzeug mit einem solchen Gerät.
Ein Gerät kann mit einer gerätefremden Anwendung über ein Kommunikationsnetzwerk kommunizieren oder Daten austauschen. In einem Kraftfahrzeug kann beispielsweise als ein solches Gerät ein Infotainmentsystem (Informations-Unterhaltungs-System) bereitgestellt sein. Eine mögliche Anwendung kann z.B. durch ein mobiles Endgerät oder einen Server des Internets realisiert sein. Das Gerät kann mit der Anwendung über das besagte Kommunikationsnetzwerk gekoppelt sein. Das Gerät kann eine digitale Schnittstelle bereitstellen, die über das Kommunikationsnetzwerk angesprochen oder erreicht werden kann. An dieser digitalen Schnittstelle kann dann beispielsweise über ein vorbestimmtes Protokoll zumindest eine Dienstfunktion des Geräts angefordert oder ausgelöst werden. In der beschriebenen Weise kann eine solche Dienstfunktion beispielsweise das Bereitstellen oder das Angeben der Geokoordinaten des Gerätes und/oder das Abspielen von Medieninhalten durch das Gerät umfassen.
Natürlich möchte man nicht, dass jede beliebige Anwendung auf diese Weise über die digitale Schnittstelle auf das Gerät zugreifen und dessen Dienstfunktion auslösen oder starten kann. Hierzu ist zu dem Verfahren der eingangs beschriebenen Art aus der DE 10 2017 102 539 A1 bekannt, dass sich eine Anwendung zunächst ein Anwendungszertifikat beschaffen muss, welches der Anwendung Zugriff auf eine Dienstfunktion einer digitalen Schnittstelle eines Kraftfahrzeugs gewährt. Ohne das Anwendungszertifikat wird der Anwendung der Zugriff auf die Dienstfunktion verweigert. Zum Beschaffen des Anwendungszertifikats ist aber eine Verbindung zu einem Serverdienst des Internets nötig. In einem Kraftfahrzeug ist eine solche Verbindung nicht immer gewährleistet, da die hierzu nötige Funkverbindung zum Internet beispielsweise aufgrund eines Funkloches unterbrochen sein kann.
Eine weitere Sicherheitslücke kann die Kommunikationsverbindung zwischen Gerät und Anwendung darstellen, da eine Schadsoftware versuchen könnte, die Kommunikation zu manipulieren und hierdurch für sich selbst eine Dienstfunktion trotz fehlender Autorisierung nutzbar zu machen. Aus der DE 10 2013 113 667 A1 ist hierzu bekannt, dass im Zusammenhang mit der Kommunikation eines Geräts mit einem Kraftfahrzeug ein Transportschichtsicherheitsprotokoll, insbesondere das TLS-Protokoll (TLS - Transport Layer Security) verwendet werden kann. Aus der Druckschrift geht auch hervor, dass hiermit eine Kommunikationsverbindung auch authentifiziert werden kann, also durch die Kommunikationsverbindung eine Kennung oder Identität eines Kommunikationspartners verifiziert werden kann.
Aus der DE 10 2015 209 108 A1 ist bekannt, dass zum Autorisieren eines Zugriffs auf Daten ein Token oder Ticket verwendet werden kann. Um eine Manipulation eines solchen Tokens oder Tickets erkennen zu können, wird dieses durch einen Serverdienst des Internets signiert. Somit wird auch bei diesem Verfahren eine Internetverbindung benötigt, die in einem Kraftfahrzeug nicht immer zuverlässig bereitstehet.
Der Erfindung liegt die Aufgabe zugrunde, in einem Gerät an dessen digitaler Schnittstelle den Zugriff einer gerätefremden Anwendung auf eine digitale Dienstfunktion zu kontrollieren.
Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausführungsformen der Erfindung sind durch die abhängigen Patentansprüche, die folgende Beschreibung sowie die Figuren beschrieben.
Durch die Erfindung ist ein Verfahren bereitgestellt, um einen Zugriff zumindest einer gerätefremden, das heißt von dem Gerät verschiedenen Anwendung auf eine digitale Dienstfunktion an einer digitalen Schnittstelle des Geräts zu kontrollieren. Die Schnittstelle kann eine Programmierschnittstelle (API - Application Programming Interface) sein. Der Zugriff wird durch eine Autorisierungseinheit kontrolliert. Die Autorisierungseinheit kann beispielsweise als ein Programmmodul des Geräts realisiert sein. Die Autorisierungseinheit kann auch außerhalb des Geräts angeordnet sein und über eine verschlüsselte Kommunikationsverbindung mit dem Gerät kommunizieren. Die Autorisierungseinheit kann in diesem Fall z.B. durch einen Server des Internets realisiert oder betrieben werden.
Es wird dabei zunächst überprüft, ob der Zugriff durch die Autorisierungseinheit selbständig oder automatisiert gewährt oder autorisiert werden kann.
Bei dem Verfahren wird hierzu durch die Autorisierungseinheit aus der jeweiligen Anwendung ein ID-Token mit Kennungsdaten der Anwendung empfangen. Ein ID-Token stellt dabei einen Datensatz dar, in welchem zumindest die Kennungsdaten enthalten sind. Durch die Autorisierungseinheit wird geprüft, ob der ID-Token ein vorbestimmtes Ausstattungskriterium für eine automatische Zugriffsautorisierung erfüllt. Mit anderen Worten wird überprüft, ob der ID-Token z.B. solche Kennungsdaten und/oder weitere Daten enthält, die es der Autorisierungseinheit ermöglichen können, selbständig den Zugriff der Anwendung auf die Dienstfunktion zu autorisieren. Die Voraussetzungen hierfür können durch das Ausstattungskriterium definiert sein. Beispielsweise kann hier auf den Stand der Technik zurückgegriffen werden, der eine automatische Zugriffsautorisierung durch eine Autorisierungseinheit für den Fall ermöglicht, dass der ID-Token durch ein vertrauenswürdiges Backend oder einen vorbestimmten Serverdienst des Internets signiert ist.
Für den Fall aber, dass das Ausstattungskriterium verletzt ist, das heißt die Autorisierungseinheit anhand des ID-Tokens nicht selbständig die Zugriffsautorisierung ausführen kann, ist erfindungsgemäß vorgesehen, einem aktuellen Benutzer des Geräts über eine Ausgabeeinrichtung die Kennungsdaten auszugeben. Mit anderen Worten kann dann der Benutzer des Geräts an der Ausgabeeinrichtung erkennen, dass gerade eine Anwendung auf die Dienstfunktion an der Schnittstelle des Geräts Zugriff erhalten möchte. Die Ausgabeeinrichtung kann hierzu beispielsweise einen Bildschirm oder eine Sprachausgabe vorsehen. Die Ausgabeeinrichtung kann Bestandteils des Geräts sein oder mit dem Gerät gekoppelt sein. Bei dem Verfahren ist des Weiteren vorgesehen, dass von dem Benutzer über eine Eingabeeinrichtung eine Zulassungsentscheidung empfangen wird. Mit anderen Worten entscheidet der Benutzer, ob der Zugriff der Anwendung auf die Dienstfunktion zugelassen werden soll oder nicht zugelassen werden soll. Die Eingabeeinrichtung kann hierzu beispielsweise einen Touchscreen, auf welchem eine graphische Eingabemöglichkeit, zum Beispiel zumindest ein Eingabefeld, dargestellt oder erzeugt ist, und/oder eine mechanische Taste und/oder eine Spracheingabe vorsehen. Die Eingabeeinrichtung kann Bestandteil des Geräts sein oder mit dem Gerät gekoppelt sein. Eine Zulassungsentscheidung des Benutzers kann beispielsweise in der binären Aussage ja/nein bestehen. Durch die Autorisierungseinrichtung wird dann in Abhängigkeit von der Zulassungsentscheidung des Benutzers der Zugriff bestätigt oder abgelehnt. Bei abgelehntem Zugriff ist es dann der Anwendung unmöglich gemacht, an der digitalen Schnittstelle des Geräts auf die digitale Dienstfunktion zuzugreifen. Bei Bestätigung des Zugriffs kann dann vorgesehen sein, dass die Anwendung zugelassen wird, sodass bei einer zukünftigen Zugriffsanforderung oder Zugriffsanfrage der Anwendung auf die Dienstfunktion diese von der Autorisierungseinrichtung zugelassen wird, das heißt die Dienstfunktion den von ihr bereitgestellten Dienst durchführt oder die Dienstfunktion sich durch die Anwendung aufrufen lässt.
Die Erfindung weist den Vorteil auf, dass für den Fall, dass anhand des ID-Tokens durch die Autorisierungseinheit des Geräts nicht selbst entschieden werden kann, ob der Zugriff autorisiert werden darf (d.h. Ausstattungskriterium ist durch den ID-Token nicht erfüllt), dennoch keine Verbindung zu einem Serverdienst des Internets nötig ist, um eine Zulassungsentscheidung zu erhalten. Vielmehr wird ausgenutzt, dass eine Benutzer des Geräts befragt wird, ob er den Zugriff der Anwendung auf das Gerät, insbesondere auf eine bestimmte, z.B. durch den ID-Token definierte Dienstfunktion, zulassen möchte. Dann wird die Zulassungsentscheidung des Benutzers für den Zugriff zugrundegelegt. Somit ist keine Internetverbindung nötig. Das Verfahren ist also offline-fähig.
Die Erfindung umfasst auch Ausführungsformen, durch die sich zusätzliche Vorteile ergeben.
Gemäß einer Ausführungsform wird für den Fall, dass das Ausstattungskriterium erfüllt ist, das heißt die Autorisierungseinheit selbständig über den Zugriff entscheiden kann, unabhängig von dem aktuellen Benutzer durch die Autorisierungseinheit selbst über das Bestätigen oder Ablehnen des Zugriffs anhand des ID-Tokens entschieden wird. Hierdurch ergibt sich der Vorteil, dass der aktuelle Benutzer nicht gestört oder unterbrochen wird.
Eine Ausführungsform sieht vor, dass das besagte Ausstattungskriterium als eine für die automatische Zugriffsautorisierung ausreichende Bedingung vorsieht oder umfasst, dass der ID-Token von der Anwendung zu dem Gerät über eine Kommunikationsverbindung übertragen wird, die mittels eines Verschlüsselungsverfahrens verschlüsselt ist. Insbesondere ist ein asymmetrisches Verschlüsselungsverfahren, beispielsweise ein Public-Key-Verfahren, vorgesehen. Die Bedingung umfasst aber des Weiteren, dass zumindest die Anwendung dabei einen kryptographischen Schlüssel verwendet, der von einer vorbestimmten Zertifizierungsstelle zertifiziert ist, die in der Autorisierungseinheit unabhängig von der Anwendung bereits als vertrauenswürdig gekennzeichnet oder gespeichert oder vermerkt ist. Die Anwendung baut also eine verschlüsselte Kommunikationsverbindung zu dem Gerät auf und verwendet hierbei einen kryptographischen Schlüssel, der zusätzlich signiert ist. Die Signatur stammt dabei von einer Zertifizierungsstelle, die der Autorisierungseinheit bereits bekannt ist. Beispielsweise kann die Zertifizierungsstelle in einer Liste der zugelassenen Zertifizierungsstellen, einer sogenannten Weißliste oder White-List, angegeben sein. In diesem Fall bestätigt oder gewährt die Autorisierungseinheit dann der Anwendung den Zugriff. Diese Ausführungsform weist den Vorteil auf, dass zentral durch eine Zertifizierungsstelle, beispielsweise einem Server des Internets, im Voraus, wenn noch eine Kommunikationsverbindung zwischen der Anwendung und dem Internet besteht, die Anwendung den kryptographischen Schlüssel zertifizieren lassen kann und dann später, ohne die Notwendigkeit einer Kommunikationsverbindung zu dem Server, allein mittels des kryptographischen Schlüssels durch Aufbauen der verschlüsselten Kommunikationsverbindung zu dem Gerät dennoch einen Zugriff auf die Gerätefunktion erhalten kann. Hierbei ist dann keine Internetverbindung mehr nötig. Bevorzugt ist vorgesehen, dass für die Kommunikationsverbindung sowohl die Anwendung als auch das Gerät einen zertifizierten kryptographischen Schlüssel verwenden.
Eine Ausführungsform sieht vor, dass das Ausstattungskriterium als eine für die automatische Zugriffsautorisierung ausreichende Bedingung umfasst, dass der ID-Token die Anwendung und eine Besitzerkennung eines Besitzers der Anwendung angibt und der ID-Token von einem vorbestimmten Serverdienst des Internets, beispielsweise der besagten Zertifizierungsstelle oder eines Serverdienstes eines Herstellers des Geräts, mit einer Signatur signiert ist. Der ID-Token gibt also an, dass eine bestimmte Anwendung eines bestimmten Besitzers (identifiziert durch die Besitzerkennung) Zugriff auf die Dienstfunktion haben möchte. Die Angabe der Anwendung und die Angabe der Besitzerkennung können beispielsweise Bestandteil der Kennungsdaten sein. Zusätzlich ist eine Signatur in dem ID-Token enthalten, also beispielsweise eine verschlüsselte Prüfsumme, beispielsweise ein verschlüsselter Hashwert. Aus Sicht der Autorisierungseinheit behauptet somit also die Anwendung mittels des ID-Tokens, eine bestimmte Anwendung zu sein und einem bestimmten Besitzer zu gehören. Der Zugriff auf die Dienstfunktion wird dann durch die Autorisierungseinheit ohne Rücksprache mit dem aktuellen Benutzer des Geräts blockiert, falls anhand der Signatur erkannt wird, dass der ID-Token manipuliert ist. Hierdurch ergibt sich der Vorteil, dass es zu keiner Fehlentscheidung des aktuellen Benutzers kommen kann, wenn versucht wird mittels eines manipulierten ID-Token Zugriff auf die Dienstfunktion des Geräts zu erlangen.
Eine Ausführungsform sieht dabei vor, dass bei unmanipuliertem, signiertem ID-Token das Ausstattungskriterium erfüllt ist und der Zugriff durch die Autorisierungseinheit selbständig (ohne Rückfrage an den Benutzer) bestätigt wird, falls eine Benutzerkennung des aktuellen Benutzers des Geräts und die besagte Besitzerkennung aus dem ID-Token signalisieren, dass der Besitzer der Anwendung einerseits und der aktuelle Besitzer des Geräts andererseits ein und dieselbe Person sind. Mit anderen Worten erfolgt die Bestätigung des Zugriffs automatisiert durch die Autorisierungseinheit ohne Rücksprache oder Rückfrage an den Benutzer, wenn der Benutzer eine eigene Anwendung an das Gerät anschließt, beispielsweise sein eigenes Smartphone. Voraussetzung hierfür ist lediglich, dass der Benutzer mit der Anwendung einen ID-Token verwendet, der durch den Serverdienst signiert ist.
Eine Ausführungsform sieht vor, dass bei unmanipuliertem, signiertem ID-Token das Ausstattungskriterium verletzt ist, falls die Benutzerkennung einerseits und die Besitzerkennung andererseits signalisieren, dass der Benutzer der Anwendung von dem aktuellen Benutzer des Geräts verschieden ist. Das Ausstattungskriterium schreibt also vor, dass nur dann der Zugriff automatisiert gewährt wird, wenn der aktuelle Benutzer des Geräts auch der Besitzer der Anwendung ist. Anderenfalls, wenn beispielsweise ein Freund oder Bekannter des Benutzers des Geräts seine eigene Anwendung, beispielsweise sein eigenes Smartphone, an das Gerät anschließen möchte, um auf die Dienstfunktion zuzugreifen, ist das Ausstattungskriterium verletzt (Besitzerkennung ungleich Benutzerkennung) und damit erfolgt die Rückfrage beim aktuellen Benutzer des Geräts in der beschriebenen Weise zum Ermitteln der Zulassungsentscheidung des Benutzers.
In diesem Zusammenhang sieht eine Ausführungsform vor, dass für den Fall, dass die Zugriffsentscheidung des Benutzers hierbei den Zugriff bestätigt, der signierte ID-Token gespeichert wird und hierdurch zukünftig das Ausstattungskriterium auch dann erfüllt ist und der Zugriff durch die Autorisierungseinheit (automatisiert, ohne Benutzerrückfrage) gewährt wird, falls aus der Anwendung nochmals der signierte ID-Token mit dieser Besitzerkennung empfangen wird. Mit anderen Worten muss also beispielsweise der besagte Freund oder Bekannte des aktuellen Benutzers des Geräts nur einmal die Zustimmung des Benutzers des Geräts erhalten und kann dann in Zukunft mit dem signierten ID-Token selbständig den Zugriff ohne nochmalige Rückfrage bei dem aktuellen Benutzer des Geräts erlangen.
Dabei ist gemäß einer Ausführungsform aber vorgesehen, dass der signierte ID-Token nur solange gespeichert gehalten wird, bis ein vorbestimmtes Ablaufkriterium erfüllt ist. Das Ablaufkriterium kann beispielsweise eine vorbestimmte begrenzte Zeitdauer für das Speichern des ID-Tokens angeben und/oder ein Löschereignis. Beispielsweise kann die Zeitdauer in einem Bereich von einer Minute bis einem Monat liegen. Als ein mögliches Löschereignis kann beispielsweise das Ende einer Fahrt definiert sein, falls das Gerät in einem Kraftfahrzeug eingebaut ist.
Bisher wurde nur beschrieben, dass für eine Anwendung der Zugriff auf die Dienstfunktion des Geräts „bestätigt“ werden kann. Was dies bedeutet ist, im Folgenden genauer beschrieben.
Eine Ausführungsform sieht hierbei vor, dass zum Bestätigen des Zugriffs ein Accesstoken oder Zugriffstoken, also ein Datensatz, an die Anwendung ausgesendet wird. Bei jeder Zugriffsanfrage der Anwendung auf die Dienstfunktion, wenn also die Anwendung die Dienstfunktion tatsächlich nutzen möchte, wird dann durch die Autorisierungseinheit überprüft, ob diese Zugriffsanfrage das Zugriffstoken enthält. Nur für diesen Fall wird die Dienstfunktion auch tatsächlich für die Anwendung aktiviert. Der Zugriffstoken kann beispielsweise verschlüsselte Zulassungsdaten oder Autorisierungsdaten enthalten, wobei die Verschlüsselung durch die Autorisierungseinheit durchgeführt werden kann. Die Entschlüsselung und/oder Verifizierung ist dann nur durch die Autorisierungseinheit möglich, die daran erkennen kann, ob die Anwendung einen bestätigten Zugriff auf die Dienstfunktion hat. Durch die Forderung, dass jede Zugriffsanfrage das Zugriffstoken enthalten oder umfassen muss, ist in vorteilhafter Weise sichergestellt, dass nicht in der Zwischenzeit mittels einer anderen Anwendung ebenfalls Zugriff auf die Dienstfunktion erhalten werden kann. Diese andere Anwendung müsste dann im Besitz des Zugriffstokens sein.
Bisher ist nur das Verfahren im Zusammenhang mit einer einzelnen Dienstfunktion beschrieben worden. Eine Ausführungsform sieht vor, dass durch das Gerät mehrere Dienstfunktionen an der digitalen Schnittstelle bereitgestellt werden und durch den Zugriffstoken dann angegeben ist, für welche der Dienstfunktionen der Zugriffstoken gilt. Der Zugriffstoken legt also einen Zugriffsbereich oder einen sogenannten Scope fest oder legt eine Menge der von der Anwendung nutzbaren oder zugreifbaren Dienstfunktionen fest. Durch die Ausführungsform ergibt sich der Vorteil, dass für unterschiedliche Anwendungen jeweils unterschiedliche Dienstfunktionen freigegeben oder zugreifbar gemacht werden können. Die Autorisierungseinheit informiert dann bevorzugt im Falle einer Revokation des Zugriffstokens für einen Erlaubnisentzug nur diese Dienstfunktionen gezielt durch vorheriges Abspeichern, welche Dienstfunktion informiert werden muss, oder sie informiert mittels einer Broadcast-Nachricht alle Dienstfunktionen über diese Revokation. Jede Dienstfunktion, für welche der revozierte Zugriffstoken galt, blockiert dann zukünftig jede den revozierten Zugriffstoken enthaltende Zugriffsanfrage. Die Autorisierungseinheit speichert also, welche Dienstfunktion (Service) mittels welchem Zugriffstoken genutzt werden darf. Erfolgt eine „Revokation“ (Erlaubnisentzug) eines Zugriffstokens, dann wird jede gespeicherte Dienstfunktion über die Revokation informiert und die Dienstfunktion kann ihren Dienst auf die verbliebenden Berechtigungen (Zugriffstokens) beschränken. Anstelle des Merkens oder Speichern der einzelnen Dienstfunktionen ist auch ein Broadcast an alle Dienstfunktionen möglich, um sie über die Revokation zu informieren.
Eine Ausführungsform sieht vor, dass die zumindest eine gerätefremde Anwendung jeweils ein mobiles Endgerät und/oder einen Internetdienst eines Servers des Internets und/oder einen PC (Personal Computer) und/oder eine Wartungseinrichtung für das Gerät umfasst.
Als das die Dienstfunktion bereitstellende Gerät ist gemäß einer besonders bevorzugten Ausführungsformen ein Fahrzeuggerät eines Kraftfahrzeugs vorgesehen. Ein solches Gerät kann beispielsweise ein Infotainmentsystem und/oder ein Telematiksystem und/oder ein Türsteuergerät (zum Steuern einer Verriegelung zumindest einer Fahrzeugtür und/oder eines Kofferraumdeckels) sein.
Die Erfindung umfasst auch die Autorisierungseinheit, die geräteextern oder geräteintern bereitgestellt sein kann. Sie weist eine Prozessoreinrichtung auf, die dazu eingerichtet ist, die die Autorisierungseinheit betreffenden Schritte einer Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen.
Die Erfindung umfasst auch ein Gerät, welches dazu eingerichtet ist, zumindest einer gerätefremden Anwendung (wie bereits beschrieben) zumindest eine Dienstfunktion an einer digitalen Schnittstelle bereitzustellen. Das Gerät weist dabei eine Prozessoreinrichtung auf, die dazu eingerichtet ist, eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Die Prozessoreinrichtung kann hierzu zumindest einen Mikroprozessor und/oder zumindest einen Mikrokontroller aufweisen. Es kann ein Programmcode bereitgestellt sein, der dazu eingerichtet ist, bei Ausführen durch die Prozessoreinrichtung die Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Der Programmcode kann in einem Datenspeicher der Prozessoreinrichtung gespeichert sein.
Gemäß einer Ausführungsform ist das Gerät insbesondere ein Fahrzeuggerät für ein Kraftfahrzeug, insbesondere ein Infotainmentsystem, ein Telematiksystem oder ein Türsteuergerät. Für ein Gerät eines Kraftfahrzeugs ist das Verfahren ganz besonders vorteilhaft, da hier damit gerechnet werden muss, dass eine Funkverbindung zum Internet und damit zu einem Serverdienst des Internets unterbrochen sein kann. Hier muss dennoch eine Autorisierung einer Anwendung, die eine Dienstfunktion des Geräts im Kraftfahrzeug nutzen möchte, also darauf zugreifen möchte, möglich sein.
Die Erfindung umfasst entsprechend auch ein Kraftfahrzeug mit einer Ausführungsform des erfindungsgemäßen Geräts. Das Kraftfahrzeug ist insbesondere als Kraftwagen, bevorzugt als Personenkraftwagen oder Lastkraftwagen, ausgestaltet.
Beispiele für Dienstfunktionen, wie sie an einer digitalen Schnittstelle jeweils bereitgestellt sein können, sind: eine Angabe einer Geoposition, die in dem Gerät gespeichert ist; eine Angabe von Nutzerdaten; das Entgegennehmen und/oder Ausgeben von Mediendaten (zum Beispiel Musikdaten und/oder Videodaten); das Ansteuern einer Fahrzeugkomponente oder einer Gerätekomponente durch das Gerät in Abhängigkeit von einem Steuerbefehl der Anwendung (beispielsweise das Entriegeln und/oder Verriegeln einer Schließanlage eines Kraftfahrzeugs). Diese Beispiels sind nicht als eine abschließende Liste zu verstehen.
Die Erfindung umfasst auch die Kombinationen der beschriebenen Ausführungsformen.
Im Folgenden ist ein Ausführungsbeispiel der Erfindung beschrieben. Hierzu zeigt:

1 eine schematische Darstellung einer Ausführungsform des erfindungsgemäßen Geräts;
2 ein Diagramm zur Veranschaulichung einer Ausführungsform des erfindungsgemäßen Verfahrens; und
3 ein Diagramm zur Veranschaulichung einer Überprüfung eines Zugriffs auf eine Dienstfunktion des Geräts von 1 auf der Grundlage eines Zugriffstokens.

In den Figuren sind funktionsgleiche Elemente jeweils mit denselben Bezugszeichen versehen.
Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden und damit auch einzeln oder in einer anderen als der gezeigten Kombination als Bestandteil der Erfindung anzusehen sind. Des Weiteren sind die beschriebenen Ausführungsformen auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
1 zeigt ein Gerät 10, das beispielsweise in einem Kraftfahrzeug 11 eingebaut sein kann. Das Gerät 10 kann in diesem Fall beispielsweise ein Infotainmentsystem oder Telematiksystem oder ein Türsteuergerät sein. Das Gerät 10 kann mit einer Ausgabeeinrichtung 12 gekoppelt sein, bei der es sich beispielsweise um einen Bildschirm des Kraftfahrzeugs 11 handeln kann. Die Ausgabeeinrichtung 12 kann auch eine Sprachausgabe vorsehen. Der Bildschirm kann auch beispielsweise als ein Touchscreen oder Berührungsbildschirm ausgestaltet sein. In diesem Fall kann der Bildschirm auch eine Eingabeeinrichtung 13 repräsentieren oder darstellen. Als Eingabeeinrichtung 13 kann aber auch beispielsweise eine mechanische Eingabeeinrichtung mit zumindest einer Taste und/oder eine Spracheingabe vorgesehen sein.
Das Gerät 10 kann über die Ausgabeeinrichtung 12 Kennungsdaten 14 an einen Benutzer 15 des Geräts 10 ausgeben und über die Eingabeeinrichtung 13 von dem Benutzer 15 zu den Kennungsdaten 14 eine Zulassungsentscheidung 16 empfangen.
Das Gerät 10 kann beispielsweise in einem Kommunikationsnetzwerk eine digitale Schnittstelle 17 bereitstellen oder erzeugen. Die Schnittstellt 17 kann beispielsweise auf der Grundlage von Ports für das TCP/IP (TCP - Transport Control Protokoll, IP - Internet Protokoll) realisiert sein. An der Schnittstelle 17 kann das Gerät 10 zumindest eine Dienstfunktion 18 zum Abruf oder Zugriff über die Schnittstelle 17 bereitstellen. Eine Dienstfunktion 18 kann beispielsweise vorsehen, aktuelle Geokoordinaten oder eine aktuelle GeoLocation XY des Geräts 10 und damit beispielsweise des Kraftfahrzeugs 11 über die Schnittstelle 17 auszugeben. Eine Dienstfunktion 18 kann beispielsweise darin bestehen, eine Medienwiedergabe 19 des Geräts 10 über die Schnittstelle 17 zu steuern.
An die Schnittstelle 17 kann eine gerätefremde Anwendung 20 angekoppelt werden. Mit anderen Worten kann eine Kommunikationsverbindung 21 durch die Anwendung 20 zur Schnittstelle 17 aufgebaut werden. Die Kommunikationsverbindung 21 kann funkbasiert und/oder kabelbasiert erfolgen. Die Kommunikationsverbindung 21 kann beispielsweise über eine Bluetooth-Verbindung und/oder eine WLAN-Verbindung und/oder eine USB-Verbindung geführt oder realisiert sein. Bevorzugt ist vorgesehen, dass die Schnittstelle 17 nur mittels einer verschlüsselten Kommunikationsverbindung 21 aufgebaut oder erreicht oder kontaktiert werden kann. Beispielsweise kann hierzu das Protokoll https (secure hyptertext transfer protocol) vorgesehen sein.
In der Anwendung 20 kann beispielsweise ein Anwendungsprogramm 22 ausgeführt werden, welches bei Ausführen durch die Anwendung 20 die Anwendung 20 veranlasst, eine Dienstfunktion 18 des Geräts 10 an der Schnittstelle 17 zu nutzen. Nicht jede Anwendung 20 darf aber eine Dienstfunktion 18 des Geräts 10 nutzen. Der Zugriff auf die zumindest eine Dienstfunktion des Geräts 10 kann durch eine Autorisierungseinheit 23 kontrolliert werden. Die Autorisierungseinheit 23 kann ein Programmmodul einer Prozessoreinrichtung 24 des Geräts sein. Auch die Dienstfunktionen 18 können jeweils durch ein Programmmodul für die Prozessoreinrichtung 24 des Geräts 10 realisiert sein. Die Autorisierungseinheit kann auch außerhalb des Geräts angeordnet sein und über eine verschlüsselte Kommunikationsverbindung mit dem Gerät kommunizieren. Die Autorisierungseinheit kann in diesem Fall z.B. durch einen Server des Internets realisiert oder betrieben werden.
Im Folgenden ist im Zusammenhang mit 1 und 2 veranschaulicht, wie der Zugriff der Anwendung 20 auf eine Dienstfunktion 18 entweder bestätigt oder abgelehnt werden kann, ohne dass das Gerät 10 währenddessen eine weitere Kommunikationsverbindung zu einem Serverdienst des Internets, also einem sogenannten Backend oder einem Computer des Internets, benötigt.
2 veranschaulicht hierzu an dem Verfahren beteiligte Komponenten, nämlich die Anwendung 20, die Autorisierungseinheit 23, die Dienstfunktion 18, einen Serverdienst 25 des Internets und den Benutzer 15. Der Serverdienst 25 kann beispielsweise durch einen Hersteller des Kraftfahrzeugs 11 oder einen anderen OEM (Originell Equipment Manufacturer) betrieben werden.
Dargestellt sind drei voneinander getrennte Phasen P1, P2, P3, zwischen denen jeweils ein beliebiger Zeitraum vergehen kann. Eine Überprüfung einer Bedingung und daraus folgende Handlungsalternativen oder kurz Alternativen für den Verlauf der jeweiligen Phase P2, P3, sind in 2 und 3 jeweils mit A, A1, A2, A3,... gekennzeichnet.
Die Phase P1 ist eine Initialisierungsphase, in welcher die Anwendung 20 selbst einen ID-Token 26 erzeugen kann, dessen Struktur beispielsweise öffentlich bekannt sein und daher von jeder Anwendung 20 genutzt oder erzeugt werden kann. Somit kann ein ID-Token 26 ungeprüfte Daten enthalten. In den ID-Token 26 kann die Anwendung 20 ihre Kennungsdaten 14, beispielsweise eine Beschreibung der Anwendung und/oder eine Besitzerkennung des Besitzers der Anwendung, eintragen.
Die Phase P2 ist eine optionale Signierungsphase, was in 2 durch die Markierung Optional 0 gekennzeichnet ist. In der Signierungsphase P2 kann die Anwendung 20 den ID-Token an den Serverdienst 25, beispielsweise über eine Internetverbindung, übertragen und eine Signierung des ID-Tokens 26 anfordern. Hierzu kann beispielsweise vorgesehen sein, dass sich der Besitzer der Anwendung 20 mittels eines Nutzernamens und eines Passworts oder einer anderen Authentifizierungsmaßnahme in einem Benutzerkonto des Serverdienstes 25 anmeldet und hierdurch seine Identität bestätigt. Die hierzu verwendete Kommunikationsverbindung zwischen der Anwendung 20 und Serverdienst 25 kann beispielsweise mittels eines JWT (Json-Web-Token) gesichert sein. Hierdurch ist verhindert, dass ein gefälschter ID-Token 26 mit einer Bezeichnung einer anderen Anwendung 20 und/oder einer Besitzerkennung eines anderen Besitzers, an den Serverdienst 25 übertragen wird. Im JWT kann optional eine Festlegung stattfinden, welches Fahrzeug/welche Fahrzeuge zu der Benutzerkennung des Benutzers gehört/gehören.
Hat sich der Besitzer der Anwendung 20 korrekt authentifiziert (o.k.), so kann in einer Alternative A ein signierter ID-Token 27 von dem Serverdienst 25 an die Anwendung 20 zurück übermittelt werden. Ist dagegen die Authentifizierung fehlgeschlagen, so wird gemäß der Alternative A ein Signierfehler 28 an die Anwendung 20 signalisiert.
Die Phase P2 kann durchgeführt werden, wenn eine Kommunikationsverbindung zu dem Serverdienst 25 besteht, also insbesondere eine Internetverbindung der Anwendung 20.
Die Phase P3 kann beispielsweise während einer Fahrt des Kraftfahrzeugs 11 stattfinden. Allgemein ist es für die Phase P3 aufgrund des verwendeten Verfahrens unnötig, dass eine Kommunikationsverbindung der Anwendung 20 oder des Geräts 10 zu dem Serverdienst 25 bestehen muss. Es ist also für das Verfahren in der Phase P3 keine Internetverbindung notwendig.
Die Phase P3 stellt die bereits beschriebene Anfrage der Anwendung 20 nach einem Zugriff auf eine Dienstfunktion 18 dar.
In einer ersten Überprüfung in einer Alternative A1 wird überprüft, ob die Kommunikationsverbindung 21 über eine verschlüsselte Kommunikationsverbindung erfolgt, bei welcher zumindest die Anwendung 20, bevorzugt auch das Gerät 10, jeweils einen kryptographischen Schlüssel verwendet, der durch eine vorbestimmte Zertifizierungsstellt zertifiziert ist. In diesem Fall ergibt sich in Alternative A1 eine gegenseitig authentifizierte verschlüsselte Verbindung, bevorzugt eine gegenseitig authentifizierte TLS-Verbindung, was hier als maTLS (mutual authentication TLS) bezeichnet ist. Sendet dann die Anwendung 20 an die Autorisierungseinheit 23 den ID-Token 26 oder den signierten ID-Token 27, so ist hierbei für die Autorisierungseinheit 23 ein Ausstattungskriterium für den empfangenen Token erfüllt und die Autorisierungseinheit 23 kann selbständig einen Zugriffstoken 29 für die Anwendung 20 ausstellen oder erzeugen und an diese übermitteln, falls die authentifizierte verschlüsselte Verbindung von einer vorbestimmte Zertifizierungsstelle zertifiziert ist. Die Anwendung 20 kann dann auf der Grundlage des Zugriffstokens 29 die Dienstfunktion 18 auslösen oder anfragen oder anfordern. Mittels des Zugriffstokens 29 wird dann die Dienstfunktion 18 freigeschaltet oder genehmigt.
In der Alternative A1 zur gegenseitig authentifizierten verschlüsselten Kommunikationsverbindung 21, wenn also keine gegenseitige Authentifizierung möglich ist, wird in einer weiteren Alternative A2 überprüft, ob ein signiertes ID-Token 27 gesendet wurde, was in 2 als STA (Signed Token Available - signierter ID-Token verfügbar) gekennzeichnet ist. Eine weitere Alternative A3 überprüft, ob der signierte ID-Token 27 manipuliert ist. Ist dies der Fall, wird eine Ablehnung 30 aufgrund manipulierten Tokens von der Autorisierungseinheit 23 an die Anwendung 20 signalisiert. Der Zugriff auf die Dienstfunktion 18 ist somit abgelehnt. Ist der ID-Token 27 dagegen unmanipuliert, so kann in einer Alternative A4 überprüft werden, ob eine in dem ID-Token 27 enthaltene Besitzerkennung 31 identisch ist mit einer Benutzerkennung des Benutzers 15, die in dem Gerät 10 bereitgestellt sein kann. Der Benutzer 15 kann beispielsweise anhand eines von ihm verwendeten Smartphones und/oder Fahrzeugschlüssels und/oder anhand einer vorangegangenen Eingabe an dem Gerät 10 erkannt werden. Ist der Besitzer der Anwendung 20 identisch mit dem Benutzer 15, so kann durch die Autorisierungseinheit 23 ebenfalls ein Zugriffstoken 29 erzeugt und an die Anwendung 20 übermittelt werden. Somit erfüllt auch diese Bedingung das Ausstattungskriterium für eine automatische Zugriffsautorisierung.
Ist dagegen bei der Alternative A4 der Besitzer der Anwendung 20 unterschiedlich zum Benutzer 15, so erfüllt der signierte ID-Token 27 nicht die nötige Ausstattung und damit das notwendige Ausstattungskriterium. Die Autorisierungseinheit 23 kann somit nicht selbständig entscheiden, ob ein Zugriffstoken 29 ausgestellt werden darf. Deshalb können in einem Schritt S10 durch die Autorisierungseinheit 23 mittels der Ausgabeeinrichtung 12 dem Benutzer 15 die Kennungsdaten 14 angegeben werden. In einer weiteren Alternative A5 kann nun überprüft werden, ob in einem Schritt S11 von dem Benutzer 15 über die Eingabeeinrichtung 13 eine Zulassungsentscheidung 16 empfangen wird, die angibt, dass der Zugriff bestätigt werden kann. In diesem Fall kann der Zugriffstoken 29 durch die Autorisierungseinheit 23 erzeugt und an die Anwendung 20 ausgegeben werden. Wird dagegen in einem Schritt S12 alternativ dazu in der Alternative A5 eine Zulassungsentscheidung 16 empfangen, die angibt, dass der Benutzer den Zugriff ablehnt, so wird durch die Autorisierungseinheit 23 ein Ablehnungssignal 33 erzeugt und an die Anwendung 20 ausgesendet. Der Anwendung 20 ist somit der Zugriff auf die Dienstfunktion 18 verweigert.
In der Alternative A2 kann der Fall auftreten, dass kein signierter ID-Token gesendet wird, sondern der unsignierte ID-Token 26. Auch in diesem Fall kann in einem Schritt S13 die Autorisierungseinheit 23 die Kennungsdaten 14 über die Ausgabeeinrichtung 12 dem Benutzer 15 ausgeben und in einer Alterative A6 in einem Schritt S14 eine Zulassungsentscheidung 16 über die Eingabeeinrichtung 13 von dem Benutzer 15 empfangen, welche den Zugriff bestätigt, sodass ein Zugriffstoken 29 durch die Autorisierungseinheit 23 erzeugt und an die Anwendung 20 ausgesendet werden kann. Wird in der Alternative A6 in einem Schritt S15 dagegen als Zulassungsentscheidung 16 von dem Benutzer 15 über die Eingabeeinrichtung 13 durch das Gerät 10 empfangen, dass der Benutzer 15 den Zugriff ablehnt, so wird durch die Autorisierungseinheit 23 der Anwendung 20 eine Ablehnung 33 signalisiert.
3 veranschaulicht, wie durch die Anwendung 20 auf der Grundlage des Zugriffstokens 29 eine Zugriffsanfrage 34 an der Schnittstelle 17 für die Dienstfunktion 18 gesendet werden kann. Diese Zugriffsanfrage 34 kann wiederholt erfolgen, um die Dienstfunktion 18 wiederholt zu nutzen, weshalb hier in 3 eine Schleife oder Loop L angegeben ist. Die Dienstfunktion 18 kann nach Empfangen der Zugriffsanfrage 34 die Autorisierungseinheit 23 auffordern, den Zugriffstoken 29 zu überprüfen. Die Bearbeitung der Zugriffsanfrage 34 stellt eine Phase P4 dar.
In einer Alternative A7 kann durch die Autorisierungseinheit 23 in einem Schritt S16 erkannt werden, dass der Zugriffstoken 29 valide oder gültig ist und dies der Dienstfunktion 18 signalisieren. Beispielsweise kann die Autorisierungseinheit 23 verifizieren, dass der Zugriffstoken 29 von der ihr selbst erzeugt wurde (z.B. anhand einer kryptographischen Verschlüsselung) und/oder der Zugriffstoken 29 noch gültig ist. Die Dienstfunktion 18 kann dann in einem Schritt S17 mit der Ausführung und dem Ergebnis der Dienstfunktion 18 reagieren und das Ergebnis 35 der Anwendung 20 übermitteln. Optional kann eine „Notifizierung“ (Benachrichtigung) vorgesehen sein. Die Autorisierungseinheit 23 speichert hierbei, welche Dienstfunktion (Service) mittels welchem Zugriffstoken 29 genutzt werden darf. Erfolgt eine „Revokation“ (Erlaubnisentzug) eines Zugriffstokens 29, dann wird jede gespeicherte Dienstfunktion über die Revokation informiert und die Dienstfunktion kann ihren Dienst auf die verbliebenden Berechtigungen (Zugriffstokens) beschränken. Anstelle des Merkens oder Speichern der einzelnen Dienstfunktionen ist auch ein Broadcast an alle Dienstfunktionen möglich, um sie über die Revokation zu informieren.
Wird bei der Alternative A7 durch die Autorisierungseinheit 23 in einem Schritt S18 stattdessen erkannt, dass der Zugriffstoken 29 ungültig ist, weil beispielsweise eine Gültigkeitsdauer abgelaufen ist, so kann die Autorisierungseinheit 23 die Ungültigkeit des Zugrifftokens 29 an die Dienstfunktion 18 signalisieren. Die Dienstfunktion 18 kann dann in einem Schritt S19 mit einer Ablehnung 36 der Zugriffsanfrage 34 reagieren.
Die Vernetzung des Geräts 10 mit externen und internen Softwarekomponenten (innerhalb des Fahrzeugs und außerhalb des Fahrzeugs) kann somit auch ohne eine durchgehende Internetverbindung kontrolliert oder abgesichert werden. Zum Schutz vor z.B. Datendiebstahl, unberechtigter Manipulation und/oder zum Schutz der Privatsphäre ist ein Verfahren vorgesehen, welches die Programmierschnittstelle des Geräts schützt. Ein Authentifikations- und Autorisations-Mechanismus wird vorgesehen. Der Datenverkehr wird bevorzugt zunächst mit Hilfe von Transportlayer Security (TLS) gegen Abhören durch dritte Komponenten gesichert. Innerhalb des TLS-Tunnels zwischen Softwarekomponenten oder Anwendungsprogrammen 22, die auf beliebigen Orten gehostet sein können, z.b. Infotainmentsystem und externes Steuergerät oder Smartphone und Infotainmentsystem, wird schließlich mit Tokens gearbeitet.
Die Schnittstelle 17 kann aus vielen einzelnen Schnittstellenelementen (Pfaden) bestehen, die also solche einzeln ausgewiesen werden können der Zugriff auf diese Pfade kann jeweils gewährt oder verweigert werden (Scope). Jeder Pfad kann zu einer bestimmten der Dienstfunktionen 18 führen.
Um eine Verwaltung der Zugriffsrechte auf diese Dienstfunktionen 18 von außerhalb des Fahrzeugs zu erlauben, wird optional das Backend (Serverdienst 25) einbezogen. Das Backend ist ein vertrauenswürdiger Partner und kann den ID-Token, der den Scope als Wunsch zur Nutzung enthält, signieren. Wir diesem Wunsch backendseitig - z.B. durch Einstellungen im Nutzerportal, entsprochen, so wird der ID-Token signiert.
Mit Hilfe des signierten oder unsignierten ID-Tokens kann eine externe Anwendung 20 bei einem Autorisierungsservice der Autorisierungseinheit 23 auf dem betroffenen Gerät (Diensterbringer) die Berechtigung für Zugriff erbitten. Sollte der ID-Token nicht signiert sein, ist der aktuelle Anwender des Gerätes um Erlaubnis für Zugriff zu fragen. Durch diesen kann dem Zugriffswunsch entsprochen werden oder der Zugriff verweigert werden oder teilweise (nur eine oder einige angefragte Dienstfunktionen) entsprochen werden. Beispielweise kann Zugriff auf GeoLocation gewährt werden, die Mediasteuerung jedoch verwehrt werden. Im Falle mindestens teilweiser Genehmigung wird ein Zugriffstoken (access_token) für die zukünftige Nutzung ausgeliefert. Dieser Zugriffstoken ist mit jeder API-Interaktion (Schnittstellenzugriff) zu senden, um die Zulässigkeit der Zugriffsanfrage 34 auszuweisen. Zugriffsanfragen 34 können entsprechend beantwortet oder deren Beantwortung verweigert werden.
Zugriffstokens haben festgelegte Gültigkeiten und können auch als „ungültig“ markiert werden, sodass ein Rechte-Management auch nach Tokenerteilung ermöglicht wird.
2 zeigt einen exemplarischen Ablauf der Authentifikation und Autorisation. Es ist zu beachten, dass der Datenaustausch bevorzugt gesichert über TLS zu erfolgen hat.
Insgesamt zeigen die Beispiele, wie durch die Erfindung an einer digitalen Schnittstellen eines Gerät ein Zugriff einer gerätefremden Anwendung auf eine Dienstfunktion des Geräts kontrolliert werden kann.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102017102539 A1 [0003]
DE 102013113667 A1 [0004]
DE 102015209108 A1 [0005]

Claims

Verfahren zum Kontrollieren eines Zugriffs zumindest einer gerätefremden Anwendung (20) auf eine digitale Dienstfunktion (18) an einer digitalen Schnittstelle (17) eines Geräts (10), wobei durch eine Autorisierungseinheit (23) aus der jeweiligen Anwendung (20) ein ID-Token (26, 27) mit Kennungsdaten (14) der Anwendung (20) empfangen wird und jeweils geprüft wird, ob der ID-Token (26, 27) ein vorbestimmtes Ausstattungskriterium für eine automatische Zugriffsautorisierung erfüllt, dadurch gekennzeichnet, dass für den Fall, dass das Ausstattungskriterium verletzt ist, - einem aktuellen Benutzer (15) des Geräts (10) über eine Ausgabeeinrichtung (12) die Kennungsdaten (14) ausgegeben werden und - von dem Benutzer (15) über eine Eingabeeinrichtung (13) eine Zulassungsentscheidung (16) empfangen wird und - durch die Autorisierungseinheit (23) in Abhängigkeit von der Zulassungsentscheidung (16) des Benutzers (15) der Zugriff bestätigt oder abgelehnt wird.
Verfahren nach Anspruch 1, wobei für den Fall, dass das Ausstattungskriterium erfüllt ist, unabhängig von dem aktuellen Benutzer (15) durch die Autorisierungseinheit (23) über das Bestätigen oder Ablehnen des Zugriffs anhand des ID-Tokens (26, 27) entschieden wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Ausstattungskriterium als eine für die automatische Zugriffsautorisierung ausreichende Bedingung umfasst, dass der ID-Token (26, 27) über eine mittels eines Verschlüsselungsverfahrens verschlüsselte Kommunikationsverbindung (21) von der Anwendung (20) zu dem Gerät (10) übertragen wird und hierbei zumindest die Anwendung (20) einen kryptographischen Schlüssel verwendet, der von einer vorbestimmten Zertifizierungsstelle zertifiziert ist, die in der Autorisierungseinheit (23) unabhängig von der Anwendung (20) bereits als vertrauenswürdig gekennzeichnet ist, und der Zugriff in diesem Fall durch die Autorisierungseinheit (23) bestätigt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Ausstattungskriterium als eine für die automatische Zugriffsautorisierung ausreichende Bedingung umfasst, dass der ID-Token (27) die Anwendung (20) und eine Besitzerkennung (31) eines Besitzers der Anwendung (20) angibt und der ID-Token (27) von einem vorbestimmten Serverdienst des Internets mit einer Signatur signiert ist, und der Zugriff blockiert wird, falls anhand der Signatur erkannt wird, dass der ID-Token (27) manipuliert ist (S12) .
Verfahren nach Anspruch 4, wobei bei unmanipuliertem ID-Token (27) das Ausstattungskriterium erfüllt ist und der Zugriff bestätigt wird, falls eine Benutzerkennung (32) des aktuellen Benutzers (15) des Geräts (10) und die Besitzerkennung (31) signalisieren, dass der Besitzer der Anwendung (20) und der aktuelle Benutzer (15) des Geräts (10) ein und dieselbe Person sind.
Verfahren nach Anspruch 4 oder 5, wobei bei unmanipuliertem ID-Token (27) das Ausstattungskriterium verletzt ist, falls die Benutzerkennung (32) und die Besitzerkennung (31) signalisieren, dass der Besitzer der Anwendung (20) von dem aktuellen Benutzer (15) des Geräts (10) verschieden ist.
Verfahren nach Anspruch 6, wobei, falls die Zugriffsentscheidung (16) des Benutzers (15) den Zugriff bestätigt, der signierte ID-Token (27) gespeichert wird und hierdurch zukünftig das Ausstattungskriterium auch dann erfüllt ist und der Zugriff durch die Autorisierungseinheit (23) gewährt wird, falls aus der Anwendung (20) nochmals der signierte ID-Token (27) mit der Besitzerkennung (31) empfangen wird.
Verfahren nach Anspruch 7, wobei der signierte ID-Token (27) nur solange gespeichert gehalten wird, bis ein vorbestimmtes Ablaufkriterium erfüllt ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei zum Bestätigen des Zugriffs ein Zugriffstoken (29) an die Anwendung (20) ausgesendet wird und bei jeder Zugriffsanfrage (34) der Anwendung (20) auf die Dienstfunktion (18) überprüft wird, ob die Zugriffsanfrage (34) das Zugriffstoken (29) enthält, und nur in diesem Fall die Dienstfunktion (18) aktiviert wird.
Verfahren nach Anspruch 9, wobei durch das Gerät (10) mehrere Dienstfunktionen (18) bereitgestellt werden und durch den Zugriffstoken (29) angegeben ist, für welche der Dienstfunktionen (18) der Zugriffstoken (29) gilt, wobei die Autorisierungseinheit (23) im Falle einer Revokation des Zugriffstokens (29) für einen Erlaubnisentzug nur diese Dienstfunktionen (18) gezielt durch vorheriges Abspeichern, welche Dienstfunktion (18) informiert werden muss, oder mittels einer Broadcast-Nachricht alle Dienstfunktionen (18) über die Revokation informiert und jede Dienstfunktion (18), für welche der revozierte Zugriffstoken (29) galt, zukünftig jede den revozierten Zugriffstoken (29) enthaltende Zugriffsanfrage (34) blockiert.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die zumindest eine gerätefremde Anwendung (20) ein mobiles Endgerät und/oder einen Internetdienst eines Servers des Internets und/oder einen PC und/oder eine Wartungseinrichtung für das Gerät umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei als Gerät (10) ein Fahrzeuggerät eines Kraftfahrzeugs (11) vorgesehen wird.
Autorisierungseinheit (23), die eine Prozessoreinrichtung (24) aufweist, die dazu eingerichtet ist, ein Verfahren nach einem der vorhergehenden Ansprüche durchzuführen.
Gerät (10), wobei das Gerät (10) ein Fahrzeuggerät eines Kraftfahrzeugs (11), insbesondere ein Infotainmentsystem, ein Telematiksystem oder ein Türsteuergerät, ist und dazu eingerichtet ist, zumindest einer gerätefremden Anwendung (20) zumindest eine digitale Dienstfunktion (18) an einer digitalen Schnittschelle (17) bereitzustellen, dadurch gekennzeichnet, dass das Gerät (10) eine Prozessoreinrichtung (24) aufweist, die dazu eingerichtet ist, die das Gerät (10) betreffenden Schritte eines Verfahrens nach einem der Ansprüche 1 bis 12 durchzuführen.
Kraftfahrzeug (11) mit einem Gerät (10) nach Anspruch 14.