Wednesday, September 3, 2014

Improving the security of mobiles and services

After the recent debacle where pictures has been leaked from Apple's iCloud, by using iBrute and EPPB to attack specific users iCloud acounts there is clearly a need to address weak security in synchronization protocols used by mobiles for backing up and synchronizing data to the cloud.

Since these apps, our built in services, on the phone relies on static information to identify and authenticate seamlessly it is relatively easy to reverse engineer the protocol and emulate an individual device. These apps and services operates on the user's behalf and can not rely on multi factor authentication (MFA) requiring user intevention.

I will here propose a solution based on a integrated chip (IC) for generating OTPs (one time passwords) to introduce some randomness to the identity information submitted from the mobile.

When the user installs and app or activates a service on the phone, the app/service registers itself as a OTP consumer to the mobile OS. The OS must be able to uniquely identify an app/service in order to prevent impersonation from other apps. No token should be required to store by the app. Most app developers are not security experts and will probably not be able to secure such a token properly.

When the app logs in to the remote service for the first time, an OTP sequence is set up in the onboard chip. The chip generates touples of passwords, one part as the actual password, and a second to use as salt for a hashing algorithm. The remote side must set up the same OTP sequence, and the process should be confirmed by the user who identifies with username, password and ideally a MFA token entered by the user. This could be a OTP generated by Google Authenticator or similar. Steve Gibsons SQRL will also be an excellent confirmation. This requires the user to create the account beforehand, or the app does this during first time login. Devices added to the account can be revoked access if they are stolen, and when devices are added the user is properly notified in a separate channel (e.g. email, SMS)

When the app or service want to communicate with the remote end this sequence will occur:
  1. App/service request OTP from IC
  2. IC generates OTP touple and hashes the first part using salt from the second part
  3. The hash is returned to the app (the app never sees the real OTP)
  4. The app supplies the hash value as part of communication setup process
  5. The remote side also generates same OTP touple as the mobile and calculates the hash
  6. Hashes are compared.
  7. A succesful compare allow for proceeding the operation.
 This will make it impossible to emulate a device by using static information. The hashing is there to obfuscate the original OTP, in order to make it even harder to guess the next password.

The proposed solution may also be used where the user is active, but as a added layer of security. Recently Tesla Motors announced that the iPhone could be used as a FOB (and probably Android/Windows devices later, guessing). If the setup process used the onboard screen of the car, scanning a QR code on the screen, the risk of illegitimate access and use of the car is minimized. This is probably just the beginning of use cases for mobiles giving access to valuable items, and security issues lies ahead.

This solution only help protect to use of a service from a mobile, not the content stored on the service providers storage. These will to varying degrees be vulnerable to other attacks, so don't put anything on a service providers storage that must absolutely not leak into the wrong hands.

This idea is free to use, but oh, I'm saving money for a Model S ;)

No comments: