SECUREPIM S RANGE OF FUNCTIONS 1. SecurePIM features and architecture

(1)

S E C U R E P I M ’ S R A N G E O F F U N C T I O N S — 1

SecurePIM features

and architecture

(2)

SecurePIM’s range of functions

1.

V E R S I O N 2 . 2 I V E R S I O N : 2 0 / 0 2 / 1 3

SecurePIM is an app suite for Apple’s iPad, iPad mini, iPhone (3GS and later) and iPod touch. It requires iOS version 6 or higher. The suite includes four applications: Mail, Calendar, Contacts and Secure Browser. We shall be adding the Documents module from the 3rd quarter of 2013. SecurePIM creates a so-called secure container on the device. All data inside this container is strongly encrypted. The user’s private key, which has a key length of at least 2048 bits, is used for the encryption, and the connection to the Microsoft Exchange Server is also encrypted. SecurePIM is currently available in German and English. SecurePIM meets the requirements of the German Federal Data Protection Act by ensuring that personal and business data are stored and managed separately from one another.

SecurePIM’s key features:

Strict separation of personal and business data through the use of a secure container The app provides all personal information manager modules including Secure Mail (S/MIME),

Calendar, Contacts and Secure Browser

Support for Microsoft Exchange Server 2007 to 2010 via the ActiveSync protocol versions 12.1, 14.0, 14.1 and 14.2

Complete control over enterprise data in the secure container through the supplied Mobile Application Management Portal

Genuine solution for a bring-your-own-device scenario

Companies that already use smart cards complying with the well-established ISO 7816 standard can also use these cards for performing authentication and decryption on iPads and iPhones

Can be integrated seamlessly in an existing public key infrastructure Outstanding usability compliant with the Apple standards

1. SecurePIM’s range of functions 3

1.1 Dashboard 4 1.2 Secure Mailer 6 1.3 Secure Contacts 8 1.4 Secure Calendar 9 1.5 Secure Browser 10 1.6 Secure Docs 1 1

2. Overview of the system architecture 12

3. Protection of enterprise data 13

3.1 Encryption with a private key 13

3.2 Separation of business and personal data 13

3.3 User authentication 14

3.4 Cryptographic methods 14

3.5 Interfaces and secure communications 15

4. Microsoft Exchange integration 16

4.1 Exchange Server integration via ActiveSync 16

4.2 S/MIME implementation 16

4.3 Email encryption 17

4.4 Email decryption 17

5. Support for smart-card readers 18

5.1 Maximum smart-card security – the card is always inserted 18 5.2 Smart-card security – the card is inserted to run the app 20 5.3 High security – encryption via a personal certifi cate

in the container 20

5.4 Setting the security level 2 1

6. Integration of public key infrastructure 22

6.1 Certifi cate management 22

6.2 Certifi cate checks 23

6.3 Public key management 24

6.4 Public keys of recipients 24

7. Requirements of the IT infrastructure 25

7.1 Supported mobile devices 25

7.2 Supported operating systems 25

7.3 IT infrastructure 25

8. Roll-out and confi guration of the application 26

8.1 Mobile Application Management Portal 28

8.2 Device registration 28

8.3 Certifi cate import (optional) 30

8.4 Data update 31

(3)

1.1 Dashboard

The Dashboard provides users with an overview of their emails, calendar events and contacts. Dashboard functionality:

Displays the latest emails and calendar events on a single page Shows frequently used contacts

Currently pending calendar events are displayed

People can be phoned with the tap of a fi nger (only on the iPhone), or an email can be written directly without leaving the Dashboard

(4)

Further features:

Fully featured email application including all the functions for browsing, receiving, sending and organizing emails on the iPhone and iPad

Emails are downloaded in the background and stored in encrypted form for ofﬂ ine access Search for emails by subject, sender and recipient

Search for emails on the server

Integration with the contacts module for effi cient addressee selection

Encrypted storage of all emails – even emails that were received in unencrypted form – to protect them in the event of loss and theft

Integration in Exchange 2007 and 2010 using Microsoft’s standard ActiveSync protocol Mapping of the entire Exchange folder structure as well as email management, including

actions such as moving and deletion

Secure email communications through S/MIME encryption, a standard supported by all commonly used email applications

Supported fi le formats for attachments: doc(x), xls(x), ppt(x), all popular image formats, PDF, txt, and many more

You can write emails ofﬂ ine; they are then sent as soon as you go online again

Public certifi cates you have received by email can easily be imported into the application

1.2 Secure Mailer

File attachments

Email fi le attachments are opened within the email app and are therefore never held on the device in an unencrypted state

Contacts integration

Integration with the contacts module for effi cient addressee selection

SecurePIM provides a secure email app approved and certifi ed by corporate security for use on the iPhone and iPad in the enterprise. Alongside all the functionality provided by a powerful email application, it offers outstanding usability, a very high level of security and is perfectly tailored to custom security requirements.

(5)

1.4 Secure Calendar

Your business contacts are protected against unauthorized access. SecurePIM accesses contacts on the internal enterprise Exchange Server and stores them in encrypted form on the device. You can therefore access contacts at all times even when there is no connection to the Internet.

Simple and secure contact management Create and edit contacts online and ofﬂ ine

Online access to business contacts on the Exchange Server Support for multiple groups of contacts

Effi ciently browse and search contacts Integration with email and telephone

Option to export phone numbers and names of contacts to the device’s standard contacts directory (if approved by corporate IT in the Mobile Application Management Portal)

Secure Calendar lets you manage your appointments and other events easily and effi ciently with the highest level of security. It uses built-in interfaces to communicate with the other modules. Simple and secure management of appointments and other calendar events

Effi ciently create, edit and delete calendar events Support for repeat events and serial events

Clear overview thanks to week view and month view on the iPad and list view and month view on the iPhone

Simply reschedule calendar events by drag-and-drop

Comprehensive range of options for browsing and searching calendar events Synchronization with Exchange Server

Send calendar event invitations

Calendar event reminders appear even if you have SecurePIM closed

(6)

1.6 Secure Docs

Secure Browser provides a secure way of accessing sensitive Web-based applications, Web pages and portals. It lets companies determine which pages their employees can use from within the secure environment of SecurePIM and which ones they cannot. This means, for instance, they can be given access from within the secure container to an internal CRM solution containing strictly confi dential information. Such information is therefore kept completely isolated from the rest of the device. Independently of this, users can continue to surf the Internet as usual using the standard browser.

Controlled access to internal Web pages, portals and Web-based applications Management of permitted and prohibited Web pages

Secure authentication for Web-based applications optionally by way of certifi cates Bookmark management

No restrictions imposed on the device’s standard browser

With Secure Docs you can access and use confi dential documents conveniently and securely even outside your internal network. SecurePIM accesses the company’s internal document management system via a secure channel and stores the fi les in encrypted form on the iPhone or iPad. Only the user can then decrypt and open the stored documents using their private key.

Online access to document management systems from anywhere; download documents and directory structures

Securely view numerous document types from within the app (e.g. PDF, Word, Excel, PowerPoint, images, emails, and many more)

Effi ciently browse, manage and view local documents stored in encrypted form Insert bookmarks, remarks, highlights and sketches when reviewing PDF documents Optimized for large PDF documents: document navigation via the table of contents, creation

of personal bookmarks, full-text search, and much more

Upload documents and directories to the document management system

(7)

P R O T E C T I O N O F E N T E R P R I S E D A T A — 3

The concept behind the secure container approach involves keeping business and personal data completely separate from one another. All business data is stored in encrypted form. A directory structure exists on the device in which all fi les are stored and encrypted using the PKCS#7 or PKCS#12 standard. In addition to this, the system includes a database whose contents are en-crypted.

Documents and attachments are only decrypted as needed within the main memory. They are only opened inside the app and are not passed on to other apps. Furthermore, no temporary fi les are generated. No other apps can access the contents of the secure container; the keychain in iOS is only used for publicly accessible content (public keys).

In addition to S/MIME encryption, all fi les are also encrypted using a device-specifi c symmetric AES key (NSFileProtection). Excluded from the encryption are freely accessible public keys and CA certifi cates as well as cached certifi cate revocation lists (CRLs).

The app can be confi gured and adapted only from a central point using the Mobile Application Management Portal (MAM Portal). The user is unable to make any unauthorized changes to the relevant settings. This means the enterprise has full control over the secure container and can manage it centrally. It is impossible, however, for the enterprise’s internal IT to access the user’s personal data through the Mobile Application Management facility.

S/MIME Mailer Document access Web browser

Login using employee smart card Calendar Contacts

User

Certiﬁ cate on smart card

IT admin

Overview of the system architecture

2.

Protection of enterprise data

3.

3.1 Encryption with a private key

A core property of encryption is the user’s private key, which forms the basis for the encryption of all data.

All data, documents and keys that are of relevance to security are only stored in the mobile device’s fi le system in encrypted form. Encryption is performed using the PKCS#7 and PKCS#12 standards, and keys with a minimum length of 2048 bits are always used.

Unencrypted data only exists in the main memory and is deleted when switching tasks, when switching to sleep mode and when the system wakes up again. Any PINs or passwords stored in the main memory are overwritten.

All fi les are additionally encrypted using a device-specifi c symmetric AES key (NSFileProtection). The internal database is encrypted with a session key that is stored in encrypted form, which in turn can only be decrypted with the user’s private key.

Excluded from the encryption are only freely accessible public keys and CA certifi cates as well as cached certifi cate revocation lists (CRLs).

3.2 Separation of business and

personal data

SecurePIM strictly separates business use and personal use. No changes need to be made to the device for this, which means that the solution can also be used without a mobile device management solution – though, in our view, an MDM solution is important and sensible depending on the deployment scenario.

All enterprise-related information and settings are held within the secure container and are therefore completely isolated from the rest of the device.

Emails, documents and attachments are only decrypted within the main memory as needed. They are only opened inside the app and are not passed on to other apps.

The container is managed by corporate IT, and the user is unable to make any unauthorized changes to the relevant settings.

Certain contact information can optionally be exported to the iOS device’s contacts directory in order, for instance, to enable caller identifi cation (but only if authorized by the enterprise’s internal IT in the Mobile Application Management Portal).

(8)

P R O T E C T I O N O F E N T E R P R I S E D A T A — 3

3.3 User authentication

Authentication can be performed using a password or smart card, though in both cases it is the user’s private RSA key that forms the basis for accessing information held in the secure container. The entered password is never cached. The enterprise’s internal IT can specify a password policy for the password.

If the user wishes to return to the app after having switched to another app, they will be required to enter the password again. Alternatively, the IT department can set a timeout after which time the user is required to log in again in order to open the app.

In addition to this, customer-specific authentication techniques such as mobile PIN or online authenti-cation via a central single sign-on service can also be integrated.

3.4 Cryptographic methods

SecurePIM works with all algorithms defined in the S/MIME standard. The algorithms are defined by the transmitting system. All other cryptographic methods are implemented by way of hybrid encryp-tion. The data itself is encrypted with a randomly generated file-specific key using AES-256. This key is then encrypted with the respective user’s public key. Restoration of the file-specific key and decryption of the content (which is dependent on the key having been restored) is therefore only possible using the user-specific secret key component of the user certificate.

One of the following methods is used to secure the secret key component:

A PKCS#12 container file. In this case, the application checks and changes (as necessary) the algorithms and password in accordance with the defined security policies (password policy; minimum algorithm quality is “3DES”).

Or

A smart card. In this case, no secret key components exist on the iPad/iPhone. The key is transferred to the smart card for decryption. The user must enter a password in order to gain access. For further information, please also refer to Chapter 5.

3.5 Interfaces and secure communications

Generally all data links are encrypted end-to-end using Transport Layer Security.

Transport Layer Security (TLS) more commonly known by its former name Secure Sockets Layer (SSL) is a hybrid cryptographic protocol for secure data communications over the Internet. As of version 3.0, the SSL protocol has been further developed and standardized under the new name TLS. TLS version 1.0 corresponds to SSL version 3.1.

SecurePIM uses this protocol to communicate over a maximum of four channels:

1. With the Exchange Server via the ActiveSync protocol (encryption using Transport Layer Security of the ActiveSync protocol, TLS SSLv3)

2. With the Mobile Application Management Portal via a Web service interface (encryption using Transport Layer Security, TLS SSLv3)

3. Optionally: VPN access for accessing the document management system and Intranet applications (encryption using Transport Layer Security, TLS SSLv3, secured by a machine certificate)

4. Optionally: Access to public key infrastructure for public keys and certificate revocation lists (depending on the configuration of the PKI)

(9)

M I C R O S O F T E X C H A N G E I N T E G R A T I O N — 4

Microsoft Exchange integration

4.

Emails, contacts and calendar events are synchronized with the Exchange Server using ActiveSync.

4.1 Exchange Server integration

via ActiveSync

Integration with the Exchange Server is achieved using protocol version 12.1 or 14 of the Microsoft ActiveSync standard. This means that Exchange Server 2007 and Exchange Server 2010 can be implemented.

The Transport Layer Security of the ActiveSync protocol is used, that is to say, all communications are encrypted subject to the policies of corporate IT. We advise using the minimum standard TLS SSLv3. Exchange ActiveSync (EAS) communicates using the WBXML standard. This is used to synchronize emails, contacts, calendar events, tasks and notes from a messaging server with a mobile device. We do not use third-party libraries since they may contain potential security vulnerabilities.

It is also possible to optionally integrate the Secure ActiveSync Gateway from our partner PointSharp. This additionally provides back-end protection of the Exchange Server with added authentication methods. Furthermore, it can also be used to permit access to the Exchange Server only via SecurePIM; access through other apps is then no longer possible.

A range of other products for the back-end protection of the Exchange Server can also be integrated alongside this.

4.2 S/MIME implementation

Emails can optionally be sent in encrypted form. The Secure/Multipurpose Internet Mail Extensions standard (S/MIME) is used to accomplish this. It enables a MIME-encapsulated email to be encrypted using a hybrid cryptographic system.

The implementation is based on the S/MIME standard 3.1 that is defined in RFC3851. With regard to the implemented sub-sections of the standard, Version 3.1 is backwards compatible with version 3.0.

The S/MIME standard is not fully implemented in this product. The following sections of the RFCs are necessary and were implemented:

RFC3851 2.4.3 EnvelopedData Content Type RFC3851 2.5.2 SMIMECapabilities Attribute RFC3851 2.5.3 Encryption Key Preference Attribute RFC3851 2.7 ContentEncryptionAlgorithmIdentifier

The weak RC2/40 encryption is not used for sending; AES-256 or DES-EDE3-CBC (for reasons of compatibility) is used as the symmetric encryption algorithm

RFC3851 3.1.2 Transfer Encoding “base64” is used for transfer encoding

RFC3851 3.2 The application/PKCS#7-mime Type Only the “.p7m” format was implemented

RFC3851 4.1 Key Pair Generation RFC3851 5. Security Considerations

see Page 16, RFC3851 2.7 ContentEncryptionAlgorithmIdentifier RFC5652 6. Enveloped-data Content Type

Supported key management algorithm is “key transport” Supported key encryption algorithm is “rsaEncryption” RFC5652 6.1 EnvelopedData Type

AES or DES-EDE3-CBC is used as the symmetric encryption algorithm

4.3 Email encryption

The parameters required for the encryption algorithms (DES-EDE3-CBC) are each generated with a high-entropy random number generator. The content is expanded up to 64 bits using DES and is then encrypted with DES-EDE3-CBC.

A recipient info structure is created for each recipient, and the values from the respective public keys of the recipients are entered into it. The DES encryption keys and initialization vectors are expanded, then encrypted with the respective public keys and added to “RecipientInfo”.

4.4 Email decryption

The application receives a p7m container file (see above, RFC3851, Chapter 3.2). The file is extracted using “base64”. If another MIME type or another content transfer encoding was used, this will result in an error. A file name that may be available will not be used or shown.

The extracted binary data consists of a PKCS#7 container. The content is defined in RFC5652 (see above, Chapter 6.1).

The application looks in “RecipientInfo” to find out if one of the recipients corresponds to the stored certificates and the respective private key. The match criteria are defined under RFC5652 6. Issuer (signing CA, see above) and the serial number for the specific certificate.

If no match is found, an error is displayed. The encrypted key value is decrypted with the respective private key.

(10)

0 0 1 1 0 0 0 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 0 0 0 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 1 1 1 0 1 0 1 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 1 1 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 1 1 1 0 1 0 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 0 1 1 0 0 1 1 1 0 1 0 1 1 1 0 0 0 0 1 1 1 1 0 1 0 1 0 0 1 1 0 1 1 0 0 1 1 1 0 1 0 1 1 1 0 0 0 0 1 1 1 1 0 1 0 1 0 0 1 1 0 1 1 0 0 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 0 1 0 1 0 0 1 1 0 0 1 1 1 0 1 0 1 S U P P O R T F O R S M A R T - C A R D R E A D E R S — 5

Support for smart-card readers

5.

To meet the most stringent security requirements, all asymmetric cryptographic operations are performed on the enterprise’s smart card or on a smart card supplied by us. In each case, the private key never leaves the card. We support ISO 7816 cards; we have tested ATOS CardOS 4.2 and higher as well as GlobalPlatform (JCOP) cards. Further card types can be implemented on request. Three smart-card readers are currently supported. An enterprise’s own middleware can be integrated on request. With this variant, access to sensitive data without the smart card and associated PIN is not possible according to the current state of the art.

In enterprises, the security requirements for different user groups typically vary. For this reason we have implemented three levels of security for authentication and decryption.

5.1 Maximum smart-card security –

the card is always inserted

The user must insert the smart card into the smart-card reader when the application starts. Only after the user has entered the associated PIN to authorize the smart card for cryptographic operations will it be possible to use the app. Depending on the smart card’s confi guration, the card will be blocked after the PIN is entered incorrectly a predefi ned number of times. If the card is removed, it is no longer possible to use the app.

Decryption of each individual email takes place on the card, which means the card must remain inserted. If the user closes the SecurePIM app or switches to another app, they will have to re-enter the PIN if they want to return to the SecurePIM app.

(11)

S U P P O R T F O R S M A R T - C A R D R E A D E R S — 5

5.2 Smart-card security – the card

is inserted to run the app

In this case, the user must insert the smart card into the smart-card reader only when the application starts. After the user has authenticated the smart card for cryptographic operations by entering the associated PIN, the user’s private key that is stored in the container will be opened. This takes place in the main memory of the device via asymmetric decryption on the smart card. In this case too, depending on the card’s configuration, the card will be blocked if the PIN is repeatedly entered incorrectly.

Now all asymmetric cryptographic operations will be performed using the user’s private key that is located in the main memory. This means that the card can be removed and the user can continue working without it.

If the user closes the app or switches to another app, the key will be removed from the main mem-ory. The next time the user opens the app, they will be required to insert the card again and re-enter the PIN.

5.3 High security – encryption via a

personal certificate in the container

No smart card is necessary for users with low level security clearance. The user’s configured private key is used for all asymmetric cryptographic operations. The key is stored on the device in encrypted form using the PKCS#12 format and is unlocked after the PIN has been entered (see 3.4 Cryptographic methods). To encrypt the PKCS#12 container, a strong algorithm is used that, in combination with the defined password policy, assures a high level of security.

Now all asymmetric cryptographic operations will be performed using the user’s private key that is located in the main memory. If the user closes the app or switches to another app, the key will be removed from the main memory. The next time the user opens the app, they will be required to re-enter the PIN.

The enterprise can specify the password policy for the password. It is likewise possible for the enterprise to specify that the key be deleted automatically after the password has been entered incorrectly a predefined number of times – key deletion is then performed regardless of whether a network connection is available or not.

5.4 Setting the security level

The methods described in the preceding sections can be assigned to different user groups. In addition to these, it is also possible to implement other customer-specific methods. For instance, a corporate single sign-on service could thus be used for authentication performed online. In the default configuration, switching from the “High security” variant to the “Smart-card security” level and back is possible. This means that, for instance, smart-card integration can be activated temporarily for travel abroad.

The private key (if one is present) is deleted from the main memory in the following situations: A timeout has occurred

The application is quit A task is switched

(12)

I N T E G R A T I O N O F P U B L I C K E Y I N F R A S T R U C T U R E — 6

Integration of public key

infrastructure

6.

Companies can employ their existing public key infrastructure (PKI). This lets them use the following functionalities of the existing infrastructure:

Provision of the user’s personal certifi cate, which is the basic requirement for all security-related operations

Access to certifi cate revocation lists for checking the validity of certifi cates and for disabling access to enterprise-related data by way of the central control element: “revoke certifi cate” Provision of the public keys of email recipients and for user-specifi c encryption of documents

before they are transferred to SecurePIM

Optionally, the Mobile Application Management Portal makes the core functionalities of a PKI (e.g. provision of public keys) available to companies that do not have their own PKI

6.1 Certifi cate management

An enterprise’s internal root certifi cates can also be classifi ed as trustworthy using fi ngerprint checks. For the “High security” and “Smart-card security” variants, the user certifi cates can be integrated in the app using the following two methods:

1. The encrypted user certifi cate is copied into the app as a PKCS#12 container (.p12 fi le) via iTunes.

2. The user sends the encrypted user certifi cate from their already set up email account to the central Mobile Application Management Portal. The portal then makes the certifi cate available when the app is installed after a check has been performed to see whether the certifi cate corresponds to the sender’s address.

The application recognizes a newly set user certifi cate and then performs the following actions: Any pre-existing certifi cate is deleted

The user must enter the transport PIN for the PKCS#12 container that was assigned by the PKI

The PKCS#12 container is decrypted in the main memory

The user is prompted to enter a new application password twice, which is checked against the requirements of the corporate password policy

A new PKCS#12 fi le is generated using the information cached in the main memory and is secured with the new application password

The generated container fi le is stored in an area of the application’s documents directory that is not visible to iTunes

The imported PKCS#12 fi le is deleted

6.2 Certifi cate checks

Certifi cates are checked each time they are used. This is the case when a new certifi cate is imported as well as when you use your own certifi cate and when encryption is performed for recipients. The following checks are performed on the certifi cates in accordance with RFC 5280 (Internet X.509 public key infrastructure and certifi cate revocation list profi les):

The current system time must lie within the certifi cate’s period of validity

A valid certifi cate chain must exist, that is to say, at a minimum the root certifi cate must be classifi ed as trustworthy by way of a fi ngerprint or by an offi cial certifi cate authority (CA) All signing CA certifi cates must be retrievable and valid (the certifi cates are cached subject to

their validity)

The certifi cate revocation lists (CRLs) are checked and automatically updated depending on their confi guration

If no CRLs is available although the policy requires that an update be performed, the system displays a corresponding message; in this case it will not be possible to log on

If there is a problem checking a recipient certifi cate, an appropriate warning will be displayed; in this situation, the user is presented with a dialog that allows them to decide whether to accept the certifi cate or not

(13)

7.1 Supported mobile devices

Apple iPhone (3GS and later) iPad 2 and later

iPad mini iPod touch

7.2 Supported operating systems

iOS 6.0 and higher

7.3 IT infrastructure

The following infrastructure should be provided by the customer and must be accessible from the Internet:

Microsoft Exchange Server 2007 or 2010 with ActiveSync version 12.1, 14.0, 14.1 or 14.2 Standard Java application server for installing the Mobile Application Management Portal Optional: Directory broker (LDAP) with the public keys of the recipients

Optional: Certifi cate revocation lists of the CAs Optional: Microsoft SharePoint server

LDAP MAM

Internet

I T I N F R A S T R U C T U R E — 7

6.3 Public key management

The public key infrastructure (PKI) provides the means to establish trust by linking public keys and identities. This ensures that the application only communicates with safe email recipients. Using public key cryptography ensures that only the encrypted data can be decrypted with the respective private key. As far as the encrypted message is concerned, the message content is encrypted using a symmetric number, and the key for the symmetric number is encrypted with the recipient’s public key. If the message has several recipients, the same symmetric key is used, but the public key of the respective recipient is used to encrypt the key:

In order to reliably generate the content of emails, the application checks for the availability of recipient public keys (To:/Cc: list of email addresses) in the local memory of the device After the validity of available local public keys has been checked, all missing or invalid public

keys (according to the email address list of the recipients) are subsequently downloaded by the application from the directory broker (LDAP) or from the Mobile Application Management Portal

All newly downloaded public keys are validated and all valid public keys are stored in the local memory of the iPhone or iPad

For enterprises that do not have a PKI, the Mobile Application Management Portal provides the necessary core functionalities of a PKI. In this case, the Mobile Application Management facility can be used to manage the keys.

6.4 Public keys of recipients

The public key of the recipient or recipients is needed for sending S/MIME emails. Public keys can be obtained using the following methods:

Automatic querying of the enterprise’s own directory service, accessible via LDAP; in this case, the email address is the criterion used to search for the recipient’s key

Import of the sender’s public key from the S/MIME signature of an email (currently being implemented)

Batch import of public certifi cates by the user via iTunes (currently being implemented) For customers that do not have a PKI, it is possible to make a directory service available

through the Mobile Application Management Portal

Requirements of the IT infrastructure

(14)

IT has full control over

SecurePIM

R O L L - O U T & C O N F I G U R A T I O N — 8

The roll-out of the application can be adapted to the existing infrastructure and largely automated. Installation and confi guration are performed as follows:

The installation can take place via Apple’s App Store or through an existing mobile device management solution. For testing purposes, it is also possible to install the app simply via a QR code that contains an internal link

For fi rst-time installations, the user enters a minimal set of data (which is dependent on the enterprise’s compliance requirements); all further settings are adopted from the Mobile Application Management Portal

Registration on the Mobile Application Management Portal takes place with a challenge response procedure by which the app and Mobile Application Management Portal positively authenticate one another

The user’s private key can be obtained through the Mobile Application Management Portal or imported via iTunes (this step is not necessary for the smart-card-only variant)

Every time the app starts, it checks via a Web service interface (if an Internet connection is available) to see whether any of the settings have been modifi ed; any changes will be adopted automatically

The app can be updated via the App Store as well as through a mobile device management solution

Roll-out via the “iOS Developer Enterprise Program” with the customer’s enterprise key is in principle also possible. Further information on this can be found on the Apple website under iOS Developer Enterprise Program.

This variant is recommended in particular for custom adaptations. virtual solution can then compile the app with the customer’s key.

Roll-out and conﬁ guration

of the application

(15)

8.1 Mobile Application Management Portal

The Mobile Application Management Portal gives corporate IT control over enterprise data on the mobile device and enables it to securely confi gure and manage SecurePIM:

The app can be confi gured and adapted only from a central point via the Mobile Application Management Portal

The user is unable to make and must not make any unauthorized changes to the relevant settings; updates are applied automatically

Remote wipe of the personal certifi cate in case the device is lost (in contrast to remotely wiping the entire device, this approach permits straightforward restoration of the data while at the same time maintaining maximum security)

Devices can be ﬂ exibly registered and removed again as long as the licensed number of devices is not exceeded

Enforcement of internal enterprise security policies, for example, to specify which user groups require smart-card authentication

Core PKI functionality for managing the certifi cates of enterprises that do not possess their own PKI

It is impossible for the enterprise’s internal IT to use the Mobile Application Management facility to access any of the user’s personal data stored outside the secure container The secure container is not updated through Apple’s push mechanisms. SecurePIM automatically updates the data as a so-called secure connected container via a Web service interface every time the app is started.

8.2 Device registration

Devices are registered when the SecurePIM app is installed for the fi rst time.

The user enters their email address and the data supplied by the company’s IT into SecurePIM. These settings can alternatively be made available to users via a link, so that the installation process can be automated for the most part. If an MDM solution exists in the enterprise, it can be used to roll-out and install SecurePIM.

The registration process begins and a connection to the MAM Portal is established, as described below:

If at this point in the setup process there is no private key present yet (either by use of a smart card or through an already performed import via iTunes), the system checks whether a certifi cate has been deposited for this user by email

If this is the case, it is loaded and the user must enter their PKCS#12 container password for their private key

In the next step, a check is performed in the MAM Portal to see whether the user is listed in the LDAP directory and whether a public certifi cate has been deposited

If this is the case, a challenge is generated and encrypted for this user; it is therefore only possible for the user who actually possesses the private certifi cate and the correct PIN to register

This takes place completely automatically in the background; after the SecurePIM user taps the button to register, they are merely informed of the result

After successful registration, the settings that are deposited in the portal are transferred directly; the user merely has to enter their security-related data (dependent on the compliance requirements)

At the same time, the user associated with the automatically activated device appears in the Mobile Application Management Portal and can be managed from that point on

(16)

8.3 Certificate import (optional)

If the “Maximum Security” variant (where the card has to remain inserted) is not selected, it will be necessary to import the user’s private key into SecurePIM’s secure container. This can be done via email or iTunes.

In both cases, the enterprise’s internal IT must provide the user with their private certificate in PKCS#12 format. This container format is very secure and an import can only be performed with the corresponding transport PIN. Steps must be taken on the IT side to ensure that the

transport PIN is highly complex.

Import via iTunes (only recommended for testing)

For this, the SecurePIM user merely needs to move the P12 file that has been made available to them into SecurePIM’s application folder.

Once this has been done, the SecurePIM app asks for the associated transport PIN and then imports the private certificate if the PIN was entered successfully.

Import via the MAM Portal

A SecurePIM user has the option (if corporate IT has authorized it or requires it) to send their private certificate to the portal by email. A cron job runs on the Mobile Application Management Portal server for this purpose.

It imports the private certificates (secured in the PKCS#12 container) from the portal email account. These container files are deleted immediately after they have been accessed by the respective user. This means that the SecurePIM user merely needs to send an email with their PKCS#12 container as an attachment to the address provided by their corporate IT. When doing this, the SecurePIM user must ensure they send the email via the account that is used in SecurePIM.

A direct import of the private key from the PKI into the Mobile Application Management Portal for automatic distribution would be technically feasible. This approach, however, must always be checked and approved on the basis of the enterprise’s internal guidelines.

8.4 Data update

The MAM Portal administrator can adapt the settings for the SecurePIM app via the MAM Portal and trigger an automatic roll-out to devices that are already registered.

Settings that can be configured there include: LDAP configurations

Exchange Server configurations Various security settings

The SecurePIM app automatically triggers a status check at regular intervals. This check is also performed every time the app is started. This makes it possible to quickly determine whether a device has been blocked or whether new settings have been deposited on the MAM Portal. Blocking flag

The MAM Portal administrator has the ability to block certain users. This may be necessary, for example, if a device is lost.

It is also possible to block specific devices. This, for instance, would then permit a user to register themselves on a new device.

Automatic transmission of new settings

The status check enables new settings to be transmitted promptly to the registered devices. No action by the user is necessary for this. New settings are transmitted after a comparison is made with a date that is stored in the SecurePIM app. This date is modified with every update and is therefore used as the reference when the settings are changed again.

(17)