If you’re reading this, there’s a good chance you’ve already seen the reports about the security ramifications of issuing certificates to mobile devices using the Simple Certificate Enrollment Protocol (more information on our site here). We’ve received many inquiries about how to determine whether a given system is at risk, and if so, what levels of exposure may be involved. Complicating the issue is the sheer number of Mobile Device Management (MDM) products that exist, and the wide variety of configuration options within them. Because of all this variability, simply asking, “Is {Product X} affected?” can lead to over-simplified answers that might still leave you exposed to risk.
Assessing the risk of a given MDM deployment can be a bit nuanced, as there are a number of factors that come into play. The primary criteria to examine when making an assessment are:
1) Where SCEP challenges are being sent (and therefore potentially misused). As you might expect, the more places that the challenge passwords are sent, and the less secure those places are, the worse off you are. Systems that turn off or allow re-use of the challenge passwords are worse still.
2) What sort of fraudulent certificate content may be requested. The less restrictions that are placed on enforcing requested certificate content, the more potential for a problem.
3) What systems or entities trust the potentially fraudulent certificates. The more widespread the trust in the issued certificates becomes, the greater the risk. If you’re looking to issue certificates that are trusted by your organization’s PKI, this is definitely something you should be taking a very careful look at.
With #1, there are two areas where MDM systems may make use of SCEP: A large source of risk stems from cases where SCEP profiles are used to deliver authentication certificates. But nearly all MDM systems use SCEP during the initial device enrollment of iOS devices.
Some MDMs use SCEP at the MDM server, to retrieve certificates on behalf of the user, and then deliver them as a PKCS#12 to the device. This maintains better control of the SCEP challenge passwords, but at the expense of the on-device key generation that iOS supports. From a PKI practitioner’s standpoint, on-device keygen is vastly preferable, and helps prevent the PKI management headaches of certificates “getting legs” and being given to users or devices where they don’t belong. For this reason, many Certificate Policy (CP) documents actually mandate on-device or hardware key generation, or non-exportable private keys.
#2 is very much dependent on the SCEP server and PKI being used. In some cases nearly any PKCS#10 will be accepted. Others allow some fields to be specified, while other fields are set programmatically. For example, many Microsoft certificate templates overwrite just about everything being requested other than the public key and the requested cert subject and subject alt name.
#3 is dependent on what else the PKI handling the SCEP requests is being used for. We’ve seen cases where organizations that aren’t even interested in issuing authentication certificates via MDM have exposed themselves to risk by leveraging their internal PKI to handle the initial MDM device enrollment.
It’s the interaction of these three factors that’s the key. But even in cases where the SCEP server’s PKI is entirely isolated and only issues device enrollment certificates, there is still a possible risk of someone requesting a certificate that represents a different device to the MDM system — perhaps one with a higher level of access or fewer restrictions. To reference #3, this could have a bigger impact in a cloud-based MDM deployment.
There’s still a lot of nuance involved, but hopefully this helps set the context. CSS has a solution that allows this to be done securely, using a SCEP Validation Service to prevent the misuse of captured challenge passwords. In my opinion, without something like this in place there will always be some risk any time SCEP challenges travel outside a trust boundary – the only question is how much.
