我有一个问题设置，我想通过电话联系用户，并且我需要尽可能保护电话的完整性。我想知道如何以最好的方式设计交互。
我担心一个非常具体的安全风险：我正在联系的人可能正在使用智能手机，并且可能在没有意识到的情况下在他们的手机上安装了恶意的第三方应用程序；而且我担心这个恶意应用程序可能会试图篡改通话的音频。我担心恶意应用程序可能会以某种方式在通话中注入虚假音频。我不需要保护对话的机密性——电话不会包含任何秘密——但我非常关心电话的完整性。
我的问题：如何尽可能减少这种风险？
对问题进行更多阐述。 我有相当多的自由度可供我使用：
我可以安排向任一方向拨打电话（我可以给用户打电话；或者我可以安排用户给我打电话）。
我控制电话的内容，因此我可以结合各种“类似验证码”的机制来尝试测试我是在与人交谈而不是与恶意软件交谈，或者我可以让用户重复对他说的话并且反之亦然，作为一种确认形式，如果有帮助的话。
如果一个方向的音频通道可以比另一个方向更有效地保护，我可以围绕它设计与用户的交互。例如，如果可以在从用户到我的方向（用户对我说的内容）保护音频通道的完整性，但不能在相反的方向上保护，我可以接受。我也可以接受另一种方式——只要我知道可以保护哪个方向。
我的主要关注点是防御无法突破其应用程序沙箱的恶意应用程序（例如，它无法获得 root 权限）。假设用户的手机没有root，没有越狱等。此外，我们假设恶意应用程序是受应用程序沙箱限制的第三方应用程序，例如，它仅限于使用第三方可用的任何API-派对应用。（如果还可以使用一些特权升级漏洞来防御突破沙箱的应用程序，那将是一个不错的奖励，但我猜没有很好的防御措施来抵御这种威胁，因此我专注于留在范围内的应用程序沙箱。）对于我的应用程序，检测篡改就足够了（当然，如果可以完全防止它，那就更好了）。
那么，应对这种威胁的最佳防御措施是什么？
约束。用户是普通大众。他们将拥有他们拥有的任何电话；我不能强迫他们使用不同的电话或给他们不同的电话。我怀疑需要一些特殊的应用程序来加密他们的电话是不切实际的（而且我不确定这是否会有所帮助，无论如何......）。我将需要能够联系许多这样的用户，因此任何解决方案都必须扩展。我希望解决方案对用户尽可能有用。
我做过的研究。我已经查看了恶意应用程序可能在 Android 和 iOS 上使用文档化 API 执行的操作。
在 iOS 上，我无法找到任何方法让恶意第三方应用程序篡改电话内容。我意识到这不能保证这是不可能的；我只是还没有找到办法。
在 Android 上，在这种威胁模型中，似乎无法保护用户拨打的呼出电话的完整性。恶意应用程序可以观察用户何时拨出电话、取消通话、控制麦克风和扬声器、显示虚假拨号屏幕，并让用户在实际与恶意软件通话时认为他们在与我通话. 恶意应用程序将至少需要PROCESS_OUTGOING_CALLS和RECORD_AUDIO权限（并且可能MODIFY_AUDIO_SETTINGS），但如果用户安装的应用程序之一是恶意的，这可能会发生。
然而，相比之下，在 Android 上，向用户发出的呼叫看起来可能是安全的——或者，至少，如果与用户的对话结构适当，则可能会变得安全。应用程序可以检测到有来电。在旧版本的 Android 上，应用程序可以阻止来电并防止手机响铃或显示任何来电迹象。然而，最新版本的 Android 已经删除了后一个功能：似乎没有程序化的方式让应用程序在用户没有意识到的情况下阻止来电。此外，如果用户接听来电，那么第三方应用程序似乎无法访问或修改通话内容。不过，情况有点棘手。我认为它应用程序 可以在从我到用户的方向静音音频通道并播放音频剪辑（这可能需要MODIFY_AUDIO_SETTINGS许可，但我们假设恶意应用程序也有），从而在那个方向伪造音频：欺骗用户认为音频剪辑来自我，而实际上它来自恶意应用程序。但是，我还没有找到恶意应用程序窃听调用内容的任何方法，所以如果我们在调用中引入足够的随机性，我们可能会使恶意应用程序难以准确猜测何时进行此攻击，如果恶意应用猜错了，那么很明显有些地方出了问题。因此，至少在我看来，我们可以设计一些交互脚本，让恶意应用程序很难欺骗我，这似乎是合理的。
如果用户使用的是功能手机，他们就无法安装第三方应用程序，因此这种担忧就消失了。
候选稻草人解决方案。这项研究使我找到了一个候选协议/脚本，用于将信息 X 传达给用户：
我打电话给用户。（别给我打电话，我给你打电话。）
我与用户闲聊了一段时间，时间是随机的。
我将信息 X 告诉用户。
我要求用户通过向我重复此信息 X 来确认。用户很乐意对我说 X。
我感谢用户，说再见，然后挂断电话。
在整个通话过程中，我在后台轻柔地播放了一些随机选择的音乐（即，在整个通话过程中都在播放同一首歌曲，并且用户可以在整个通话过程中在后台听到它）。
通话开始时随机持续时间闲聊的目的是随机化信息 X 的通信时间，以便恶意应用程序无法通过静音从我到用户的音频通道并播放来“覆盖”它一个音频剪辑（恶意应用程序不知道在什么时间执行此操作，因为我已经随机化了 X 的通信时间）。让用户向我确认的目的是作为额外的后备防御，以防恶意应用程序试图通过使我静音和播放音频剪辑来欺骗我。音乐的目的是让用户有机会注意到我的部分音频是否在任何时间点被替换。
这只是我想到的一个候选协议。我提到它只是作为一个起点和一个稻草人供你批评。希望您能找到更好的解决方案。也许您会发现此协议存在严重问题。没关系。我正在寻找我能想出的最佳方案，而且我不致力于任何特定的协议或交互方式——你告诉我我应该使用什么协议。
应用程序设置。如果您关心，应用程序设置是远程投票，我想使用电话通道来确认用户的投票，并防止恶意软件在没有检测到的情况下更改用户的投票。然而，一个好的解决方案在其他设置中也可能有用，例如，在线银行交易的电话确认或使用电话确认作为交易中的一个步骤的其他高安全设置。
有关的。另请参阅恶意电话软件能否对电话发起 MITM 攻击？. 然而，这个问题集中在恶意代码的威胁模型上，它突破了应用程序沙箱并获得了手机的根级访问权限；在那个威胁模型中，事情看起来毫无希望。 这个问题侧重于稍微不同的威胁模型，其中用户确实安装了恶意应用程序，但恶意软件无法突破应用程序沙箱。