Not surprising, the serious Comodo certificate breach last month is impacting all of the mobile platforms as well. Luckily for most of us so far the incident has not appeared to be found using the impacted certificates in the “wild”. But raises several questions on certificate trust, the certificate vendors we give all this trust, and how much certificates are important to our general Internet access.
Public Certificate Management
Some browsers currently automatically update certificates via CRL (Certificate Revocation List) or use OCSP (Online Certificate Status Protocol) and vendors are usually pretty quick to update their user base. I believe Firefox and Opera use OCSP by default witch Comodo also supports.
Sophos has a good article about it here. But to really ensure that the bad certificates are not used most operating system vendors will also issue patches or updates at that level as well where the certificate store is usually managed.
Mobile Operating Systems
As we all know in my blog the multiple mobile operating systems create difficulties in a combined support approach. On every mobile device many of the commonly used top certificate vendor’s trust root certificates are automatically embedded and valid for many years in the future. With many mobile devices rarely being update (if we look at the past history) knowing what trust root certificates are present across a wide range of devices is critical before you purchase a certificate to use on your public mobile web site.
I found this excellent site in Denmark to test SSL browser certificates, but they also have a great table of mobile devices, browser support, and trust root certificates:
The Microsoft bulletin has now been updated to reflect their supported mobile platforms:
But no direct patches have been made available for Windows Mobile and Windows Phone so far: http://support.microsoft.com/kb/2524375
Historically very rare to see any Windows Mobile patches publically distributed. With the recent Windows Phone updating finally going on, it could be a different story there.
On the Apple iOS side, the Comodo certificate authority has been included in iOS and previous versions. The recent iOS 4.3.2 update specifically addresses the certificates in question and black lists them: http://support.apple.com/kb/HT4606
For the Apple MacOS, there is this patch: http://support.apple.com/kb/HT4608
I can also assume that a valid Comodo root certificate is probably present on most of the Android devices being sold. But it may came down to the OEM/mobile operator that made/sold the device to support it. Thus I haven’t seen (so far) any patches from any vendors on this issue. See the mobile device table I mentioned above, http://www.ssltest.net/compare/sar.php, for a good current list of Android devices and their trust root certificates..
I was also unable to find too much specific information on the 3rd party mobile browsers in regards to their efforts to update their products. If the same logic and code is being used with CRL and OCSP processes we can hope the bad certificates will be handled correctly.
In the Enterprise
This incident again showcases that the mobility space is still taking somewhat a backseat to the “legacy” computing environment in regards to operating systems and browser support. With millions and millions of devices being used and soon forecasted to be used in the Enterprise and public consumer areas I believe this will soon need to change and the vendors (hardware and software) will need to address the needs and avenues to provide emergency patch management. I believe the security risk is greater within the mobile arena then others, as it’s harder on the smaller screens or mobile operating systems to actually verify the web links sent in e-mail phishing attacks etc.
In this case with certificates, for those Enterprise environments who have invested in a Mobile Device Management (MDM) solution they are some avenues to push down and update certificates based upon mobile platform support.
Announced last week, this has been a long time coming in my mind. The mobile device space has become increasing confusing and an overall lack of support for many features until you dig deeper and find vendor details. It has been hard to find out what each device supports before you connect them to your company’s Exchange. This has been especially true on the many Android flavors and devices now available and being released at a very fast pace. Many companies are now seeking to change their mobile device policies, remain somewhat secure, and allow users to connect their personal owned devices.
For additional information on EAS support on mobile devices take a peak at my posting from last month here. It contains a few good links on EAS support on certain platform levels.
At this time the Microsoft certification or logo requirements are not too broad, and mainly hit the common security settings and features:
- Must be current Exchange ActiveSync licensee (most OEMs and some software vendors)
- Use Exchange ActiveSync v14 (Exchange 2010) or later
- Direct Push email, contacts & calendar
- Accept, Decline & Tentatively Accept meetings
- Rich formatted email (HTML)
- Reply/Forward state on email
- GAL Lookup
- ABQ strings provided: device type and device model
- Remote Wipe
- Password Required
- Minimum Password Length
- Timeout without User Input
- Number of Failed Attempts
It appears that the Apple and some Nokia (and of course the current Microsoft flavors) devices have already been approved.
It will be interesting to see how this is picked up by the OEMs and mobile operators. I would like to see additional security features, such as encryption and deactivation of specific features etc. make the list. Although if such additional certification “tiers” are later introduced in the near future many devices might not make the list. :-)