Under The Bridge Under The Bridge

Tag: security
Mobile App Security: CryptoKit Your Critical Kit

Here’s a set of posts that you should make some time to read if you’re any kind of mobile developer, not because there’s anything strikingly new here — in fact, hopefully there isn’t! — but just to be sure that you have a good basic grounding in 2020’s app security requirements, both for iOS and that other platform:

Mobile App Security: Best Practices on Android & iOS

Android App Security: Best Practices

iOS App Security: Best Practices

Smartphone apps are the center of most peoples’ technology usage. They deal with a lot of private and sensitive user data like your personal health information or banking information. Protecting this data as well as possible is heavily important and the topic of this article.

In this article, we focus on iOS App Security. We’ll show you concrete techniques for making your iOS apps more secure. Our best practices cover means for securely storing data as well as sending & receiving data over the network. You’ll see why it is so hard to get security right and how you can improve your app security by using services from Apple and other providers…

Most of this hasn’t changed much since the last time we did any posts about security here 8-10 years ago, so it should pretty much be a refresher for you, with the possible exception of what you might have overlooked with all that actually exciting stuff out of last year’s WWDC:

Apple’s CryptoKit is a new API that was introduced in iOS 13 and provides lower-level APIs to perform cryptographic operations or implement security protocols.

CryptoKit is based on top of more lower-level APIs. They were available before but introduced additional risk factors since developers often used them in a wrong way.

CryptoKit also allows you to use the SecureEnclave to get cryptographically safe functions that are performant and optimized for the device’s hardware…

So that’s pretty much a solid win all around there, isn’t it? Next time you’re touching crypto stuff, do yourself and the rest of the ecosystem a favor and adopt it! Isn’t a great deal of resources out there, but here’s what we’ve noticed:

WWDC session 709: Cryptography and Your Apps and associated playground

Discover the New Apple CryptoKit Framework

Common Cryptographic Operations With Cryptokit

When CryptoKit is not Enough

CryptoKit and the Secure Enclave

Particularly that last one, if you want really really secure:

For us developers, how the Secure Enclave deals with biometrics is not the most exciting part about it, because we cannot query it directly. Even our biometric APIs are constrained and they are fully handled by the system, so we cannot really do much work on top of that. The real exciting thing is that we as developers can leverage the Secure Enclave to encrypt and decrypt information with keys that are specific to a specific setup in a specific device…

And that’s about it for state of the art security. For your non-up-to-date users, their recommendation is

If you want to support older iOS versions you can use those lower-level APIs or use well known open-source third-party libraries like CryptoSwift.

That one does look pretty much the most comprehensive to us at the moment as well, yep; but there’s a wide variety of libaries in this space with varying focuses, so we’ll just point you at the currently best maintained curated lists with applicable sections — those links should stay relevant for another decade we trust!

Awesome iOS: Security

Awesome Swift: Security

UPDATES:

Introducing Swift Crypto

Swift Crypto is a new Swift package that brings the fantastic APIs of Apple CryptoKit to the wider Swift community. This will allow Swift developers, regardless of the platform on which they deploy their applications, to access these APIs for a common set of cryptographic operations…

How To Be Evil: Guide To Violating iOS User Privacy

Remember last year there was this fuss about apps harvesting your location data and selling it? 

The curious case of Accuweather and other apps selling our location data

Well, if you were doing that, the news today is Apple’s not going to put up with it, apparently:

Apple finally decided to start enforcing guidelines on selling location data

So the question that’s no doubt on your mind today then, Dear Evil™ Readers, is: What ways are left to be Evil™ to my users?

As it happens, and this is just the strangest thing, since fastlane was purchased by Google, it seems that the main thing @KrauseFx has been working on is compiling a Manual Of How To Be Evil™:

Privacy research

I work on privacy research projects for the iOS platform in my free time. Those projects are in no way affiliated with my work or my employer…

Definitely not, we’d never suspect that! It’s not as if that employer has repeatedly needed to pay out tens of millions of dollars for privacy breaches…

oh, wait.

All kidding aside, you probably want to read through the collection of articles on that page to be aware of things that could happen to you and how to protect against them, even if you’re not planning to Use Them For Evil™ — 

— or, as may happen, inadvertently. No, seriously. In iOS Privacy: watch.user, that bit about

take pictures and videos without telling you
upload the pictures/videos it takes immediately

Yeah, that was one of the more memorable bug reports we’ve had, back in this kinda-Vine kinda-Instagram thing we worked on back in the day:

QA: Troll, why is your code uploading pictures of my girlfriend?

TROLL: Dude, my code is not uploading pictures of your girlfriend.

QA: *holds up device*

TROLL: Huh. OK … how is my code uploading pictures of your girlfriend?

(Lesson Learned there: even if you use timers only for photo countdowns, your app should listen for applicationSignificantTimeChange, or strange things may happen.)

But the one that we actually want to draw your attention today that you definitely need to read is how to protect your app from other people using it for Evil™:

Trusting third party SDKs

Third-party SDKs can often easily be modified while you download them! Using a simple person-in-the-middle attack, anyone in the same network can insert malicious code into the library, and with that into your application, as a result running in your user’s pockets.

31% of the most popular closed-source iOS SDKs are vulnerable to this attack, as well as a total of 623 libraries on CocoaPods…

… What’s the worst that a malicious SDK could do?

  • Steal sensitive user data, basically add a keylogger for your app, and record every tap
  • Steal keys and user’s credentials
  • Access the user’s historic location data and sell it to third parties
  • Show phishing pop-ups for iCloud, or other login credentials
  • Take pictures in the background without telling the user

The attack described here shows how an attacker can use your mobile app to steal sensitive user data…

And as an aid to that, there’s a repo set up now:

Trusting SDKs – HTTPs

A crowd-sourced list of SDKs and how they protect their downloads with HTTPs.

Based on the Trusting SDKs post by @KrauseFx this repo contains a crowd-sourced list of SDKs and their status when it comes to security when downloading the binary or source code…

Since you are responsible for your app’s behaviour whether the source of Evil™ is your code or your SDKs’ code, it behooves you considerably to acquaint yourself with the risks here — so read up thoroughly, and good luck with not being the next privacy-violating headline!

Designing For Privacy

So as you’ve no doubt heard by now from all over, the furor du jour is that apps have a habit of broadcasting your contact data. What, you mean that stuff we put on a radio station carried in our pocket may turn out somewhat less than totally private? OMG, the shock. Welcome to the global village, folks, enjoy your stay!

All cynicism aside, there are a couple takeaways from this pother for the app developer who wants to avoid negative attention, even if you can manage to handle it as adroitly as the Path people did:

1. Be aware of Apple’s full disclosure requirements:

17.1 Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used

And also of the requirements with any other services like Facebook, Twitter et al. you may be using: privacychoice.org has a good resource list for starters.

2. Go to at least a little bit of effort to make your app not the easiest avenue to nick user info from. A discussion suitable even for the nontechnical client to get their head around when you’re discussing architecture choices is from the inimitable Matt Legend Gemmell here:

Hashing for privacy in social apps

If the Path use case matches yours, why yes this clever spark has provided a handy AddressBook wrapper for you:

HashContacts: an iOS Address Book Wrapper

… It turns out, however, that it is trivially easy to wrap the Apple provided Address Book frameworks in a way that safe guards the data by:

  • Asking for user permission before opening the address book
  • Then hashing the desired data so that it is kept private.

After only 3 hours of effort I wrote a class (available in github) that provides both of these functions in an easily dropped-in fashion…

If your needs are a little more complex, the nice Karelia people have in their wide ranging open source collection

KSCrypto – Simple wrapper for sha1 hashing files

which shows you how to get a digest on input streams, from NSData or an NSURL’s contents or whatever, using the SHA-1 functions from the Common Crypto API which is part of libSystem. And is almost certainly good enough for you. But note the discussion here about MD5 being considered broken and SHA-2 considered current best practice before you make any irrevocable algorithmic decisions!