0

I have an interesting problem. Let's say we have a user, Bob, who logs in to some service. How can that service prove Bob's identity, assuming Bob actively wants others to try and impersonate him? i.e. How can we be sure that the user logging in is indeed Bob?

  • Using the MAC/IP address of Bob wouldn't work as these can be easily spoofed.
  • A username/password as means of authentication wouldn't work since Bob could just give these credentials to anyone.
  • A public-key system (e.g. using RSA for signing) wouldn't work as Bob could just share his private key with anyone.

What I essentially need is Bob to have some proof of ID that he cannot share (or is at least hard for someone else to replicate, given all information that Bob has).

Edit (in case this is useful): I'm working with an iOS app (Bob) and a Python web server (the service).

pedrofb
  • 37,271
  • 5
  • 94
  • 142
Dotl
  • 1,406
  • 1
  • 13
  • 16
  • Something like an RSA token, or an encrypted USB key or card that must be inserted? – Ron Maupin Jan 30 '17 at 13:35
  • @RonMaupin For the USB key or card - Bob could just give this away to anyone. Re the RSA token, could you explain this a little further please? – Dotl Jan 30 '17 at 13:38
  • Bob could give it away, but then Bob wouldn't have it. This question is probably better asked on [security.se]. – Ron Maupin Jan 30 '17 at 13:39
  • _A public-key system (e.g. using RSA for signing) wouldn't work as Bob could just share his private key with anyone_ is not correct. You can use a cryptographic token as said @RonMaupin or a cryptographic software system that manage non-extractable keys. e.g WebCryptographApi for web browsers or AndroidKeyStore or iOS KeyChain. Depend on your execution environment – pedrofb Jan 30 '17 at 13:40
  • @pedrofb Thanks for this info. I'm assuming that sharing private keys is technically possible, but in practice software makes this infeasible? Also, I've updated my question for clarity on the platforms I'm working with. – Dotl Jan 30 '17 at 13:43

1 Answers1

1

Alternatives:

  • Hardware token that the user must present during authentication like a usb token or a cryptographic smartcard

  • Biometrics can not be shared. For example fingerprint/voice/ear/iris recognition. In some cases you will need a reader (note fingerprint biometric data is not available in mobile devices), and you have to work with confidence ranges and huge databases for comparison. An ID is never 100% reliable.

  • public key cryptographic systems that manage non-extractable keys. The cryptographic provider in user side allow to generate or import keys that can be marked as non extractable, and can not be exported outside. e.g WebCryptographyApi, AndroidKeyStore, iOS KeyChain or Window Keystore. During user registration, is generated a cryptographic key pair, public and private. The public is sent to server associated with user account, and private is stored securely. Authentication is done with a digital signature using the private key.

See FIDO UAF (Universal authentication Framework) and FIDO U2F(Universal second factor)

https://fidoalliance.org/about/what-is-fido/

About iOS KeyChain, it allows to mark a key as non extractable. See Apple Documentation

Important

If you do not set the CSSM_KEYATTR_EXTRACTABLE bit, you cannot extract the imported key from the keychain in any form, including in wrapped form.

Take a look also to Store and retrieve private key from Mac keychain programatically

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • Thank-you for your answer, this is very useful. In the case of using a public key system, couldn't Bob just send someone else's public key (let's call him Imp) to the server? This way, Imp could send all messages (singed using his own private key) to the server by using his own separate public/private key pair. The server thinks it is communciating with Bob, when it is in fact Imp. Of course, this means Bob himself won't be able to communicate with the server (since Imp can't share his private key to Bob), but let's assume he doesn't care. – Dotl Feb 05 '17 at 13:25
  • To protect you from this case it is necessary that during the registration of the public key, Bob sends the digital signature of a challenge with the private key. Then, only the owner of the private could register the public key – pedrofb Feb 06 '17 at 08:03