“Borderline bulletproof” security for API keys

In episode 5 of my Keep in Touch podcast I shared some thoughts on how I currently think about protecting credentials, API keys, and secrets (summarised as keys for the rest of the post) for 1st and 3rd party services and APIs. This blog post is a recap of those ideas and also a call for feedback and input from you.

The risks

The problem I am talking about addressing, is related to the fact that many applications embed keys in their binaries. These keys are required to authenticate (and authorise) the app, the user, or both with remote services. These services could be public or private APIs. Similar considerations apply if these APIs are 1st party or 3rd party.

If these keys are bundled with the app, a nefarious attacker could extract them and then impersonate the developer.

It’s not my intention to teach bad actors how to execute their plans, but I do want to give a few examples of some attack vectors that could lead to sensitive information falling in the wrong hands:

  • the nightmare scenario: the attacker could run a man-in-the-middle attack by running a WiFi hotspot or could be operating one of the nodes on the internet between the device and the APIs the app connects to
  • the easier than you’d think scenario: the attacker could run an on-device proxy (such as the brilliant Charles for iOS app that I use daily for non-nefarious reasons), and monitor all traffic
  • the attacker could grab the app binary (ie. apk or ipa) and do a string search for key-like strings
    Any of the above could lead to the attacker obtaining the keys that the app uses to authenticate itself against remote servers. Once they get these keys they can start impersonating the app and its users.

The hypothesis

I believe that by not including any keys in the app’s binary and by provisioning these credentials only via a channel owned by the operating system that uses SSL pinning, the risks mentioned above can be reduced or even avoided.

SSL pinning is essential in order to prevent an attacker from inspecting the traffic between the client app and the remote endpoints.

Animated GIF showing the way keys can be securely transmitted from cloud to app to server. This flow is described in detail below

This animation attempts to illustrate the approach I am suggesting:

  1. Provision the app without any keys
  2. Attempt to detect if the app is running on a jailbroken / rooted device, and bail if that is the case
  3. Upload the necessary keys to the Trusted Cloud provided by the Host operating system (i.e. CloudKit for iOS apps) using another app (i.e. console, browser, etc)
  4. Enforce read-only access to these keys for the client app
  5. Upon (first) launch, fetch the keys from the Trusted Cloud
  6. If the keys must be stored, only store them in a keychain or in a secure enclave
  7. Use the keys to communicate with the Server using an SSL pinned connection
  8. Should the keys become compromised, they should be replaced, and the client apps should naturally fetch the new keys. For this reason, getting the new keys should not require the previous keys.

The steps above rely on the fact that the mobile OS provides a cloud service that uses SSL pinning in order to communicate to the client apps. Without it, there cannot be a secure key provisioning mechanism and the entire flow falls apart.

The checklist

Often times the security considerations come in “late” or “after the fact”. To assess the state of affairs, and to add more protection going forward, I would go over the checklist below:

  • Limit the number of people who have access to the credentials. Replace the credentials when these people leave the job.
  • Never embed the keys in the codebase
  • Never grant the build (or distribution) servers access to the keys
  • Only trust the cloud service that belongs to the platform vendor for your app (i.e. CloudKit for iOS apps, Firebase for Android apps.)
  • Avoid storing the keys anywhere (on the device) unless really necessary
  • If the keys must be stored, then the only acceptable place is the Keychain
  • Avoid bundling black-box libraries. If the libraries use networking, inspect all networking traffic
  • Do not use a 3rd party networking library unless absolutely necessary. Always check the source code of such libraries
  • Never be the largest consumer of any one technology, framework, or library
  • Only load the keys at the code level that really needs them. Do not pass them through the business layer, particularly if there are 3rd party analytics or logging libraries bundled with the app
  • Obfuscate the code and avoid obvious naming strategies for the keys
  • Check the app’s signature / hash or anything else similar that guarantees that the binary has not been tampered with
  • Be mindful of jailbroken or rooted devices but never change the code in order to support them
  • Do a quid-pro-quo vulnerability analysis with a trusted partner (make sure dinner or beer is something at stake if an issue is found)

If you have more to add to this list, I would love to hear from you!

Closing comments

I think of myself as a security minded person, but I am by no means an expert. I offer no guarantees that implementing the steps above is going to remove or prevent any security related problems for a system I have not seen before, but, based on my current knowledge, I do believe it is the closest thing to a “borderline bulletproof” approach to securing keys and credentials that native apps use.

Lastly, I sincerely hope that, if you read this and have identified a flaw in my reasoning, or if you can spot an oversight, you will share with me (ideally with a solution in tow) so I can update the article.

The free and easy way to start a Podcast

Setting up a Podcast in 2019 can be fast, free, and painless. More importantly, the distribution and maintenance of the show can be (almost) fully automated. This post covers the steps I took to launch KeepInTouch.fm together with my co-host, Todd.

MVP – Minimum Viable Podcast

  • First we decided what our show is about. Keep in Touch covers topics from two main areas: Apple/Google tech platforms, and raising kids
  • To solve the hosting and publishing of the show we set up an account on Anchor.fm
  • Lastly, we recorded and published the show

That’s could’ve been the proverbial it, but since both Todd and I are tech people, we were not satisfied, yet. Why not? Because of the details…

Past the basics

We wanted the show to have a home that we could customise, personalise. We also wanted to be able to understand and interact with our audience. To achieve this we made did a few more things:

  • We put a little effort in the show artwork, we created chapters for the shows (chapter artwork and web links when appropriate), and we collected and published thorough show notes.
  • We recorded and edited the audio outside Anchor, and only published the mastered audio. It’s not perfect but it’s definitely less *rough*.
  • We bought a domain and we set up a website: KeepInTouch.fm.
  • We set up a Twitter account: @KeepInTouchFM.
  • We set up a vanity Google Alert for our show title and website.
  • Speaking of vanity, we created a Chartable.com account to keep an eye on how the show is doing in the charts (we were #7 in the Educational Technology category at one point!).
  • We transferred the ownership of the Apple Podcasts and Spotify feeds.
  • We set up the Stitcher and TuneIn feeds ourselves.
  • We integrated the podcast RSS feed with our new website: once we publish a show, a corresponding blog post gets created (almost) auto-magically.

Some of these enhancements will be the subject of future blog posts.

Things we learned

  • Apple Podcasts took about five days to process Anchor’s request to list our show.
  • Google Podcasts approved the show almost immediately but took about two weeks to actually make it available to listeners.
  • PocketCasts picked up the show immediately (most likely due to an integration between them an Anchor).
  • Anchor didn’t seem to get the show listed in TuneIn so we had to list add show manually.
  • Anchor doesn’t actually support all the podcasting networks.
  • Hosting the show’s website on GitHub pages was straightforward but did have some limitations. We forked Jekyll-Import to add support to the Jekyll RSS importer for Podcast RSS feeds, so we needed a home on GitHub. Hosting the website itself on GitHub made sense since Git enables a simple way to publish new episodes / blog posts.

Costs

  • Hosting and publishing the show: Free.
  • Hosting the website: Free.
  • Having a custom domain name: same cost as for any other type of website.
  • Podcast recording and editing tools: Free (not really, since we decided to use our own microphones and Digital Audio Workstation).
  • Time required to record, edit, and publish the show: 1 hour for the recording, 4 hours for editing (takes less and less each time), 30 minutes for packaging and publishing.

We are four episodes in, and we are having a lot of fun. I hope you will give our show a listen and let us know what you think. Keep in touch by subscribing on Apple Podcasts or Google Podcasts.

Apple Wishlist from a New Zealand Customer

I live in Wellington, New Zealand and I own a truckload of Apple products. This is my wishlist of things I wish Apple would start doing.

iPhone & iPad

  • Visual Voicemail. I get that it may be up to the telcos, but I’d love to know that lots of pressure is being put on them to add support for this feature.
  • TV app
  • #images support for iMessage when the preferred language is Te Reo.

Apple Watch

  • LTE. Again, I realise it’s probably our telcos being slow to update their tech stack, but I wonder if they get the same lead time as their Australian counterparts.

Apple TV

  • TV app. Once you use it, it’s hard to go back to another interaction paradigm.
  • Siri support. Guess what, Siri understands us even when we use an Australian Apple Id and a cheap VPN. How come we have Siri on iOS, and watchOS, but not on tvOS? Even Siri on macOS works…

HomePod

  • Surely they know we use the same plug and voltage?!

Grab bag

  • Apple News. I am a registered Apple News Publisher, I can see Apple News in the Today View, so why can’t we have the News app?!
  • Public Transit support in Maps (thanks for Flyover, though).
  • Ability to purchase TV Shows.
  • … an Apple Store. Sending Macs and iOS devices to Sydney for repairs is super painful and not very well aligned with the Apple Green strategy. Authorised repair agents often can’t help (e.g Apple Watch is a no go).

What have I missed? What’s on your list? Head off to twitter to tell me how naïve I am.

A Recommendation for the Air New Zealand Customer Carbon Offsetting Programme

Air New Zealand has a Carbon Offset programme and that’s a really good thing. I wish it was more attractive to flyers, though. If you don’t normally offset your flight’s carbon footprint, I’m curious to hear if the changes I propose below would make you more interested in participating in this programme.

At KiwiFoo this year I spoke to a few smart people and asked them if they offset their carbon footprint when flying Air NZ. People looked away, shrugged, and shook their heads. When asked why, their answers were a variation around the same theme: it felt futile, and a bit of a waste of time and money.

The rest of this blog post details how I believe this programme can be rejuvenated. I believe more people would participate in the programme if they felt appreciated and rewarded.

Real benefits

People are asked to spend money in order to offset their flights. There is even a calculator for that.

The offset cost for a return flight from Wellington to Auckland, as far as I know, can be as low as $2.49.

Wellington to Auckland Carbon Offset Cost $2.49 In return for that, what you get is just a good feeling. And that should be enough. But it’s not in our human nature for an anonymous good gesture like that to become the norm. What humans need is rewards, or, as we like to call it nowadays, a strong value proposition.

What if, upon paying to offset the carbon emissions, flyers get the following in return:

  1. A bag tag (or an insert in the vein of the orange priority tag that Star Alliance Gold members receive) that makes the bag stand out. How about a Pohutukawa insert that flyers can pick up somewhere near the check-in machines? This would be very similar to how Electric Vehicles often carry a blue badge.
  2. Luggage priority (value!). That would require the creation of a middle tier in luggage processing. Orange priority tags > Pohutukawa tags > Regular.
  3. Upweight for OneUp.  Currently, these are the upweight tiers: Elite – 50%, Gold – 30%, Silver – 10%. What if Pohutukawa was 5%?
  4. A creative, community designed, visual representation of the flyer’s aggregate contribution on the Air New Zealand website and apps.

Peer pressure

When other travellers see repeatedly the Pohutukawa Bag Tag insert, they may become curious with regards to what it represents. They may even learn more about the programme, and they may be encouraged to try it.

For each flight, let all the flyers see how much of the carbon footprint has been offset. Visually, that could be as simple as colouring in an Air NZ plane. Better still, maybe there is a way to produce a heat-map of the plane showcasing where the carbon offset spending occurred.

When there is a positive offset (ie. more carbon was offset than produced), then maybe there can be a new form of reward for the fliers who contributed (e.g. discount on the carbon offset cost of their next flight).

Closing notes

I’m secretly hoping somebody from Air New Zealand comes across this blog post and it inspires them to look at the Carbon Offset Programme once again. Is it producing the results that they were hoping it would? Are there ways to make it more attractive to flyers and to encourage them to contribute? I am a Star Alliance Gold member, I fly a lot more than I’d like to, and I often forget that this programme exists.

Apple needs iMessage on Android

I believe Apple needs to build iMessage for Android. They have lots of reasons not to build it but I believe that have at least one really good reason to do it.

Apple has already acknowledged Android’s importance by building Apple Music for Android (I won’t count the Android to iPhone migration app). This was a sound business decision, the same was building iTunes for Windows was a necessary move. The sheer number of Android users will bring about more revenues and will help prevent services like Spotify from generating a lock-in effect for the hoards of people moving from Android to iOS.

iMessage is different, though. iMessage does not generate any profits (yet), and has simply been a value-ad for the iOS (and Mac) customers. They could have continued down this path, but something changed recently: Apple has doubled down on their fight for privacy. Tim Cook’s resolve and public appearances arguing against FBI’s request to build a backdoor in iOS is unprecedented. He even gave the first ever interview from his office on 1 Infinite Loop.

No other player in the space advertises privacy as a core product “feature”. Apple needs it not just because it is a differentiating factor, but because they truly believe this is the right thing to do for their customers.

The fact of the matter is that Apple’s customers interact with people on other platforms all the time, and not all the apps they use to communicate with their friends on non-Apple platforms are secure. Sure, WhatsApp provides end-to-end encryption, Telegram does too, and so do many other apps. But none of these apps are controlled by Apple.

Building iMessage for Android will give Apple the ability to tell its iPhone customers that all their communication with their family and friends can be secure.

There’s an argument to be made, that for this to be completely accurate, Apple would also need to build iMessage for the web.

A bonus reason (speculation), is that iMessage is one step away from becoming a transaction platform (much like WeChat). Person-to-person payments could be one such type of transaction. In order to be successful, such a product needs to be available on as many devices as possible, thus making Android impossible to ignore.

p.s. If iMessage is to be added to Android, then FaceTime will most likely be added, too.