Tag Archives: Android

“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:

Provision the app without any keys
Attempt to detect if the app is running on a jailbroken / rooted device, and bail if that is the case
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)
Enforce read-only access to these keys for the client app
Upon (first) launch, fetch the keys from the Trusted Cloud
If the keys must be stored, only store them in a keychain or in a secure enclave
Use the keys to communicate with the Server using an SSL pinned connection
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.

Android Fragmentation – Just the way I like it

The 6th instalment of the Wellington Android Meetup took place today. I decided not to write about the content (I wouldn’t do justice to the presenters, and the audience contributed so much content, that I’d surely forget to mention something important), instead I wish to write about just how “fragmented” Android is … in Wellington, New Zealand.

Four talks

We had four speakers. Two men: Matt and Lucas; and two women: Jayna and Leonie. That was not planned, it just happened.

We had two fairly technical presentations that encouraged us to improve our technical chops and solve problems in more beautiful ways, and two that challenged us to think about what we like, what brings us joy, and what we are prepared to do from the goodness of our hearts.

People in the room

I glanced around the room and I was so happy to see how diverse it was. So many skin colours, genders, ethnicities, and ages!

In the room we had students, unemployed folks, business owners, developers, designers, testers, and even Windows Phone developers! There were people working for startups and people working for organisations with 500+ employees!

Lots of people at the android meetup, more students than usual (Yay!) and a good few #io15Wellington shirts pic.twitter.com/5iSF9oTt2l

— Kate Henderson (@Mistyepd) July 30, 2015

There were women. Not just sitting on chairs but engaging in the discussions. Driving them and asking the tough questions. Challenging the speakers and the audience. Recommending better ways to do things. As it should be!

I bring this up because I think back of where we started. I looked at some old photos I took and I struggle to find the women. I looked at the GDG Wellington reports I sent, and I blush seeing a mere two women attending one of the early sessions! Today, almost 20% of the audience were women!

But we are not stopping here. Tonight Lucas announced that we are planning a GDG Dev Fest W. The plan is to create a safe place for an evening, a day, or a weekend, where women can come and learn about technology without fearing that they may get laughed at, looked at in a condescending way, interrupted or ignored. Get in touch with Lucas or with myself if you want to help.

Fragmented

The Android community in Wellington is fragmented in the best possible way. This diversity makes the meetings more interesting, the points of view more diverse and more relevant.

I was the proud host of tonight’s gathering. It this kind of fragmentation that keeps me going, that motivates me to try harder, that makes me proud to be a small part of this incredible community. Our group now has more than 200 members, so I am hopeful that we have not seen the best of what this incredible bunch of people have to offer!

Thanks to everyone who attended.

Testing is organised skepticism

You can let all the different types of software testing scare you out of your pants or you can look at the funny side of testing.

These quotes could be a starting point… I shared them with the amazing Android folks here in Wellington as part of the fourth edition of our Android Meetup.

Thanks to the lovely people at Powershop for hosting the evening, for the food, and for making this happen.

Wellington Android Meetup – The first edition

It’s true. The Android developer community in Wellington is strong and mature, if tonight’s first Android Meetup is anything to go by.

The setup

Android Meetup Attendees

Just over 30 people took part in the first (of hopefully many more to come) Meetup that I was proud to facilitate and host together with the rest of the Trade Me Mobile team at our Market Lane office. We will try to make sure this becomes a regular event, especially now that the GDG Wellington was created.

The turn out was fantastic (we had to supplement the available slots at the last-minute). The show of hands confirmed that the majority of attendees were developers but we also had designers, testers and business folk. This diversity definitely helped during the Q&A sessions…

The talks

The theme of the evening was Material Design and the agenda was simple. I gave a quick intro, then we kicked off properly with a presentation by Matthew Shearer (our Lead Android developer) about the challenges that we face at Trade Me when tacking Material Design in our app, followed by an interesting Q&A, then the spotlight was given to Glenn Parker (Xero) who showed off a few ideas/early mocks for their product. Other people in the room mentioned that Material Design was high up on their TODO list but they just haven’t gotten around to it.

The evening continued with food and drinks followed by an open discussion around the future of this group.

Where to from here?

We are very keen for this event to not be owned by one organisation. Instead, we’ll aim to put in place a roster so that other teams around town can host it and offer more diversity not just in terms of venues but also in terms of hours. We even floated the idea of doing it over lunch sometime to cater for those with young kids or who have engagements in the evenings…

Happiness Survey

As expected, the attendees behaved really well and communicated freely. There was no awkward job/hiring talk, nor any immature comments of any kind.

Toward the end of the event we brainstormed a few ideas for future sessions. We’ll vote on the group and we will decide what we will talk about next time (late January or early February). As this picture shows, people found the event valuable for the time they invested (2 hours) so I will call it a success!

DevMob 2014 – Epilogue

This year’s DevMob was different compared to all the previous DevMobs: there was tangible equilibrium between iOS and Android, with both platforms showing maturity in terms of tools, design metaphors and developer attention.

Sponsors & Venue

DevMob 2014 – Wellington

This (un)unconference¹ would not have been possible without support from the sponsors: Microsoft, Alphero, Xero, Powershop, CactusLab, JSA, and 3 Months.

This year, the swag was particularly nice (thanks to the Alphero team). The sponsors also contributed with very interesting talks, availability and engagement throughout the weekend, and a wicked Lego Death Star draw!

It was Wellington’s turn to host, and the chosen venue was Samuel Marsden Collegiate School. I give it the thumbs up: the food was great, there were plenty of rooms (and each had a projector), and we were even allowed to use the amphitheatre.

An evolving conference

Over the years, the conference evolved from being focused on iOS only, to sharing the spotlight between iOS and Android. This reflects the marketshare and the user base of the two platforms, and the ever growing number of developers interested in them. As one of the attendees who hasn’t missed a single iteration of this event, I’m happy to see such organic growth. It’s also good to see that the Microsoft folk have not given up, and keep attending these gatherings and contributing with incredibly useful insights (Azure being one such example).

My observation (potentially wrong) is that, year after year, the iOS talks have become a bit more abstract and more high level (a good incentive for me to return). At the same time, the audience has managed to keep some practical sessions on the board:

the show-and-tell sessions took a UI/UX spin
the demos contained products that are more and more polished (even though their authors consider them “rough”)
the live coding sessions were focused on concepts that a newcomer would probably struggle to fully understand, but would still find valuable

If a couple of years ago Julius was struggling² to attract a handful of devs to take part in a blue-sky discussion, this year all the Android sessions had full rooms. Refreshingly, Google’s Material Design was at the centre of most discussions. The tools and libraries that people spoke about covered everything you can possibly think of: from analytics, networking, and storage, all the way to dependency injection and reactive programming.

I’m sad to see that Android developers still have to battle with basic things such as networking and resource loading. Michael Rueger from Xero gave a very good talk about the way their app tackles this area. I definitely think his talk should be shared at one of the next Wellington Android Development Meetups. While I’m talking about Xero, Glenn Parker was particularly active and even shared some interesting work they have underway. The Poweshop folks also contributed a great amount, confirming that Wellington is the place to be for Android developers. Not to be outdone, I shared as much as I could about the way that we do things at Trade Me.

No doubt about it, Android is a first class citizen and there’s some outstanding work being done in this space.

New in 2014

Back in 2009 when Jade Software launched DevMob (under the NZiDev moniker), the questions that people used to ask were along the lines of “how do I code, test, deploy, market my app, all at the same time?”. After just 5 editions, this question has transformed into “how do I run a distributed team? how do we collaborate with designers and testers? how do you manage an app’s backlog?”.

This year, I believe two themes were new to the stage: mobile development at scale, and an in-depth look at how to build mobile software. The gimmicky apps were pretty much absent, confirming that the mobile gold rush is well and truly over. For a change, Layton and Karl did not have to too many questions on how to build the next million dollar app.

Scale

Surprisingly, managing scale was probably one of the most talked about things this year. So much so that the group ended up creating a follow-up session after Luke Gumbley‘s “Backlog management / Feature planning” talk.

Team building, maintaining happiness, and dealing with ownership, all got tackled by the audience. The information flowed freely and openly thanks to the trusted environment that makes so many people return to this event year after year.

Depth

It wasn’t just the management side of things that was new this year. The sessions went deeper into the product life-cycle with topics such as API design, security, functional testing and mocking, UX, continuous integration and more.

I was happy to see large development houses (Cactuslab, JSA, Powershop, Trade Me, Vend, Xero, etc) share intimate details about how they tackle many aspects of the SDLC. The fact that non-coding topics permeated DevMob 2014 is encouraging for future iterations of this (un)conference.

Until next time

I missed out on the socialising that traditionally happens after the first day of the conference. I suppose that’s part of the deal when the event is hosted in one’s home town.

Many thanks to the hosts Nat, Janine, Tanya, Julie and everyone who contributed to making this event a success.

If I got anything wrong, or if you wish to pass any feedback, you can reach me on twitter.

Notes:
¹ To learn more about (un)conferences you can visit Nat’s website, buy this Kindle book, or, my favourite option, just take part in one!
² Julius is no longer struggling to attract new people to his talks. He now just needs to find a way to keep Sam awake. (Okay, this photo is cropped and you can’t see the 30 people sitting behind Sam, but it’s funny nonetheless.)

Julius teaches Sam Material Design

Smart Lock – I called it

In my Log In post I was hoping that One day, smarter Log In pages would be able to Trust my location. A mere 2 days later, Google announces Smart Lock (as part of Google Play Services 6.5 and Lollipop).

The Verge provides a good translation of what this will mean to regular users.

In a nutshell, you can now define a location as safe, and then your Lollipop phone won’t ask you to unlock it when you’re nearby—it’ll just let you straight in.

Nick Parfene

Technology. Community