API -安全设计问题

Question

我正在构建一个GUI桌面应用程序，它将与GUI服务器中的API(http)通信。

在客户端，我有一个GUI桌面应用程序和一个GSM调制解调器(硬件)。GUI桌面应用程序将向get服务器中的API发出请求，并获得要发送的SMS。

我在这里的问题是如何设计应用程序，这样客户端就不会通过向send服务器上的API发送请求来欺骗，说消息是发送的。有人对如何解决这个问题有什么想法吗？发送SMS的GSM调制解调器位于不受信任的客户端。如何保护API来处理这种环境？我读过关于工作证明的文章，这种方法能帮助解决我的问题吗？

诚挚的问候

Answer 1

这听起来像是你想提供一个应用程序，将支付您的订户发送短信代表你。但是，由于发送消息可能会使客户端付出代价，所以您认为您的客户可能会欺骗您，声称已经发送了消息，而没有实际发送消息。

除非GSM调制解调器内部有一个加密的、可信赖的组件，可以向您提供有签名的状态报告，否则很可能无法通过加密方法强制执行。客户端总是能够提供自己的实现。

因此，我会用随机测试方法来处理这个问题。对于每个客户端，您的服务器可以随机决定何时让它们向受信任的接收方发送消息。也许测试消息只发送了10条普通消息中的一条，或者50条消息中有一条发送了类似的信息。也许你可以在一个滑动的尺度上建立测试。首先，前三四个中有一个是测试消息，然后当它们继续通过测试时，您就减少了测试需求。如果有人作弊，你不会收到短信，你可以调查。

当然，你必须在设计上考虑周到。您可以将其写入EULA协议中，告知客户端系统将定期发送测试消息，并且可以酌情取消它们的订阅。但是你不能告诉他们测试方法的细节。如果您的客户端能够准确地了解哪些消息是测试消息，他们可能仍然会作弊，并且只对测试做出响应。因此，您的测试消息必须看起来像普通的消息，它们必须去普通的目的地。如果一条消息没有到达，你就不应该马上断定他们欺骗了你，因为还有很多其他的组件可能已经坏了。你得调查一下。

另一种选择是要求客户提供以账单副本的形式发送的证明。GSM系统记录每个短信目的地。也许你可以和GSM供应商一起审核他们的记录？相关的，也许你可以租给他们的GSM调制解调器，并提供自己的帐户，让客户支付你的GSM服务。

Answer 2

您不能信任不可信的设备。这种同义断言意味着，攻击者可以随意检查和修改运行在攻击者控制硬件上的软件；在这些代码中没有隐藏的秘密，攻击者将无法学习。无法保证调用给定服务器的代码实际上是“您的”代码，而不是修改后的版本。

工作证明不起作用。工作证明旨在解决另一个问题，即大量发送请求:在此设置中，我们承认调用方可能被攻击者任意更改；但工作证明允许服务器保证，至少攻击者的代码必须为每个请求投入大量的计算能力。

在你的例子中，你的问题不是大量发送请求的问题，所以工作证明不适用。您的问题是，不受信任的组件应该发送一条SMS (包含定义的内容)，然后告诉您它发送了，它可能是谎言。我看到了一些可能的解决办法，但没有一个是真正令人满意的：

• 您可以为不受信任的客户端使用一些专用的、抗篡改的硬件。这就是某些付款终端机所发生的事情:终端被屏蔽，并在打开它的箱子时自杀；因此，它中运行的任何代码现在都可以被“信任”。
• 用彩信代替短信。我不确定细节，但显然您可以标记要发送给多个收件人的MMS，因此代码可以将MMS发送到预期的收件人和Web服务器；然后Web服务器将检查接收到的MMS是否确实被标记为“将被发送”给预期的收件人。当然，这就引发了许多问题，即这种多发送功能的安全性到底有多大。
• 让用户将他的消息发送到数字符号服务器，在该服务器上声明短信已经发送。因此，如果发现用户没有发送短信，那么就会有用户不忠的证据，这样你就可以起诉他们。这个“解决方案”是防止攻击者通过严厉的法律报复威胁他们的攻击。