iOS devices such as iPads and iPhones are quickly becoming a part of the enterprise IT landscape, in a trend sometimes referred to as “the consumerization of IT.” From a security practitioner’s standpoint, there are a number of factors here that are cause for concern, including the prospect of unmanaged or “under-managed” devices accessing corporate data, the variety of devices and form factors involved, and the rapid pace of adoption, to name a few.
Enterprise Public Key Infrastructure (PKI) and digital certificates can help. iPhones and iPads are natively capable of using digital certificates for authentication to corporate networks and data in a variety of ways:
- Corporate wireless networks (802.1X and EAP-TLS)
- VPN gateways via the built-in Cisco client
- Microsoft ActiveSync
- Mutually-authenticated SSL web sites via the Safari browser
Each of these allows an organization to restrict access to the above resources to ONLY allow devices that have been given a certificate from the corporate PKI. This, combined with robust controls surrounding certificate issuance, and organizational policy settings such as passcodes and remote wipe capabilities (e.g via ActiveSync), can start to bring some control to the situation, and in a relatively scalable fashion. In addition, the use of certificates can mitigate the need for every iOS application to collect and store the user’s username and password, which is also a good thing.
Like any PKI-enabled application, a proper implementation requires careful planning around the certificate lifecycle. There are often more aspects, but all certificate planning should include areas such as:
- Issuance: What users and/or devices need certificates, and what is the process for getting them there?
- Renewal: All certificates expire, typically in 1 to 2 years. Having a well-defined process for handling renewal can prevent massive headaches down the road. Planning here should outline who is responsible for identifying certificates that are about to expire, and the process required to renew expiring certs.
- Revocation: If a device is lost, or there’s a suspected compromise of a certificate’s private key, certificates should be revoked to prevent them from continuing to be valid enterprise credentials.
- Replacement: If a certificate is accidentally deleted, or otherwise lost, the certificate must either be recovered (in the case of encryption certificates), or replaced outright. Frequently the efforts here can mimic those used for issuance or renewal.
When it comes to issuing certificates to iPhones or iPads, there are two general options:
- Create a PKCS#12 (.pfx) file containing the certificate and private key. This can be installed in the device by pointing the Safari browser at a web server with the file, or by including the .pfx file in an iOS profile.
- Configure the device to enroll for a certificate via SCEP (Simple Certificate Enrollment Protocol) in an iOS profile (.mobileconfig file). Microsoft Certification Authorities natively include SCEP support as an added role on Windows Server 2008 and Server 2008 R2 operating systems.
There are some issues with both approaches, however. CSS views .pfx files as being inherently a bit dangerous: being files, they are quite mobile, and it can be hard to control where they go. In addition, they are susceptible to offline password guessing, and once the password has been guessed, the key is compromised. Finally, PKI “non-repudiation” is weakened: since the key is created centrally, it’s difficult to attest with 100% certainty that only the certificate bearer has had access to the private key.
SCEP-based enrollment is definitely a better option security-wise, as the private key is generated on the device, and is not exportable. The primary problem here is one of scale: the iOS profile places certificate content such as the Subject (Distinguished Name), and the SCEP one-time “challenge” password inside the configuration information. So the .mobileconfig profiles cannot be shared between devices – each needs its own. It’s possible to change the challenge password settings so that the challenges can be re-used, but it should be noted that this is a terrible idea – the way SCEP works, Active Directory credentials are not involved, so the challenge is really the only factor used to authenticate the certificate request.
Finally, regardless of the issuance method used, the certificates will expire, and iOS currently does nothing to handle this automatically. So, as mentioned above, some sort of process will need to be put in place to handle impending certificate expiration.
Coming Tomorrow: Using CSS’ Certificate Reporting Tool to help manage certificates for iPads and iPhones.
