2

I have a mobile application (Android, iOS) and a server, which handles requests from the application.

It is easy to perform standard authentication using SSL, password and random token to authenticate the user.

However, I have no idea how to authenticate the mobile device AND the user. I need to prevent the user from using other devices then the one he used for the first time (for some very good reason).

The problem is I must expect the user will not cooperate. On contrary, he will probably try to use another device, but I have to stop him.

I think the SIM card must be the key to this problem. However, I cannot make any changes to SIM card itself (I cannot install any special SIM applet to the SIM). I can use only the features ANY SIM card provides.

Is there any possible solution?

Improve this question
2
  • 3
    I would try to re-think the requirements and possibly the implementation so that the user would Not want to use anything other than the first device. That is, assuming that the "very good reason" actually makes sense, which I am reluctant to blindly agree with
    – Purefan
    Sep 30, 2015 at 13:12
  • You need to include specifics about the platform that you are targeting. iOS or Android at a minimum?
    – Neil Smithline
    Sep 30, 2015 at 17:37

2 Answers 2

Reset to default
1

In mobile app -> server scenario, I like to have an approach for each of the following identity

  1. User Identity - i.e. person trying to initial transaction with your server
  2. Application Identity - application being used by user to perform the transaction
  3. Device Identity- the actual device being used.

Each of these are important part of the comprehensive identity management. In your case, device Identity is the focus. There are a lot of device specific information like SIM card ID, IMEI, UDID (in case of apple) that can be used to tie a specific device to a user. An alternate approach can be that at the time of initial registration of the device, you can generate a public and private key pair on that device. You can associate the public key with the user id on your server. Now, every time you initiate the session or perform transaction, you can use the private key to sign a token (e.g. JWT) and send it with request. As part of authentication/authorization process on server, you can validate the token received and match it with authenticated user id based on saved association.

In addition to that, I am assuming, you have good process in place to handle 1. Transfer of mobile device - people sell or give their devices away and new people want to use device to run your application (with or without device wipe). 2. Multiple users - people in same family may use the same device but different user id to perform transactions.

Improve this answer
2
  • Thank you for your opinions! However, I do not look for information how to identify device, yes, I could use SIM card ID or IMEI. I need to authenticate it - no attacker with his evil application should be able to pretend he is using the device on another device. Is there any way to do this?
    – vojta
    Oct 1, 2015 at 9:04
  • @vojta only if the device has an accessible trustable TPM. Otherwise you need to settle for standard asymmetric keys in the app data folder and let the device OS help the app keep it secret.
    – Natanael
    Oct 3, 2015 at 18:42
1

Android provides APIs to store and manipulate private key material without revealing them to the app (often with hardware-support). You can generate a key and use it to authenticate to the server.

The keys can be marked as non-exportable, but I am not sure if the restriction is enforeced in hardware and whether the keys will be included in backups or not.

IOS has a Keychain as well but the keys are normally made accessible to the app, so it may be copied on a rooted device.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.