YES SECURE PIM  -  FEATURES & ARCHITECTURE

YES SECURE PIM  -  RANGE OF FUNCTIONS

YES Secure PIM 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, Documents and Secure Browser.

YES Secure PIM 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. YES Secure PIM is currently available in German and English.

YES Secure PIM 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.

YES Secure PIM keyfeatures:

• 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 (BYOD) 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

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 finger (only on the iPhone), or an email can be written directly without leaving the Dashboard

SECURE MAILER

YES Secure PIM provides a secure email app approved and certified 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.

      File attachments

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

                                                                                                                                                                 Contact integration

                                                                                                                                                                  Integration with the contacts module for efficient addressee selection

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 offline access
• Search for emails by subject, sender and recipient
• Search for emails on the server
• Integration with the contacts module for efficient 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 file formats for attachments: doc(x), xls(x), ppt(x), all popular image formats, PDF, txt, and many more
• You can write emails offline; they are then sent as soon as you go online again
• Public certificates you have received by email can easily be imported into the application

SECURE CONTACT

Your business contacts are protected against unauthorized access. YES Secure PIM 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 offline
• Online access to business contacts on the Exchange Server
• Support for multiple groups of contacts
• Efficiently 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

Secure Calendar lets you manage your appointments and other events easily and efficiently 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
• Efficiently 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 YES Secure PIM closed

SECURE BROWSER

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 YES Secure PIM 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 confidential 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 certificates
• Bookmark management
• No restrictions imposed on the device's standard browser

SECURE DOCS

With Secure Docs you can access and use confidential documents conveniently and securely even outside your internal network.

YES Secure PIM accesses the company's internal document management system via a secure channel and stores the files 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)
• Efficiently 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

OVERVIEW OF THE SYSTEM ARCHITECTURE

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 files are stored and encrypted using the PKCS#7 or PKCS#12 standard.

In addition to this, the system includes a database whose contents are encrypted. 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 files are also encrypted using a device-specific symmetric AES key (NSFileProtection). Excluded from the encryption are freely accessible public keys and CA certificates as well as cached certificate revocation lists (CRLs).

The app can be configured 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.

PROTECTION OF ENTERPRISE DATA

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 file 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 files are additionally encrypted using a device-specific 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 certificates as well as cached certificate revocation lists (CRLs).

SEPARATION OF BUSINESS AND PERSONAL DATA

YES Secure PIM 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 identification (but only if authorized by the enterprise's internal IT in the Mobile Application Management Portal).

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 authentication via a central single sign-on service can also be integrated.

CRYPTOGRAFIC METHODS

YES Secure PIM 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 encryption. 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.

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.

YES Secure PIM 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)

MICROSOFT EXCHANGE INTEGRATION

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

EXCHANGE SERVER INTEGRATION WITH ACTIVSYNC

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 YES Secure PIM; 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.

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

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

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.

SUPPORT FOR SMART-CARD READERS

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.

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 configuration, the card will be blocked
after the PIN is entered incorrectly a predefined 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 YES Secure PIM app or switches to another app, they will have to re-enter the PIN if they want to return to the YES Secure PIM app.

SMART-CARD SECURITY - THE CARD 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 memory. The next time the user opens the app, they will be required to insert the card again and re-enter the PIN.

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.

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
• The device is put in standby

INTEGRATION OF PUBLIC KEY INFRASTUCTURE

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 certificate, which is the basic requirement for all security-related operations
• Access to certificate revocation lists for checking the validity of certificates and for disabling access to enterprise-related data by way of the central control element: "revoke certificate"
• Provision of the public keys of email recipients and for user-specific encryption of documents before they are transferred to YES Secure PIM
• 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

CERTIFICATE MANAGEMENT

An enterprise's internal root certificates can also be classifi ed as trustworthy using fingerprint checks.

For the "High security" and "Smart-card security" variants, the user certificates can be integrated in the app using the following two methods:;

1. The encrypted user certificate is copied into the app as a PKCS#12 container (.p12 file) via iTunes.

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

The application recognizes a newly set user certificate and then performs the following actions:

• Any pre-existing certificate 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 file is generated using the information cached in the main memory and is secured with the new application password
• The generated container file is stored in an area of the application's documents directory that is not visible to iTunes
• The imported PKCS#12 file is deleted

CERTIFICATE CHECKS

Certificates are checked each time they are used. This is the case when a new certificate is imported as well as when you use your own certificate 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 certificate revocation list profiles):

• The current system time must lie within the certificate's period of validity
• A valid certificate chain must exist, that is to say, at a minimum the root certificate must be classified as trustworthy by way of a fingerprint or by an official certificate authority (CA)
• All signing CA certificates must be retrievable and valid (the certificates are cached subject to their validity)
• The certificate revocation lists (CRLs) are checked and automatically updated depending on their configuration
• 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 certificate, 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 certificate or not.

The CRLs are reloaded after a defined period of time according to their own requirements.

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.

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

SUPPORTED MOBILE DEVICES

• Apple iPhone (3GS or newer)
• iPad 2 or newer
• iPad mini
• iPod touch

SUPPORTED OPERATING SYSTEMS

• iOS 6.0 en newer

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: Certificate revocation lists of the CAs
• Optional: Microsoft SharePoint server

ROLL-OUT APPLICATION CONFIGURATION

The roll-out of the application can be adapted to the existing infrastructure and largely automated. Installation and configuration 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 first-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 modified; 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.

MOBILE APPLICATION MANAGEMENT PORTAL (MAM)

The Mobile Application Management Portal gives corporate IT control over enterprise data on the mobile device and enables it to securely configure and manage YES Secure PIM:

• The app can be configured 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 certificate 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 flexibly 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 certificates 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. YES Secure PIM automatically updates the data as a so-called secure connected container via a Web service interface every time the app is started.

DEVICE REGISTRATION

Devices are registered when the YES Secure PIM app is installed for the first time.
The user enters their email address and the data supplied by the company's IT into YES Secure PIM.

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 YES Secure PIM.

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 certificate 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 certificate 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 certificate and the correct PIN to register
• This takes place completely automatically in the background; after the YES Secure PIM 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

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 YES Secure PIM'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 YES Secure PIM user merely needs to move the P12 file that has been made available to them into YES Secure PIM's application folder.

Once this has been done, the YES Secure PIM 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 YES Secure PIM 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 YES Secure PIM 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 YES Secure PIM user must ensure they send the email via the account that is used in YES Secure PIM.

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.

DATA UPDATE

The MAM Portal administrator can adapt the settings for the YES Secure PIM 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 YES Secure PIM 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 YES Secure PIM app. This date is modified with every update and is therefore used as the reference when the settings are changed again.

Try it yourself !

The solution for you, the YES Secure PIM and the Mobile Application Management Portal. 

Request more information via email or our contact form .

Back to YES Secure Network