Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I want to create a web service that can only be accessed by a specific type of entity: my own mobile application. Is there any well-accepted methods to do this?

I'm thinking about embedding a secret into this mobile application, but it seems to be susceptible to reverse engineering and can be easily sniffed on network. I would appreciate if anyone can suggest me some alternatives.

Thanks

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Client SSL certificate authentication would be something you could consider. Instead of providing credentials, your server will request you to provide a certificate (which you can embed in your application).

A small overview I took from Wikipedia:

The following full example shows a client being authenticated (in addition to the server like above) via TLS using certificates exchanged between both peers.

Negotiation Phase:

  • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested
    cipher suites and compression methods.
  • The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
  • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).
  • The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest
    message.
  • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
  • The client responds with a Certificate message, which contains the client's certificate.
  • The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the
    selected cipher.) This PreMasterSecret is encrypted using the public
    key of the server certificate.
  • The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's
    certificate's public key. This lets the server know that the client
    has access to the private key of the certificate and thus owns the
    certificate. The client and server then use the random numbers and
    PreMasterSecret to compute a common secret, called the "master
    secret". All other key data for this connection is derived from this
    master secret (and the client- and server-generated random values),
    which is passed through a carefully designed pseudorandom function.
  • The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated
    (and encrypted if encryption was negotiated). " The ChangeCipherSpec
    is itself a record-level protocol and has type 20 and not 22.
    Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
  • The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
  • Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and
    encrypted if encryption was negotiated). " The server sends its own
    encrypted Finished message.
  • The client performs the same decryption and verification.

Application phase:

  • At this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages
    exchanged between client and server will also be encrypted exactly
    like in their Finished message.
share|improve this answer
    
So the client's private key will not be prone to reverse engineering? –  AdnanG Sep 5 '13 at 12:53
1  
Obviously if you have access to the source or the device, it's prone to reverse engineering. But you've already lost if an attacker has physical access to your device (or your binaries for that matter). –  Lucas Kauffman Sep 5 '13 at 13:07
    
The mobile application that I talked about should be publicly available, so I think this approach will still be prone to reverse engineering? –  Andree Sep 7 '13 at 10:35
    
Yep that's right –  Lucas Kauffman Sep 7 '13 at 11:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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