Symantec Vs Mcafee Vs Trend Micro

This technical note explains how OpenTrust securely delivers digital certificates with SCEP (Simple Certificate Enrollment Protocol), without being affected by the published by US-CERT.

This vulnerability enables an attacker to impersonate another user when enrolling for an X.509 certificate with SCEP. As with any other protocol or system, the security of SCEP lies in the details of the implementation: Proper identity vetting and credentials verification are keys to make certificate issuance secure. OpenTrust, unlike some of its competitors, took great care at implementing all recommendations set in the SCEP RFC, to ensure the secure delivery of certificates via SCEP. In short: by using a “one-time use” challenge for each SCEP request, and by not trusting the identity attributes (Common name, email, etc.) set in the certificate request by the requester.

By using these simple techniques, and providing PKI administrators and MDM vendors with the tools and API to easily manage SCEP requests, OpenTrust ensures secure certificate enrollment with the SCEP protocol.

It is important to note that the vulnerability penetrates the SCEP protocol when vendors poorly implement the security controls recommended in the SCEP standards. SCEP remains an effective way to issue certificates to any device – provided the certificate registration and issuance is correctly implemented.

And now for the gory details… Let’s review in detail the OpenTrust SCEP implementation.

This vulnerability is due to the fact that many SCEP mobile implementations:

• Blindly trust the identity (Subject Name) contained in the SCEP client request, and issues the certificate for any identity requested by the SCEP client.
• Use the same challenge (i.e. the shared secret between the CA and the SCEP client) for multiple clients, even though the SCEP draft RFC draft-nourse-scep-23 specifically says that: “When utilizing the challengePassword, the server distributes a shared secret to the requester which will UNIQUELY associate the enrollment request with the requester. The distribution of the secret must be private: only the end entity should know this secret. The actual binding mechanism between the requester and the secret is subject to the server policy and implementation.”

OpenTrust has been using SCEP to securely issue certificates on network devices for more than 10 years, and, from the start, understood the importance of properly authenticating and authorizing the certificate requests, and to never trust a client device to establish its own identity.

The OpenTrust SCEP implementation ensures, before any SCEP request, that the user or device is registered in advance by a trusted third party, typically the MDM platform for mobile devices, or an administrator for other devices. We eliminate the risk described in the US-CERT vulnerability report by:

• Providing a one-time SCEP challenge (shared secret) for each certificate request. There is no global password that once stolen from a compromised endpoint can be used to issue fraudulent certificates.
• Ignoring the identity (Subject Name and Subject Alternative Name) provided in the SCEP request. The user identity is provided in advance by the trusted third party.

In the case of iOS, the MDM service distributes a profile containing the SCEP parameters (SCEP URL and challenge) to issue a specific certificate on the device. The following sequence describes how the certificate issuance process is secured by the OpenTrust SCEP implementation. For clarity, we do not distinguish between the OpenTrust registration authority and SCEP responder (OpenTrust CMS), and the Certificate Authority (OpenTrust PKI).

The MDM server, strongly authenticated with its own certificate, registers a SCEP request, using a simple HTTPS REST API provided by OpenTrust CMS. The registration request is “Please register this SCEP request for Tony Stark”. OpenTrust CMS returns the SCEP URL and challenge for this request. It is unique to that request and only valid for a limited period of time. The MDM server builds the iOS configuration profile and sends it to the device. During this stage, some kind of user authentication usually takes place to validate the identity of the user. The device issues a SCEP request to the SCEP URL, using the unique challenge provided by the MDM. The OpenTrust SCEP server verifies the challenge, and if it is valid, issues a certificate for the identity provided in step 1, not the one from the SCEP request. From the SCEP request, OpenTrust only uses the public key, generated on the device, to build the certificate, after establishing the “proof of possession” of the private key by theSCEP client, by verifying the signature of the SCEP Request, signed with the device private key.

OpenTrust CMS is not affected by the vulnerability because:

• It does not trust the identity information provided in the SCEP request. The user identity is provided “out of band” by the MDM server, unbeknown to any attacker that could have control of the untrusted device
• The SCEP challenge is unique to each and every certificate. It is only usable once for a given request.

Using this simple yet effective technique, the OpenTrust implementation of the SCEP protocol cannot be used to impersonate another user when enrolling for an X.509 certificate.