Over the air Mobile
Device Management support – iOS
iOS Enterprise ready?
iOS has OS level implementations of kernel APIs(secured) to support
Mobile device management. But these APIs are not publicly available
or exposed until it’s triggered from a process called “MDM
Enrollment”.
Because apple
believes it's too risky to expose device management APIs to user
phase.
In addition to
that,”MDM Enrollment”provides a highly secured data transmission
between the device and server(iOS Middleware).
iOS MDM
Fig 1
Here are the three steps to trigger to support MDM
1. Basic Authentication phase
2. Certificate enrollment phase
3. Device
configuration phase
Basic
Authentication Phase
1.In this process a URL is exposed to user from iOS Middleware
(Figure1).
Once the user taps the URL ,it ask the user to enter his user name
and password for
authentication. User credentials are checked with MDM Directory
service(Figure1).
2. Once the device
is authenticated ,a “device configuration profile”(payload)
request is sent to
the device. This payload,request the device to send basic device
attributes such as UUID,
device version etc.
note: Payloads
are property lists(plist),which wrap in XML and send it to the
device.
Profile
service payload
X.509 Certificate enrollment Phase
Once the device sends its response to profile service(iOS
Middleware).this response contains the device attributes ,which then
to be sent to MDM(figure 1).
To provide a secure
tunnel between the device and iOS Middleware,iOS supports certificate
enrollment. At the end of this process a secret X.509 certificate is
delivered to device. Device later can use this particular certificate
to encrypt valuable data in MDM transaction.
iOS supports SCEP
protocol to do this certificate enrollment.
In response profile
service delivers a SCEP payload to device. This payload should
include SCEP server URL,where device can request a certificate.
SCEP Payload
device install SCEP payload without any user intervention.
During the
installation SCEP payload instructs the device to generate pair keys
called private key and public key.
Device keep the
private key with itself and use its public key to generate a
CSR(certificate signing request)and send it to the SCEP server .
With the public key SCEP server talks to CA and issue a X.509
certificate to the device.
(discussed below)
What's
SCEP and how it works ?
Simple certificate enrollment protocol (SCEP) allows server/client to
do a secure transaction in a network,to avoid the data modified or
seen by anyone.
In this process a
client / server / device sends a CSR(included its public key) request
to SCEP mentioning the operation as GetCACert(requesting a
certificate from CA).
SCEP server has two
ways to handle this request.
1.In the presence of Registration authority-RA
Fig 2
In this method SCEP sends its request to RA,RA validates and
authenticates the SCEP
request and send
a request to CA. In response CA issues a digital certificate.
2.In the absence of Registration authority-RA
In this method SCEP
directly talks to CA and gets a digital certificate.
Once the certificate is issued by CA,then it sends that to a
operation called PKIOperation. In this
issued certificate first its encrypted and then signed using
PKCS7 format,and form a X.509
identity certificate. This X.509 certificate is sent to device and
get installed without user intervention. Later this certificate is
used to encrypt payloads for secure transaction.
X.509 certificate :
It’s encrypted and signed certificate.
Each apple devices gets their respective X.509 certificate.
Because of its
uniqueness , data encryption can be achieved. I will discuss this in
next phase.
Encrypted Profile Phase
Device sends its own X.509(received from SCEP server)to profile
service in iOS Middleware .
This certificate is
used to encrypt MDM configuration payload and results a encrypted
data. Later this encrypted data is signed using server(iOS
Middleware) credentials and send back to device.
In the device
end,encrypted data can be decrypted using its own private key and
obtain the original MDM configuration payload and install without any
user intervention.
Note: Other devices or third parties in
the Internet can not see data since its encrypted using a particular
device certificate.
MDM
configuration payload
Device in response
sends an acknowledgment to the iOS Middleware and perform a check in
to the server.
In this
acknowledgment response, device sends three tokens to the server
1.Device token
-device identity.
2.Push magic
token-unique MDM server sends with each push request
3.Unlock token-an
escrow key used to clear the passcode on the device.
These three tokens are sent to MDM directory service and saved
against user credentials.
How to do
control iDevice from MDM?
Fig 4
To do an operation on device ,MDM directory service sends Device
unique token and push magic
token to APNS pusher service.
Now APNS pusher service sends a command to Apple APNS cloud ,which
then give a “wake up call” to device.
APNS push service sample given below
Note: you need to have a Apple MDM push certificate to do this push
operation.
Register MDM APNS
Device then sends a request to Payload service ,mentioning its state
(Idle).This request actually invite Payload service to send further
commands (such as device lock,wipe,etc) to the device.
In the Payload service end,it asks the MDM directory service for the
operation to be performed on the device.
Once the operation (say LOCK) command is received in Payload
service,it creates a XML based property list(plist).And it sends it
to the Device.
Sample payload for LOCK operation is given below.
Now the device is performed the operation (locked ) over the air
command. Same as other operations are performed on the device.
At last device sends an acknowledgment signal,mentioning its
state(Acknowledgment) to server side about the status of the
operation it performed.
**************************************** End ************************************
Mayuran.K
Software
Engineer -WSO2 Mobile Inc
Mobile: +
94 778174806
