jcarlson's picture By

In their latest OS release, iOS 7, Apple allows for a number of mechanisms to share data, both in the form of files or streaming data. Two of these mechanisms highlight some of the different design choices Apple has made and will likely continue to make in the SDK.


The Multipeer Connectivity Framework allows for peer to peer connectivity between devices. The framework is completely new to iOS 7, allowing for both transactional exchanges of streaming data or real-time (non-transactional) exchanges. From a security point of view, this framework is obviously interesting but Apple has made clear choices to supply the developer with security options (as they often have in iOS - which typically leads OS X by the way). In particular, the Multipeer Connectivity framework allows for encrypted communication and an accompanying security identity and certificate to authenticate the supplied identity.

Apple continues to make sharing and social services a priority, enabling a variety of new mechanisms within iOS 7.

Bear in mind, the developer can -- and most likely will -- ignore security considerations, but at least they are available. Delegate methods are also available to validate the certificate upon session initialization. Naturally, for any applications with privacy considerations, that’s what we would recommend. Because this is all new, we can see a clear picture of how Apple built in security options from the beginning and while it probably won’t be used as frequently as it should be, Apple has made it fairly easy to integrate in a clear chain of events.

In contrast, when we look at AirDrop, we see a very different story. AirDrop is an IPC mechanism that allows interaction not only between applications on a single device (which isn’t that new), but on another device as well, depending on the OS settings. AirDrop is interwoven with the existing, and very apple-airdrop-securitycentral, UIKit framework. Because it’s an IPC mechanism, the underlying call must be handled within the Application Delegate, which is exactly what we see. However, this left Apple with limited options, so in order to enable the IPC mechanism for a given filetype not only does the Delegate have to implement the appropriate call, Apple also chose to enable the system interaction using entitlements. The entitlements registers the application as a handler for a given filetype, whether custom or a known UTI, and then the user picks among the choices when data is shared with them. The choice to use entitlements historically has been a means to allow for certain functionality within core frameworks, such as UIKit.  An example of this was iCloud which uses entitlements to allow access to the ubiquity container through Foundation classes.

AirDrop, which is available on recent devices, allows for a more sophisticated sharing mechanism than the old URL based method.

For applications that use AirDrop with fewer security handlers built-in to the use case(s), it’s left to the developer to do more vetting. In those cases a custom file type could be used along with public/private key pairing to verify the authenticity of the file. If the security concerns are less severe, then using an iOS-compliant version of libmagic (such as with MagicKit, which can be found on GitHub) to provide a “file”-like interface to verify data, file types, etc, can serve as a barrier to attackers as well as a good integrity check on the incoming data.

However, this raises the question of how many capabilities could be added to core frameworks without re-engineering large sections. Apple has an advantage relative to Google’s Android in that the market tends to keep up, so backwards compatibility to iOS 2 or 3 is not likely to be a strong consideration. Looking at these choices from the outside, it seems that Apple has clearly begun incorporating security from the ground up within new frameworks, whereas older frameworks lacked built-in security features, relying on opt-in system strategy to enable private APIs to interact with the OS. As feature creep continues, there are potential risks as to how to expose OS functionality without compromising security. Layered approaches often result in more bugs and greater opportunity for security missteps.

iOS remains one of the most secure platforms on the consumer market, but this area bears watching over the long term, to see how security and engineering decisions evolve within one of the most popular consumer platforms. My bet is that depending on the popularity of various services, Apple will attempt to re-engineer a service and incorporate that into the operating system. We’ve already seen this with their identity management system and the pattern is likely to continue.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.




contact menu