iOS Security Overview

I recently read Apple's iOS security overview which outlines the various security measures present on iOS devices.

It's a fairly short read at under 20 pages and it's great stuff to familiarize yourself with if you're developing on the platform. Here is a summary / some limited thoughts (I don't know much about security):

• A lot of Apple's security measures are possible due to novel hardware solutions
• The ARM processor's Execute Never which marks pages as non-executable
• AES 256 crypto engine and SHA-1 are built into the file system and implemented in hardware, which drastically reduces the overhead of encrypting everything
• Novel ways of wiping sensitive data that would otherwise linger in flash memory
• UIDs are not readable by software or firmware, yet still used as input to crypto

A lock inside a lock inside a lock

• The file system encryption is of an onion nature
• File metadata is not available all the time. This is to restrict access when the device is locked or interrupted by a phone call, etc. and availability rules are described by a files' class
• File metadata is encrypted. The file data itself is encrypted too, and that key is only available after decrypting the file metadata (that's right, each file has its own key)
• Did I mention that the file class which points to the file's metadata is also encrypted? See image above
• It's fast to remote wipe your device: just destroy the top level keys and nothing else on the filesystem is accessible
• Every encryption/security algorithm I've heard of is deployed here (ok not ROT13):
• Address space layout randomization
• Lots of certificates to authenticate trusted code
• Asymmetric elliptic curve cryptography (Curve25519)
• Yarrow
• PBKDF2
• SSL, VPN, etc.
• AES and SHA-1
• escalating time delays: it'd take years to brute force a short password
• I don't understand keybags yet
• My eyes glazed over and it sounds too similar to teabags

This weekend was one well spent as I participated in Music Hack Day SF for the first time.

I initially partnered with Kelly Dunn, who has been working on a project to send OSC messages triggered by Sifteo cube user interaction events (more here: Siftosc).

From 2pm on, we toyed with the idea of creating an air drum setup, which treats the cubes as shakers or drum sticks, using Renoise's built-in OSC server. Ultimately this didn't pan out since we weren't able to trigger note events without preprogramming a beat into Renoise, but Kelly did get the shaker implementation working and went on to do a crazy hack where he used the Sifteo cubes to manipulate his monome controller .

I moved on to experimenting with PureData on iOS with libpd a good 3-4 hours later. I got a basic grid-based synth working, but was unhappy with the sound quality on the iPhone simulator, which is a known issue with libpd. I learned a lot about puredata and could have potentially demoed the app despite its annoying distortion issues, but since I didn't have a device to deploy to and it was still before midnight on the first day, I decided to start over with something else.

Looking for examples of manipulating microphone input on iOS, I found aurioTouch, a powerful demo app created by Apple to showcase audio processing with the microphone. I started tinkering with this but was starting to feel fatigued from wrangling libpd and wanted to move on from audio low level synthesis.

I took an hour break and decided to work on a zany, assuredly demo-able project.

Enter sideTrack. It's a Rube Goldberg-esque python script which leverages many different APIs to mutate an initial seed song many times over until it eventually plays a completely unpredictable song, while speaking the nonsensical phrases it uses to perform each search.

Similarly to how one might fall down a wikipedia hole, this python script uses random lyrics, geography, song titles and more to repeatedly mutate different searches into a track with a spotify url, which is finally played via AppleScript after exceeding a depth limit parameter.

It leverages APIs from MusiXMatch, EchoNest, Spotify, and google maps to mutate the songs at each depth level. It worked and the results were always surprising. I was grateful to receive generous prizes from spotify and 3scale.

Here's a screen cap of sideTrack:


Regardless of frustration from my numerous aborted project ideas, music hack day was a ton of fun. I met some very talented and passionate folks, and eagerly await the next music hackathon.

9 hours of messing with iPhone SDK

The iPhone feels like a new frontier, at least for non-early adopters such as myself.

After learning about Walk Score, I was in a bit of disbelief that their application was not available on the iPhone. Their lookup simply requires a latitude and longitude, which the iPhone readily provides. I dreamed of running around while looking for an apartment and pressing a button on my phone to get its walk score.

So knowing nothing about Objective C, mobile development, XCode, or much else related to Apple development I set out to whip up a simple mashup of iPhone + Walk Score today and went at it for about 9 hours.

Unfortunately I haven't yet produced anything close to finished.

But I learned quite a bit.

For example, I learned that diving straight into the iPhone samples was a fruitless, frustrating process. The interface builder was not intuitive and I spent over an hour trying to add functionality to a button.

After downloading a 50-page tutorial on "Your First iPhone Application," I learned how rigorously the SDK enforces the Model-View-Controller principles, such that a simple Hello World app requires substantial scaffolding (50 pages worth!).

Additionally I got a taste of Objective C, a taste I have not yet acquired. It's more verbose than Java, yet is dynamically typed with difficult syntax and a reasonable number of dependency issues.

I learned that Objective C prefers a SAX style XML parsing.

I figured out how to send HTTP queries to Walk Score, parsed their XML response, and displayed a score for a fixed latitude and longitude.

After this I wondered if a browser based approach held more advantages. It would spare XML parsing and simply direct users to the search results page for their coordinates. This idea held appeal, since I would reuse the existing browser functionality, and some scores took time to calculate and would require a redirect anyway.

As my networks professor mused a couple of days ago, "Perhaps one of the best programmers I've met is also one of the laziest programmers I've met, he never does more than he has to for his code to get the job done. Maybe his laziness is what makes him so good." (He was relating it to the design decisions behind NAT)

After learning how to load web pages using an embedded browser, it came time to retrieve live GPS coordinates. Unfortunately, this is not as simple as a one-line API call. Using GPS is expensive battery-wise and is best done sparingly according the dev docs. For this reason a custom manager is required, which I was hooking up before deciding to call it a day and write this developer diary entry.

Perhaps later this week I will wrap up the GPS retrieval and integrate it into the iPhone app browser call. But I also learned it might not be worth it:
--Walk Score's heat maps show certain places, such as San Francisco, have near universal scores of 80-90 with only small pockets of lower quality. If the result is nearly uniform, is the experience of walking around with this app anything like I imagined?
--Apple has a certification program in place. Testing and verifying the app might be a costly endeavor, and it might not even find its way into the Apple store.
--Now that I learned some basics, I find myself less interested in this project versus what I could now begin working on.

All in all, a great experience. I'm still very excited to see what I can produce on this platform, even if I have to hold my nose to write Objective C...