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

Abstract

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

Technical area

This invention relates to the field of key distribution, and more particularly to methods of distributing private keys of asymmetric cryptosystems to mobile devices.

State of the art

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.

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.

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.

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.

On the mobile device, a digital identity must also be available to the user for encryption and decryption.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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 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 ,

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 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.

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.

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.

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.

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.

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.

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.

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.

description of the problem

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.

When using software keys, they must be securely distributed to the user's devices without requiring the user to perform elaborate manual steps.

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 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.

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.

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.

Description of the invention

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.

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.

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.

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.

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.

• 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 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 ,

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.

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 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 Figure 6, the tasks of the MDM proxy are outlined in a flow chart for the Apple MDM Protocol.

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 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 ,

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.

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.

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 ,

QUOTES INCLUDE IN THE DESCRIPTION

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.

Cited patent literature

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

Cited 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 (10)

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.

Images