DE102019003814A1 - Automatisches Einloggen eines Clients bei einem Server - Google Patents

Automatisches Einloggen eines Clients bei einem Server Download PDF

Info

Publication number
DE102019003814A1
DE102019003814A1 DE102019003814.2A DE102019003814A DE102019003814A1 DE 102019003814 A1 DE102019003814 A1 DE 102019003814A1 DE 102019003814 A DE102019003814 A DE 102019003814A DE 102019003814 A1 DE102019003814 A1 DE 102019003814A1
Authority
DE
Germany
Prior art keywords
client
file
server
key
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019003814.2A
Other languages
English (en)
Inventor
Helmut Schuster
Daniel Albert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE
Original Assignee
Giesecke and Devrient Mobile Security GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Priority to DE102019003814.2A priority Critical patent/DE102019003814A1/de
Publication of DE102019003814A1 publication Critical patent/DE102019003814A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

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 (14)

  1. 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).
  2. 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.
  3. 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.
  4. 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).
  5. 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.
  6. 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.
  7. 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).
  8. 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).
  9. 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).
  10. 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).
  11. 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.
  12. 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.
  13. 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.
  14. 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.
DE102019003814.2A 2019-05-29 2019-05-29 Automatisches Einloggen eines Clients bei einem Server Pending DE102019003814A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102019003814.2A DE102019003814A1 (de) 2019-05-29 2019-05-29 Automatisches Einloggen eines Clients bei einem Server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019003814.2A DE102019003814A1 (de) 2019-05-29 2019-05-29 Automatisches Einloggen eines Clients bei einem Server

Publications (1)

Publication Number Publication Date
DE102019003814A1 true DE102019003814A1 (de) 2020-12-03

Family

ID=73264530

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019003814.2A Pending DE102019003814A1 (de) 2019-05-29 2019-05-29 Automatisches Einloggen eines Clients bei einem Server

Country Status (1)

Country Link
DE (1) DE102019003814A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002055609A (ja) * 2000-08-09 2002-02-20 Ricoh Co Ltd 電子文書に公開鍵を埋め込む方法または電子文書に埋め込まれた公開鍵を取り出す方法、装置、記録媒体
US7694150B1 (en) * 2004-06-22 2010-04-06 Cisco Technology, Inc System and methods for integration of behavioral and signature based security
US8752203B2 (en) * 2012-06-18 2014-06-10 Lars Reinertsen System for managing computer data security through portable data access security tokens
EP3258407A1 (de) * 2016-06-17 2017-12-20 Fujitsu Limited Vorrichtung, verfahren und programm zur steuerung von profildatenausgabe

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002055609A (ja) * 2000-08-09 2002-02-20 Ricoh Co Ltd 電子文書に公開鍵を埋め込む方法または電子文書に埋め込まれた公開鍵を取り出す方法、装置、記録媒体
US7694150B1 (en) * 2004-06-22 2010-04-06 Cisco Technology, Inc System and methods for integration of behavioral and signature based security
US8752203B2 (en) * 2012-06-18 2014-06-10 Lars Reinertsen System for managing computer data security through portable data access security tokens
EP3258407A1 (de) * 2016-06-17 2017-12-20 Fujitsu Limited Vorrichtung, verfahren und programm zur steuerung von profildatenausgabe

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ELLINGWOOD, Justin: SSH Essentials: Working with SSH Servers, Clients, and Keys. Digitalocean.com, 2014. URL: https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys [abgerufen am 23. Januar 2020] *
ELLINGWOOD, Justin: SSH Essentials: Working with SSH Servers, Clients, and Keys. Digitalocean.com, 2014. URL: https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys [abgerufen am 23. Januar 2020]

Similar Documents

Publication Publication Date Title
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
DE112015005024T5 (de) Öffnen lokaler Anwendungen von Browsern
DE102018007534A1 (de) Zeitgebundener sicherer Zugang
EP2159653B1 (de) Verfahren zur Einräumung einer Zugriffsberechtigung auf ein rechnerbasiertes Objekt in einem Automatisierungssystem, Computerprogramm und Automatisierungssystem
DE112017004033T5 (de) Verfahren zum Erhalten von geprüften Zertifikaten durch Mikrodienste in elastischen Cloud-Umgebungen
DE112020000538T5 (de) Feinkörnige zugriffskontrolle auf token-grundlage
DE102012018540A1 (de) Teilnehmeridentitätsmodul zum Authentisieren eines Teilnehmers an einem Kommunikationsnetzwerk
DE102008011191A1 (de) Client/Server-System zur Kommunikation gemäß dem Standardprotokoll OPC UA und mit Single Sign-On Mechanismen zur Authentifizierung sowie Verfahren zur Durchführung von Single Sign-On in einem solchen System
DE102015122518A1 (de) Authentifizierung von Datenkommunikationen
DE102014206325A1 (de) Verteiltes Authentifizierungssystem
DE102016012835A1 (de) Automatisches Identifizieren einer verringerten Verfügbarkeit von Vielkanalmedienverteilern zur Authentisierung oder Autorisierung
DE112020002343T5 (de) Verteilung von Sicherheitsberechtigungsnachweisen
DE102011077218A1 (de) Zugriff auf in einer Cloud gespeicherte Daten
EP2632104B1 (de) Verfahren und Telekommunikationssystem zur Anmeldung eines Nutzers an einem gesicherten personalisierten IPTV-Dienst
DE102016200382A1 (de) Verfahren zur Überprüfung einer Sicherheitseinstufung eines ersten Geräts mit Hilfe eines digitalen Zertifikats, ein erstes und zweites Gerät sowie eine Zertifikat-Ausstellungsvorrichtung
EP3908946B1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
EP2575385A1 (de) Verfahren zur Initialisierung und/oder Aktivierung wenigstens eines Nutzerkontos, zum Durchführen einer Transaktion, sowie Endgerät
EP3053317B1 (de) Verfahren zur authentisierung gegenüber einem server
DE102019003814A1 (de) Automatisches Einloggen eines Clients bei einem Server
DE112016000705T5 (de) Automatisches Entdecken und An-Bord-Nehmen von elektronischen Vorrichtungen
EP2919145A1 (de) Authentifizierungsvorrichtung, Authentifizierungssystem und Authentifizierungsverfahren
EP3376419A1 (de) System und verfahren zum elektronischen signieren eines dokuments
DE102021132225A1 (de) Verwaltung von gemeinsam genutzten authentifizierungsnachweisen
EP3355548A1 (de) Verfahren und system zur authentisierung eines benutzers
EP4115584B1 (de) Gesicherter und dokumentierter schlüsselzugriff durch eine anwendung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT EPAYMENTS GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT MOBILE SECURITY GMBH, 81677 MUENCHEN, DE

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT MOBILE SECURITY GMBH, 81677 MUENCHEN, DE

R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT EPAYMENTS GMBH, 81677 MUENCHEN, DE