Trust is everything. Mobiconf 2018 presentation, on how to use iOS features to protect confidentiality of your users' data.

1. SECURITY? CHECK!
Don’t let your app hacked.

2. TOMEK CEJNER

3. @TOMEKCEJNER

4. We’re software company, not an agency :)
iOS engineer / mobile architect
I will talk about what’s important when building a software product.

5. TRUST
I think the most important is not a scale, performance, but a trust.
When we deal with customer’s data, they trust us.
It’s especially important in the age of GDPR.
Above all it’s good to know about security features of iOS when you deal with law enforcement, especially in time of unrest.

6. If something can harm your business, it will be security leak.
It’s easy to loose a trust by a data breach, and hard to regain.
Some customers may quickly jump the ship.

8. MOTIVATORS
INTERNAL
EXTERNAL
Where are drivers of your care about security?
Inside - you care about your users.
Outside - you care about prospective contract and allow external audit. PREPARE.

9. NETWORK COMMUNICATION
DATA STORE
SECRETS
Worry not, iOS is our friend here. It comes with technologies to protect…

10. NETWORK COMMUNICATION SECURITY

11. ATS
ATS

12. APP
TRANSPORT
SECURITY
Stands for A… T… S…
Introduced in iOS 9, enforces certain level of security at transport layer.

13. HTTPS
TRUSTED CERTIFICATE
TLS 1.2
…
It does by putting some restrictions, like using encrypted channel.
Trusted Certificates - the other party of connection is verified.
TLS in a version considered safe (at least for now).
Previous were vulnerable to number of attacks.

14. ATS EXCEPTIONS
GLOBALLY
PER DOMAIN
NSAllowArbitraryLoads
NSExceptionAllowsInsecureHTTPLoads
Some sites may be incompatible with ATS, and there’s way to add exceptions.
You can either set them for all application or specific domain.
AllowArbitraryLoads - disable all ATS features. Should trigger review and you have to testify.
AllowInsecureHTTPLoads - just enables HTTP, e.g. weather charts from state agency.

15. ATS EXCEPTIONS IN RELEASED BINARY
Even though apple says exception trigger additional review, loosening protection too much may get unnoticed.
Next slide: MITM

16. MAN-IN-THE-MIDDLE
One of the basic form of attacking network apps.

17. Here’s a hacker. a malicious person willing to tap into communication.

18. No, maybe that one. This is real pro - wears a mask, he knows that FBI may be watching thru the webcam.

19. So we have app communicating with backend and that is good.

20. Imagine malicious actor trying to intercept communication.
By setting up free wifi or hacking into network you are in.

21. FAKE
1. Certificate will do the job, right? It is issued by trusted organization, bound to server.
2. Attacker prepares forged cert, which (in normal conditions) has to be self-signed. The app will alert that something is wrong. We cannot trust that fake cert.
3. Not always, he may install CA Cert into device’s trust store under attack. That makes forged certificate trusted and app continues to work

22. 📌
SSL CERTIFICATE PINNING
What we can do?

23. FAKE
We can store the server certificate in the app bundle and compare with the one on the server when connection is established.

24. SSL CERTIFICATE PINNING
AGAINST CERTIFICATE
AGAINST PUBLIC KEY
It does not solve the weakness of the certificate authorities certificate signing process. But minimize the window of opportunity.
Against CERT: need to publish new version of app when new cert is available; old versions stop working. Overlap needed.
Against Public key: not affected by frequently rotating certificates (provided all are signed with the same key)

25. COMMUNICATION
PROCESS
Pinning may be tricky.
* Establish a process: system engineers need to notify mobile devs that certificate is about to expire.
* Reminder of certificate expiring soon.
* Key pinning - make sure key will not change.

26. PER-APP VPN
Additional layer of safety.
If transport security is still a concern, consider this.
It’s enterprise feature and requires additional MDM software.
iOS 9+
No development required.

27. DATA STORE SECURITY
Everything on device is encrypted. Apple built pretty sophisticated data protection based on cryptography and it is in software and hardware.

28. File Metadata
File Contents
File Key
Filesystem Key
Filesystem key offers no security, is useful for remote wipe.

29. File Metadata
File Contents
File Key
Filesystem Key
Class Key
Passcode Key
Hardware Key
Hardware key based on UID.
Passcode provides entropy. Use Touch ID/Face ID to use better passcodes.
With iOS 8 all encryption keys are on device. Apple can’t extract data, they have no advantage.
80 ms every check.
6-alphanumeric - 5 years brute force.

30. PROTECTION CLASSES
NSFileProtectionComplete
NSFileProtectionCompleteUnlessOpen
NSFileProtectionCompleteUntilFirstUserAuthentication *
NSFileProtectionNone
Complete: keys alive only when device is unlocked. After locking is discarded in 10secs.
CompleteUnlessOpen: asymmetrical crypto lets app access the file, and key is discarded when closed.
CompleteUntilFirstAuth.: The key is not removed when device is locked and lives until reboot. If expected stolen or seized device, you should turn it off.
None: only filesystem keys, used for remote wipe

31. DELEGATE METHODS
UIApplicationDelegate
applicationProtectedDataWillBecomeUnavailable()
applicationProtectedDataDidBecomeAvailable()
You can also be notified.
When device is about to be locked the notification is called. You can release file handles.
And opposite, when device has been unlocked.

32. DOCUMENTS FOLDER
IS STILL BACKED UP
If you have access to backup, or backups are in iCloud. Password verification takes 1 minute.

33. CACHES
NSURLIsExcludedFromBackupKey
Caches is the place, but can be cleared by iOS anytime.
Another option is to use NSURLIsExcluded… resource value to exclude specific files from backup.

34. SECRETS
Yes, apps have secrets, not THAT secrets, but you may want to store confidential information.

35. 🤫

36. KEYCHAIN
Keychain is a great place to store small amounts of sensitive data securely, like passwords, keys.
The API is low-level. And I mean low-level.

37. OSStatus SecItemAdd(CFDictionaryRef attributes,
CFTypeRef _Nullable *result);
OSStatus SecItemUpdate(CFDictionaryRef query,
CFDictionaryRef attributesToUpdate);
OSStatus SecItemDelete(CFDictionaryRef query);
OSStatus SecItemCopyMatching(CFDictionaryRef query,
CFTypeRef _Nullable *result);
The procedural API is very verbose and you want a wrapper. There are 153 of them.
The keychain is a database.

38. let dictionary = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrAccount as String: "user124",
kSecValueData as String: “P@ssW0rd",
kSecAttrService as String: “AwesomeApp”,
kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlocked
] as [String:Any]
The Keychain API is very verbose and flexible.
Almost all functions need passing a dictionary as a parameter, both for querying and for setting a value.

39. kSecAttrAccessibleWhenUnlocked *
kSecAttrAccessibleAfterFirstUnlock
kSecAttrAccessibleAlways
kSecAttrAccessibleWhenPasscodeSet
when unlocked: when device is unlocked, default, strongest.
after first: when is unlocked and stays until reboot - if need access in background
always: when locked or not - DO NOT USE
passcode set: only possible when passcode is set; removing passcode removes items

40. kSecAttrAccessibleWhenUnlockedThisDeviceOnly
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
kSecAttrAccessibleAlwaysThisDeviceOnly
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
Following suffixes guarantee that the items WILL RESTORE ONLY TO SAME DEVICE.

41. STORING USER CREDENTIALS

43. USE OAUTH 2.0 INSTEAD

44. AUTHORIZATION CODE GRANT
The App
Authorization Server
Resource Server
Authorization request
Authorization Code
Call API with Access Token
Data response
Web Browser
Redirect to
Requests Access Token
Provides Access Token
Such session management is safer.
Elaborate but guarantees:
1. App does not know password, never sees the credentials.
2. User can trust, because they enter credentials on trusted website.
3. You can expire the token at any time no need to reset password
4. Control apps

45. USER CREDENTIALS GRANT
The App
Authorization Server
Resource Server
Sends Login + Password
Access Token
Call API with Access Token
Data response
For 1st party apps.

46. ACCESS TOKEN
HIJACKED
If the communication channel is compromised.
Or device keychain is compromised.
Or you were careless and did not use keychain.

47. REFRESH TOKENS
The App Authorization ServerResource Server
Makes API Call
Good!
Sends Refresh Token
Returns new Access and
Refresh tokens
Makes API Call
Oh. Token expired.
You can make hackers life harder by introducing refresh tokens.

48. LOCAL AUTHENTICATION
PASSCODE
TOUCH ID
FACE ID

49. CODE EXAMPLE
authenticationContext.evaluatePolicy(
.deviceOwnerAuthenticationWithBiometrics,
localizedReason: "Knock, knock",
reply: { [unowned self] (success, error) -> Void in
if (success) {
// Fingerprint recognized
// Go to view controller
self.navigateToAuthenticatedViewController()
} else {
// Check if there is an error
if let error = error {
let message = self.errorMessageForLAErrorCode(error.code)
self.showAlertViewAfterEvaluatingPolicyWithMessage(message)
}
}
})

50. PROTECTED ACCESS
NOT EXACTLY
Hello, I am a startup, I ain’t doing that stuff.

51. I am doing photo sharing app for dogs.
What could go wrong?

52. But mind that, even in photo sharing app for dogs, you customers reputation may crush when faced data breach.

53. SECURITY BY OBSCURITY

54. Pro Tip:
USE CRYPTO TO PROTECT DATA
You can ask user to provide a password and use it as an encryption key.

55. CODE EXAMPLE 2
LA can work together with keychain, or in other words, access to keychain items can be controller by authentication.

56. CODE EXAMPLE 3
var error: NSError?
let access = SecAccessControlCreateWithFlags(NULL,
kSecAttrAccessibleWhenUnlocked,
kSecAccessControlUserPresence,
&error);
let dictionary = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrAccount as String: "user124",
kSecValueData as String: "P@aaW0rd",
kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlocked,
kSecAttrAccessControl: access
] as [String:Any]
You can specifically require biometrics or passcode, or just user presence.

57. IF YOU’RE PARANOID

58. LOGS

59. CUSTOM KEYBOARDS

60. SCREENSHOT WHEN GOING TO
BACKGROUND

61. CROSS-SITE SCRIPTING
Make sure the mobile stack is also sanitizing user input somewhere.

62. HOW DO I GET THERE?
How do I make my app secure.

63. DEFINE A THREAT MODEL
Who is the adversary. There is no absolute security.
Any app could be compromised when faced an attacker with enough skills, funding and time.

64. SECURITY AUDIT
HACK YOURSELF
ASK SOMEONE TO HACK YOU

65. OWASP MOBILE TOP 10
Open Web Application Security Project

66. OWASP MOBILE TOP 10
M1 - Improper platform usage
M2 - Insecure data storage
M3 - Insecure communication
M4 - Insecure authentication
M5 - Insufficient cryptography
M6 - Insecure authorization
M7 - Client code quality
M8 - Code tampering
M9 - Reverse engineering
M10 - Extraneous Functionality
List of RISKS.
LEISURE READ, AWARENESS DOCUMENT
Good FIRST STEP into culture of producing secure code.

67. CHECKLIST FOR MOBILE SECURITY
Does it make COMPREHENSIVE CHECKLIST?

68. NO

69. MOBILE APPLICATION SECURITY VERIFICATION STANDARD
https://github.com/OWASP/owasp-masvs
REQUIREMENTS
Covers: Authentication, Data storage, Network communication, Code quality

70. MASVS LAYERS
The MASVS defines two strict security verification levels (L1 and L2), as well a set of reverse engineering resiliency requirements (MASVS-R)
L1 - General
L2 - The apps which deal with sensitive data

71. SUMMARY

72. DON’T LET DOWN YOUR USERS

73. THANK YOU!