3

My Windows Server just requested a certificate update related to the compromise of a root certificate a while ago. I remember Firefox, Safari, Flash, the .Net pile of stuff and Internet Explorer all requested that update earlier.

I know code is signed with a certificate, and hence my question:

  • are those certificates related in any way,

  • if they are then can the fact a root certificate was compromised be a risk to signed code (like allowing some evil code to execute, or maybe allowing someone to tamper with the signed code ?)

  • and finally, in the case of iOS, would that mean every single application needs to be recompiled with new certificates, or have no ill effect on previously signed code?

User97693321
  • 394
  • 2
  • 5
  • 16
Kheldar
  • 157
  • 1
  • 5
  • For the people who voted to close because "it's not related to programming", note that I was considering the code implications here, with the possibility such an attack might require every single developer involved to recompile his source, since we upload a signed binary to Apple's Store, not the source. I have my answers and will mark one asap, so if you still think closing is necessary, go ahead. –  Sep 07 '11 at 15:23

2 Answers2

4

First, the Apple code signing root is not related to the compromised root (DigiNotar), so to your first question, there is no direct impact on iOS code signing from this. This cert is in the iOS root store, so it could impact applications, including Safari or anyone who uses the built-in URL loading system or the root keystone.

If the Apple code signing key (or one of the major intermediaries) were compromised then that could be catastrophic to the code signing system in theory. In practice, the attacker would also need to masquerade as the Apple update server, which is a different problem. But if you put these two things together, yes, they could push anything they wanted in theory.

There are only two ways in general to handle a key compromise in X.509: wait for the certificate to expire or revoke it. Most root certificates have fairly long validity ranges (often decades). Lower-level certificates have shorter ranges (months or years).

Revoking a certificate means that the software (iOS in this case) needs to check a revocation list and reject certificates on it. That would break every piece of software out there until they were all resigned and reinstalled.

Because Apple controls the app store and iOS, there are actually some other options at their disposal. They could patch iOS to do a one-time verification of every piece of software against the hashes at the app store, and then apply a new signature. When you control all the parts of the system, it's easier to determine trust.

Just because the root certificates are compromised doesn't by itself mean that malicious code would suddenly run on everyone's devices (or anyone's devices). Compromising a certificate is just one piece of a more complicated attack. But it'd be a useful piece.

Keep in mind that Mac and Windows and Unix etc existed for many years without code signing. Most modern OSes have some kind of code signing, but it isn't used very extensively (often only at package install). When it fails, users generally ignore it. The iOS scheme is a big step forward, but you can muddle along without it.

Code signing does not ensure that code is benign. There are several malicious things I could do that would be almost impossible for Apple to detect before approving the app. And just because they have a credit card on file doesn't mean Apple really knows who submitted the app.

So code signing is an important security measure, but it isn't the only security measure. As you suggest, the keys are very important, but they're just one part of the system.

Rob Napier
  • 210
  • 1
  • 3
  • 9
2

If you have installed signed code based on being signed by a X.509 certificate signed by a bogus root, it might have been bogus code. And it might have done some unpleasant thing or another on your system.

However, it has no implication for code signed by certificates that were not signed by the compromised root.

bmargulies
  • 2,333
  • 3
  • 17
  • 20
  • Would that mean that one evil person (in the sense, it could be an organization) could eventually, having compromised a root certificate: 1- impersonate an update server 2- push bogus code updates? Or am I completely off? –  Sep 07 '11 at 12:47
  • 1
    Yes, that's exactly what it means. That's why a compromised root is a big deal. – bmargulies Sep 07 '11 at 13:11