Okay, this question applies to most scenarios where a vendor distributes an SDK binary to 3rd party developers to use. But for easier discussion, let's assume I am developing an iOS SDK in Objective-C, and planning to hand it to any developers who have registered on our portal.
This SDK will access our services located on our server. And since the resources on our server are limited (well, on any server actually), we have built in some simple throttling mechanism in the SDK to prevent bad use of API's, like putting a remote procedure calls in a loop which executes 10K times a second, whether purposefully or not. Anytime such a thing happens, we throw.
As long as the developers use the binary as is, things are fine. But what if someone tries to do some funny things, like breaking our throttling mechanism by changing the binary, then linking to their app? In such a case, our client throttling mechanism no longer works, and a few instances of their app running could bring our server down.
Our thought is that we can build some checksum validation mechanism in the SDK binary, then calculate the binary's checksum during runtime initialisation, and compare that to the one in the binary. If our binary is tampered with, we cancel the initialisation, and prevent the host app from using our resources.
We already have server-side throttling mechanism on the server. But we also throttle on the client, since many unthrottled requests to the server still consume resources unnecessarily on the server, even we have throttling ready on the sever.
Is that a viable thought? Anyone have experience on this matter?
Thanks!
Related
I'm designing some OSX/iOS apps that I'd like to share a resource to be hosted on a webserver. I would like to have some sort of web app or script that can store a list of subscribers, and to notify them when the resource is updated. (The obvious goal here is to avoid having every app poll the webserver for updates.)
The only trick here is that I'd like a significant number of clients (say, a dozen) to be subscribed for updates on a 24/7 basis. I'm not sure if it's a good idea for all of the clients to maintain a live connection... I imagine that many web service providers will be happy about their webserver maintaining a dozen persistent connections (especially if they're virtually always idle).
(Edit) I looked into the Apple Push Network Service (APNs), but it's not the right solution for my problem. APNs requires an Entrust SSL Certificate, and some heavy interaction with the Apple Push Network service. My project is much simpler and more lightweight: I just need a script that says, "Upon receiving data from Device A, push it out to Devices B/C/D" (presuming those devices are somehow accessible... either through a persistent connection or some other technique).
What's the absolute simplest way of providing this mechanism?
The "simplest way" probably means different things to different people. If you're not a fan of locking yourself into third party services then there's a veritable plethora of app frameworks and open source tools you could use to build something yourself. But this is hardly 'simple' if web app development isn't your strong point.
There are several 'off the shelf' services available to do real-time messaging on iOS: bear in mind I'm just listing the ones I know from memory, there are other alternatives. Pusher and PubNub both offer real-time messaging services for mobile apps, along with ready to go SDKs. You can interface with them to send messages bi-directionally via sockets (so similar to how APNS works, but with considerable more control).
You could use these services with your own device/user management system, or you could use a 'backend as a service' provider such as Parse or Stackmob - you may not need this step, it depends how complex your intended app/integration is.
XMPPFramework has a publish–subscribe module (for XEP-0060) which works with most XMPP servers. I've even adapted it to work with Chat Server which comes with Snow Leopard.
If you already have an XMPP server this might be worth doing; otherwise it's kind of a heavyweight solution.
I'm familiar with SOAP and Webservices for peer-to-peer or client/server messaging on other platforms. What is the Apple equivalent for messaging?
I'm trying to put together an application server that will manage a collaborative work environment. It will have an average of 200 and maximum of 1000 mobile clients on a LAN. For example, one Mac and 200 iPhones. I'm planning to use Apple's Enteprise approach to distribute our private (commercial) app to each of our iPhones clients.
The server can push configuration settings to each client. The server will also push small sets of data to the clients. The clients will perform tasks on this data locally, and eventually report back status to the server. The clients can request more data sets from the server. These exchanges can be managed asynchronously.
There is also be a need to have synchronous exchanges for critical processes. This is rare, but it is a requirement.
The data that needs to be exchanged is reasonably small. These client/server processes are time dependent, so performance is critical requirement.
The network won't be shared, but needs to be tightly controlled (and fast). E.g. it can be Bonjour if there is a compelling reason for that.
I'm looking for a recommendation on which components of the Mac/iOS SDKs to leverage. Please leave 3rd party software out of this discussion. I must know what Apple already offers and what gaps exist before considering outside software. Thanks.
If you are only going to be using Mac and iOS products then Bonjour is really your best bet. There are a ton of native ways to transmit data in either byte or object forms.
There were a couple great videos from WWDC 2012 showing what the new Xcode can do to create client and server applications. It is under NDA, but you may want to take a look there: https://developer.apple.com/videos/wwdc/2012/.
Also you said you did not want third party, any particular reason? Would you use an open source layer on top of Bonjour?
What are the best practices to add sensitive data to the iOS application?
For sensitive data I mean a key or token to communicate with some external server.
Can we compile a certificate in the app, and iOS can remove it on installation?
I feel like we can not really 100% guarantee security of it, but what is the best practice layer we can add.
There is no mechanism that will ensure to a server that only your application is allowed to speak to it. So if that is your goal, then it is unsolvable. This has been talked to death on SO. Just a few:
Secure Communication Between iPhone and Server?
Store an encryption key in Keychain while application installation process
Secure https encryption for iPhone app to webpage
(And the many other links within those postings.)
And elsewhere:
Obfuscating Cocoa
You cannot authenticate devices or software. You can only authenticate users. That means a login. Without a login that is partially stored in the user's brain (or at least in something separate from their iPhone), it's just obfuscation.
Now, that doesn't mean that obfuscation is useless. It isn't. You can get some mileage out of a simple authentication token (like a client key), but don't expect it to survive an attack. That doesn't mean you shouldn't do it; it just means you shouldn't spend a lot of time/money on it since it will fail pretty fast.
In no cases should you implement something that ticks off paying customers. Read the several threads linked above (and the several threads linked from those threads). If after that, you still absolutely need a solution, then you'll need to hire someone to keep track of the cracks and fix them every time a new one comes out. It will never stop.
Since Apple controls the entire hardware/software stack, is it possible to obtain the following (through some type of trusted computing):
the hardware certifies that the software is genuine, non-jail broken iOS
iOS certifies to my server that the app run is an unmodified app
What this achieve is as follows:
when my server sends out data, it is guaranteed that the data can only be used in the way I intend it to be used (since it's running my app unmodified, on an non-jail broken iOS).
This prevents things like a modified app which steals data being transmitted from the server to the client. I realize one could theoretically eavesdrop, but this can be eliminated via encryption.
Thanks!
Briefly, no.
You're talking about Trusted Computing concepts on a platform that does not support TC. IOS does not include anything near Trusted Computing - Remote Attestation. It has no TPM.
The chain of trust established by Apple chip merely tries to stop execution if the signature of the next element in the boot chain is invalid. If one thing fails (jailbroken), their's no real -effective- way of detecting it. It is very similar to Secure Boot introduce by Microsoft but it's very different then Trusted Computing which attest which version of the system it is currently running.
With Trusted Computing, the TPM store the measurements (PCRs) of the system boot (SRTM). At boot, the first thing executed (CRTM - the only thing we really need to trust implicitly) will start the chain by measuring the BIOS, send the measure to the TPM (in a PCR) and pass execution to it (the BIOS). Then the BIOS does the same thing for the next element in the boot chain.
The measurements stored in the PCRs can then be used to encrypt or decrypt information (SEAL/UNSEAL operations) depending on the environment loaded in memory.
The TPM does not take action on the measurements (good or bad). The idea is not to restrain what can be loaded but to being able to know what environment is loaded on the platform. If something has been modified, the TPM will not contain the proper PCRs values and the UNSEAL operation (decrypt using PCRs as the key) will not work.
In the case of Remote Attestation, we're talking about the QUOTE operation. It's basically the same thing then SEAL but uses other keys to make sure the evaluating party can validate the attestation is really coming from a real/compliant TPM.
Sure, a system could use the SEAL operation to protect a secret used to decrypt the operating system and thus produce -in some way- the same effect as secure boot.
For more info, see my other posts.
I have heard that web-based chat clients tend to use networking frameworks such as the twisted framework.
But would it be possible to build a web-based chat client without a networking framework - using only ajax connections?
I would like to build a session-based one-to-one web chat client that uses sessions to indicate when a chat has ended. Would this be possible in Rails using only ajax and without a networking framework?
What effect does it have to use a networking framework and what impact would it have on my app to not use one? Also any general recommendations for approaching this project would be appreciated.
If i understand you correctly, you want to have to clients connect to you server and send messaged to each other to each other through ajax, via the server.
This is possible, there are two approaches to do this.
The easy approach is to have both client poll every few seconds to check for new messages posted by the other. Drawback is that the messages are not instantly delivered. I think this is an example found in the rails book.
The more complex approach is to keep an open connection and sent the messages to the client as soon as they are received by the server. To do this you can use something like Juggernaut
I would like to add that though the latter works, it is not something http was meant for and it a bit of hack, but hey, whatever gets the job done. A working example of this is the rails chat project which uses a juggernaut derivative.
Technically speaking every network based application has a networking framework under it and, therefore, is socket based...
The only real question here is whether you want to have all that chatter go through your server or allow point to point communication. If the former, you can use the ajax framework to talk to your web server. This means that all of your clients will be constantly polling the web server for updates.
If the later, then you have to allow direct tcp connections between the two clients and need to get a little closer to the metal so to speak.
So, ask yourself this: Do you want to pay for the traffic costs AND have potential liability over divulging whatever it is that people might be typing into their client; or, would you rather just build a chat program that people can use to talk to each other?
Of course, before even going that far, do you really want to build yet another chat client? That space is already pretty crowded.