哈Ha！
今天，我将谈论我和我的同事几个月来一直在做什么：关于移动即时通讯程序的推送通知。 正如我所说，在我们的应用程序中，主要重点是安全性。 因此，我们发现了推送通知是否存在“弱点”，如果是，我们如何对其进行分级以将此有用选项添加到我们的服务中。
我正在发布我的
文章的翻译，
其中包括我自己的一些补充。 它包含“调查”的结果以及有关如何解决该问题的故事。
探索装备
在经典模型中，推送通知使Messenger容易受到MITM攻击（中间人，中间人）。 例如，对于Google，Microsoft和旧版本的iMessage，应用程序将加密密钥发送到Apple服务器-用户在服务器上通过身份验证，并且消息头（或其内容）被解密。
结果，有机会通过获得对推送通知服务器的访问来读取对应关系。 这意味着对通信的任何加密都是没有用的：推送通知仍将留给第三方阅读的机会。 Xaker.ru上
“加密明智地加密”一文的作者致力于消息加密方法，对此进行了详细讨论。
如果您认为Apple和Google的服务器不允许100％泄漏用户加密密钥，请考虑其员工可以访问它们。 员工就是人。
由于存在推送的所有漏洞，包括信号和电报在内的许多“安全”通讯程序都在使用它们。 否则，用户将不得不通过不断进入应用程序来“手动”监视新消息。 这非常不方便，竞争的使者将获得优势。
偏执和常识
在我们的项目中，几个月前我们就解决了这个问题。 我们需要使推送通知具有竞争力。 但同时，不要在安全性上造成漏洞，因为任何数据泄漏都会破坏项目的信誉。
但是，我们已经有了一个重要的优势：我们的Messenger是去中心化的（数据存储在区块链上），而员工则无法访问帐户。 只有用户拥有加密密钥，并且对话者的公共密钥可在区块链上使用，以防御MITM攻击。
在推送的第一个版本中，我们决定尽可能安全地运行它，并且完全不传输消息的文本。 推服务从节点接收的不是消息文本，而仅仅是关于其接收事实的信号。 因此，用户看到了通知“一条新消息已到达”。 只能在Messenger中读取它。
工作原理：视频 。
之后，我们了解到Apple的最新通知具有新的安全功能。 他们
发布了 UNNotificationServiceExtension，允许开发人员通过APNS发送完全加密的通知数据。 然后，最终用户设备上的应用程序解密（或下载其他数据）并显示通知。 我们将其作为第二版推送的基础。
现在，我们为iOS开发了第二个版本的推送通知，它使您可以显示消息文本而没有安全风险。 在新概念中，逻辑如下所示：
- 推送服务发送带有事务号的推送通知（加密的消息可能非常大，并且通知的大小非常有限）
- 收到通知后，设备将启动我们的NotificationServiceExtension-一个微型应用程序，该应用程序通过ID向节点请求交易，并使用保存的密码对其进行解密，并向系统发送新通知。 密码存储在安全的仓库中。
- 系统显示带有解密消息或翻译的通知。
- 按键不会像普通文本消息一样走到任何地方。 推服务不具有解密消息的能力。
我们以该版本为工作版本，并在iOS应用程序的最新更新中实现了该版本。
对技术方面感兴趣的人可以查看源代码：
github.com/Adamant-im/adamant-notificationService 。