DE102015014168A1

DE102015014168A1 - Method for distributing private keys from users to mobile devices

Info

Publication number: DE102015014168A1
Application number: DE102015014168.6A
Authority: DE
Inventors: wird später genannt werden Erfinder
Original assignee: SECARDEO GmbH
Current assignee: SECARDEO GmbH
Priority date: 2015-11-03
Filing date: 2015-11-03
Publication date: 2017-05-04

Abstract

Verfahren zur sicheren Verteilung privater Schlüssel eines Benutzers aus einem zentralen Schlüsselspeicher auf die von einem System zur Mobilgeräteverwaltung (MDM-System) verwalteten Mobilgeräte des Benutzers, das die folgenden Schritte umfasst: a) Lesen eines Konfigurationsprofils für ein Mobilgerät welches Daten zur Identifikation eines Benutzers enthält; b) Auslesen privater Schlüssel, welche den Identifikationsdaten zugeordnet sind aus einem zentralen Schlüsselspeicher; c) Speichern von einem oder mehreren privaten Schlüssel in dem Konfigurationsprofil;A method for securely distributing a user's private key from a central keystore to the user's mobile device managed by a mobile device management (MDM) system, comprising the steps of: a) reading a configuration profile for a mobile device containing data for identifying a user ; b) reading private keys associated with the identification data from a central keystore; c) storing one or more private keys in the configuration profile;

Description

Technisches GebietTechnical area

Diese Erfindung betrifft das Gebiet der Schlüsselverteilung und insbesondere Verfahren zur Verteilung privater Schlüssel asymmetrischer Kryptosysteme auf Mobilgeräte.This invention relates to the field of key distribution, and more particularly to methods of distributing private keys of asymmetric cryptosystems to mobile devices.

Stand der TechnikState of the art

Der Einsatz von Mobilgeräten wie SmartPhones oder Tablet-PCs nimmt sowohl im privaten als auch im geschäftlichen Bereich zu. Im geschäftlichen Umfeld dominieren dabei Apple Geräte mit dem Betriebssystem iOS gefolgt von Android und Windows Phone.The use of mobile devices such as SmartPhones or tablet PCs is increasing both in the private and in the business sector. In the business environment Apple devices dominate with the iOS operating system followed by Android and Windows Phone.

Die Sicherheit beim geschäftlichen Einsatz von Mobilgeräten ist eine kritische Anforderung. Auf Mobilgeräten können dazu kryptografische Operationen zur Ver- und Entschlüsselung, Authentisierung und digitalen Signatur ausgeführt werden. Das Betriebssystem stellt hierzu entsprechende symmetrische und asymmetrische Krypto- sowie Hashfunktionen zur Verfügung. So kann beispielsweise ein Apple iPhone Benutzer mit seiner iOS Mail App ausgehende E-Mails nach dem S/MIME Standard gemäß RFC 5751, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 – Message Specification IETF 2010 , mit den öffentlichen Schlüsseln der Empfänger verschlüsseln und empfangene E-Mails mit seinem privaten Schlüssel entschlüsseln. Dabei werden digitale Zertifikate gemäß X.509 „ITU-T X.509, Directory Information Technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks, 2005” verwendet. Ein digitales Zertifikat ordnet den öffentlichen Schlüssel eines Public Key Kryptosystems einem Benutzer oder Gerät zu und wird von einer vertrauenswürdigen Zertifizierungsstelle (Certification Authority, CA) digital signiert. Die Erzeugung, Verteilung und Verwaltung von digitalen Zertifikaten und privaten Schlüsseln für Mobilgeräte ist dabei eine wichtige Aufgabe.Security in mobile business use is a critical requirement. On mobile devices, cryptographic operations for encryption and decryption, authentication and digital signature can be performed. The operating system provides corresponding symmetrical and asymmetric crypto and hash functions for this purpose. For example, an Apple iPhone user can use their iOS Mail app to send outbound emails after the S / MIME Standard according to RFC 5751, Secure / Multipurpose Internet Mail Extensions (S / MIME) Version 3.2 - Message Specification IETF 2010 Use the public keys to encrypt the recipient and decrypt received e-mails with his private key. This digital certificates are in accordance with X.509 "ITU-T X.509, Directory Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks, 2005" used. A digital certificate associates the public key of a public key cryptosystem with a user or device and is digitally signed by a trusted certification authority (CA). The creation, distribution and management of digital certificates and private keys for mobile devices is an important task.

Für die zuvor beschriebenen kryptografischen Mechanismen müssen so genannte digitale Identitäten, das sind Zertifikate mit zugehörigem privatem Schlüssel, auf dem Mobilgerät verfügbar sein. Dabei muss unterschieden werden zwischen digitalen Identitäten für Geräte, beispielweise zur Geräteauthentisierung, und Benutzer, beispielsweise zur Datenverschlüsselung.For the cryptographic mechanisms described above, so-called digital identities, which are certificates with a corresponding private key, must be available on the mobile device. A distinction must be made between digital identities for devices, for example for device authentication, and users, for example for data encryption.

Zur Verschlüsselung von Daten für Partner müssen deren Zertifikate auf dem Mobilgerät verfügbar sein. In DE 20 2013 016 466 A1 wird ein Verfahren beschrieben, mit dem Zertifikate von externen Partnern im Internet gefunden und auf das Mobilgerät geladen werden können. Dabei erfolgt eine Umsetzung von Suchanfragen des ActiveSync Protokolls in das LDAP Protokoll.To encrypt data for partners, their certificates must be available on the mobile device. In DE 20 2013 016 466 A1 A method is described that allows certificates from external partners to be found on the Internet and downloaded to the mobile device. In the process, search queries of the ActiveSync protocol are converted into the LDAP protocol.

Auf dem Mobilgerät muss zur Ver- und Entschlüsselung auch eine digitale Identität für den Benutzer verfügbar sein.On the mobile device, a digital identity must also be available to the user for encryption and decryption.

Digitale Identitäten und insbesondere deren private Schlüssel können entweder in einer speziellen Hardware, beispielsweise einer Chipkarte oder einem Trusted Platform Module (TPM) gespeichert und verarbeitet werden oder sie werden in Form von Software-Keys genutzt. Der Einsatz von Chipkarten ist bei Mobilgeräten stark eingeschränkt und mit hohen Kosten verbunden und hat daher keine Verbreitung gefunden.Digital identities and in particular their private keys can either be stored and processed in special hardware, for example a chip card or a trusted platform module (TPM), or they are used in the form of software keys. The use of smart cards is severely limited in mobile devices and associated with high costs and has therefore found no distribution.

Für die Speicherung von digitalen Identitäten stellen die Betriebssysteme einen eigenen abgesicherten Speicherbereich (Zertifikatsspeicher) zur Verfügung. In „Windows Server 2008 PKI and Certificate Security”, Microsoft Press 2008 wird beschrieben wie in Microsoft Windows private Schlüssel und Zertifikate im Windows Certificate Store verwaltet werden. Bei Apple iOS wird hierzu die iOS Keychain, siehe auch „Keychain Services Programming Guide” unter developer.apple.com , und unter Android der Keystore, siehe auch „Android Keystore System” unter developer.android.com , verwendet.For storing digital identities, the operating systems provide their own secure storage area (certificate store). In "Windows Server 2008 PKI and Certificate Security", Microsoft Press 2008 describes how to manage Microsoft Windows private keys and certificates in the Windows Certificate Store. For Apple iOS this is the iOS Keychain, see also "Keychain Services Programming Guide" at developer.apple.com , and under Android the keystore, see also "Android Keystore System" at developer.android.com , used.

Damit ein Benutzer seine Daten, beispielsweise E-Mails, auf jedem seiner Geräte ver- und entschlüsseln oder diese stets mit demselben privaten Schlüssel signieren kann, müssen seine digitale Identitäten, insbesondere sein Verschlüsselungszertifikat samt zugehörigem privatem Schlüssel, in den Zertifikatsspeichern all seiner Geräte verfügbar sein. Nur dann ist gewährleistet, dass ein Kommunikationspartner, der ein veröffentlichtes Zertifikat des Benutzers zur Verschlüsselung verwendet, sicher sein kann, dass der Empfänger die Daten dann auch entschlüsseln kann.In order for a user to be able to encrypt and decrypt his data, such as e-mails, on any of his devices or to always sign them with the same private key, his digital identities, in particular his encryption certificate and associated private key, must be available in the certificate stores of all his devices , Only then is it guaranteed that a communication partner who uses a published certificate of the user for encryption can be sure that the recipient can then decrypt the data.

Mobilgeräte wie das Apple iPhone bieten die Möglichkeit sowohl für Benutzer als auch für das Gerät selbst Schlüsselpaare zu generieren und Zertifikatsanforderungen an eine Registrierungsstelle zu senden.Mobile devices such as the Apple iPhone provide the ability for both users and the device itself to generate key pairs and send certificate requests to a registrar.

Für die digitalen Identitäten von Benutzern wird dieser Weg aus den zuvor geschilderten Gründen nicht empfohlen. Digitale Identitäten von Benutzern werden in Unternehmen in einem zentralen Schlüsselspeicher (Key-Archive) verwaltet. Hier werden sie verschlüsselt nach der Schlüsselgenerierung gespeichert und können von dort im Rahmen geregelter Abläufe durch autorisierte Instanzen rekonstruiert werden. In einer Microsoft Windows CA erfolgt dies durch sogenannte Key Recovery Agents.For the digital identities of users this way is not recommended for the reasons described above. Digital identities of users are managed in enterprises in a key archive. Here they are stored encrypted after the key generation and can be reconstructed from there within the framework of controlled processes by authorized authorities. In a Microsoft Windows CA, this is done by so-called Key Recovery Agents.

Digitale Identitäten für Geräte hingegen können durch das Gerät selbst erzeugt werden. In Zeichnungen Seite 1 wird der Ablauf bei der Ausstellung eines Gerätezertifikats gezeigt. Das Mobilgerät generiert ein asymmetrisches Schlüsselpaar und sendet den öffentlichen Schlüssel in einer Zertifikatsanforderung an eine Registrierungsinstanz (Registration Authority, RA) 1. Diese prüft die Anforderung und sendet diese weiter an die ausstellende CA 2. Die CA stellt ein X.509 Zertifikat gemäß der CA-Richtlinie aus und sendet es an die RA zurück 3. Die RA sendet das Zertifikat dann an das Mobilgerät, welches das Zertifikat zusammen mit dem zugehörigen privaten Schlüssel als digitale Identität in seinem Zertifikatsspeicher ablegt 4. Für diesen Ablauf wird von Apple SCEP ( Simple Certificate Enrollment Protocol, Internet Draft, IETF 2011 ) verwendet. Microsoft nutzt dafür Oasis WS-Trust mit den von Microsoft unter msdn.microsoft.com veröffentlichten „[MS-WSTEP]: WS-Trust X.509v3 Token Enrollment Extensions” . Abweichend davon kann im Schritt 1 das Schlüsselpaar durch die RA generiert werden und in Schritt 4 die vollständige digitale Identität an das Mobilgerät gesendet werden. Digital identities for devices, on the other hand, can be generated by the device itself. Drawings page 1 shows the process of issuing a device certificate. The mobile device generates an asymmetric key pair and sends the public key in a certificate request to a Registration Authority (RA) 1 , It checks the request and sends it to the issuing CA. 2 , The CA issues an X.509 certificate under the CA policy and sends it back to the RA 3 , The RA then sends the certificate to the mobile device, which stores the certificate along with the associated private key as a digital identity in its certificate store 4 , For this process, Apple SCEP ( Simple Certificate Enrollment Protocol, Internet Draft, IETF 2011 ) used. Microsoft uses for it Oasis WS-Trust with Microsoft's msdn.microsoft.com "[MS-WSTEP]: WS-Trust X.509v3 Token Enrollment Extensions" , Deviating from this, in step 1 the key pair can be generated by the RA and in step 4 the complete digital identity can be sent to the mobile device.

Die zentralisierte Verwaltung von Mobilgeräten erfolgt in Unternehmen über ein Mobilgeräteverwaltungssystem (Mobile Device Management System, MDM), auch als Enterprise Mobility Management (EMM) bezeichnet. Die Verwaltung umfasst die Inventarisierung von Geräten, die Software- und Datenverteilung, sowie den Schutz der Daten auf diesen Geräten. Auch Aufgaben der drahtlosen Verwaltung via Mobilfunk/WLAN gehören dazu. Zur Verwaltung dienen Konfigurationsprofile, die betriebssystemspezifisch sind. Die Verteilung der Konfigurationsprofile vom MDM System auf die betreffenden Geräte erfolgt über MDM Protokolle, die sich je nach Hersteller und Betriebssystem unterscheiden. Diese MDM Protokolle verwenden zum Schutz kryptografische Mechanismen zur Authentisierung und Verschlüsselung. In Zeichnungen Seite 2 ist der prinzipielle Ablauf abgebildet. Der MDM-Server sendet über das Internet eine Nachricht an einen Benachrichtigungsserver die signalisiert, dass er Daten an das Mobilgerät M senden möchte 1. Der Benachrichtigungsserver sendet daraufhin eine Wecknachricht über das Mobilfunknetz an das Mobilgerät M 2. Das Mobilgerät fragt dann über ein IP Netzwerk beim MDM-Server an 3. Der MDM-Server sendet dann Anweisungen, beispielsweise zum Löschen von Daten auf dem Gerät oder zum Installieren eines Konfigurationsprofils, an das Mobilgerät 4. Der genaue Protokollablauf ist abhängig vom Hersteller des Mobilgerätes sowie des MDM Systems. Im Folgenden werden die wichtigsten Protokolle vorgestellt.The centralized management of mobile devices in the enterprise takes place via a Mobile Device Management (MDM) system, also known as Enterprise Mobility Management (EMM). Management includes inventorying devices, distributing software and data, and protecting data on those devices. Also tasks of the wireless administration via portable radio / WLAN belong to it. The administration profiles are configuration-specific operating system-specific. The distribution of the configuration profiles from the MDM system to the respective devices takes place via MDM protocols, which differ depending on the manufacturer and the operating system. These MDM protocols use cryptographic mechanisms for authentication and encryption for protection. Drawings page 2 shows the basic procedure. The MDM server sends a message via the Internet to a notification server signaling that it wants to send data to the mobile device M. 1 , The notification server then sends a wake-up message over the mobile network to the mobile device M 2 , The mobile device will then contact the MDM server over an IP network 3 , The MDM server then sends instructions to the mobile device, such as deleting data on the device or installing a configuration profile 4 , The exact protocol depends on the manufacturer of the mobile device and the MDM system. In the following, the most important protocols are presented.

Das Open Mobile Alliance (OMA) Device Management (DM) Protocol, veröffentlicht als „OMA Device Management V1.2” unter technical.openmobilealliance.org , basiert auf der Synchronization Markup Language (SyncML), die eine Untermenge von XML darstellt. OMA DM spezifiziert die Provisionierung, Gerätekonfiguration, Software Upgrades sowie das Fehlermanagement für Mobilgeräte. Hierfür wird ein Anfrage/Antwort-Protokoll verwendet, das eine gegenseitige Authentisierung umfasst.The Open Mobile Alliance (OMA) Device Management (DM) Protocol, published as "OMA Device Management V1.2" at technical.openmobilealliance.org , based on the Synchronization Markup Language (SyncML), which is a subset of XML. OMA DM specifies provisioning, device configuration, software upgrades and fault management for mobile devices. For this purpose, a request / response protocol is used, which includes a mutual authentication.

Microsoft verwendet in ihrem unter msdn.microsoft veröffentlichten „[MS-MDM]: Mobile Device Management Protocol” eine Untermenge des OMA-DM Protokolls. Die damit zu verwaltenden Mobilgeräte müssen zuvor mit dem Mobile Device Enrollment Protocol [MS-MDE] registriert worden sein. Dabei wird ein Device Identify Certificate für das Gerät ausgestellt, welches anschließend für eine SSL/TLS Client Authentisierung gegenüber dem MDM System verwendet wird. Jede SyncML Nachricht des MDM Client enthält einen zusätzlichen HTTP Header „MS-Signature and Authorization”. Dieser Header enthält eine BASE64 kodierte abgesetzte CMS (Cryptographic Message Syntax) Signatur des SHA-2 Hashwertes der kompletten SyncML Nachricht (SyncHdr, SyncBody). Die Signatur wird mit dem privaten Schlüssel des Device Identify Certificate erzeugt.Microsoft uses in their under msdn.microsoft released "[MS-MDM]: Mobile Device Management Protocol" a subset of the OMA-DM protocol. The mobile devices to be managed with this must first have been registered with the Mobile Device Enrollment Protocol [MS-MDE]. A device identification certificate is issued for the device, which is subsequently used for SSL / TLS client authentication in relation to the MDM system. Each SyncML message from the MDM client includes an additional MS-Signature and Authorization HTTP header. This header contains a BASE64 encoded remote CMS (Cryptographic Message Syntax) signature of the SHA-2 hash value of the complete SyncML message (SyncHdr, SyncBody). The signature is generated with the private key of the Device Identify Certificate.

Das Microsoft Mobile Device Enrollment Protocol führt die Ausstellung von Zertifikaten gemäß Oasis WS-Trust und den Microsoft WS-Trust X.509v3 Token Enrollment Extensions [MS-WSTEP] durch. Damit können Zertifikatsanforderungen in den gängigen Formaten PKCS#10 [RFC2986], PKCS#7 [RFC3852], oder CMC [RFC2797] mittels dem SOAP Protokoll übermittelt werden. Mit der RequestSecurityToken Operation wird ein Gerät registriert. Die Antwortnachricht RequestSecurityTokenResponseCollection enthält ein XML Provisioning Dokument in base64-Kodierung. Diese Dokument enthält das angeforderte Client Certificate, ein vertrauenswürdiges Root Certificate und Intermediate Certificates.The Microsoft Mobile Device Enrollment Protocol performs issuance of Oasis WS-Trust certificates and the Microsoft WS-Trust X.509v3 Token Enrollment Extensions [MS-WSTEP]. In this way, certificate requests in the standard formats PKCS # 10 [RFC2986], PKCS # 7 [RFC3852], or CMC [RFC2797] can be transmitted using the SOAP protocol. The RequestSecurityToken operation registers a device. The response message RequestSecurityTokenResponseCollection contains an XML provisioning document in base64 encoding. This document contains the requested Client Certificate, a Trusted Root Certificate, and Intermediate Certificates.

Für Android wurde die Android Device Administration API spezifiziert und unter developer.android.com veröffentlicht. Diese kann von Apps verwendet werden, um Administrationsaufgaben durchzuführen. Mit der Version Android for Works erfolgt eine Trennung privater und geschäftlicher Bereiche auf dem Mobilgerät. Hiermit können auch Profile von einem MDM/EMM System verwaltet werden. Dazu dient eine Work Policy Controller App, welche Anfragen an das MDM System sendet und die verfügbaren Policies über die Device Administration API auf dem Gerät aktiviert. Welches Protokoll zwischen der Work Policy Controller App und dem MDM System abgewickelt wird ist nicht spezifiziert und kann vom MDM Hersteller individuell, beispielsweise gemäß SyncML, implementiert werden.For Android, the Android Device Administration API specified and available at developer.android.com released. This can be used by apps to perform administrative tasks. The Android for Works separates personal and business areas on the mobile device. It can also manage profiles from an MDM / EMM system. This is done through a Work Policy Controller App, which sends requests to the MDM system and activates the available policies through the Device Administration API on the device. Which protocol is handled between the Work Policy Controller App and the MDM system is not specified and can be implemented individually by the MDM manufacturer, for example according to SyncML.

Apple legt in ihrer „Mobile Device Management Protocol Reference”, für registrierte Benutzer zugänglich unter developer.apple.com , fest, wie iOS Geräte verwaltet werden. Mit dem Protokoll werden Kommandos zur Geräteverwaltung an das Gerät gesendet. Insbesondere können damit von einem MDM System aus Konfigurationsprofile inspiziert, installiert oder gelöscht werden. Dies sind XML-Strukturen im Property List Format (.plist), die beispielsweise zur Konfiguration von E-Mail- oder Netzwerk-Einstellungen dienen und die in der „Apple Configuration Profile Reference” unter developer.apple.com spezifiziert sind. Das iOS Gerät wird über den Apple Push Notification Service (APNS) „aufgeweckt”, um dann vom MDM System Kommandos abzurufen. Mit dem Kommando InstallProfile wird das Mobilgerät angewiesen das angegebene Profil zu installieren. Die MDM-Nutzdaten (Payload) sind in einem solchen Konfigurationsprofil enthalten. Ein Beispiel hierfür ist in Zeichnungen Seite 7 aufgeführt. Es kann zu einem Zeitpunkt nur eine MDM Payload auf einem Gerät installiert sein. Diese können vom MDM signiert und für das Gerät mit einem Identity Certificate verschlüsselt werden. Dies geschieht im CMS Format gemäß RFC 5652 Cryptographic Message Syntax (CMS), IETF 2009 .Apple lays in her "Mobile Device Management Protocol Reference", for registered users accessible at developer.apple.com Determine how iOS devices are managed. The protocol sends device management commands to the device. In particular, configuration profiles can be inspected, installed or deleted from an MDM system. These are XML structures in the property list format (.plist), which are used, for example, to configure e-mail or network settings and are stored in the "Apple Configuration Profile Reference" at developer.apple.com are specified. The iOS device is "woken up" via the Apple Push Notification Service (APNS) and then retrieved commands from the MDM system. The InstallProfile command instructs the mobile device to install the specified profile. The MDM payload is contained in such a configuration profile. An example of this is shown in drawings page 7. There can be only one MDM payload installed on a device at a time. These can be signed by the MDM and encrypted for the device with an identity certificate. This happens in CMS format according to RFC 5652 Cryptographic Message Syntax (CMS), IETF 2009 ,

Das verwaltete Apple iOS Gerät erhält im Rahmen des initialen MDM Check-in Protokolls ein Identity Certificate und authentisiert sich hiermit im SSL/TLS Handshake gegenüber dem MDM System. Jede Nachricht des MDM Client kann einen zusätzlichen HTTP Header „Mdm-Signature” enthalten. Dieser Header enthält eine BASE64 kodierte abgesetzte CMS (Cryptographic Message Syntax) Signatur des Hashwertes der Nachricht. Die Signatur wird mit dem privaten Schlüssel des Identity Certificate erzeugt.The managed Apple iOS device receives an identity certificate as part of the initial MDM check-in protocol and authenticates itself in the SSL / TLS handshake to the MDM system. Each message of the MDM client can contain an additional HTTP header "Mdm Signature". This header contains a BASE64 encoded remote CMS (Cryptographic Message Syntax) signature of the hash value of the message. The signature is generated with the private key of the identity certificate.

In US9027112B2 wird beschrieben, wie ein iOS Mobilgerät im Check-in Protokoll ein Identity Certificate erhält. Dies kann entweder in einem Management Profil enthalten sein, welches individuell auf dem Gerät installiert wird oder es wird im Rahmen einer SCEP (Simple Certificate Enrollment Protocol) Anfrage/Antwort erzeugt.In US9027112B2 It describes how an iOS mobile device receives an identity certificate in the check-in log. This can either be contained in a management profile which is installed individually on the device or it is generated as part of a SCEP (Simple Certificate Enrollment Protocol) request / response.

Es wurde beschrieben, wie digitale Identitäten für Mobilgeräte ausgestellt werden, die zur Authentisierung und Transportverschlüsselung dienen. Darüber hinaus werden auf dem Gerät digitale Identitäten für Benutzer benötigt mit denen dieser Daten wie E-Mails ver- und entschlüsseln oder sich als Person gegenüber Diensten authentisieren kann. Solche digitalen Identitäten für Benutzer werden üblicherweise nicht auf einem Mobilgerät erzeugt und müssen daher auf das Mobilgerät übertragen werden.We described how to issue digital identities to mobile devices used for authentication and transport encryption. In addition, the device requires digital identities for users to encrypt and decrypt data, or to authenticate as a person to services. Such digital identities for users are typically not generated on a mobile device and therefore must be transferred to the mobile device.

Zur Übertragung von digitalen Identitäten hat sich für den Datenspeicher das PKCS#12 Format, RFC 7292: PKCS #12: Personal Information Exchange Syntax Standard v1.1 IETF 2014 , durchgesetzt. Der darin verschlüsselt codierte private Schlüssel kann nach Eingabe des korrekten Passworts entschlüsselt und dann in den Speicher des jeweiligen Betriebssystems geladen werden. Hinsichtlich der Verwaltung und der Zugriffsberechtigungen unterscheiden sich die Betriebssysteme deutlich.For the transmission of digital identities has for the data storage the PKCS # 12 Format, RFC 7292: PKCS # 12: Personal Information Exchange Syntax Standard v1.1 IETF 2014 enforced. The encrypted private key can be decrypted after entering the correct password and then loaded into the memory of the respective operating system. The operating systems differ significantly in terms of administration and access rights.

Microsoft stellt mit dem Windows-Dienst Credential Roaming eine Möglichkeit bereit, digitale Identitäten eines Benutzers auf verschiedene Rechner in einer Domäne zu verteilen, die der Benutzer verwendet. Dieser Dienst ist beschränkt auf Computer, die Mitglied einer Active Directory Domäne sind. Das Verfahren ist in EP 1 585 286 A2 beschrieben.With the Windows Credential Roaming service, Microsoft provides a way to distribute a user's digital identities across different machines in a domain that the user uses. This service is limited to computers that are members of an Active Directory domain. The procedure is in EP 1 585 286 A2 described.

Unter Android kann jede Applikation (App) die Zugriffsberechtigungen für Schlüssel bei deren Generierung oder Import in den Android Keystore festlegen. Diese Berechtigungen können anschließend nicht mehr verändert werden. Über die Android Keychain API können systemweite Schlüssel von Apps verwendet werden, nachdem der Benutzer über einen Systemdialog die Berechtigung dazu erteilt hat.Under Android, any application (app) can set access permissions for keys when they are generated or imported into the Android keystore. These permissions can not be changed afterwards. The Android Keychain API allows you to use system-wide keys from apps after the user authorizes them through a system dialog.

Unter Windows Phone können digitale Identitäten im PKCS#12 Format mittels Internet Explorer, E-Mail App oder einem MDM System in den Zertifikatsspeicher importiert werden. Der Import einer digitalen Identität von einem MDM System geschieht im SyncML Protokoll über den Configuration Service Provider ClientCertificateInstall. Dieser liefert dem Gerät neben weiteren Attributen den Schlüsselcontainer PFXCertBlob und das zugehörige Passwort PFXCertPassword.Under Windows Phone, PKCS # 12 digital identities can be imported into the certificate store using the Internet Explorer, Email App, or MDM system. The import of a digital identity from an MDM system is done in the SyncML protocol via the Configuration Service Provider ClientCertificateInstall. In addition to other attributes, this provides the device with the key container PFXCertBlob and the corresponding password PFXCertPassword.

Jede Apple iOS Applikation (App) kann nur auf Keychain-Einträge innerhalb der eigenen Keychain Access Group über die Keychain Services API zugreifen. Eine iOS App kann über die Funktion SecPKCS12Import eine digitale Identität der eigenen Access Group hinzufügen. Auf die Einträge der Apple Keychain Access Group können nur Apple Apps wie iOS Mail oder Safari zugreifen. Digitale Identitäten aus einem PKCS#12 Container können unter iOS durch Download mittels Safari, Öffnen als E-Mail-Anhang oder Import eines Konfigurationsprofils installiert werden. Digitale Identitäten, die auf einem dieser Wege installiert werden, werden der Apple Keychain Access Group zugeordnet. Die Dateiendung .p12 ist hierfür reserviert und sie kann daher von keiner anderen App verwendet werden.Each Apple iOS application (app) can only access Keychain entries within its own Keychain Access Group through the Keychain Services API. An iOS app can use the SecPKCS12Import function to add a digital identity to its own access group. The entries in the Apple Keychain Access Group can only be accessed by Apple apps such as iOS Mail or Safari. Digital identities from a PKCS # 12 container can be installed on iOS by downloading via Safari, opening as an e-mail attachment or importing a configuration profile. Digital identities that are installed in one of these ways are assigned to the Apple Keychain Access Group. The file extension .p12 is reserved for this purpose and therefore it can not be used by any other app.

Das Apple MDM Protocol verwendet Nutzdaten, die in der Apple Configuration Profile Reference definiert sind. Die Certificate Payload, kann einen PKCS#12 Container sowie das zugehörige Passwort enthalten. Ferner werden applikationsspezifische Nutzdaten wie die Email Payload sowie Exchange Payload definiert, welche Referenzen (UUID) auf eine übermittelte Certificate Payload enthalten können (SMIMESigning-CertificateUUID, SMIMEEncryption-CertificateUUID). In Zeichnungen Seite 8 ist ein Beispiel für eine Exchange Payload aufgeführt.The Apple MDM Protocol uses payloads defined in the Apple Configuration Profile Reference. The certificate payload can contain a PKCS # 12 container as well as the associated password. Furthermore, application-specific user data such as email payload and exchange payload are defined, which references (UUID) can contain a transmitted certificate payload (SMIMESigning-CertificateUUID, SMIMEEncryption-CertificateUUID). See drawings on page 8 for an example of an Exchange Payload.

Beschreibung des Problemsdescription of the problem

Damit ein Benutzer auf allen seinen Geräten Zugriff auf die mittels seinem digitalen Zertifikat verschlüsselten Daten hat, muss auf jedem Gerät der Zugriff auf seinen privaten Schlüssel möglich sein.For a user to have access to the data encrypted by means of his digital certificate on all his devices, access to his private key must be possible on each device.

Bei der Nutzung von Software-Schlüsseln müssen diese auf sichere Art und Weise auf die Geräte des Benutzers verteilt werden ohne dass der Benutzer aufwändige manuelle Schritte durchführen muss.When using software keys, they must be securely distributed to the user's devices without requiring the user to perform elaborate manual steps.

Eine automatisierte Verteilung kann über ein MDM System mittels der zuvor beschriebenen Verfahren erfolgen. Dazu müssen die Container, welche die privaten Schlüssel der Benutzer enthalten sowie die zugehörige Passwörter auf dem MDM System gespeichert werden.Automated distribution can be accomplished via an MDM system using the methods previously described. To do this, the containers containing the users' private keys and the associated passwords must be stored on the MDM system.

Apple lässt es für ein mittels MDM verwaltetes iOS-Gerät nicht zu, dass das Passwort für eine digitale ID auf anderem Weg als über das MDM Protokoll auf das Gerät gelangt. Auch eine manuelle Eingabe durch den Benutzer ist nicht möglich.Apple does not allow an MDM-managed iOS device to pass the password for a digital ID to the device by any means other than the MDM protocol. Even a manual input by the user is not possible.

Die Speicherung von Containern mit privaten Schlüsseln samt Passwort zur Entschlüsselung des Containers stellt ein erhebliches Sicherheitsrisiko für ein Unternehmen dar. Ein Angreifer, der sich Zugang zum MDM System verschafft hat unmittelbar Zugriff auf alle privaten Schlüssel aller mobilen Anwender des Unternehmens und kann damit alle für diese verschlüsselten Daten lesen auf die er Zugriff erlangt. Das MDM ist üblicherweise vom Internet aus erreichbar und es wurden in der Vergangenheit bereits erfolgreiche Angriffe auf solche Systeme demonstriert.Storing containers with private keys and password to decrypt the container poses a significant security risk to a business. An attacker who gains access to the MDM system has direct access to all the private keys of all mobile users of the company and can do all of these for them read encrypted data to which he obtained access. The MDM is typically accessible from the Internet, and successful attacks on such systems have been demonstrated in the past.

Ein weiteres, nicht tragbares Risiko stellt der Administrator des MDM Systems dar. Dieser kann sich ebenfalls Zugriff auf alle privaten Schlüssel verschaffen. Ferner ist es durchaus Praxis, dass der Administrator die privaten Schlüssel der mobilen Benutzer manuell in das MDM System importiert, die zuvor aus einem Schlüsselarchiv beispielsweise im PKCS#12 Format exportiert wurden.Another unacceptable risk is the administrator of the MDM system, who can also gain access to all private keys. Further, it is quite common practice for the administrator to manually import the mobile users' private keys into the MDM system that were previously exported from a key archive, for example, in PKCS # 12 format.

Beschreibung der ErfindungDescription of the invention

Die Aufgabe der hier vorliegenden Erfindung ist es, private Schlüssel eines Benutzers sicher aus einem zentralen Schlüsselspeicher wie einem Schlüsselarchiv oder einem Zertifikatsportal auf die von einem MDM-System verwalteten Mobilgeräte des Benutzers zu verteilen und zu verwalten. Der private Schlüssel kann dabei Bestandteil einer digitalen Identität, beispielsweise im PKCS#12 Format, sein, welche das Benutzerzertifikat samt zugehörigem privatem Schlüssel sowie gegebenenfalls weitere Zertifikate enthält. Das technische Verfahren wird im Folgenden beschrieben.The object of the present invention is to securely distribute and manage a user's private keys from a central keystore such as a key archive or a certificate portal to the user's mobile devices managed by an MDM system. The private key can be part of a digital identity, for example in the PKCS # 12 format, which contains the user certificate together with the associated private key and optionally further certificates. The technical process is described below.

Das Verfahren erfordert keine technischen Änderungen am Mobilgerät oder am MDM System. Es kann durch Vorschalten eines zusätzlichen Systems zwischen Geräte-Client und MDM-Server realisiert werden. Ein solches System wird im Folgenden als „MDM-Proxy” bezeichnet.The procedure does not require any technical changes to the mobile device or the MDM system. It can be realized by connecting an additional system between device client and MDM server. Such a system will be referred to as "MDM proxy" in the following.

Der MDM-Proxy gibt sich in dem durchgeführten MDM-Protokoll gegenüber dem Mobilgerät als MDM System aus und gegenüber dem MDM System als Mobilgerät. Der MDM Proxy empfängt Nachrichten des verwendeten MDM-Protokolls von der sendenden Instanz, modifiziert diese bei Bedarf, und sendet sie an die empfangende Instanz. Dabei können gängige MDM-Protokolle wie das Apple-MDM Protocol, MS-MDM Protocol oder SyncML eingesetzt werden.The MDM proxy pretends to be an MDM system to the mobile device in the MDM protocol being performed and to be a mobile device to the MDM system. The MDM proxy receives messages from the MDM protocol used by the sending entity, modifies them as needed, and sends them to the receiving entity. Common MDM protocols such as the Apple MDM Protocol, MS-MDM Protocol or SyncML can be used.

Zur Authentisierung gegenüber dem Mobilgerät verwendet der MDM-Proxy eine digitale Identität ID-PS (Proxy Server) mit einem entsprechenden Serverzertifikat, dem alle Mobilgeräte vertrauen. Das Mobilgerät i authentisiert sich gegenüber dem MDM-Proxy mit einer digitalen Identität ID-MC_i (Mobile Client i) mit einem entsprechenden Clientzertifikat. Zur Authentisierung gegenüber dem MDM System verwendet der MDM-Proxy für jedes Mobilgerät i eine individuelle digitale Identität ID-PC_i (Proxy Client i) mit einem entsprechenden Clientzertifikat.To authenticate to the mobile device, the MDM proxy uses a digital identity ID-PS (Proxy Server) with a corresponding server certificate that all mobile devices trust. The mobile device i authenticates itself to the MDM proxy with a digital identity ID-MC _i (Mobile Client i) with a corresponding client certificate. For authentication to the MDM system, the MDM proxy for each mobile device i uses an individual digital identity ID-PC _i (Proxy Client i) with a corresponding client certificate.

Zur Authentisierung gegenüber dem MDM-System und dem Gerät kann das SSL/TLS Protokoll mit gegenseitiger Client-/Server-Authentisierung im Protokoll-Handshake verwendet werden. Alternativ kann die Authentisierung des Gerätes gegenüber dem MDM-Proxy sowie des MDM-Proxys gegenüber dem MDM-System anhand einer digitalen Signatur erfolgen. Die digitale Signatur kann über Teile der MDM-Nachricht gebildet werden und beispielsweise im HTTP-Header übertragen werden, wenn HTTP zum Nachrichtentransport verwendet wird.For authentication with the MDM system and the device, the SSL / TLS protocol with mutual client / server authentication in the protocol handshake can be used. Alternatively, the device can be authenticated against the MDM proxy and the MDM proxy relative to the MDM system by means of a digital signature. The digital signature can be formed over parts of the MDM message and, for example, transmitted in the HTTP header if HTTP is used for message transport.

Die digitale Identität ID-PS wird bei der Installation des MDM-Proxy erzeugt. Die digitalen Identitäten ID-MC_i und ID-PC_i werden während der Registrierung des Geräts i erzeugt. Dies kann auf verschiedenen Wegen erfolgen:

a) Durch manuelle Installation
b) Durch Übermittlung in einem MDM-Profil
c) Durch Erzeugung mit einem Certificate Enrollment Protokoll wie SCEP oder MS-WSTEP

The ID-PS digital identity is generated when the MDM proxy is installed. The digital identities ID-MC _i and ID-PC _i are generated during registration of the device i. This can be done in different ways:

a) By manual installation
b) By transmission in an MDM profile
c) By generating with a certificate enrollment protocol such as SCEP or MS-WSTEP

In Zeichnungen Seite 3 ist ein Ausführungsbeispiel für die Registrierung eines Mobilgerätes gemäß b) und c) abgebildet. Das Mobilgerät meldet sich über ein Netzwerk am MDM-Proxy an 1. Dieser leitet die Nachricht an den MDM-Server weiter 2. Der MDM Server sendet ein MDM Profil zurück 3. Dieses Profil kann bei Variante b) die ID-MC_i enthalten. In dem Fall erzeugt der MDM-Proxy eine Kopie ID-PC_i und sendet das Profil mit ID-MC_i an das Mobilgerät weiter und der Registrierungsablauf ist damit beendet 4. Bei Variante c) ist im MDM Profil die Adresse einer Registrierungsinstanz RA1 oder die Adresse eines Proxys, beispielsweise der MDM-Servers, enthalten an die das Mobilgerät seine Zertifikatsanforderung senden soll. Diese Adresse wird im MDM-Profil ersetzt durch die Adresse des MDM-Proxys und das Profil wird an das Mobilgerät weitergeleitet 4. Das Mobilgerät generiert ein Schlüsselpaar und sendet den öffentlichen Schlüssel in einer Zertifikatsanforderung, beispielsweise mittels SCEP, an den MDM-Proxy 5. Der MDM-Proxy erzeugt ein Schlüsselpaar und sendet den öffentlichen Schlüssel in einer Zertifikatsanforderung an die Registrierungsinstanz RA1 weiter 6. Die Registrierungsinstanz RA1 prüft die Zertifikatsanforderung und leitet sie an die CA1 weiter 7. Der CA1 wird durch den MDM-Proxy und den MDM-Server vertraut. Diese stellt ein Zertifikat Cert-PCi aus und sendet es an RA1 zurück 8. RA1 leitet das Zertifikat an den MDM-Proxy weiter 9. Dieser ist nun im Besitz der digitalen Identität ID-PC_i. Der MDM-Proxy leitet nun die vom Mobilgerät empfangene Zertifikatsanforderung an die Registrierungsinstanz RA2 weiter 10. Die Registrierungsinstanz RA2 prüft die Zertifikatsanforderung und leitet sie an die CA2 weiter 11. Der CA2 wird durch das Mobilgerät vertraut. Diese stellt ein Zertifikat Cert-MCi aus und sendet es an RA2 zurück 12. RA2 leitet das Zertifikat an den MDM-Proxy weiter 13. Dieser sendet das Zertifikat an das Mobilgerät und dieses ist nun im Besitz der digitalen Identität ID-MC_i 14.In drawings page 3 an embodiment for the registration of a mobile device according to b) and c) is shown. The mobile device logs on via a network on the MDM proxy 1 , This forwards the message to the MDM server 2 , The MDM server returns an MDM profile 3 , In profile b) this profile can contain the ID-MC _i . In that case, the MDM proxy generates a copy ID-PC _i and forwards the profile with ID-MC _i to the mobile device and the registration process is completed 4 , In variant c), the MDM profile contains the address of a registration authority RA1 or the address of a proxy, for example the MDM server, to which the mobile device should send its certificate request. This address is replaced in the MDM profile by the address of the MDM proxy, and the profile is forwarded to the mobile device 4 , The mobile device generates a key pair and sends the public key in a certificate request, for example by SCEP, to the MDM proxy 5 , The MDM proxy generates a key pair and forwards the public key in a certificate request to the registration authority RA1 6 , The registration authority RA1 examines the certificate request and forwards it to the CA1 7 , The CA1 is trusted by the MDM proxy and the MDM server. This will issue a certificate Cert-PCi and send it back to RA1 8th , RA1 forwards the certificate to the MDM proxy 9 , This is now in the possession of the digital identity ID-PC _i . The MDM proxy then forwards the certificate request received from the mobile device to the registration authority RA2 10 , Registration authority RA2 examines the certificate request and forwards it to CA2 11 , The CA2 is trusted by the mobile device. This will issue a Cert-MCi certificate and return it to RA2 12 , RA2 forwards the certificate to the MDM proxy 13 , This sends the certificate to the mobile device and this is now in possession of the digital identity ID-MC _i 14 ,

Das Ausführungsbeispiel in Zeichnungen Seite 3 verwendet unterschiedliche RA- und CA-Dienste zur Ausstellung der MDM-Proxy- und der Gerätezertifikate. Es sind auch Ausführungen möglich, bei denen RA1 und RA2 sowie CA1 und CA2 identisch sind, das heißt dass nur eine gemeinsame Zertifizierungsstelle verwendet wird.The Embodiment in Drawings Page 3 uses different RA and CA services to issue the MDM proxy and device certificates. Embodiments are also possible in which RA1 and RA2 as well as CA1 and CA2 are identical, ie that only one common certification authority is used.

Der MDM-Proxy hat im MDM-Protokoll die Aufgabe, digitale Identitäten für Benutzer aus einem zentralen Schlüsselspeicher zu holen und als Profil-Nutzdaten dem jeweiligen Mobilgerät des Benutzers zu übermitteln. Die zum Zugriff benötigten Passwörter können dabei ebenfalls mit den Profil-Nutzdaten an das Gerät oder auf einem separaten Weg an den Benutzer übermittelt werden.In the MDM protocol, the MDM proxy has the task of retrieving digital identities for users from a central keystore and transmitting them as profile user data to the respective mobile device of the user. The passwords required for access can also be transmitted with the profile user data to the device or on a separate path to the user.

In Zeichnungen Seite 4 ist ein Ausführungsbeispiel hierzu abgebildet und wird beispielhaft für das Apple MDM Protocol beschrieben. Das Mobilgerät authentisiert sich, beispielsweise nachdem es über eine Push-Nachricht aufgeweckt wurde, gegenüber dem MDM-Proxy und sendet eine Anfragenachricht nach dem auszuführenden Kommando 1. Der MDM Proxy authentisiert sich gegenüber dem MDM Server, leitet die Anfragenachricht weiter 2 und erhält das auszuführende Kommando 3. Der MDM Proxy prüft, ob es sich um ein InstallProfile Kommando handelt. In dem Fall wird geprüft, ob in dem Profil Nutzdaten enthalten sind, welche digitale Identitäten eines Benutzers enthalten können, beispielsweise eine Mail- oder Exchange Payload. Falls dies nicht der Fall ist, sendet der MDM-Proxy das Kommando unverändert an das Mobilgerät weiter. Um die benötigten digitalen Identitäten des Benutzers in den Nutzdaten zu ergänzen, sendet der MDM-Proxy eine Anfragenachricht, welche die Identität des Benutzers, beispielsweise eine E-Mailadresse, enthält an einen Dienst zur Schlüsselwiederherstellung (Key-Recovery Server) 4. Dieser befindet sich üblicherweise in einem anderen, internen Netzwerk welches über eine Firewall abgesichert ist. Der Key-Recovery Server fragt im zentralen Schlüsselarchiv an, ob für die Benutzer-Identität eine oder mehrere digitale Identitäten archiviert sind 5. Das Schlüsselarchiv sendet die verfügbaren digitalen Identitäten ID-U_i des Benutzers an den Key-Recovery Server, verschlüsselt mit dessen öffentlichem Schlüssel, zurück 6. Der Key-Recovery Server entschlüsselt die digitalen Identitäten mit seinem privaten Schlüssel und erzeugt jeweils eine mit Passwort geschützte digitale ID im PKCS#12 Format und sendet diese mit dem Passwort über eine, beispielsweise mittels TLS, verschlüsselte Verbindung an den MDM-Proxy weiter 7. Der MDM-Proxy fügt die für die Nutzdaten, beispielsweise Exchange Payload, benötigten digitalen Identitäten inklusive Passwort als Certificate Payload vom Typ com.apple.security.pkcs12 in die PLIST-Struktur des Profils ein. Ferner wird eine Referenz auf die jeweilige Certificate Payload, beispielsweise SMIMEEncryption-CertificateUUID, in die vorhandenen Nutzdaten (z. B. Exchange Payload) eingefügt. Die neu entstandene PLIST-Struktur des Profils wird dann dem Mobilgerät zugesendet 8. Das Mobilgerät speichert die erhaltenen Konfigurationsdaten, wobei die darin enthaltenen digitalen Identitäten ID-U_i in die System-Key-Chain abgespeichert werden.In drawings on page 4, an embodiment is illustrated and described by way of example for the Apple MDM Protocol. The mobile device, for example, after being woken up via a push message, authenticates itself to the MDM proxy and sends a request message for the command to be executed 1 , The MDM proxy authenticates itself to the MDM server, forwards the request message 2 and receives the command to execute 3 , The MDM Proxy checks if it is an InstallProfile command. In that case, it is checked whether the profile contains user data which may contain a user's digital identities, for example a mail or exchange payload. If this is not the case, the MDM proxy sends the command unchanged to the mobile device. To supplement the user's required digital identities in the payload, the MDM proxy sends a request message containing the user's identity, such as an e-mail address, to a key recovery server service. 4 , This is usually located in another, internal network which is protected by a firewall. The key recovery server in the centralized key archive queries whether one or more digital identities are archived for the user's identity 5 , The key archive sends back the available digital identities ID-U _{i of} the user to the key recovery server, encrypted with its public key 6 , The key recovery server decrypts the digital identities with its private key and generates a password-protected digital ID in PKCS # 12 format and forwards it with the password via an encrypted connection, for example using TLS, to the MDM proxy 7 , The MDM proxy inserts the digital identities including the password required for the user data, such as Exchange Payload, as a certificate payload of the type com.apple.security.pkcs12 into the PLIST structure of the profile. Furthermore, a reference to the respective certificate payload, for example SMIMEEncryption-CertificateUUID, is inserted into the existing payload (eg exchange payload). The newly created PLIST structure of the profile is then sent to the mobile device 8th , The mobile device stores the configuration data obtained, wherein the digital identities contained in ID-U _i are stored in the system key chain.

In Zeichnungen Seite 6 sind die Aufgaben des MDM-Proxys in einem Ablaufdiagramm für das Apple MDM Protocol skizziert.In Figure 6, the tasks of the MDM proxy are outlined in a flow chart for the Apple MDM Protocol.

In einem weiteren Ausführungsbeispiel wird die beschrieben Funktionalität des MDM-Proxys direkt auf dem MDM-Server erbracht. Dies kann dadurch realisiert werden, dass der MDM-Proxy als lokaler Proxy-Dienst installiert wird und die Kommunikation mit dem MDM-System wie oben beschrieben lokal auf dem MDM-Server anstelle über ein Netzwerk abgewickelt wird.In another embodiment, the described functionality of the MDM proxy is provided directly on the MDM server. This can be accomplished by installing the MDM proxy as a local proxy service and, as described above, communicating with the MDM system locally on the MDM server instead of over a network.

In einem weiteren in Zeichnungen Seite 5 abgebildeten Ausführungsbeispiel wird eine programmtechnische Integration vorgenommen, so dass die MDM-Anwendung über eine Schnittstelle die entsprechenden Bibliotheksfunktionen des zuvor beschriebenen MDM-Proxys aufruft. Diese werden hier als Key-Recovery Client bezeichnet. Die Funktionen des Key Recovery Clients können lokal über eine Programmierschnittstelle (API) oder durch entfernte Funktionsaufrufe (RPC, SOAP) ausgeführt werden. Damit kann der Key Recovery Client auch auf einem anderen Rechner ausgeführt werden. Der Ablauf ist wie folgt: Das Mobilgerät sendet eine Anfragenachricht an die MDM-Anwendung auf dem MDM-Server nach dem auszuführenden Kommando 1. Falls es sich um ein InstallProfile Kommando handelt und hierfür digitale Identitäten eines Benutzers benötigt werden, ruft die MDM-Anwendung den Key-Recovery Client auf und übergibt das Profil 2. Der Key-Recovery Client sendet die enthaltene Benutzeridentität an den Key-Recovery Server 3. Der Key-Recovery Server fragt im zentralen Schlüsselarchiv an, ob für die Benutzer-Identität eine oder mehrere digitale Identitäten archiviert sind 4. Das Schlüsselarchiv sendet die verfügbaren digitalen Identitäten ID-U_i des Benutzers an den Key-Recovery Server, verschlüsselt mit dessen öffentlichem Schlüssel, zurück 5. Der Key-Recovery Server entschlüsselt diese und erzeugt jeweils eine mit Passwort geschützte digitale ID im PKCS#12 Format und sendet diese mit dem Passwort an den Key-Recovery Client zurück 6. Der Key-Recovery Client übergibt das Resultat an die aufrufende MDM Anwendung 7. Diese fügt die digitalen Identitäten inklusive Passwort als Certificate Payload vom Typ com.apple.security.pkcs12 in die PLIST-Struktur des Profils sowie eine Referenz auf die jeweilige Certificate Payload, beispielsweise SMIMEEncryption-CertificateUUID, in die vorhandenen Nutzdaten ein und sendet diese an das Mobilgerät 8. In another exemplary embodiment depicted in drawings on page 5, a program-technical integration is performed so that the MDM application calls the corresponding library functions of the previously described MDM proxy via an interface. These are referred to here as Key-Recovery Client. The functions of the Key Recovery Client can be executed locally via a programming interface (API) or through remote function calls (RPC, SOAP). This allows the Key Recovery Client to run on another computer. The procedure is as follows: The mobile device sends a request message to the MDM application on the MDM server for the command to be executed 1 , If it is an InstallProfile command and requires a user's digital identities, the MDM application will call the Key-Recovery Client and pass the profile 2 , The Key Recovery Client sends the included user identity to the Key Recovery Server 3 , The key recovery server in the centralized key archive queries whether one or more digital identities are archived for the user's identity 4 , The key archive sends back the available digital identities ID-U _{i of} the user to the key recovery server, encrypted with its public key 5 , The key recovery server decrypts these and generates a password-protected digital ID in PKCS # 12 format and sends it back to the key-recovery client with the password 6 , The Key-Recovery Client transfers the result to the calling MDM application 7 , This inserts the digital identities including the password as a certificate payload of the type com.apple.security.pkcs12 into the PLIST structure of the profile as well as a reference to the respective certificate payload, for example SMIMEEncryption-CertificateUUID, into the existing user data and sends it to the mobile device 8th ,

Mit dem zuvor beschriebenen Verfahren werden die digitalen Identitäten samt zugehörigem Passwort verschlüsselt über die Netzwerke übertragen. Ein Ausspähen des enthaltenen privaten Schlüssels wird somit während der Übertragung verhindert. Die digitalen Identitäten werden auch nicht auf der Festplatte des MDM-Proxys abgespeichert. Ein Ausspähen der Daten ist somit nur über den Hauptspeicher des MDM-Proxys in dem Moment der Verarbeitung, beispielsweise über einen Memory-Dump, möglich. Dazu sind entsprechende Werkzeuge, hohe Rechte auf dem System, vertieftes Fachwissen und ein hoher Analyseaufwand notwendig. Das Restrisiko ist damit äußerst gering im Vergleich zu dem zur Problembeschreibung vorhandenen Stand der Technik.With the method described above, the digital identities together with the associated password are transmitted in encrypted form over the networks. Spying out the contained private key is thus prevented during the transmission. The digital identities are also not stored on the hard disk of the MDM proxy. Spying out the data is thus only possible via the main memory of the MDM proxy at the moment of processing, for example via a memory dump. This requires appropriate tools, high rights on the system, in-depth specialist knowledge and a high degree of analysis effort. The residual risk is thus extremely low in comparison to the existing state of the art for problem description.

Um das vorhandene geringe Restrisiko zu minimieren, kann das Schutzniveau für die digitalen Identitäten ID-U_i durch Verschlüsselung des Profils weiter erhöht werden. Das Ausführungsbeispiel in Zeichnungen Seite 4 wird dazu erweitert. Dabei werden das interne Netzwerk sowie die Komponenten Key-Recovery Server und Schlüsselarchiv als sicher angenommen. Der MDM Server kann die PLIST des Profils mittels CMS mit dem öffentlichen Schlüssel aus Cert-PCi des MDM-Proxys verschlüsseln und optional mit dem eigenen privaten Schlüssel signieren, bevor er die Profil-Nachricht sendet 3. Der MDM-Proxy entschlüsselt die Profil-Nachricht mit ID-PCi und prüft die optional enthaltene Signatur. Der MDM-Proxy sendet nun das vollständige Profil über eine verschlüsselte Verbindung an den Key-Recovery Server 4. Dieser holt sich vom Schlüsselarchiv wie beschrieben die digitalen Identitäten des Benutzers und erweitert hiermit wie zuvor beschrieben die Nutzdaten des Profils. Der Key-Recovery Server beschafft sich das Zertifikat Cert-MCi des Mobilgerätes, beispielsweise aus den Protokolldaten oder über eine Verzeichnisabfrage, verschlüsselt das Profil mit dem enthaltenen öffentlichen Schlüssel und sendet es an den MDM-Proxy 7. Der MDM Proxy leitet das verschlüsselte Profil an das Mobilgerät weiter 8. Hier kann das Profil mit ID-MC_i entschlüsselt und ID-U_i in die System-Key-Chain abgespeichert werden. Damit bleibt ID-U_i während der Übertragung und Verarbeitung zwischen dem Key-Recovery Server und dem Mobilgerät immer verschlüsselt, sodass nur das Mobilgerät das Profil entschlüsseln kann und ein Ausspähen über den Hauptspeicher des MDM-Proxys kann praktisch ausgeschlossen werden.In order to minimize the existing low residual risk, the protection level for the digital identities ID-U _i can be further increased by encrypting the profile. The embodiment in drawings page 4 is extended thereto. The internal network as well as the key recovery server and key archive components are assumed to be secure. The MDM server can encrypt the PLIST of the profile using CMS with the public key from Cert-PCi of the MDM proxy and optionally sign it with its own private key before sending the profile message 3 , The MDM proxy decrypts the profile message with ID-PCi and checks the optional signature. The MDM proxy now sends the full profile over an encrypted connection to the key recovery server 4 , As described above, this fetches the user's digital identities from the key archive and expands the user data of the profile as described above. The key recovery server acquires the certificate Cert-MCi of the mobile device, for example from the protocol data or via a directory query, encrypts the profile with the contained public key and sends it to the MDM proxy 7 , The MDM Proxy forwards the encrypted profile to the mobile device 8th , Here the profile can be decrypted with ID-MC _i and ID-U _i stored in the system key-chain. This keeps ID-U _i encrypted during transfer and processing between the Key-Recovery server and the mobile device, so that only the mobile device can decrypt the profile and spying on MDM's main memory can be virtually eliminated.

Auch das Ausführungsbeispiel in Zeichnungen Seite 5 kann hierzu für eine höhere Sicherheit erweitert werden. Dabei übergibt die MDM-Anwendung dem Key-Recover Client die PLIST Struktur des Profils 2. Dieser sendet diese weiter an den Key-Recovery Server 3. Dieser holt sich vom Schlüsselarchiv wie beschrieben die digitalen Identitäten des Benutzers und erweitert hiermit wie zuvor beschrieben die Nutzdaten des Profils. Der Key-Recovery Server beschafft sich das Zertifikat Cert-MCi des Mobilgerätes, beispielsweise aus den Protokolldaten oder über eine Verzeichnisabfrage, verschlüsselt das Profil mit dem enthaltenen öffentlichen Schlüssel und sendet es an den Key-Recovery Client zurück 6. Der Key-Recovery Client liefert das Resultat zurück an die MDM-Anwendung 7. Diese sendet das verschlüsselte Profil an das Mobilgerät 8.Also, the embodiment in drawings page 5 can be expanded for this purpose for greater security. The MDM application passes the PLIST structure of the profile to the Key-Recover Client 2 , This sends it on to the key recovery server 3 , As described above, this fetches the user's digital identities from the key archive and expands the user data of the profile as described above. The key recovery server acquires the certificate Cert-MCi of the mobile device, for example from the protocol data or via a directory query, encrypts the profile with the contained public key and sends it back to the key-recovery client 6 , The Key-Recovery Client returns the result to the MDM application 7 , This sends the encrypted profile to the mobile device 8th ,

ZITATE ENTHALTEN IN DER BESCHREIBUNG QUOTES INCLUDE IN THE DESCRIPTION

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.This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Zitierte PatentliteraturCited patent literature

DE 202013016466 A1 [0005]
US 9027112 B2 [0020]
EP 1585286 A2 [0023]

Zitierte Nicht-PatentliteraturCited non-patent literature

S / MIME Standard according to RFC 5751, Secure / Multipurpose Internet Mail Extensions (S / MIME) Version 3.2 - Message Specification IETF 2010 [0003]
X.509 "ITU-T X.509, Directory Information Technology - Open Systems Interconnection - The Directory: Public-key and Attribute Certificate Frameworks, 2005" [0003]
Windows Server 2008 PKI and Certificate Security, Microsoft Press 2008 [0008]
"Keychain Services Programming Guide" at developer.apple.com [0008]
"Android Keystore System" at developer.android.com [0008]
Simple Certificate Enrollment Protocol, Internet Draft, IETF 2011 [0012]
Oasis WS-Trust with the "[MS-WSTEP]" released by Microsoft at msdn.microsoft.com: WS-Trust X.509v3 Token Enrollment Extensions " [0012]
"OMA Device Management V1.2" at technical.openmobilealliance.org [0014]
msdn.microsoft released "[MS-MDM]: Mobile Device Management Protocol" [0015]
Android Device Administration API specified and available at developer.android.com [0017]
"Mobile Device Management Protocol Reference", available to registered users at developer.apple.com [0018]
"Apple Configuration Profile Reference" at developer.apple.com [0018]
CMS format according to RFC 5652 Cryptographic Message Syntax (CMS), IETF 2009 [0018]
PKCS # 12 Format, RFC 7292: PKCS # 12: Personal Information Exchange Syntax Standard v1.1 IETF 2014 [0022]

Claims

A method for securely distributing a user's private key from a central keystore to the user's mobile device managed by a mobile device management (MDM) system, comprising the steps of: a) reading a configuration profile for a mobile device containing data for identification of a user; b) reading private keys associated with the identification data from a central keystore; c) storing one or more private keys in the configuration profile;

The method of claim 1, wherein the configuration profile has been received before step a) in a message from the MDM system and after step c) is sent to the mobile device.

Method according to claim 2, in which the authentication of the mobile device takes place on the basis of a digital certificate Z1 and the authentication with respect to the MDM system by means of Z2, which are generated beforehand in the following steps: I. receiving a configuration profile for a mobile device from an MDM system containing address data for requesting certificates; II. Adjusting the configuration profile so that certificate requests from the mobile device can be received by the method and sending the configuration profile to the mobile device; III. Receiving a certificate request ZA1 from a mobile device and generating a key pair and a further certificate request ZA2 therefor; IV. Sending ZA1 to a registry RA1 and from ZA2 to a registry RA2; V. receiving a certificate Z1 from RA1 and Z2 from RA2; VI. Sending Z1 to the mobile device;

A method according to claim 2, wherein the private key is contained in a data memory which is encrypted with a password.

The method of claim 4, wherein the password is stored in the configuration profile.

A method according to claim 5, wherein the configuration profile in step c) of claim 1 is encrypted with a public key of the mobile device.

Method according to Claim 5 or 6, in which the Apple MDM Protocol is used for message exchange.

Method according to Claim 5 or 6, in which the OMA SyncML Common Specification is used for message exchange.

Method according to Claim 5 or 6, in which the Microsoft MDM Protocol is used for message exchange.

System for distributing private keys of users in a PKCS # 12 mobile storage data store to mobile devices characterized by acting as a proxy between a mobile device and an MDM system and forwarding all messages unmodified except messages conveying configuration profiles containing private user keys can be read by the system from a central keystore and entered in the PKCS # 12 format together with the associated password for decryption and other user data in the respective configuration profiles that are sent to the mobile device.