iOS How do I protect an XML feed?

[RodThePlod]

Hey all,

I'm writing an app that will connect to my server and download XML content which it will then display to the user.

Thing is, I'd like to secure this in such a way only my app can access the feed. For example, I don't want other iPhone apps (or websites, etc.) to be able to access and use my feed for free. Maybe at some point, though, I may want to charge and allow them access.

What's the best method to achieve this? Shall I hash it? Some other technique?

I want to get the design of this right at the start rather than implement something and then have to go making major changes down the line.

Any advice appreciated.

Rod

 

[jnic]

Thing is, I'd like to secure this in such a way only my app can access the feed. For example, I don't want other iPhone apps (or websites, etc.) to be able to access and use my feed for free. Maybe at some point, though, I may want to charge and allow them access.

What's the best method to achieve this? Shall I hash it? Some other technique?

Sounds like you're asking for perfect DRM, which I'm afraid is impossible. Someone can always reverse-engineer your app and imitate it to your server.

Your best option is probably to implement something imperfect but difficult to reverse-engineer, so (for example) you could implement some fairly heavy encryption at both ends and break the key up in memory on the device so that it's difficult to extract with a debugger.

 

[Pring]

If you're serving the feed from within Apache look into just using plain ol' Apache HTTP Authentication.

http://httpd.apache.org/docs/2.0/howto/auth.html

 

[ace2600]

One way would be sending UDID, timestamp, and HASH(secret_key, UDID, timestamp) in your request. The UDID would identify each device, the timestamp would harden against replay attacks, and the secret key would be known only by your app and the server. The server would create its own hash and compare to the hash in the request.

This is for securing requests, but you would still need to encrypt the XML if that's a security concern.

 

[RodThePlod]

Thanks for the quick replies.

I'll check out the Apache HTTP authentication and also look into the hashing/encryption methods.

Whatever system I use, I want to be able to potentially offer the ability for collaboration in the future (third parties accessing the feeds) - so I guess I'll have to make a trade off between security and convenience/ease of access in the future.

OK - thanks again for these pointers - much appreciated.

Rod.

 

[jnic]

One way would be sending UDID, timestamp, and HASH(secret_key, UDID, timestamp) in your request. The UDID would identify each device, the timestamp would harden against replay attacks, and the secret key would be known only by your app and the server. The server would create its own hash and compare to the hash in the request.

This is for securing requests, but you would still need to encrypt the XML if that's a security concern.

What is the purpose of preventing replay attacks in this system? Also, given that the only way the server knows about UDIDs is from user requests, what's to stop me forging the UDID? This means we're back to preventing key extraction from memory, but with a pointless layer of hashing.

 

[jnic]

If you're serving the feed from within Apache look into just using plain ol' Apache HTTP Authentication.

http://httpd.apache.org/docs/2.0/howto/auth.html

If you're using Apache auth make sure you run it over SSL (or similar strong encryption), otherwise reverse-engineering your protocol is trivial.

 

[RodThePlod]

This means we're back to preventing key extraction from memory, but with a pointless layer of hashing.

jnic, I'll go have a look through the Apple documentation. Do you happen to know if there are sections which touch on this?

Also - regarding the strong encryption that you mentioned previously, would you expect to see any significant performance hits on the device side with this?

Cheers,

Rod.

 

[Pring]

I think you're overcomplicating it.

You have an XML feed served over HTTP(or HTTPS as jnic rightly points out), all you need to do is set up a private password to encrypt it.

Have a look at http://www.niallkennedy.com/blog/2006/09/authenticated-private-feeds.html

Sites like 37signals, daringfireball, etc just use simple HTTP authentication. Dead easy to set up and works a treat.

 

[ace2600]

What is the purpose of preventing replay attacks in this system? Also, given that the only way the server knows about UDIDs is from user requests, what's to stop me forging the UDID? This means we're back to preventing key extraction from memory, but with a pointless layer of hashing.

Without the timestamp, another party could copy the request and reuse (replay) it from their website, other app, whatever and whenever. So I don't follow your logic about the hash being unnecessary.

The UDID can absolutely be forged, but is included in the hash with the secret key so it would have to from a previous message. The UDID is probably optional. I was including it as a way to make sure the same request was not sent twice.

I am under the impression the OP's concern is preventing a website from requesting the XML feeds, not actually securing the XML feeds in transit. I agree there's still an issue about how to secure the secret key.

 

[jnic]

@ace2600: Ah, my mistake; I'd implicitly assumed that this would be over SSL, whereas of course implementing the protocol yourself might mean you don't include a nonce in the exchange by default.

@RodThePlod: There's unlikely to be much on hiding keys in memory (though plenty around the web on breaking DRM); however this may well be overkill as Pring suggests, in which case all you need is a client-side SSL library (there'll be plenty around in C).

would you expect to see any significant performance hits on the device side with this?

AES is very quick and has existed since long before computers were as fast as an iPhone. A standard C implementation will be plenty fast enough.

 

[RodThePlod]

I am under the impression the OP's concern is preventing a website from requesting the XML feeds, not actually securing the XML feeds in transit.

Correct!

@RodThePlod: There's unlikely to be much on hiding keys in memory (though plenty around the web on breaking DRM); however this may well be overkill as Pring suggests, in which case all you need is a client-side SSL library (there'll be plenty around in C).

AES is very quick and has existed since long before computers were as fast as an iPhone. A standard C implementation will be plenty fast enough.

OK Cool. Thanks guys. I think I know which direction I'm heading in now!



Rod.