What Are the Implications for Application Signing?

2012-02-16 • SEND FEEDBACK |
Related: Apple, Apple iOS, Apple iPhone and iPad, Apple macOS, iOS, John W, security

Digitally signing an application means that a cryptographic certificate is used to mark it as trusted. Trust here means not only trusting the signer, but also the authority signing the signer’s own certificate.

Digital signing is one means of defeating malware, at least certain types of malware . In this regard it is a big move forward, though I see it as increasingly less important, because more and more infections originate on malware sites and by phishing, not from applications. Still, it is a very good thing in terms of locking down one vector of system compromise.

Apple is apparently moving in a direction where applications will be signed, with an apparent feature to disable (worldwide) any application it cares to, by building into the operating system a feature whereby an application can be prevented from running if it is deemed Bad (somehow, by someone, for any reason, at any time).

If an app is found to be malware, Apple can revoke that developer’s certificate, rendering the app (along with any others from the same developer) inert on any Mac where it’s been installed.

Read that again: Apple will possess the ability (subject to government demands or pressures (legal or not), court orders, arbitrary whim, hacker intrusion) to disable any application. Or perhaps in the future to not just disable, but to remove the application. That’s a powerful tool to silence some forms of speech given Apple’s market dominance: what developer would dare throw away 100% of sales?

Apple is a private party. Constitutionally-guaranteed (ha ha) free speech rights apply to the government versus citizens, NOT to private parties, a point many people are unclear on. So there is no free speech protection with a private company like Apple.

Remember also that free speech in the future might mean almost exclusively digital free speech— online, not printed matter. And that a digital device might be your only practical means for all your expression outside your immediate personal interactions.

Consider the following, which is hardly a complete list:

• Apple disables, removes or forbids an application because of Congressional pressure. No Rule of Law, no due process, just arbitrary removal or shut-down of an application. This already happened once last year. It doesn’t matter whether you agree or disagree with what any particular app does; that’s not the point. Policies regard can change at any time.
• A repressive country (Iran, China, Syria, etc) decides that it doesn’t like the certain apps being used by Undesirable Elements. So it demands that Apple disable those apps. Apple doesn’t want to risk its commercial market there, so it disables those apps.
• Hackers penetrate Apple’s systems. All applications of any kind worldwide could be suddenly disabled and/or removed. If a key cryptographic provider (RSA) can be compromised, it can happen anywhere. Or consider this article. Or this one. Or this one. Or this one. Or thousands of others. And that’s just what has been made public; assuming all such compromises are disclosed would be extremely naive. An exploit of this magnitude would be like an Olympic gold medal for hackers— highly attractive.

In short, does the alleged security improvement make matters better, or perhaps hold the potential for calamity on a wide scale as in a software “nuclear meltdown”?

Trust requires transparency. I would feel better about Apple’s signing initiative if it were removed from Apple’s control and implemented by a 3rd party, along with rigorous and explicit legal protections, designed to preclude government meddling. Good luck with that.

Having been part of PGP in its earlier days, I would also favor a strong public key infrastructure based on multiple trusted parties, not a conventional single point of failure that when compromised takes down everything. This has long been technically feasible, but it won’t happen unless Apple throws its weight behind it as part of its signing initiative.

Highly recommended: https://www.schneier.com/

Reader Comments

My readers really seem to dislike what I wrote. But I am writing at a conceptual level, and not one email has addressed the core issues, which I feel are the real issue.

John R writes:

Let's start by examining the reasons why iOS doesn't allow you to run unapproved third-party software.

• Thirty percent. Apple certainly benefits from taking a 30% cut of software sales made through the App Store. (It should be noted, of course, that you can publish free software via the App Store as well)
• Carrier network limitations. If iOS users run bandwidth-intensive apps on wireless networks, there's a real potential for iOS users to overwhelm wireless networks already struggling to keep up with demand. This is why applications such as Skype, or even Apple's own FaceTime, don't let you videoconference over cellular networks. Apple has extraordinary leverage with carriers, but Apple simply can't sell a device that would overwhelm the networks it relies on.
• Because they can. iOS is a new platform, with no history of allowing you to run unapproved third-party software.

I agree that concentrating too much power in the hands of Apple is a very dangerous thing. I also partially agree with your recent assertions that Apple is de-prioritizing the pro market. (I say "partially" because I'm a developer, so I'm coming from a different perspective than a photographer or videographer)

However, I don't think Gatekeeper represents the kind of threat you think it does:

https://www.macworld.com/article/165408/2012/02/mountain_lion_hands_on_with_gatekeeper.html:

From a technical perspective, it would be very easy for Apple to disallow unsigned apps. It doesn't look to me like they have any intention of doing that. It's almost like a more permissive version of File Quarantine, which has been in OSX since 10.5 or 10.6.

Even we assume Apple is acting in maximum self-interest and with zero goodwill towards customers (always a good assumption for any business) I still don't think it'd serve them to lock down OSX ala iOS. I just fail to see how it would benefit them.

Clearly, funneling a larger percentage of OSX software through the App Store is in their favor. But developers won't work on a locked-down OS, and if nothing else Apple needs iOS developers to write their software on OSX. Apple also values its image, and I believe there smart enough to know that if "early adopters" and "intellectuals" start turning their noses up at a locked-down OSX, others will follow.

I'm unsubscribing from your news updates. I'm a satisfied customer of your digLloyd Tools, but I think a lot of your current assertions are unfounded and sensational.

DIGLLOYD: That MacWorld article is non-conceptual, talking only about the here and now specifics, reassuring to be sure, but that is its very weakness if one takes a longer term view. If there is no issue, the article need not have been written at all.

Wishful thinking is not a substitute for conceptual thinking.

What the current Apple policy is, what actually makes it into Mac OS X Mountain Lion, and what future changes will be, no one can say. It’s only a small step to locking down the OS in a future (even minor) revision. The iPhone and iPad are clear enough in that regard. And the electronic world is converging into one huge interconnected device.

Future predictions often look wrong, though I am not predicting what will happen, I am only saying what could happen, and I doubt I have scratched the surface.

Should Apple remove the app-signing feature? That’s a much harder question, since it does have benefits. A lot depends on how it actually works, and whether it can withstand security scrutiny and whether the structure can be made secure from arbitrary whims: a software “kill” switch is a very real possibility for abuse.

Apple policies can and do change, but are also subject to governmental edicts around the world. Now that Apple has such huge market strength with iPhone and iPad, what might be the juicy possibilities for the control freaks in government? And the fact that Mac OS X is not locked down the same way right now as iPhone might be looked at in hindsight as a curiousity. And it might never happen too.

The point is to think about the implications of any widespread modern infrastructure of any kind (as an exercise, what if iCloud is wildy successful with 500M users, and terrorists target the 2 or 3 data centers housing it? Or just the power cables feeding them?). All these issues are made much more worth thinking about due to sheer size and scale. The state of things now or 6 months from now is not the concern.

Markus H writes:

OS X 10.8 still allows you to disable application signing completely at any given moment.

And how many iOS apps have been pulled from actual devices so far?

DIGLLOYD: Still and so far.

John W writes:

You've failed on some crucial fact-checking on your recent article on application signing. The code-signing check only applies to applications which are currently quarantined, per Apple's new Developer ID Tutorial. The "quarantine bit" is seen in the now-familiar dialog in OS X (since 10.5) that queries the user whether they're sure they want to open an application file downloaded from the web. Once the quarantine bit is unset, the file is assumed-good forever more.

To rephrase: once an application is installed, Apple has no ability to cause it to stop running remotely. They can only prevent future installs from working, for apps signed with revoked Developer ID certificates. This is precisely what's needed to stop malware propagation, without overstepping into interfering with the operation of a user's system.

In fact, I'll go one further: this is pretty close to the holy grail that knowledgable application developers and users have sought for ages. Prior to now, this required a cumbersome sequence of steps:

1. The developer must create a public-key encryption key-pair, and publish the public key on known key servers, such as pgp.mit.edu.
2. The developer signs the distribution packaging for a new release (archive file, disk image file, etc.) with the developer's private PGP/gnupg key. This creates a signature file for the app's released files.
3. The user must download both the app's file and the signature.
4. The user must install and use relatively obscure command line utilities (e.g. gnupg).
5. The user must remember to perform the signature check.
6. Ideally, the developer's signature should be trusted by some mechanism such as a "chain of trust". Without this, any bad actor could simply follow the steps above to create a "signed" app package, one not signed by the original developer(s).

Most readers' eyes will have glazed over somewhere in the middle of step 1, which highlights the problems that prevented this from being effective in the real-world. First, the process above was suitable, at best, for use by trained professionals such as system administrators and software developers. Many of them didn't even bother. Second, establishing a chain of trust for all the packages one might need to install and use was usually a prohibitive amount of work, which undermines the effectiveness of the whole affair.

With Mountain Lion, Apple has automated this process and put the control over the level of application access into the hands of the end-user. End users may opt-out of the checking process entirely -- any app from any source may be installed. The default is to allow apps which are signed by Apple for the Mac App store, or signed with a free Developer ID provided by Apple. Finally, users may opt-in to the most restrictive path -- only Mac App store applications may be installed.

A summary of Gatekeeper and its implications from an independent Mac developer was written on Panic's blog, which summarizes the state of affairs as well as Apple's positioning regarding these changes (with praise and critique in turns) quite well.

DIGLLOYD: Agreed, Apple is now making accessible to an ordinary user what has been a technically challening app verification process that only geeks have been willing to use. And yes, there is a 'bypass' in place now. And that could never, ever, ever be changed? Blue skies.

This response is concrete-bound thinking in the here and now. But a trend is in motion, and it only takes a little time for infrastructure to develop to a point where some ugly things become real possibilities. What is exactly the case now or even when Mac OS X 'Mountain Lion' is released is hardly relevant to the conceptual issues involved; my concern is with where this is all leading.