DE102019003814A1

DE102019003814A1 - Automatisches Einloggen eines Clients bei einem Server

Info

Publication number: DE102019003814A1
Application number: DE102019003814.2A
Authority: DE
Inventors: Helmut Schuster; Daniel Albert
Original assignee: Giesecke and Devrient Mobile Security GmbH
Current assignee: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE
Priority date: 2019-05-29
Filing date: 2019-05-29
Publication date: 2020-12-03

Abstract

Bei einem Verfahren zum Einloggen eines Clients (100) auf einem Server (210), wird zunächst eine durch den Client (100) hochgeladene Datei von dem Server (210) empfangen (S1), wobei die Datei einen öffentlichen Schlüssel des Clients (100) umfasst. Aus der Datei extrahiert (S3) der Server (210) den öffentlichen Schlüssel des Clients (100) und sucht (S32) in einer Schlüsseldatenbank (230) nach einem mit dem öffentlichen Schlüssel des Clients (100) übereinstimmenden Eintrag. Falls ein übereinstimmender Eintrag gefunden wurde, erfolgt ein automatisches Einloggen (S4) des Clients (100) auf dem Server (210). Falls kein übereinstimmender Eintrag gefunden wurde, wird das automatische Einloggen des Clients (100) verweigert (S9).

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Einloggen eines Client bei einem Server, einen Server zum Anwenden von Diensten auf eine durch einen Client-Rechner hochgeladene Datei sowie eine Plattform und ein System zum Bereitstellen von Diensten an einem Client-Rechner.
Heutzutage existiert eine Vielzahl von serverbasierten Diensten, wie beispielsweise Cloud-Dienste, zur Verarbeitung und Speicherung von Benutzerdaten. Derartige Dienste können beispielsweise ein Speicherdienst für Fotos, ein Videoschnittprogramm-/ dienst für Videoschnitte oder ein Dienst zur Bearbeitung von Applikationen sein. Diese Dienste haben gemeinsam, dass sich der Benutzer zuerst bei einem Dienst-Provider, wie beispielsweise einem Cloud-Speicher, anmeldet und anschließend Dateien hochlädt, damit die darin enthaltenen Daten durch die von dem Dienst-Provider bereitgestellten Dienste analysiert und bearbeitet werden können. Üblicherweise ist ein explizites Anmelden des Benutzers nötig, denn erst dadurch kann der Dienst eindeutig entscheiden, welchem Benutzer die hochgeladene Datei zuzuordnen ist.
Daher ist für viele Cloud-Dienste ein Benutzerkonto bzw. -Account notwendig. Der Account besteht üblicherweise aus einer Kennung des Benutzers, wie beispielsweise einer E-Mail-Adresse, sowie einem zugehörigen Passwort. Es existiert darüber hinaus auch die Möglichkeit, dass sich der Benutzer über einen anderen Account oder Dienst authentisiert. Beispielsweise ist es möglich, sich über den eigenen Facebook-Account für verschiedene Dienste einzuloggen.
Um einen Zugriff unbefugter Dritter möglichst sicher zu verhindern, bieten viele Dienstanbieter bzw. Dienst-Provider eine Multi-Faktor-Authentifizierung zum Einloggen an, wie beispielsweise die Zwei-Faktor-Authentisierung. Bei der Multi-Faktor-Authentifizierung muss ein Benutzer zusätzlich zum Passwort mindestens einen zweiten Faktor zur Authentifizierung nachweisen oder eingeben, den ein Angreifer nicht wissen oder besitzen kann. In der Regel ist dies ein mittels eines OTP-Token (OTP = „one time password“) generiertes Einmal-Passwort, eine TAN-Nummer beim Online-Banking oder der Nachweis einer zusätzlichen Chipkarte.
Ein Nachteil der bekannten Verfahren besteht darin, dass diese ein großes Maß an Interaktion seitens des Benutzers erfordern. Insbesondere ist ein explizites Einloggen des Benutzers bei dem Dienst-Provider notwendig, auch dann, wenn bei der anschließenden Nutzung der bereitgestellten Dienste keine Benutzerinteraktion mehr erforderlich ist.
Auch die Verwendung eines sogenannten zweiten Faktors im Rahmen einer Zwei-Faktor-Authentifizierung erfordert üblicherweise weitere manuelle Schritte. So muss der Benutzer einen Code bzw. ein Einmalpasswort von einem OTP-Token ablesen und in ein anderes Gerät eingeben oder eine Chipkarte in ein Lesegerät einführen. Bei automatisiert ablaufenden Diensten ist dies jedoch hinderlich, da dies die Anwesenheit des Benutzers erfordert.
Zudem ist das Einloggen mittels Benutzerkennung und Passwort mit hoher Unsicherheit verbunden, da diese Informationen - beispielsweise durch Schadprogramme, wie zum Beispiel Trojaner auf dem PC - leicht ausgespäht und anschließend missbraucht werden können. Dies gilt umso mehr, wenn diese Daten fest für die Nutzung eines automatisiert ablaufenden Dienstes auf einem PC hinterlegt sind.
Aus der Patenanmeldung CN 105429961 ist ein Verfahren zum automatischen Registrieren und automatischen Anmelden an einem Server basierend auf der Seriennummer der Festplatte des Client-Rechners bekannt. Nachteil eines solchen Verfahrens ist, dass der Benutzer nur von einem bestimmten Gerät auf Dienste des Servers zugreifen kann. Darüber hinaus kann ein unbefugter Dritter durch Zugang zum Gerät Dateien hochladen und Dienste des Servers auf Kosten des Benutzers im Anspruch nehmen.
Insofern ist es die Aufgabe der vorliegenden Erfindung, eine Lösung zu schaffen, die ein geräteunabhängiges, einfaches und sicheres Nutzen von Diensten ohne explizites Einloggen durch den Benutzer erlaubt.
Der Erfindung liegt die Erkenntnis zugrunde, dass diese Aufgabe gelöst werden kann, indem ein Benutzer mittels einer hochgeladenen Datei automatisch erkannt und vollautomatisch für einen Dienst authentifiziert werden kann.
Insbesondere beruht die Erfindung darauf, bereits vorhandene kryptographische Informationen, die bereits an später zu verarbeitenden Daten des Benutzers vorhanden sind, für die automatische Authentifizierung des Benutzers gegenüber dem Dienst zu nutzen.
Gelöst wird diese Aufgabe durch ein Verfahren und eine Vorrichtung gemäß den unabhängigen Ansprüchen. Die davon abhängigen Ansprüche spezifizieren vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung.
Unter Daten wird hierin ganz allgemein jede Form von digitalen Informationen verstanden, insbesondere können diese in geordneter Form als Dateien wie z.B. Bilder, Dokumente, Programme und Archive vorliegen. Weiter können Daten auch Datensätze aus einer Datenbank oder andere Informationen sein, die z.B. direkt über den Arbeitsspeicher des Clients auf den Server gespeichert werden sollen. Wird in diesem Dokument von Dateien gesprochen, ist dies gleichwertig mit Daten zu sehen und umgekehrt.
Unter einem Server wird auch ein Cloud-Dienst verstanden, in welchem eine Vielzahl an Servern oder Serverfarmen gegebenenfalls miteinander verbunden sind, mitunter an geographisch verteilten Standorten. Wird nachfolgend auf Server Bezug genommen, so sind zentrale Server gemeint, die von Anbietern bzw. Service-Providern von Online-Speicherplatz betrieben werden, um Clients Online-Speicherplatz sowie die notwendigen Ressourcen für serverseitige Operationen bereitzustellen. Der zentrale Server ist in den meisten Ausführungsbeispielen als ein externer Server beschrieben, der mit dem Benutzer über ein Informationsnetzwerk wie zum Beispiel das Internet verbunden ist. Genauso kann der zentrale Server in einem Firmengebäude nur ausgewählten Mitarbeitern zur Verfügung stehen.
Die Bezeichnung „Benutzer“ fasst Endnutzer, wie beispielsweise private Anwender sowie Firmen und deren Mitarbeiter zusammen, wobei ein Dienst-Provider eine Vielzahl an Benutzern als seine Kunden hat.
In der vorliegenden Anmeldung wird der Begriff „Client“ verwendet, um z.B. Personal-Computer (PC), Laptops, NetBooks, mobile und sonstige Endgeräte und dergleichen zu beschreiben, also jene Geräte, auf welchen Benutzer Daten zum Beispiel in Form von Dateien gespeichert haben und von welchen aus die Dateien auf zentrale Server hochgeladen werden, um serverbasierte Dienste in Anspruch zu nehmen.
Es wird davon ausgegangen, dass zur Übertragung von Daten zwischen dem Client und dem Server durch den Dienst-Provider eine geeignet verschlüsselter Kanal nach dem Stand der Technik verwendet wird, wie z.B. eine SSL-Verbindung.
In einem Verfahren zum Einloggen eines Clients bei einem Server eines Dienst-Providers gemäß einem ersten Aspekt der Erfindung empfängt der Server eine durch den Client hochgeladene Datei, wobei die Datei einen öffentlichen Schlüssel des Clients umfasst. Weiter extrahiert der Server den in der Datei enthaltenen öffentlichen Schlüssel des Clients und sucht in einer Schlüsseldatenbank nach einem Eintrag, der mit dem öffentlichen Schlüssel des Clients übereinstimmt. Weiter führt der Server, falls die Schlüsseldatenbank einen übereinstimmenden Eintrag enthält, ein automatisches Einloggen des Clients durch. Falls die Schlüsseldatenbank keinen übereinstimmenden Eintrag enthält, verweigert der Server das automatische Einloggen des Clients.
Hierdurch wird eine vollautomatische Authentifizierung eines Clients durchgeführt. Der Client wird automatisch anhand von an dem Server übertragenden Daten erkannt, so dass ein explizites Einloggen des Clients entfallen kann. Darüber hinaus müssen bei automatisiert ablaufenden Diensten, insbesondere Cloud-Diensten, Benutzername und Passwort nicht mehr in den Programmen und Diensten der Cloud hinterlegt werden. Der Aufwand beim Ändern eines Passwortes wird dadurch reduziert. Durch den automatischen Authentifizierungsvorgang lässt sich die Programmierung der Clients, die bestimmte Cloud-Dienste nutzen, ebenfalls vereinfachen.
Vorzugsweise umfasst das automatische Einloggen ein temporäres Einloggen des Clients, das ein Zugriffsrecht auf Dienste des Servers in Bezug auf die betreffende Datei gewährt. Das temporäre Login ist für die einmalige Anwendung von Diensten des Servers auf diese Datei gültig. Nach Abschluss des Dienstes erfolgt ein automatisches Logout des Clients.
Das automatische Einloggen kann jedoch auch nach Abschluss des Dienstes bestehen bleiben und für weitere automatische oder manuelle Schritte in Bezug auf die Datei genutzt werden.
Nach Abschluss des Dienstes kann die gegebenenfalls geänderte Datei auf den Client heruntergeladen werden.
Vorzugsweise werden im Rahmen eines vorgelagerten Vorbereitungsprozesses die öffentlichen Schlüssel von Clients bei den Dienst-Providern hinterlegt, um diese später mit dem aus der hochgeladenen Datei extrahierten öffentlichen Schlüssel zu vergleichen. Der Client kann dem Server seinen öffentlichen Schlüssel nach dem Anlegen eines Accounts bei dem Dienst-Provider im Rahmen eines üblichen Login/Logout-Prozesses mit den entsprechenden Zugangsdaten übermitteln. Dabei können die Zugangsdaten eine Benutzerkennung, z.B. eine ClientID, und ein Passwort enthalten. Der Server speichert die ClientID und die von dem Client empfangenen öffentlichen Schlüssel in der Schlüsseldatenbank. Ein in der Schlüsseldatenbank gespeicherter öffentlicher Schlüssel eines Clients ist somit eindeutig durch die zugehörige ClientID bestimmt.
Vorzugsweise umfasst die durch den Client hochgeladene Datei eine digitale Signatur. Der Server extrahiert aus der durch den Client hochgeladenen Datei diese digitale Signatur und führt eine Prüfung der Datei auf Integrität und Gültigkeit durch. Dieser Schritt dient dazu, sicherzustellen, dass die digitale Signatur tatsächlich zu der hochgeladenen Datei passt. Hierdurch wird verhindert, dass ein Angreifer eine digitale Signatur eines anderen Clients in der Datei einfügt, und dadurch die Datei auf Kosten anderer Entwickler analysieren und bearbeiten lässt.
Vorzugsweise wird die digitale Signatur durch den Client aus den in der Datei enthaltenen Daten und einem privaten Signaturschlüssel des Clients berechnet. Dabei wird vorzugsweise der private Signaturschlüssel nicht direkt auf die Datei angewendet, sondern auf deren Hashwert, der mittels einer Hashfunktion aus der Datei berechnet wird.
Der Dienst-Provider speichert alle gültigen digitalen Signaturen von Dateien, die bereits durch den Dienst-Provider analysiert und bearbeitet wurden in einer Signaturdatenbank.
Vorzugsweise überprüft der Server, ob die hochgeladene Datei in unveränderter Form bereits analysiert oder bearbeitet wurde, indem nach der digitalen Signatur der Datei in der Signaturdatenbank gesucht wird. Falls die Signaturdatenbank einen übereinstimmenden Eintrag enthält, verweigert der Server das automatische Einloggen des Clients. Dadurch wird verhindert, dass ein Angreifer eine Datei mit einer gültigen Signatur eines Dritten hochlädt und somit Kosten für den Dritten verursacht. In diesem Fall kann der Client aufgefordert werden, sich explizit einzuloggen, indem der Server eine entsprechende Aufforderung an den Client sendet. Mittels empfangener Anmeldedaten des Clients, wird anschließend der Client durch den Server authentifiziert. Vorzugsweise enthalten die Anmeldedaten die ClientID und ein zugehöriges Clientpasswort. Dieser zusätzliche Schritt eines expliziten Einloggens des Clients ist jedoch nur in den Fällen notwendig, in den eine bereits bearbeitete Datei in unveränderter Form erneut hochgeladen wird. Denn sobald sich der Inhalt einer Datei geändert hat, ändert sich auch der entsprechende Hashwert, was zwangsläufig zu einer neuen, noch nicht vorher benutzten digitalen Signatur führt.
Vorzugsweise wird falls die Signaturdatenbank keinen übereinstimmenden Eintrag enthält, die neue Signatur der hochgeladenen Datei durch den Server in die Signaturdatenbank aufgenommen.
Wie bereits eingangs beschrieben beruht das automatische Einloggen des Clients auf dem öffentlichen Schlüssel des Clients, der in der hochgeladenen Datei enthalten ist. Der Server vergleicht diesen Schlüssel mit den öffentlichen Schlüsseln aus der Schlüsseldatenbank. Falls kein Eintrag gefunden wird, wurde entweder der öffentliche Schlüssel des Clients noch nicht dem Account des Clients und somit der Schlüsseldatenbank hinzugefügt oder ein unbekannter Dritter versucht eine Datei durch den Server bearbeiten zu lassen.
In beiden Fällen sendet der Server vorzugsweise eine Aufforderung zum manuellen Einloggen an den Client und führt ein Authentifizieren des Clients mittels der empfangenen Anmeldedaten des Clients durch. Vorzugsweise enthalten die Anmeldedaten die ClientID und ein zugehöriges Clientpasswort. Nach der Authentifizierung des Clients, speichert der Server den öffentlichen Schlüssel des Clients zusammen mit der ClientID in der Schlüsseldatenbank.
Gemäß einem zweiten Aspekt betrifft die Erfindung einen Server zum Anwenden von Diensten auf eine durch einen Client bereitgestellte Datei. Der Server ist dazu eingerichtet, eine durch den Client hochgeladene Datei zu empfangen, wobei die Datei einen öffentlichen Schlüssel des Clients umfasst. Weiter ist der Server dazu eingerichtet, den in der Datei enthaltenen öffentlichen Schlüssel des Clients zu extrahieren, und in einer Schlüsseldatenbank nach einem mit dem öffentlichen Schlüssel des Clients übereinstimmenden Eintrag zu suchen. Weiter ist der Server dazu eingerichtet, falls die Schlüsseldatenbank einen übereinstimmenden Eintrag enthält, ein automatisches Einloggen des Clients durchzuführen und falls die Schlüsseldatenbank keinen übereinstimmenden Eintrag enthält, das automatische Einloggen des Clients zu verweigern. Dadurch wird der Client automatisch authentifiziert und erhält Zugriffsrechte auf Dienste des Servers zum Anwenden auf die Datei, ohne dass sich der Client explizit auf dem Server einloggen muss.
Gemäß einem dritten Aspekt betrifft die Erfindung eine Plattform, insbesondere eine Cloud-Plattform, zum Bereitstellen von Diensten an einem Client. Die Plattform umfasst eine Schlüsseldatenbank und einen Server gemäß dem zweiten Aspekt der Erfindung. Vorzugsweise umfasst die Plattform eine Signaturdatenbank. Vorzugsweise ist der Server dazu eingerichtet ein Verfahren gemäß dem ersten Aspekt auszuführen.
Gemäß einem vierten Aspekt betrifft die Erfindung ein System zum Einloggen eines Clients auf einem Server. Das System umfasst einen Client, einen Server sowie eine Schlüsseldatenbank. Der Client ist dazu eingerichtet, eine Datei, die einen öffentlichen Schlüssel des Clients enthält, mittels einer digitalen Signatur, die auf einem privaten Signaturschlüssel des Clients basiert, zu signieren und die signierte Datei auf dem Server hochzuladen. Der Server ist dazu eingerichtet den in der Datei enthaltenen öffentlichen Schlüssel des Clients zu extrahieren und in der Schlüsseldatenbank nach einem mit dem öffentlichen Schlüssel des Clients übereinstimmenden Eintrag zu suchen. Weiter ist der Server dazu eingerichtet, falls die Schlüsseldatenbank einen übereinstimmenden Eintrag enthält, ein automatisches Einloggen des Clients durchzuführen und falls die Schlüsseldatenbank keinen übereinstimmenden Eintrag enthält, das automatische Einloggen des Clients zu verweigern. Dadurch wird der Client automatisch authentifiziert und erhält Zugriffsrechte auf Dienste des Servers zum Anwenden auf die Datei, ohne dass sich der Client explizit auf dem Server einloggen muss.
Mit der vorliegenden Erfindung wird eine vollautomatische Authentifizierung eines Clients erreicht. Der Client wird automatisch anhand von an dem Server übertragenden Daten erkannt, so dass ein explizites Einloggen des Clients somit entfallen kann. Darüber hinaus müssen bei automatisierten Diensten, insbesondere Cloud-Diensten, Benutzername und Passwort nicht mehr in den Programmen und Diensten der Cloud hinterlegt werden. Der Aufwand beim Ändern eines Passwortes wird dadurch reduziert. Durch den automatischen Authentifizierungsvorgang lässt sich die Programmierung der Clients, die bestimmte Cloud-Dienste nützen, ebenfalls vereinfachen.
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung erfindungsgemäßer Ausführungsbeispiele sowie weiteren Ausführungsalternativen im Zusammenhang mit den folgenden angehängten Zeichnungen. Diese zeigen:

1 eine bevorzugte Ausführungsform eines erfindungsgemäßen Systems;
2 eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens;
3 vorbereitende Schritte einer ersten Phase einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens;
4a Schritte einer zweiten Phase der bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens;
4b Schritte einer dritten Phase der bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens; und
5 Schritte einer vierten Phase der bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens.

In den verschiedenen Figuren werden gleiche Bezugszeichen und Bezeichnungen für gleiche Elemente verwendet.
Die erfindungsgemäße Lösung wird anhand eines Systems, welches einen Client und eine Plattform umfasst, verdeutlicht. Die Plattform stellt Dienste, insbesondere Cloud-Dienste, an dem Client zur Analyse und Bearbeitung von Dateien bereit.
Als eine bevorzugte Ausführungsform wird im Folgenden eine Cloud-Plattform beschrieben, die Installationsdateien für Android-Applikationen, sogenannte APK-Dateien, analysiert und bearbeitet. Die Cloud-Plattform bietet die Möglichkeit, APK-Dateien durch den Client auf einem Server der Cloud-Plattform hochzuladen, die sich beim Hochladen selbst authentifizieren, ohne dass ein explizites Einloggen des Clients an dem Server erforderlich ist. Darüber hinaus stellt die Cloudplattform weitere Dienste an dem Client bereit, die es dem Client unter Anderem ermöglichen Voreinstellungen zur Analyse von APK-Dateien durch den Clouddienst zu verändern oder Statistiken einzusehen, die die Ergebnisse von Analysen und Modifikationen der APK-Dateien betreffen.
Die Cloud-Plattform bietet jedoch auch weiterhin die Möglichkeit des bekannten Zugangs zum APK-Cloud-Dienst mittels des expliziten Einloggens durch den Client an.
1 ist ein Blockdiagramm, das ein System zur Bereitstellung von Diensten, insbesondere Cloud-Diensten, an einem Client darstellt. Das System 300 umfasst einen Client 100, der direkt von einem Endbenutzer verwendet werden kann, um mit einer Plattform 200, insbesondere einer Cloud-Plattform, über ein drahtloses oder drahtgebundenes Netzwerk 110 zu kommunizieren, um durch die Cloud-Plattform 200 bereitgestellte Dienste im Anspruch zu nehmen.
Der Client 100 kann beispielsweise ein Smartphone, ein Laptop, ein Tablett-Computer, ein PC, eine intelligente Uhr, ein IoT-Gerät (loT = „Internet of Things“) oder ein sonstiges mobile oder stationäres Endgerät sein.
Die Cloud-Pattform 200 umfasst einen Server 210 und eine Schlüsseldatenbank 230 (Schlüssel DB). Darüber hinaus kann die Cloud-Plattform eine Signaturdatenbank 220 (Signatur DB) umfassen.
2 ist ein systematisches Diagramm, das das erfindungsgemäße Verfahren zum automatischen Einloggen eines Clients auf einem Server einer Cloud-Plattform verdeutlicht. Das Verfahren kann durch das System 300 aus 1 ausgeführt werden.
In einem ersten Schritt S1 empfängt der Server 210 eine durch den Client 100 hochgeladene Datei, beispielsweise eine APK-Datei. Die APK-Datei umfasst eine digitale Signatur. Die digitale Signatur ist ein asymmetrisches Kryptosystem, bei dem der Client mit Hilfe eines privaten Signaturschlüssels (dem „Private Key“) zu einer zu signierenden digitalen Datei einen Wert berechnet. Dieser Wert wird als digitale Signatur zusammen mit dem öffentlichen Schlüssel (dem „Public Key“) des Clients der Datei hinzugefügt. Üblicherweise wird der private Signaturschlüssle nicht direkt auf die Datei angewendet, sondern auf deren Hashwert, der mittels einer Hashfunktion aus der Datei berechnet wird.
Es ist bekannt, APK-Dateien durch APK-Signaturen zu signieren. Üblicherweise werden APK-Signaturen unter Verwendung eines sogenannten „APK Signature Scheme“ gebildet, indem ein APK-Signaturblock in die APK-Datei eingefügt wird. Innerhalb des APK-Signaturblocks werden Signaturen und Informationen zur Identität des Unterzeichners (Benutzer, APK-Entwickler) gespeichert. Ein Aufbau eines derartigen APK-Signaturschemas ist beispielsweise bekannt aus https:/ / source.android.com/ security/ apksigning/ v2.
Der Server 210 extrahiert aus der durch den Client hochgeladenen APK-Datei die digitale Signatur und führt in Schritt S2 eine Prüfung der Signatur auf Integrität und Gültigkeit durch. Die Integritäts- und Gültigkeitsprüfung erfolgt dabei unter Zuhilfenahme der Signaturdatenbank 220. Die Signaturdatenbank 220 speichert alle gültigen digitalen Signaturen von Dateien, die bereits durch den Dienst-Provider, welcher Dienste über die Cloud-Plattform 200 bereitstellt, analysiert und bearbeitet wurden. Eine bevorzugte Implementierung der Signaturüberprüfung wird weiter unten mit Bezug auf 4a beschrieben.
Der Schritt der Signaturüberprüfung ist optional und dient dazu, sicherzustellen, dass die digitale Signatur tatsächlich zu der hochgeladenen Datei passt. Hierdurch wird verhindert, dass ein Angreifer eine digitale Signatur eines anderen Clients in der hochgeladenen Datei einfügt, und dadurch die Datei auf Kosten anderer Entwickler/Benutzer analysieren und bearbeiten lässt.
Die erfindungsgemäße Lösung beruht darauf, bereits vorhandene kryptographische Informationen, die in den APK-Dateien enthalten sind, für die Authentifizierung des Clients gegenüber dem Cloud-Dienst zu nutzen. Ein Beispiel solcher kryptographischen Informationen ist der öffentliche Schlüssel des Clients, der in der signierten APK-Datei enthalten ist.
Im Schritt S3 extrahiert der Server 210 aus der empfangenen APK-Datei den öffentlichen Schlüssel des Clients 100, und führt unter Zuhilfenahme der Schlüsseldatenbank 230 eine Schlüsselüberprüfung durch. Die Schlüsseldatenbank 230 speichert Einträge der Form [ClientID, öffentlicher Schlüssel] für alle Clients, die einen Account bei dem Dienst-Provider angelegt haben und/ oder Dienste des Providers in Anspruch genommen haben. Da ein öffentlicher Schlüssel üblicherweise einmalig ist, kann der Server aus einem Eintrag in der Schlüsseldatenbank anhand des öffentlichen Schlüssels den Client eindeutig bestimmen.
Dabei kann die Schlüsselüberprüfung mittels einer Suchanfrage an die Schlüsseldatenbank 230 implementiert werden, mittels welcher der Server 210 nach einem dem öffentlichen Schlüssel entsprechenden Eintrag in der Schlüsseldatenbank 230 sucht. Falls die Schlüsseldatenbank 230 einen entsprechenden Eintrag enthält, wird dem Client mit der ermittelten ClientID ein automatisches Login auf dem Server gewährt (Schritt S4).
Vorzugsweise wird durch das automatische Login ein temporäres Einloggen des Clients realisiert, das ein Zugriffsrecht auf Dienste des Servers in Bezug auf die Datei gewährt. Das temporäre Login ist für die einmalige Anwendung von Dienste des Servers auf die Datei gültig. Nach Abschluss des Dienstes erfolgt ein automatisches Logout des Clients (Schritt S7).
Das automatische Einloggen kann jedoch auch nach Abschluss des Dienstes bestehen bleiben und für weitere automatische oder manuelle Schritte in Bezug auf die Datei genutzt werden.
Nach dem automatischen Einloggen des Clients kann die hochgeladene Datei analysier und gegebenenfalls bearbeitet werden (Schritt S5). Dabei können durch den Server Statistiken des Accounts des Clients ergänzt werden oder auch Kosten anfallen, die über den Account abgerechnet werden. Die bearbeitete Datei wird anschließend (Schritt S6) auf den Client heruntergeladen.
Durch das erfindungsgemäße Verfahren erfolgt die Authentifizierung des Clients 100 durch den Server 210 automatisch, d.h., ohne ein explizites Einloggen des Clients.
Wie oben erläutert, beruht das erfindungsgemäße Verfahren auf einem Verglich zwischen dem in der hochgeladenen Datei enthaltenen öffentlichen Schlüssel des Clients, mit den in der Schlüsseldatenbank gespeicherten öffentlichen Schlüsseln von Clients. Dabei werden die öffentlichen Schlüssel von Clients im Rahmen eines vorgelagerten Vorbereitungsprozesses bei den Dienst-Providern hinterlegt. Dies kann beispielsweise im Rahmen eines einmaligen Login/Logout-Verfahrens, wie in 3 dargestellt, erfolgen.
3 zeigt den Vorgang des Hinterlegens des öffentlichen Schlüssels des Clients 100 bei dem Server 210, im Rahmen eines normalen Login/Logout-Verfahrens des Clients 100. In einem ersten Schritt Sa, sendet der Client, unter Eingabe der ClientID und eines Passwortes, eine Login-Anforderung an dem Server 210. Nach erfolgreichem Einloggen, überträgt der Client seinen öffentlichen Schlüssel in Schritt Sb an dem Server. Dies kann beispielsweise durch Anlegen eines Benutzerprofils bei dem Dienst-Provider unter Angabe des öffentlichen Schlüssels erfolgen. Der Server 210 speichert in Schritt Sc den öffentlichen Schlüssel zusammen mit der ClientID in der Schlüsseldatenbank 230. Anschließen, führt der Client ein Logout-Schritt Sd durch.
Der Client kann seinen öffentlichen Schlüssel aber auch gleichzeitig mit dem Anlegen eines Accounts bei dem Dienst-Provider hinterlegen. Denkbar sind auch Lösungen, die einen sogenannten Key-Server verwenden, d.h. ein Schlüsselserver der öffentliche Schlüssel sammelt und diese in der Schlüsseldatenbank 230 speichert.
Aus Sicherheitsgründe ist es wichtig, dass der bei einem APK Cloud-Dienst hinterlegte öffentliche Schlüssel verschieden ist von einem weiteren öffentlichen Schlüssel, den ein Client für das Einstellen einer APK-Datei in einen App Store verwendet.
Die Schlüsseldatenbank 230 speichert somit Einträge der Form [ClientID, öffentlicher Schlüssel] für alle Clients, die einen Account bei dem Dienst-Provider angelegt haben oder die Dienste des Dienst-Providers in Anspruch genommen haben. Da ein öffentlicher Schlüssel üblicherweise einmalig ist, kann der Server aus einem Eintrag in der Schlüsseldatenbank anhand eines öffentlichen Schlüssels den Client eindeutig bestimmen.
Die einzelnen Schritte des erfindungsgemäßen Verfahrens zum Einloggen eines Clients auf einem Server werden nun im Zusammenhang mit den 4 und 5 ausführlich beschrieben.
4a zeigt eine bevorzugte Implementierung der Signaturüberprüfung (Schritt S2 in 2).
Der Server extrahiert aus der durch den Client hochgeladenen Datei die digitale Signatur (Schritt S21) und führt eine Prüfung der Datei auf Integrität und Gültigkeit durch (Schritt S22). Schritt S22 dient dazu, sicherzustellen, dass die digitale Signatur tatsächlich zu der hochgeladenen Datei passt. Hierdurch wird verhindert, dass ein Angreifer eine digitale Signatur eines anderen Clients in die hochgeladene Datei einfügt, und dadurch die Datei auf Kosten anderer Entwickler analysieren und bearbeiten lässt. Bekannte Verfahren zur Signaturüberprüfung wie beispielsweise Verfahren zur Signaturüberprüfung von Android Applikationen können hierzu zum Einsatz kommen.
Falls die Überprüfung der Integrität und Gültigkeit der Signatur in Schritt S23 fehlschlägt, wird ein automatisches Einloggen des Clients verweigert (Schritt S9).
Falls die Überprüfung der Integrität und Gültigkeit der Signatur in Schritt S23 erfolgreich ist, ist sichergestellt, dass die Signatur tatsächlich der hochgeladenen APK-Datei entspricht und Angriffe durch manipulierte APK-Dateien ausgeschlossen werden können.
Um zu verhindern, dass eine bereits analysierte APK-Datei in unveränderter Form ohne eine explizite Zustimmung des Clients erneut analysiert wird („APK-Replay-Angriff“), vergleicht der Server in Schritt S24 die gültige digitale Signatur der Datei mit Einträgen in der Signaturdatenbank 220. Die Signaturdatenbank 220 enthält alle gültigen digitalen Signaturen von Dateien, die bereits durch den Dienst-Provider analysiert und bearbeitet worden sind.
Falls in Schritt S25 festgestellt wird, dass die Signaturdatenbank 220 einen übereinstimmenden Eintrag enthält, verweigert der Server das automatische Einloggen des Clients (Schritt S9). Dadurch wird verhindert, dass ein Angreifer eine Datei mit einer gültigen Signatur eines Dritten zum Bearbeiten durch die Serverdienste hochlädt und somit Kosten für den Dritten verursacht.
Vorzugsweise fordert der Server, falls das automatische Einloggen fehlschlägt, den Client auf, sich manuell einzuloggen, um dadurch den Client authentifizieren zu können.
5 zeigt ein Flussdiagramm, das eine bevorzugte Implementierung des manuellen Einloggens verdeutlicht. Das manuelle Einloggen für die Fälle, in welchen die Signaturdatenbank die Signatur der hochgeladenen Datei enthält umfasst die Schritte S91 bis S93.
Im Schritt S91 sendet der Server eine Aufforderung an den Client, sich manuell einzuloggen. Mittels empfangener Anmeldedaten des Clients (Schritt 92), wird anschließend der Client durch den Server authentifiziert (Schritt 93). Vorzugsweise enthalten die Anmeldedaten die ClientID und ein zugehöriges Client-Passwort. Dieser zusätzliche Schritt eines expliziten Einloggens des Clients ist jedoch nur in den Fällen notwendig, in den eine bereits bearbeitete Datei in unveränderter Form erneut hochgeladen wird. Denn sobald sich der Inhalt einer Datei geändert hat, ändert sich auch der entsprechende Hashwert, was zwangsläufig zu einer neuen, noch nicht vorher benutzten digitalen Signatur führt.
Falls die Signatur der hochgeladenen APK-Datei nicht in der Signaturdatenbank 220 gefunden wurde, ist sichergestellt, dass diese APK-Datei noch nicht durch den Dienst-Provider analysiert wurde, wodurch ein „APK-Replay-Angriff“ ausgeschlossen werden kann. In diesem Fall kann der Server mit dem nächsten Schritt des erfindungsgemäßen Verfahrens, nämlich der Schlüsselüberprüfung (Schritt S3 in 2) fortfahren. Vorzugsweise wird darüber hinaus die neue digitale Signatur durch den Server in die Signaturdatenbank 220 aufgenommen (Schritt S8 in 5).
4b zeigt eine bevorzugte Implementierung der Schlüsselüberprüfung (Schritt S3 in 2).
Im Schritt S31 extrahiert der Server 210 aus der empfangenen APK-Datei den öffentlichen Schlüssel des Clients 100, und sucht in Schritt S32 in der Schlüsseldatenbank 230 nach einem übereinstimmenden Eintrag. Falls die Schlüsseldatenbank 230 einen entsprechenden Eintrag enthält (Schritt S33), wird die zugehörige ClientID aus der Datenbank ermittelt und dem Client wird mit der ermittelten ClientID in Schritt S4 ein automatisches Login auf dem Server gewährt.
Falls die Suche nach dem öffentlichen Schlüssel in der Schlüsseldatenbank im Schritt S33 fehlschlägt, wurde entweder der öffentliche Schlüssel des Clients noch nicht dem Account des Clients hinzugefügt oder ein unbekannter Dritter versucht eine Datei durch den Server bearbeiten zu lassen.
In beiden Fällen sendet der Server vorzugsweise eine Aufforderung zum manuellen Einloggen an den Client und führt ein Authentifizieren des Clients mittels der empfangenen Anmeldedaten des Clients durch, wie bereits im Zusammenhang mit der Ausführungsform der 5 erläutert. Nach erfolgreichem Authentifizieren des Clients, speichert der Server den öffentlichen Schlüssel des Clients zusammen mit der ClientID in der Schlüsseldatenbank (Schritt S94 in 5).
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

CN 105429961 [0008]

Claims

Verfahren zum Einloggen eines Clients (100) auf einem Server (210), gekennzeichnet durch folgende Schritte des Servers (210): - Empfangen (S1) einer durch den Client (100) hochgeladenen Datei, wobei die Datei einen öffentlichen Schlüssel des Clients umfasst; - Extrahieren (S31) des in der Datei enthaltenen öffentlichen Schlüssels des Clients; - Suchen (S32) eines mit dem öffentlichen Schlüssel des Clients übereinstimmenden Eintrags in einer Schlüsseldatenbank (230); und - automatisches Einloggen (S4) des Clients (100) falls die Schlüsseldatenbank (230) einen übereinstimmenden Eintrag enthält (S33) sowie - Verweigern (S9) des automatischen Einloggens des Clients (100) falls die Schlüsseldatenbank keinen übereinstimmenden Eintrag enthält (S33).
Verfahren nach Anspruche 1, dadurch gekennzeichnet, dass das automatische Einloggen ein temporäres Einloggen des Clients (100) umfasst, das ein Zugriffsrecht auf Dienste des Servers (210) in Bezug auf die Datei gewährt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass es weiter den folgenden Schritt umfasst: - Anwendung (S5) von durch den Server bereitgestellten Diensten auf die Datei, insbesondere Bearbeitung der Datei, und Herunterladen (S6) der bearbeiteten Datei auf den Client.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass es weiter die folgenden Schritte umfasst: - Anlegen (S01) eines Client-Accounts unter Verwendung einer ClientID; und - Speichern (S03) eines von dem Client (100) empfangenen (S02) öffentlichen Schlüssels zusammen mit der ClientID in der Schlüsseldatenbank (230).
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Datei eine digitale Signatur enthält und das Verfahren weiter die folgenden Schritte umfasst: - Extrahieren (S21) der digitalen Signatur; und - Überprüfen (S22) der Datei auf Integrität und Gültigkeit unter Verwendung der digitalen Signatur.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die digitale Signatur der Datei eine durch den Client (100) generierte digitale Signatur ist, die auf einem privaten Signaturschlüssel des Clients basiert.
Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass es weiter die folgenden Schritte umfasst: - Suchen (S24) der digitalen Signatur in einer Signaturdatenbank (220); und - Verweigern (S9) des automatischen Einloggens des Clients falls die Signaturdatenbank (220) einen übereinstimmenden Eintrag enthält (S25); sowie - Hinzufügen (S8) der digitalen Signatur zur Signaturdatenbank (220) falls die Signaturdatenbank (220) keinen übereinstimmenden Eintrag enthält (S25).
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass es weiter den folgenden Schritt umfasst, sofern die Signaturdatenbank (220) einen übereinstimmenden Eintrag enthält: - Durchführen eines manuellen Einloggens des Clients (100).
Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass es weiter die folgenden Schritte umfasst, falls die Schlüsseldatenbank (230) keinen übereinstimmenden Eintrag enthält: - Durchführen (S9) eines manuellen Einloggens des Clients (100); und - Speichern (S94) des öffentlichen Schlüssels des Clients (100) in der Schlüsseldatenbank (230) zusammen mit einer durch das manuelle Einloggen empfangenen ClientID des Clients (100).
Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass der Schritt des manuellen Einloggens weiter die folgenden Schritte umfasst: - Senden (S91) einer Aufforderung zum manuellen Einloggen an den Client (100); - Empfangen (S92) von Anmeldedaten von dem Client (100), wobei die Anmeldedaten vorzugsweise die ClientID und ein zugehöriges Client-passwort enthalten; und - Authentifizieren (S93) des Clients (100) mittels den empfangenen Anmeldedaten des Clients (100).
Server (210) zum Anwenden von Diensten auf eine von einem Client (100) empfangenen Datei, dadurch gekennzeichnet, dass der Server (210) dazu ausgestattet und eingerichtet ist: - eine durch den Client (100) hochgeladene Datei zu empfangen, wobei die Datei einen öffentlichen Schlüssel des Clients umfasst; - den in der Datei enthaltenen öffentlichen Schlüssel des Clients (100) zu extrahieren; - in einer Schlüsseldatenbank (230) nach einem mit dem öffentlichen Schlüssel des Clients (100) übereinstimmenden Eintrag zu suchen; - falls die Schlüsseldatenbank (230) einen übereinstimmenden Eintrag enthält, ein automatisches Einloggen des Clients (100) durchzuführen; und - falls die Schlüsseldatenbank keinen übereinstimmenden Eintrag enthält, das automatische Einloggen des Clients (100) zu verweigern.
Server (210) nach Anspruch 11, dadurch gekennzeichnet, dass der Server (210) ferner dazu ausgestattet und eingerichtet ist, ein Verfahren nach einem der Ansprüche 2 bis 10 auszuführen.
Plattform (200), insbesondere Cloud-Plattform, zum Bereitstellen von Diensten, dadurch gekennzeichnet, dass die Plattform (200) eine Schlüsseldatenbank (230) und einen Server (210) nach Anspruch 11 oder 12 umfasst.
System (300) zum Einloggen eines Clients auf einem Server, umfassend einen Client (100) und einen Server (210), dadurch gekennzeichnet, dass das System (300) weiter eine Schlüsseldatenbank (230) umfasst, wobei der Client (100) dazu eingerichtet ist: - eine Datei, die einen öffentlichen Schlüssel des Clients (100) umfasst, mittels einer digitalen Signatur, die auf einem privaten Signaturschlüssel des Clients (100) basiert, zu signieren; und - die signierte Datei auf dem Server (210) hochzuladen; wobei der Server (210) dazu eingerichtet ist: - den in der Datei enthaltenen öffentlichen Schlüssel des Clients (100) zu extrahieren; - einen mit dem öffentlichen Schlüssel des Clients übereinstimmenden Eintrag in der Schlüsseldatenbank (230) zu suchen; und - ein automatisches Einloggen des Clients (100) durchzuführen falls die Schlüsseldatenbank (230) einen übereinstimmenden Eintrag enthält; sowie - das automatische Einloggen des Clients (100) zu verweigern falls die Schlüsseldatenbank (230) keinen übereinstimmenden Eintrag enthält.