API - Security design issues

Question

I'm building a GUI Desktop application that will communicate with an API(http) in a webserver.

In the client side I have a GUI Desktop application and a GSM Modem(hardware). The GUI Desktop application will make requests to the API in the webserver and will get the SMS's to send.

My question here goes on how can I design the application so that the Clients don't cheat by sending requests to the API on the webserver saying that message is send. Anyone got any ideas on how to solve this problem? The GSM modem that send SMSs is in a untrusted client. Ideas on how to protect an API dealing with this kind of environment? I've been reading about proof-of-work, this approach can help to solve my problem?

Best Regards

Answer 1

It sounds like you want to provide an app that will pay your subscribers to send SMS messages on your behalf. But since sending messages might cost the clients, you think your clients might cheat you by claiming to have sent the message without actually having sent it.

Unless there's a cryptographically trustworthy component baked inside the GSM modems that can provide a signed report of status back to you, there is likely no way to enforce it through cryptographic means. The clients are always able to provide their own implementations.

So instead, I would approach this with a random testing methodology. For each client, your server could randomly decide when to have them send a message to a trusted receiver. Maybe the test message is sent one time out of ten ordinary messages, or one message out of 50, something like that. Maybe you build the testing on a sliding scale. To start, one out of the first three or four is a test message, then as they continue to pass tests, you reduce the testing requirements. If someone is cheating, you won't receive the SMS, and you can investigate.

You have to be thoughtful in the design, of course. You can write it into the EULA agreement telling the clients that the system will periodically send test messages, and that they can be unsubscribed at your discretion. But you mustn't give them details of the testing methodology. If your clients can learn exactly which messages are test messages, they may still cheat and only respond to the tests. So your test messages must look like ordinary messages, and they must go to ordinary looking destinations. And if a message fails to arrive, you shouldn't immediately decide they've cheated you, as there are many other components that could have broken. You would have to investigate.

---

A different option would be to require that the clients provide proof of sending in the form of a copy of their billing statement. GSM systems record every SMS message destination. Perhaps you could arrange with the GSM providers to audit their records? Related, perhaps you could lease them the GSM modems and provide the accounts yourself, having the clients pay you for GSM service.

Answer 2

You cannot trust untrusted devices. This tautological assertion means that software which runs on attacker's controlled hardware can be inspected and altered by the attacker at will; there is no secret which can be hidden in such code, that the attacker won't be able to learn. There is no way to guarantee that the code which calls a given server is really "your" code, and not a modified version.

A proof-of-work does not help. Proofs-of-work are meant to solve another problem, i.e. mass sending of requests: in this setup, we acknowledge that the caller may have been arbitrarily altered by the attacker; but the proof-of-work allows the server to guarantee that, at least, the attacker's code had to invest substantial amounts of computing power for each request.

In your case, your problem is not a question of mass-sending of requests, so proofs-of-work don't apply. Your problem is that an untrusted component is supposed to send a SMS (with defined contents) and then tell you that it did, and it may lie. I see a few possible workarounds, none of them really satisfying:

• You could use for the untrusted client some dedicated, tamper-resistant hardware. That's what happens with some payment terminals: the terminal is shielded and commits suicide when its case is opened; so whatever codes runs in it can now be "trusted".

• Replace the SMS with MMS. I am not sure of the details, but apparently you can tag a MMS to be sent to multiple recipients, so the code may send the MMS to both the intended recipient, and your Web server; your Web server will then check that the received MMS was indeed tagged as "to be sent" to the intended recipient as well. Of course, this raises a lot of questions on how secure this multi-sending feature really is.

• Have the user digitally sign his message to the Web server where it is stated that the SMS was sent. So that if it is discovered that the user did not actually send the SMS, then there will be proofs of the user's disloyalty, so that you may sue them. This "solution" is about preventing attackers from attacking by threatening them with heavy legal retaliation.