DE102020105061A1

DE102020105061A1 - Verfahren und vorrichtung für fahrzeugunterstützte dynamische mehrfaktorauthentifizierung

Info

Publication number: DE102020105061A1
Application number: DE102020105061.5A
Authority: DE
Inventors: Venkata Maruthe Ravikumara Sharma Chengalvala; James Wilhelm Heaton
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2019-02-28
Filing date: 2020-02-26
Publication date: 2020-09-03
Also published as: US20200276960A1; US10814835B2; CN111625808A

Abstract

Diese Offenbarung stellt ein Verfahren und eine Vorrichtung für fahrzeugunterstützte dynamische Mehrfaktorauthentifizierung bereit. Ein System beinhaltet einen Prozessor, der eine Authentifizierungsanforderung an einem Fahrzeug von einer Anwendung empfängt, die auf einer Vorrichtung in Kommunikation mit dem Fahrzeug ausgeführt wird, einschließlich einer Sicherheitsbezeichnung. Das empfangende Fahrzeug bestimmt dann, ob das Fahrzeug Zugriff zu einem primären Sicherheitsauthentifizierungssystem hat, das der Sicherheitsbezeichnung entspricht. Das Fahrzeug verwendet ebenfalls, als Reaktion darauf, dass das Fahrzeug Zugriff hat, das primäre Authentifizierungssystem dazu, einen Benutzer über das bestimmte primäre Sicherheitsauthentifizierungssystem zu authentifizieren und der Vorrichtung Benutzeranmeldeinformationen bereitzustellen, die auf Grundlage einer erfolgreichen Verwendung des primären Authentifizierungssystems erlangt wurden.

Description

GEBIET DER TECHNIK
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Vorrichtungen für dynamische Mehrfaktorauthentifizierung mit Fahrzeugunterstützung.
ALLGEMEINER STAND DER TECHNIK
Mit digitalen Zugriffssystemen und der Fähigkeit zur Fernkommunikation werden Fahrzeugsysteme immer zugänglicher, ohne auf einen physischen Schlüssel oder eine direkt verbundene Vorrichtung angewiesen zu sein. Dies stellt eine Vielzahl nützlicher Zugriffsarten bereit, setzt das Fahrzeug jedoch auch einer Vielzahl verstärkter Versuche aus, die Sicherheit zu umgehen.
Bei den meisten Fahrzeugen vor dem Jahr 2000 war ein physischer Schlüssel erforderlich um auf die Fahrzeugzündung zuzugreifen und/oder sie zu starten. Selbst wenn kein physischer Schlüssel erforderlich war, verlangte das Fahrzeug typischerweise vom Benutzer, einen Anhänger zu besitzen, der sich drahtlos gegenüber dem Fahrzeug authentifizierte und im Wesentlichen bestätigte, dass der Benutzer im Besitz einer Vorrichtung war, die für den Zugang zum und das Starten des Fahrzeugs bestimmt ist.
Darüber hinaus war der Zugriff auf Fahrzeugdaten weitgehend auf physische Fahrzeugschnittstellen, vor allem auf den Anschluss des bordseitigen Datenbusses (onboard data bus - ODB), beschränkt. Selbst wenn der ODB-Zugriff nicht durch eine Sicherheitsmaßnahme an sich geschützt war, stellte die Tatsache, dass sich ein Benutzer innerhalb des Fahrzeugs befinden und über den ODB-Abschluss eine physische Verbindung zum Fahrzeug herstellen musste, sicher, dass diese Zugriffe zumindest typischerweise unter zulässigen Bedingungen durchgeführt wurden.
KURZDARSTELLUNG
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, eine Authentifizierungsanforderung an einem Fahrzeug von einer Anwendung zu empfangen, die auf einer Vorrichtung in Kommunikation mit dem Fahrzeug ausgeführt wird, einschließlich einer Sicherheitsbezeichnung. Der Prozessor ist auch dazu konfiguriert, zu bestimmen, ob das Fahrzeug Zugriff auf ein der Sicherheitsbezeichnung entsprechendes primäres Sicherheitsauthentifizierungssystem hat. Der Prozessor ist ferner dazu konfiguriert, als Reaktion darauf, dass das Fahrzeug Zugriff hat, das primäre Authentifizierungssystem dazu zu verwenden, einen Benutzer über das bestimmte primäre Sicherheitsauthentifizierungssystem zu authentifizieren und der Vorrichtung Benutzeranmeldeinformationen bereitzustellen, die auf Grundlage einer erfolgreichen Verwendung des primären Authentifizierungssystems erlangt wurden.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein Verfahren ein Empfangen einer Authentifizierungsanforderung an einem Fahrzeug, einschließlich einer Sicherheitsbezeichnung, von einer Anwendung in Kommunikation mit dem Fahrzeug. Das Verfahren beinhaltet ebenfalls ein Bestimmen eines primären Authentifizierungssystems, das für das Fahrzeug zugänglich ist, das die Sicherheitsbezeichnung erfüllt. Das Verfahren beinhaltet ferner als Reaktion auf das Bestimmen des primären Authentifizierungssystems ein Verwenden des primären Authentifizierungssystems, um einen Benutzer zu authentifizieren, und das Bereitstellen von Anmeldeinformationen an die Anwendung als Reaktion auf ein erfolgreiches Authentifizieren über das für das Fahrzeug zugängliche Authentifizierungssystem.
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein Verfahren als Reaktion darauf, dass ein Fahrzeug bestimmt, dass das Fahrzeug keinen Zugriff auf ein primäres Authentifizierungssystem hat, das in einer Authentifizierungsanforderung spezifiziert ist, die von einer Anwendung empfangen ist, die auf einer Vorrichtung in Kommunikation mit einem Fahrzeugcomputer ausgeführt wird, ein Bestimmen einer Vielzahl von verfügbaren sekundären Sicherheitsauthentifizierungssystemen, die dazu vordefiniert sind, gemeinsam eine vordefinierte Sicherheitsstufe zu repräsentieren, die der Sicherheitsbezeichnung entspricht, wenn sie erfolgreich verwendet werden, um den Benutzer in Verbindung miteinander zu authentifizieren, auf Grundlage von einem vordefinierten Aggregationsmodell, das eine Vielzahl von Authentifizierungssystemaggregationsoptionen und entsprechenden Sicherheitsstufen für jede Aggregation definiert. Das Verfahren beinhaltet ebenfalls ein Verwenden der bestimmten Vielzahl verfügbarer sekundärer Authentifizierungssysteme, um die Authentifizierungsanforderung zu erfüllen.
Figurenliste

1 zeigt ein veranschaulichendes Fahrzeugrechensystem;
2 zeigt ein veranschaulichendes Beispiel eines Fahrzeugsystems mit mehreren dafür bereitgestellten veranschaulichenden Sicherheitsprotokollen;
3A zeigt ein veranschaulichendes Beispiel eines Prozesses zum Verwenden verschiedener Authentifizierungsoptionen als Reaktion auf eine Anforderung zur Authentifizierung;
3B zeigt eine alternative Version der Authentifizierung, wobei das Fahrzeug mehr Kontrolle darüber aufweist, welches verfügbare Authentifizierungssystem eine geeignete Authentifizierung bereitstellt.

DETAILLIERTE BESCHREIBUNG
Detaillierte Ausführungsformen werden in dieser Schrift nach Bedarf offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich der Veranschaulichung dienen und in verschiedenen und alternativen Formen umgesetzt werden können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Demnach sind die hier offenbarten konkreten strukturellen und funktionalen Details nicht als einschränkend anzusehen, sondern lediglich als Grundlage, um den Fachmann die vielfältige Verwendung des beanspruchten Gegenstands zu lehren.
1 veranschaulicht eine beispielhafte Blockstruktur für ein fahrzeugbasiertes Rechensystem 1 (vehicle based computing system - VCS) für ein Fahrzeug 31. Ein mit einem fahrzeugbasierten Rechensystem bereitgestelltes Fahrzeug kann eine visuelle Frontend-Schnittstelle 4 enthalten, die sich im Fahrzeug befindet. Der Benutzer kann zudem dazu in der Lage sein, mit der Schnittstelle, sofern sie bereitgestellt ist, zu interagieren, zum Beispiel über einen berührungsempfindlichen Bildschirm. Bei einer weiteren beispielhaften Ausführungsform geschieht die Interaktion zum Beispiel durch Knopfdruck, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
Bei der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Der in dem Fahrzeug bereitgestellte Prozessor 3 ermöglicht das Verarbeiten von bordseitigen Befehlen und Abläufen. Ferner ist der Prozessor 3 sowohl mit einem nichtpersistenten 5 als auch einem persistenten Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nichtpersistente Speicher 7 ein Direktzugriffsspeicher (RAM) und der persistente Speicher 5 ist ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher. Im Allgemeinen kann der persistente Speicher 5 alle Formen von Speicher beinhalten, die Daten erhalten, wenn ein Computer oder eine andere Vorrichtung ausgeschaltet wird. Dies beinhaltet unter anderem HDDs, compact discs (CDs), digital video discs (DVDs), Magnetbänder, Solid-State-Laufwerke, tragbare Universal-Serial-Bus-(USB-)Laufwerke und jede andere geeignete Form persistenten Speichers.
Der Prozessor 3 ist ebenfalls mit einer Anzahl von unterschiedlichen Eingängen verbunden, die dem Benutzer ermöglichen, eine Schnittstelle mit dem Prozessor 3 zu bilden. Bei dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Zusatzeingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der eine berührungsempfindliche Anzeige sein kann, und ein BLUETOOTH-Eingang 15 allesamt bereitgestellt. Eine Eingangswähleinheit 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingängen wechseln kann. Der Eingang in sowohl das Mikrofon 29 als auch den Zusatzverbinder 33 ist durch einen Wandler 27 von analog in digital umgewandelt, bevor er an den Prozessor weitergegeben wird. Obwohl dies nicht gezeigt ist, können viele der Fahrzeugkomponenten und Zusatzkomponenten, die mit dem Prozessor 3 verbunden sind, ein Fahrzeugnetzwerk (wie etwa unter anderem einen CAN-Bus) verwenden, um Daten an den und von dem Prozessor 3 (oder Komponenten davon) weiterzuleiten.
Ausgaben des Systems können unter anderem einen Ausgang einer visuellen Anzeige 4 und eines Lautsprecher- 13 oder Stereosystems beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digitalzu-Analog-Wandler 9. Der Ausgang kann ebenfalls an eine entfernte BLUETOOTH-Vorrichtung erfolgen, wie etwa eine persönliche Navigationsvorrichtung (personal navigation device - PND) 54 oder eine USB-Vorrichtung, wie etwa eine Fahrzeugnavigationsvorrichtung 60, entlang der bei 19 bzw. 21 gezeigten bidirektionalen Datenströme.
In einer veranschaulichenden Ausführungsform verwendet das System den BLUETOOTH-Sendeempfänger 15, um über eine Antenne 17 mit der Mobilvorrichtung (nomadic device - ND) 53 eines Benutzers zu kommunizieren (z. B. Mobiltelefon, Smartphone, PDA oder jede andere WLAN-fähige Vorrichtung). Die Mobilvorrichtung 53 kann dann dazu verwendet werden, das Signal 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren, zum Beispiel, Kommunikation 55 mit einem Mobilfunkmast 57 oder Wi-Fi-Zugriffspunkt.
Beispielhafte Kommunikation zwischen der Mobilvorrichtung 53 und dem BLUETOOTH-Sendeempfänger 15 ist durch das Signal 14 dargestellt.
Das Koppeln einer Mobilvorrichtung 53 mit dem BLUETOOTH-Sendeempfänger 15 kann durch eine Schaltfläche 52 oder eine ähnliche Eingabe vorgegeben werden. Dementsprechend wird der Prozessor 3 angewiesen, dass der bordseitige BLUETOOTH-Sendeempfänger 15 mit einer Mobilvorrichtung gekoppelt wird.
Daten können zwischen dem Prozessor 3 und dem Netzwerk 61 unter Verwendung von zum Beispiel einem Datentarif, Daten über Sprache oder DTMF-Tönen kommuniziert werden, die der Mobilvorrichtung 53 zugeordnet sind. Alternativ kann es wünschenswert sein, ein bordseitiges Modem 63 zu beinhalten, das eine Antenne 18 aufweist, um Daten zwischen dem Prozessor 3 und dem Netzwerk 61 über Mobilfunk zu kommunizieren 16.
In einigen Ausführungsformen kann das Modem 63 eine Verbindung 20 mit dem Mast 57 herstellen, um mit dem Netzwerk 61 zu kommunizieren. Als ein nichteinschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein und die Kommunikation 20 kann eine Mobilfunkkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor 3 mit einem Betriebssystem bereitgestellt, das eine Anwendungsprogrammierschnittstelle (application programming interface - API) zum Kommunizieren mit einer Modemanwendungssoftware beinhaltet. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine Firmware auf dem BLUETOOTH-Sendeempfänger 15 zugreifen, um die drahtlose Kommunikation 14 mit einem entfernten BLUETOOTH-Sendeempfänger (wie etwa dem in einer Mobilvorrichtung 53) abzuschließen. Bluetooth ist eine Unterart der IEEE-802-PAN-Protokolle (PAN - Personal Area Network; persönliches Netzwerk). IEEE-802-LAN-Protokolle (LAN - Local Area Network; lokales Netzwerk) beinhalten Wi-Fi und weisen eine bedeutende Funktionalitätsüberschneidung mit IEEE 802 PAN auf. Beide sind zur drahtlosen Kommunikation innerhalb eines Fahrzeugs geeignet. Ein weiteres Kommunikationsformat, das in diesem Bereich eingesetzt werden kann, sind die optische Freiraumkommunikation und nicht standardisierte Verbraucher-IR-Protokolle.
Bei einer weiteren Ausführungsform beinhaltet die Mobilvorrichtung 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. Bei einer Daten-über-Sprache-Ausführungsform kann eine Technik, die als Frequenzmultiplexverfahren bekannt ist, eingesetzt sein, wenn der Eigentümer der Mobilvorrichtung an der Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeitpunkten, wenn der Besitzer die Vorrichtung nicht verwendet, kann für die Datenübertragung die ganze Bandbreite verwendet werden (in einem Beispiel 300 Hz bis 3,4 kHz). Während das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet möglicherweise geläufig ist und nach wie vor verwendet wird, wurde es weitgehend durch Hybride mit Codemultiplexverfahren (CDMA), Zeitmultiplexverfahren (TDMA), Raummultiplexverfahren (SDMA) für eine digitale Mobilfunkkommunikation ersetzt. Wenn der Benutzer einen Datentarif aufweist, der der Mobilvorrichtung zugeordnet ist, ist es möglich, dass der Datentarif eine Breitbandübertragung zulässt und das System eine wesentlich höhere Bandbreite verwenden kann (was die Datenübertragung beschleunigt). In einer anderen Ausführungsform ist die Mobilvorrichtung 53 durch eine Mobilfunkkommunikationsvorrichtung (nicht gezeigt) ersetzt, die im Fahrzeug 31 verbaut ist. In noch einer anderen Ausführungsform kann die Mobilvorrichtung 53 eine Vorrichtung eines drahtlosen lokalen Netzwerks (LAN) sein, die zum Beispiel (unter anderem) über ein Wi-Fi-Netzwerk kommunizieren kann.
In einer Ausführungsform können eingehende Daten durch die Mobilvorrichtung 53 über einen Daten-über-Sprache- oder Datentarif, durch den bordseitigen BLUETOOTH-Sendeempfänger 15 und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD 7 oder einem anderen Speichermedium gespeichert werden, bis zu einem Zeitpunkt, an dem die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die eine Verbindung mit dem Fahrzeug herstellen können, sind eine persönliche Navigationsvorrichtung 54, zum Beispiel mit einem USB-Anschluss 56 und/oder einer Antenne 58, eine Fahrzeugnavigationsvorrichtung 60 mit einem USB 62 oder einem anderen Anschluss, eine bordseitige GPS-Vorrichtung 24, oder ein entferntes Navigationssystem (nicht abgebildet), das Konnektivität zum Netzwerk 61 aufweist.
Darüber hinaus könnte der Prozessor 3 mit einer Vielzahl anderer Zusatzvorrichtungen 65 verbunden sein. Diese Vorrichtungen können über eine drahtlose 67 oder drahtgebundene 69 Verbindung (z. B. USB) verbunden sein. Zu den Zusatzvorrichtungen 65 können unter anderem persönliche Medienwiedergabegeräte, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen gehören.
Außerdem oder alternativ könnte der Prozessor 3 mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, zum Beispiel unter Verwendung eines Wi-Fi-(IEEE-802. 11-)Sendeempfängers 71. Dies könnte dem Prozessor 3 ermöglichen, eine Verbindung zu Fernnetzwerken im Bereich des lokalen Routers 73 herzustellen.
Während ältere Fahrzeuge häufig einen physischen Zugriff benötigten (einen Anhänger, einen Schlüssel, eine eingesteckte Vorrichtung), um mit den Fahrzeugen eine Schnittstelle zu bilden oder diese zu verwenden, sind moderne Fahrzeuge 31 dazu in der Lage, drahtlos zu kommunizieren, um den Zugriff auf Modelle zu unterstützen. Im Zuge dieser Änderungen müssen die Fahrzeuge 31 nun möglicherweise mehrere Vorrichtungen für den drahtlosen Zugriff authentifizieren, und es besteht die Möglichkeit, Aspekte dieser Vorrichtungen (z. B. einen Fingerabdruckleser oder eine Tastatur) zu nutzen, um eine erhöhte Sicherheit bereitzustellen.
Ein Nachteil der meisten modernen Zugriffssysteme besteht jedoch darin, dass sie alle verschiedenen Authentifizierungsverfahren immer noch als binär behandeln. Das heißt, wenn sich ein Benutzer über das eine oder andere festgelegte Verfahren authentifizieren kann, ist dies für einen bestimmten Authentifizierungsprozess ausreichend. Unterschiedliche Prozesse können unterschiedliche Authentifizierungsarten anfordern, diese Anforderungen können jedoch wiederum binärer Natur sein, d. h., sie funktionieren entweder, wenn die angeforderte Authentifizierungsart vorhanden ist, oder schlagen fehl, wenn die angeforderte Authentifizierungsart nicht vorhanden ist. Eine bestimmte Art oder eine Reihe von Authentifizierungsarten kann auf der Grundlage angefordert werden, dass diese Arten eine ausreichend hohe Sicherheit für einen bestimmten Prozess aufweisen. Diese Paradigmen nutzen die Unterschiede in der Authentifizierungsfähigkeit nicht aus, zum Beispiel ist ein Fingerabdruckscan fast eindeutig eine Garantie dafür, dass ein bestimmter Benutzer anwesend ist, wohingegen ein numerischer Code von jedem eingegeben werden kann, der Zugriff auf den Code erlangt hat.
Darüber hinaus sind einige Authentifizierungen aktiv (Fingerabdruck, Code), während andere Authentifizierungen passiv sind (zum Beispiel auf Grundlage der Anwesenheit der Vorrichtung). Die veranschaulichenden Ausführungsformen stellen Möglichkeiten bereit, die Sicherheit digitaler Systeme zu verbessern, indem Sicherheitsstufen definiert werden, die mit verschiedenen verfügbaren Sicherheitsoptionen zusammenhängen, und Anwendungen und Prozessen ermöglicht wird, bestimmte Sicherheitsgarantien zu erfüllen, die zum Beispiel auf der Kritikalität der Sicherheit beruhen. Indem dem Fahrzeug 31 ermöglicht wird, das Vorhandensein und die Arten verfügbarer Optionen zu erkennen und zu bestimmen, ob der Sicherheitsnachweis geeignet war, muss die Anwendung und/oder der Prozess nicht wirklich wissen, ob eine bestimmte Sicherheitsmaßnahme getroffen wurde oder nicht, sondern nur, dass bestimmte Zusicherungen auf Grundlage einer von der Anwendung oder dem Prozess festgelegten Sicherheitsstufe getroffen wurden.
Zum Beispiel kann ein Girokonto-Programm mit einer hohen Sicherheit verbunden sein, da ein Benutzer nur möchte, dass der Zugriff bestimmten Personen gewährt wird. Ein Fingerabdruck ist ein gutes Verfahren zum Sichern eines derartigen Zugriffs, aber vielen Vorrichtungen und/oder Fahrzeugen fehlt die Fähigkeit zur Identifizierung von Fingerabdrücken. In Ermangelung der besten Option (z. B. eines Fingerabdrucks) kann eine Kombination einer bestimmten Vorrichtung, die in Verbindung mit einem verwendeten Code verwendet wird, ausreichend sein. Anders ausgedrückt, in diesem Beispiel entsprechen zwei mittelsichere Faktoren (Anwesenheit der Vorrichtung und Code) einem hohen Sicherheitsfaktor. Unter einem derartigen Modell könnte die Girokontenanwendung „hohe Sicherheit“ spezifizieren und ein Fahrzeug 31 entscheiden lassen, ob diese Anforderung von einer fahrzeugdefinierten Hochsicherheitsoption (wie vom Hersteller vordefiniert) oder mehreren fahrzeugdefinierten mittleren Sicherheitsoptionen erfüllt wird. Die Anwendung kann in Bezug auf die Einzelheiten der Authentifizierung unabhängig bleiben, solange das Fahrzeug 31 überprüft, dass Mindeststandards gemäß einem gemeinsamen Herstellersatz von festgelegten Sicherheitsstufen für verschiedene verfügbare Authentifizierungsoptionen erfüllt wurden.
In anderen Fällen erfordert die anfordernde Anwendung oder der anfordernde Prozess möglicherweise bestimmte Protokolle (z. B. „nur Fingerabdruck“), es fehlt jedoch möglicherweise die Fähigkeit, zu bestimmen, ob etwas anderes als eine Vorrichtung, auf der sich die Anwendung befindet, eine derartige Fähigkeit beinhaltet. In diesen Fällen kann das Fahrzeug 31 zusätzliche Authentifizierungsoptionen erkennen und kann sogar eine Liste dieser Optionen an einen Anwendungsanbieter (z. B. einen Unterstützungsserver) senden, falls der Anbieter über die Eignung einer sekundären Authentifizierungsoption entscheiden möchte, es jedoch nicht dem Fahrzeughersteller überlassen will, was das sein soll. Unter Verwendung des vorhergehenden Beispiels würde der Girokontoprozess „nur Fingerabdruck“ als Zugriffsbeschränkung spezifizieren, und dann könnte das Fahrzeug 31 die Tatsache identifizieren, dass das Fahrzeug einen bordseitigen Fingerabdruckleser beinhaltet, dessen Eingabe an die Anwendung bereitgestellt werden könnte. Alternativ könnte das Fahrzeug 31 einen Anwendungsunterstützungsserver oder die Anwendung darüber informieren, dass das Fahrzeug 31 einen Insassen durch Gesichtserkennung verifizieren kann, und die Anwendung oder der Server könnte bestätigen, dass dies ausreicht, um den Zugriff in Abwesenheit eines Fingerabdruckscanners zu verifizieren.
Oder in einem anderen Beispiel könnte das Fahrzeug dem Überprüfungsanwendungsanbieter alternativ anzeigen, dass das Fahrzeug 31 eine detektierte Vorrichtung und einen durch den Benutzer eingegebenen Code als Authentifizierung des Benutzers identifiziert hat und es dem überprüfenden Anwendungsanbieter überlassen, zu entscheiden, ob dies ausreicht (zu welchem Zeitpunkt der Anbieter eine Zugriffsanforderung auf Grundlage der angegebenen Überprüfung authentifizieren könnte, die vorhanden und erkennbar war).
Dies ermöglicht es wiederum, dass die Codierung der Anwendung gegenüber sich ändernden Sicherheitsoptionen relativ unabhängig bleibt, statt einfach innerhalb eines Paradigmas bestimmter Sicherheitsstufen arbeiten zu müssen und einzuschätzen, welchen Einfluss eine ausgewählte Stufe auf einen Verbraucher hat (d. h. Einstellen einer Anwendung als „hohe Sicherheit“ kann unter bestimmten Bedingungen den Zugriff verhindern, wenn bestimmte Sicherheitsbeschränkungen fehlen und eine geeignete alternative Kombination niedrigerer Sicherheitsfaktoren nicht möglich ist oder akzeptiert wird).
Auf diese Weise können bestimmte Anwendungen zum Beispiel „beste Verfügbarkeit“ oder eine geordnete Auswahl von Optionen angeben, die an die tatsächlich vorhandenen Optionen angepasst werden können. In diesem Fall weist die Anwendung zumindest die Gewissheit auf, dass die derzeit am besten verfügbare Sicherheitsvorkehrung (zum Zeitpunkt des Zugriffs) verwendet wurde.
2 zeigt ein veranschaulichendes Beispiel eines Fahrzeugsystems mit mehreren dafür bereitgestellten veranschaulichenden Sicherheitsprotokollen 200. In diesem Beispiel beinhalten die nichteinschränkenden Arten des Sicherheitszugriffs eine Sprach- oder Sichtidentifizierung 201 (die jeweils durch ein Mikrofon oder eine Kamera ermöglicht wird), eine Vorrichtungsidentifizierung (auf Grundlage einer Vorrichtungs-ID) 203, eine biometrische Identifizierung 205 (hier ein Fingerabdruckscanner) und eine numerische Schlüsselcode-Eingabe 207.
In diesem Beispiel verläuft jedes dieser Systeme in ein Vorverarbeitungssystem 202 des Fahrzeugs 31, das die Logik beinhaltet, um zum Beispiel Sprach-/Sichtidentifizierung 209, einschließlich der Identifizierung verschiedener Audio- oder visueller Merkmale zu verwalten.
Gleichermaßen kann die Vorrichtungsvorverarbeitung 211 eine Logik zum Erlangen und Extrahieren einer Vorrichtungs-ID über eine drahtlose Verbindung oder ein detektiertes Signal beinhalten. Die Fingerabdruckvorverarbeitung 213 kann das Scannen eines Fingerabdrucks nach Schlüsselelementen beinhalten und die Code-Vorverarbeitung 215 kann einfach die Eingabe eines bestimmten numerischen Codes akzeptieren.
Dann kann in diesem Beispiel ein Identitätsauswahlprozess 217 vordefinierte Sicherheitsdetails für die Identitätsarten bereitstellen, die für eine bestimmte Anwendung oder Anforderung relevant sind. Somit könnte die Auswahleinheit 217 diese Arten auf Grundlage von zum Beispiel einer zugeordneten Sicherheitsstufe bereitstellen, sodass eine hochsichere Option (z.B. Fingerabdruck 213) stellvertretend für praktisch jede andere Anforderung bereitgestellt werden könnte, aber zum Beispiel, wenn die Fähigkeit, einen Fingerabdruck 213 zu scannen, nicht vorhanden war, kann die Identitätsauswahleinheit 217 mehrere alternative mittlere Sicherheitsbestätigungen/-versuche bereitstellen.
Unter Verwendung der bereitgestellten Eingabe kann die bordseitige Identitätsverarbeitung 204 gespeicherte Benutzerdaten verwenden, um Identitätsdetails 219 zu bestätigen. Dies kann sowohl die spezifische Identifizierung einer Person (z. B. eine biometrische 213 oder Spracherkennung 209) oder die Erkennung einer autorisierten Person einer bestimmten Stufe (z.B. besitzt eine „Master“-Vorrichtung 211 und kennt einen Code 215) oder die Erkennung einer allgemein autorisierten Person (z.B. weist ein Mindestmaß an Sicherheitszugriff, z. B. Code 215 auf) beinhalten.
Wenn die Identifizierung verwendbar ist, um einen eindeutigen Benutzer bei Schritt 221 zu identifizieren, kann der Prozess in Schritt 223 die spezifische Benutzeridentität mit der Zugriffsanforderung verknüpfen. Dies kann auch zu einer Protokollierung der Benutzerauthentifizierung bei Schritt 225 sowie zu einer Protokollierung der bestimmten Anwendung führen, für die die Zugriffsinformationen bereitgestellt wurden.
Wenn die Identifizierung bei Schritt 221 nicht eindeutig ist, kann das System bei Schritt 225 bestimmen, ob bestimmte Berechtigungen oder eine bestimmte Benutzerstufe identifiziert wurden. Wenn zum Beispiel eine ID einer mobilen Vorrichtung als Master-Vorrichtung und eine andere als eine sekundäre Vorrichtung festgelegt ist, kann das Vorhandensein einer Master-Vorrichtung und eines gemeinsamen Codes als Zugriffsstufe angesehen werden, die höher ist als die der sekundären Vorrichtung mit dem gleichen Code oder keine Vorrichtung, wenn der gemeinsame Code eingegeben wird. Wenn das System bei Schritt 225 eine Zugriffsidentifizierung der Berechtigungsstufe detektiert (d. h., es gibt mindestens eine definierte Berechtigung, die mit einer Benutzeridentität oder einem detektierbaren Merkmal zusammenhängt), kann das System der Zugriffsanforderung in Schritt 227 eine Benutzerart zuweisen und die Authentifizierungsarten sowie die Berechtigungsstufe bei Schritt 229 protokollieren. Diese Art der Authentifizierung ist zum Beispiel nicht immer so sicher wie die eindeutige Identifizierung, da jeder Benutzer die Master-Vorrichtung und den Code besitzen kann, ohne die Zusicherung, dass es sich um eine bestimmte Person handelt.
Andererseits ist diese Art der Authentifizierung immer noch sicherer als die bloße Eingabe von Code, der mitgehört oder auf andere fragwürdige Weise erlangt werden könnte, und daher ist das System dazu in der Lage einen Benutzer bei Schritt 231 auf Grundlage von Erfüllen eines Mindestsicherheitsprotokolls (z. B. Code-Eingang in diesem Beispiel) als ein allgemeiner Benutzer zu klassifizieren. Wiederum kann die Anforderung bei Schritt 229 protokolliert werden, und alle protokollierten Zugriffsanforderungen, die Ergebnisse, etwaige Identifizierungen, das/die verwendete(n) Protokoll(e) und die Anwendungen, an die die Anforderungen gesendet wurden, können an einen Identifizierungsdatenspeicher 233 gesendet werden, der für zukünftige Überprüfungen verwendet werden kann, um Identifizierungsreferenzen für den Identifizierungsdetailprozess bereitzustellen und der Zugriffsanforderungen für bestimmte Benutzer auf Grundlage von bestimmten Anwendungen verfolgen kann. Ein Identitätsverwaltungsprozess 235, der ebenfalls in der Cloud 206 ausgeführt wird, kann die Identitätsauswahl verwalten und bei Abwesenheit einer anderen Quelle dieser Informationen bei der Klassifizierung, welche Identifizierungen für welche Anwendungen geeignet sind, behilflich sein.
3A zeigt ein veranschaulichendes Beispiel eines Prozesses zum Verwenden verschiedener Authentifizierungsoptionen als Reaktion auf eine Authentifizierungsanforderung, die von einem Prozessor 3 des Fahrzeugs 31 ausgeführt werden kann. In diesem Beispiel empfängt das Fahrzeug 31 in Schritt 301 eine Authentifizierungsanforderung. Diese Anforderung kann zum Beispiel eine Bezeichnung einer bevorzugten Identifizierung (z. B. eines Fingerabdrucks) bei Schritt 303 beinhalten. Andere Spezifikationen können zum Beispiel eine bevorzugte Benutzerartkorrelation (z. B. einzelner Benutzer, Hauptbenutzer) beinhalten und der Anforderungsprozess kann es dem Fahrzeug überlassen, zu bestimmen, ob ein bestimmtes verfügbares Authentifizierungssystem verwendet werden konnte, um die angeforderte Korrelation bereitzustellen. Wenn die Anwendung zum Beispiel fordert, dass ein einzelner Benutzer identifiziert wird, überprüft das Fahrzeug 31 die Anforderung, wenn Authentifizierungsparameter erkannt werden, die zur Definition eines einzelnen Benutzers verwendbar sind.
In noch einem weiteren Beispiel kann die Anforderung einfach eine Sicherheitsstufe (z. B. hoch) definieren und es dem Fahrzeug 31 überlassen, zu bestimmen, ob eine verfügbare Zugriffsmöglichkeit verwendet werden konnte, um eine hochsichere (aus der Sicht des Fahrzeugherstellers) Authentifizierung zu erlangen. Wenn bei Schritt 305 ein derartiges primäres Authentifizierungssystem verfügbar ist (primär in dem Sinne, dass das einzelne System oder die spezifizierte Gruppe von Systemen die mit der Anwendungssicherheitsbezeichnung verbundenen Anforderungen erfüllt), verwendet das Fahrzeug 31 das primäre Authentifizierungssystem, um bei Schritt 307 eine Benutzeridentifizierung zu erlangen. Dies kann sowohl eine spezifische, eindeutige Identifizierung als auch/oder eine Berechtigungsebene beinhalten. Wenn die Identifizierung in Schritt 309 mit einer erwarteten Identifizierung übereinstimmt, kann das Fahrzeug 31 die Zugriffsanforderung gewähren (diese Anmeldeinformationsübereinstimmung kann auch bei einer anfordernden Anwendung auftreten, die die Identifizierung empfängt) oder eine Authentifizierungsüberprüfung an eine anfordernde Anwendung zurücksenden.
In einigen Fällen kann zum Beispiel die anfordernde Einheit eine oder mehrere sekundäre Identifizierungen auf Grundlage der von der primären Identifizierung zurückgegebenen Ergebnisse verlangen. Wenn zum Beispiel eine anfordernde Anwendung die Sicherheit spezifiziert, dass das Fahrzeug 31 entweder: a) den Benutzer eindeutig identifiziert oder b) den Benutzer als Master-Benutzer identifiziert, kann letzterer eine Vorrichtungs-ID (als Master-Vorrichtung) und eine Codeeingabe erfordern. Wenn die Vorrichtung, die durch die Vorrichtungs-ID identifiziert wurde, tatsächlich eine Master-Vorrichtung auf Grundlage der Bezeichnung des Fahrzeugs 31 war, ist es möglicherweise keine Master-Vorrichtung, die die anfordernde Anwendung zuvor gesehen hat. Obwohl das Fahrzeug 31 den Benutzer aufgrund der Anwesenheit der Master-Vorrichtung (aus Sicht des Fahrzeugs 31) und des Code-Eingangs als Master-Benutzer authentifiziert hat, kann die Anwendung eine einmalige weitere Authentifizierung anfordern, da sie diese Master-Vorrichtungs-ID noch nicht gesehen und bestätigt hat. In einem derartigen Fall könnte bei Schritt 313 eine weitere sekundäre Identifizierung aus verfügbaren Optionen verwendet werden.
Gleichermaßen, wenn das/die primäre(n) Authentifizierungsverfahre(n) bei Schritt 305 nicht verfügbar ist/sind, kann das Fahrzeug 31 bei Schritt 313 sekundäre Alternativen in Betracht ziehen. Wenn eine unzureichende oder ungeeignete (auf Grundlage der Anwendungsbezeichnung, was zum Beispiel geeignet ist oder nicht) sekundäre Identifizierung verfügbar ist, kann das Fahrzeug 31 die Zugriffsanforderung bei Schritt 315 ablehnen. Andernfalls kann das Fahrzeug 31 die sekundäre Identifizierung durch die verfügbaren sekundären Authentifizierungssysteme erlangen, die einzeln als weniger sicher eingestuft wurden, die aber insgesamt bestimmt werden können, um Mindestsicherheitsanforderungen zu erfüllen. Diese Feststellung, was eine akzeptable Kombination von Optionen mit geringerer Sicherheit darstellt, kann von einem Hersteller oder von der anfordernden Anwendung definiert werden, wobei zum Beispiel angegeben werden kann, ob eine Kombination von drei Optionen mit geringerer Sicherheit geeignet war oder ob eine Kombination von bestimmten Optionen mit geringerer Sicherheit geeignet ist war.
Zum Beispiel kann ein Hersteller ein Aggregationsmodell aufweisen, das angibt, welche sekundären Systeme mittlerer oder geringer Sicherheit aggregiert werden, um eine Authentifizierung mit hoher Sicherheit bereitzustellen. Dieses Modell kann für Fahrzeuge 31 zugänglich sein. In anderen Beispielen kann die anfordernde Anwendung einen Satz von sekundären Authentifizierungssystemen bezeichnen, die zur Erfüllung der Anforderung verwendet werden können (z. B. Vorrichtungs-ID und Passcode oder Vorrichtungs-ID, Passcode und lokale drahtlose Netzwerkidentifizierung). In diesem letzteren Beispiel ist die drahtlose Netzwerkidentifizierung ein weiterer verwendbarer Faktor, der einen Benutzer passiv als innerhalb der Kommunikationsentfernung befindlich authentifizieren kann, wenn keine Verbindung zu einem bekannten drahtlosen Netzwerk besteht, von dem bekannt ist, dass es für frühere akzeptable Zugriffsanforderungen vorhanden war (z. B. eine Netzwerkadresse wird in Bezug auf die Anwendung gespeichert). Dies ist noch ein weiteres Beispiel für die Arten von Authentifizierungssystemen, die von einem Fahrzeug 31 als Reaktion auf eine Zugriffsanforderung bereitgestellt werden können.
Wenn in diesem Beispiel die sekundären Zugriffsbestimmungen erfüllt waren (was bedeutet, dass das primäre Authentifizierungsverfahren nicht verfügbar war), kann das Fahrzeug 31 in Schritt 321 auch einen bestimmten Zugriff beschränken. In Bezug auf eine Girokontenanwendung kann ein Benutzer zum Beispiel dazu in der Lage sein, einen Kontostand zu überprüfen, aber kein Geld zu überweisen. Dies könnte wiederum alles auch über die bestimmte Anwendung gesteuert werden und nicht durch einen bordseitigen Fahrzeugprozess gesteuert werden, es sei denn, die Zugriffsbeschränkung betraf zum Beispiel das Fahrzeug 31 oder einen anderen bordseitigen Fahrzeugprozess (z.B. die Girokontoanwendung befand sich auf dem Fahrzeug und war für fahrzeuginterne oder fahrzeugunterstützte Einkäufe verwendbar, die dann aufgrund der niedrigeren Sicherheitsstufe durch das Fahrzeug eingeschränkt werden könnten).
3B zeigt eine alternative Version der Authentifizierung, die ebenfalls durch einen Prozessor 3 des Fahrzeugs 31 ausführbar ist, wobei das Fahrzeug 31 mehr Kontrolle darüber aufweist, welches Authentifizierungssystem eine geeignete Authentifizierung bereitstellt. In diesem Beispiel empfängt das Fahrzeug 31 bei Schritt 331 eine Authentifizierungsanforderung sowie bei Schritt 333 eine Sicherheitsbezeichnung. Hierbei kann die Sicherheitsbezeichnung eine von mehreren vordefinierten Ebenen sein, zum Beispiel hoch, mittel oder niedrig. Da die Anwendung, die die Anforderung bereitstellt, möglicherweise nicht dazu in der Lage ist, verfügbare Sicherheitsauthentifizierungsoptionen zu bewerten, kann das Fahrzeug 31 bei Schritt 335 prüfen, welche bordseitigen Optionen verfügbar sind.
In diesem Beispiel kann das Fahrzeug 31 auch dazu in der Lage sein, andere verbundene Vorrichtungen (außer einer anfordernden Vorrichtung) zu nutzen, die Optionen beinhalten können, die in einem Fahrzeug 31 bordseitig fehlen. Zum Beispiel kann ein erstes Telefon die Authentifizierungsanforderung bereitstellen und eine hochsichere Authentifizierung festlegen. Fehlt dem Fahrzeug 31 eine Fähigkeit zur eindeutigen oder hochsicheren Identifizierung kann das Fahrzeug 31 bei Schritt 337 bestimmen, dass ein anderes verbundenes Telefon einen Fingerabdruckscanner beinhalten kann, der von dem Fahrzeug 31 zur Authentifizierung verwendet werden kann und als einer geeigneten hochsicheren Authentifizierung entsprechend vordefiniert ist. In diesem Sinne kann das Fahrzeug 31 die Authentifizierungsfähigkeit mehrerer Vorrichtungen zum Zwecke des Bedienens einer Authentifizierungsanforderung konsolidieren.
Auf Grundlage der verfügbaren Identifizierungsarten kann das Fahrzeug 31 dann in Schritt 339 den verschiedenen verfügbaren Authentifizierungsarten Sicherheitsstufen zuweisen und zu Schritt 305 übergehen, wobei die Anforderung so behandelt wird, als hätte es die spezifische verfügbaren Authentifizierungsart (biometrisch) angefordert, die jetzt mit der anforderungsspezifischen Sicherheitsstufe (hohe Sicherheit) korreliert wurde.
Unter Verwendung der veranschaulichenden Ausführungsformen und dergleichen können die Fahrzeuge 31 sowohl bordseitige als auch verbundene Systemauthentifizierungsanforderungen erfüllen, indem sie eine geeignete Authentifizierung aus einer Vielzahl von verfügbaren Optionen bestimmen, wie sie vom Fahrzeug 31 erkannt wurden und entsprechend den Sicherheitsarten, die für diese Optionen vorbestimmt sind, sowie Kombinationen von niedrigeren Sicherheitsoptionen, die bei Verwendung in Kombination als eine höhere Sicherheitsanforderung erfüllend vorbestimmt sind. Dies ermöglicht Anwendungsentwicklern, die Sicherheit festzulegen, ohne unbedingt wissen zu müssen, welche Optionen zum Zeitpunkt einer Anforderung verfügbar sein werden. Da sich die Fahrzeuge 31 in Bezug auf Optionspakete stark unterscheiden, könnte es ansonsten schwierig sein, eine Anwendung auszugestalten, die die erforderliche Sicherheitsstufe für alle Fahrzeuge 31 erfüllt, sofern nicht ein sehr minimaler Standard beinhaltet ist (einer, von dem sichergestellt ist, dass ihn alle Fahrzeugen 31 aufweisen).
Neben der Ausführung beispielhafter Prozesse durch ein sich in einem Fahrzeug 31 befindliches Fahrzeugrechensystem können die beispielhaften Prozesse in bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Zu einem derartigen System können unter anderem eine drahtlose Vorrichtung 53 (z. B. unter anderem ein Mobiltelefon) oder ein entferntes Rechensystem (z. B. unter anderem ein Server in einem entfernten Netzwerk 61), das über die drahtlose Vorrichtung 53 oder ein Fahrzeugmodem 63 verbunden ist, gehören. Zusammen können derartige Systeme als fahrzeuggebundene Rechensysteme (vehicle associated computing systems - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Verfahrens ausführen, wobei dies von der konkreten Umsetzung des Systems abhängt. Als Beispiel und nicht als Einschränkung ist es, falls ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung 53 aufweist, wahrscheinlich, dass nicht die drahtlose Vorrichtung 53 diesen Abschnitt des Prozesses durchführt, da die drahtlose Vorrichtung nicht Informationen an oder von sich selbst senden und empfangen würde. Für den Durchschnittsfachmann liegt auf der Hand, wann es unangemessen ist, ein bestimmtes VACS auf eine bestimmte Lösung anzuwenden.
Bei jeder der in dieser Schrift erörterten veranschaulichenden Ausführungsformen wird ein beispielhaftes, nicht einschränkendes Beispiel eines von einem Rechensystem durchführbaren Prozesses gezeigt. Für jeden Prozess ist es möglich, dass das Rechensystem, das den Prozess ausführt, für den begrenzten Zweck des Ausführens des Prozesses als Spezialprozessor zum Durchführen des Prozesses konfiguriert wird. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden, sondern sind als Beispiele für Arten von Prozessen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu erzielen. Nach Bedarf können zusätzliche Schritte den Prozessen hinzugefügt oder daraus entfernt werden.
Hinsichtlich der veranschaulichenden Ausführungsformen, die in den Figuren beschrieben sind, die veranschaulichende Prozessabläufe zeigen, ist anzumerken, dass ein Universalprozessor zum Zwecke des Ausführens einiger oder aller der durch diese Figuren gezeigten beispielhaften Verfahren vorübergehend als Spezialprozessor befähigt werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor erneut vorübergehend als Spezialprozessor eingesetzt werden, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann bis zu einem angemessenen Grad Firmware, die in Übereinstimmung mit einem vorkonfigurierten Prozessor handelt, den Prozessor dazu veranlassen, als zum Zwecke des Durchführens des Verfahrens oder einer sinnvollen Variation davon bereitgestellter Spezialprozessor zu wirken.
Obwohl vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind beschreibende und keine einschränkenden Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener umsetzender Ausführungsformen auf logische Weise kombiniert werden, um situationsbezogen geeignete Variationen von hier beschriebenen Ausführungsformen zu erzeugen.
Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, das Folgendes aufweist: einen Prozessor, der zu Folgendem konfiguriert ist: Empfangen einer Authentifizierungsanforderung an einem Fahrzeug von einer Anwendung, die auf einer Vorrichtung in Kommunikation mit dem Fahrzeug ausgeführt wird, einschließlich einer Sicherheitsbezeichnung; Bestimmen, ob das Fahrzeug Zugriff auf ein primäres Sicherheitsauthentifizierungssystem hat, das der Sicherheitsbezeichnung entspricht; als Reaktion darauf, dass das Fahrzeug Zugriff hat, Verwenden des primären Authentifizierungssystems, um einen Benutzer über das bestimmte primäre Sicherheitsauthentifizierungssystem zu authentifizieren; und Bereitstellen von Benutzeranmeldeinformationen, die auf Grundlage der erfolgreichen Verwendung des primären Authentifizierungssystems erlangt wurden, an die Vorrichtung.
Gemäß einer Ausführungsform beinhaltet die Sicherheitsbezeichnung ein bevorzugtes Verfahren zur Authentifizierung.
Gemäß einer Ausführungsform beinhaltet das bevorzugte Authentifizierungsverfahren Sprachidentifizierung.
Gemäß einer Ausführungsform beinhaltet das bevorzugte Authentifizierungsverfahren eine visuelle Identifizierung.
Gemäß einer Ausführungsform beinhaltet das bevorzugte Authentifizierungsverfahren biometrische Identifizierung.
Gemäß einer Ausführungsform beinhaltet die Sicherheitsbezeichnung eine bevorzugte Authentifizierungskorrelationsstufe.
Gemäß einer Ausführungsform beinhaltet die Korrelationsstufe eine eindeutige Identifizierung.
Gemäß einer Ausführungsform beinhaltet die Korrelationsstufe eine Stufenidentifizierung mit mehreren Ebenen.
Gemäß einer Ausführungsform beinhaltet die Sicherheitsbezeichnung eine Sicherheitsstufe eines vordefinierten Satzes von Sicherheitsebenen.
Gemäß einer Ausführungsform identifizieren die Benutzeranmeldeinformationen den Benutzer eindeutig.
Gemäß einer Ausführungsform identifizieren die Benutzeranmeldeinformationen den Benutzer als zu einem einer Vielzahl von vordefinierten Zugriffsebenen gehörend, ohne den Benutzer eindeutig zu identifizieren.
Gemäß einer Ausführungsform ist der Prozessor dazu konfiguriert, eine Vielzahl von verfügbaren sekundären Sicherheitsauthentifizierungssystemen zu bestimmen, die individuell als eine niedrigere Authentifizierungsebene bereitstellend vordefiniert sind als ein nicht verfügbares primäres Sicherheitsauthentifizierungssystem, die als zusammen eine Sicherheitsstufe darstellend vordefiniert sind, die der angeforderten Sicherheitsbezeichnung entspricht, wenn sie erfolgreich in Kombination miteinander verwendet werden, um den Benutzer zu authentifizieren.
Gemäß einer Ausführungsform ist der Prozessor dazu konfiguriert, die bestimmte Vielzahl von verfügbaren sekundären Authentifizierungssystemen anstelle des primären Authentifizierungssystems zu verwenden, um den Benutzer zu authentifizieren und Benutzeranmeldeinformationen bereitzustellen, als Reaktion auf Bestimmen, dass das primäre Authentifizierungssystem nicht verfügbar ist.
Gemäß der vorliegenden Erfindung ist ein Verfahren bereitgestellt, das Folgendes aufweist: Empfangen einer Authentifizierungsanforderung an einem Fahrzeug, einschließlich einer Sicherheitsbezeichnung, von einer Anwendung in Kommunikation mit dem Fahrzeug; Bestimmen eines primären Authentifizierungssystems, das für das Fahrzeug zugänglich ist, das die Sicherheitsbezeichnung erfüllt; als Reaktion auf Bestimmen des primären Authentifizierungssystems, Verwenden des primären Authentifizierungssystems, um einen Benutzer zu authentifizieren; und Bereitstellen von Anmeldeinformationen an die Anwendung, als Reaktion auf eine erfolgreiche Authentifizierung über das für das Fahrzeug zugängliche Authentifizierungssystem.
Gemäß einer Ausführungsform ist die Erfindung ferner gekennzeichnet durch ein Empfangen einer Identifizierung eines Authentifizierungssystems, das durch eine Vorrichtung bereitgestellt ist, die drahtlos mit dem Fahrzeugrechensystem verbunden ist, die unterschiedlich zu einer Vorrichtung ist, auf welcher die Anwendung ausgeführt wird; und Einbinden des identifizierten Authentifizierungssystems in das Bestimmen.
Gemäß einer Ausführungsform beinhaltet die Sicherheitsbezeichnung eine bestimmte Authentifizierungsart.
Gemäß einer Ausführungsform beinhaltet die Sicherheitsbezeichnung eine bestimmte Authentifizierungskorrelation.
Gemäß einer Ausführungsform beinhaltet die Sicherheitsbezeichnung eine Sicherheitsebene einer vordefinierten Vielzahl von Sicherheitsebenen.
Gemäß einer Ausführungsform ist die Erfindung ferner gekennzeichnet durch Bestimmen einer Vielzahl von verfügbaren Authentifizierungssystemen, die, auf Grundlage von vorbestimmten Sicherheitsstufen, die mit individuellen der Vielzahl zusammenhängen, aggregiert werden, um die bestimmte Sicherheitsebene auf Grundlage eines vorbestimmten Aggregationsmodells zu erzielen.
Gemäß der vorliegenden Erfindung ist ein Verfahren bereitgestellt, das Folgendes aufweist: als Reaktion darauf, dass ein Fahrzeug bestimmt, dass das Fahrzeug keinen Zugriff auf ein primäres Authentifizierungssystem hat, das in einer Authentifizierungsanforderung spezifiziert ist, die von einer Anwendung empfangen ist, die auf einer Vorrichtung in Kommunikation mit einem Fahrzeugcomputer ausgeführt wird, Bestimmen einer Vielzahl von verfügbaren sekundären Sicherheitsauthentifizierungssystemen, die dazu vordefiniert sind, gemeinsam eine vordefinierte Sicherheitsstufe zu repräsentieren, die der Sicherheitsbezeichnung entspricht, wenn sie erfolgreich verwendet werden, um den Benutzer in Verbindung miteinander zu authentifizieren, auf Grundlage von einem vordefinierten Aggregationsmodell, das eine Vielzahl von Authentifizierungssystemaggregationsoptionen und entsprechenden Sicherheitsstufen für jede Aggregation definiert; und Verwenden der bestimmten Vielzahl von verfügbaren sekundären Authentifizierungssystemen, um die Authentifizierungsanforderung zu erfüllen.

Claims

System, das Folgendes umfasst: einen Prozessor, der zu Folgendem konfiguriert ist: Empfangen einer Authentifizierungsanforderung an einem Fahrzeug von einer Anwendung, die auf einer Vorrichtung in Kommunikation mit dem Fahrzeug ausgeführt wird, einschließlich einer Sicherheitsbezeichnung; Bestimmen, ob das Fahrzeug Zugriff zu einem primären Sicherheitsauthentifizierungssystem hat, das der Sicherheitsbezeichnung entspricht; als Reaktion darauf, dass das Fahrzeug Zugriff hat, Verwenden des primären Authentifizierungssystems, um einen Benutzer über das bestimmte primäre Sicherheitsauthentifizierungssystem zu authentifizieren; und Bereitstellen von Benutzeranmeldeinformationen, die auf Grundlage von erfolgreicher Verwendung des primären Authentifizierungssystems erlangt wurden, an die Vorrichtung.
System nach Anspruch 1, wobei die Sicherheitsbezeichnung ein bevorzugtes Authentifizierungsverfahren beinhaltet.
System nach Anspruch 2, wobei das bevorzugte Authentifizierungsverfahren Sprachidentifizierung beinhaltet.
System nach Anspruch 2, wobei das bevorzugte Authentifizierungsverfahren visuelle Identifizierung beinhaltet.
System nach Anspruch 2, wobei das bevorzugte Authentifizierungsverfahren biometrische Identifizierung beinhaltet.
System nach Anspruch 1, wobei die Sicherheitsbezeichnung eine bevorzugte Authentifizierungskorrelationsstufe beinhaltet.
System nach Anspruch 6, wobei die Korrelationsstufe eine eindeutige Identifizierung beinhaltet.
System nach Anspruch 6, wobei die Korrelationsstufe eine Stufenidentifizierung auf mehreren Ebenen beinhaltet.
System nach Anspruch 1, wobei die Sicherheitsbezeichnung eine Sicherheitsstufe eines vorbestimmten Satzes von Sicherheitsebenen beinhaltet.
System nach Anspruch 1, wobei die Benutzeranmeldeinformationen den Benutzer eindeutig identifizieren.
System nach Anspruch 1, wobei die Benutzeranmeldeinformationen den Benutzer als zu einem einer Vielzahl von vordefinierten Zugriffsebenen gehörend identifiziert, ohne den Benutzer eindeutig zu identifizieren.
System nach Anspruch 1, wobei der Prozessor dazu konfiguriert ist, eine Vielzahl von verfügbaren sekundären Sicherheitsauthentifizierungssystemen zu bestimmen, die individuell als eine niedrigere Authentifizierungsebene bereitstellend vordefiniert sind als ein nicht verfügbares primäres Sicherheitsauthentifizierungssystem, die als zusammen eine Sicherheitsstufe darstellend vordefiniert sind, das der angeforderten Sicherheitsbezeichnung entspricht, wenn sie erfolgreich in Kombination miteinander verwendet werden, um den Benutzer zu authentifizieren.
System nach Anspruch 12, wobei der Prozessor dazu konfiguriert ist, die bestimmte Vielzahl von verfügbaren sekundären Authentifizierungssystemen anstelle des primären Authentifizierungssystems zu verwenden, um den Benutzer zu authentifizieren und Benutzeranmeldeinformationen bereitzustellen, als Reaktion auf Bestimmen, dass das primäre Authentifizierungssystem nicht verfügbar ist.
Verfahren, das Folgendes umfasst: Empfangen einer Authentifizierungsanforderung an einem Fahrzeug, einschließlich einer Sicherheitsbezeichnung, von einer Anwendung in Kommunikation mit dem Fahrzeug; Bestimmen eines primären Authentifizierungssystems, das für das Fahrzeug zugänglich ist, das die Sicherheitsbezeichnung erfüllt; als Reaktion auf Bestimmen des primären Authentifizierungssystems, Verwenden des primären Authentifizierungssystems, um einen Benutzer zu authentifizieren; und Bereitstellen von Anmeldeinformationen an die Anwendung als Reaktion auf eine erfolgreiche Authentifizierung über das für das Fahrzeug zugängliche Authentifizierungssystem.
Verfahren nach Anspruch 14, das ferner Folgendes umfasst: Empfangen der Identifizierung eines Authentifizierungssystems, das durch eine Vorrichtung bereitgestellt ist, das drahtlos mit dem Fahrzeugrechensystem verbunden ist, die unterschiedlich zu einer Vorrichtung ist, auf welcher die Anwendung ausgeführt wird; und Einbeziehen des identifizierten Authentifizierungssystems in das Bestimmen.