0

I want to send a small message from my iOS app to my server.

However, I want to have a high degree of assurance that the data was in fact: (1) generated on the device, and (2) by my app.

Is there way to achieve this? I care more about (1) than (2).

Roku has had such a feature for a long time: http://sdkdocs.roku.com/display/sdkdoc/Channel+Packaging+And+Publishing#ChannelPackagingAndPublishing-37ContentSecurityModel

Each Roku box has a unique client certificate that is signed by Roku as the Certificate Authority. The firmware also supports a special header, x-roku-reserved-dev-id, that always sends the developer id of the currently running application. Since this is authoritative and can't be forged, the developer's web server can only accept connections from a Roku Streaming Player running their application. Likewise, the Roku Streaming Player can enforce that it is talking to the developer's web server by including the CA certificate of the authority that issued their web server certificate in their channel application.

user3625974
  • 93
  • 1
  • 5
  • 1
    It seemed to me that 2 should be the priority. If 2 is true, then 1 has to be as well. Since no one can run your app on anything other than idevice! – user523234 Jan 24 '15 at 19:20
  • But an attacker can write their own code, they do not need to use the app or the device. The most important thing is that the person connecting has the correct credentials which must be sent with each message/request. – zaph Jan 24 '15 at 21:38
  • Zaph: take a look at the description at the Roku doc and http://sdkdocs.roku.com/display/sdkdoc/roUrlTransfer. You can't break those checks even by writing your own code. You need to extract the Roku device's burned-in certificate (which is "sufficiently difficult"). A feature like this could be used by app providers to prevent 3rd party clients (without getting into a discussion on whether that is a good thing). – user3625974 Jan 24 '15 at 23:59
  • Yes a "burned-in certificate", if you can get one in the app you are golden. – zaph Jan 25 '15 at 01:27
  • @zaph, of course communications between your server and your app needed to be: 1. secure, 2. authenticated (with some kind of secret code to validate it is from your app) – user523234 Jan 26 '15 at 17:11
  • Yes and the hard part is the initial authentication, a shared secret and keeping it secret. – zaph Jan 26 '15 at 17:17

1 Answers1

1

Normally you would add this kind of information when making a request. You can add additional headers to specify information about your device, application, its version, anything really.

Example:

NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.example.com"]];
[request addValue:@"iOS" forHTTPHeaderField:@"X-platform-name"];
[request addValue:@"ApplicationName" forHTTPHeaderField:@"X-application-name"];

Better yet

[request addValue:[UIDevice currentDevice].model forHTTPHeaderField:@"X-platform-name"];

OR

You could also check it using Javascript

var iOS = false;
var p = navigator.platform;

if( p === 'iPad' || p === 'iPhone' || p === 'iPod' ){
    iOS = true;
}
Abubakr Dar
  • 4,078
  • 4
  • 22
  • 28
  • 3
    This is easily spoofed. If security is important, the value sent in the header needs to be something that only the app could create, and that can be validated by the server. – Mike Taverne Jan 24 '15 at 19:59