嘿哈布爾！
今天我將談論我和我的同事幾個月來一直在做的事情：行動即時通訊工具的推播通知。 正如我已經說過的，在我們的應用程式中，主要重點是安全性。 因此，我們發現推播通知是否有“弱點”，如果有，我們如何消除它們，以便將這個有用的選項添加到我們的服務中。
我正在出版我們的翻譯 我自己做了一些小補充。 它包含“調查”的結果以及有關如何解決問題的故事。
我們檢查材料
在經典模型中，推播通知使訊息使者容易受到 MITM（中間人）攻擊。 例如，對於 Google、Microsoft 和舊版的 iMessage，應用程式會將加密金鑰傳送到 Apple 伺服器 - 在伺服器上，對使用者進行身份驗證，並對訊息標頭（或其內容）進行解密。
因此，有機會透過存取推播通知伺服器來讀取信件。 這意味著任何通訊加密都是無用的：推播通知仍然有被第三方讀取的可能性。 文章的作者更詳細地討論了這種可能性。 在 Xaker.ru 上，致力於加密訊息的方法。
如果您認為 Apple 和 Google 的伺服器 100% 安全，不會洩露用戶加密金鑰，請考慮他們的員工可以存取這些伺服器的事實。 員工也是人。
儘管推播通知存在許多漏洞，但許多「安全」即時通訊工具（包括 Signal 和 Telegram）都使用它們。 否則，用戶將不得不透過不斷登入應用程式來「手動」監控新訊息。 這非常不方便，而且相互競爭的信使會獲得優勢。
偏執和常識
在我們的專案中，我們幾個月前就密切關注過這個問題。 我們需要添加推播通知選項以保持競爭力。 但同時，不要打開安全漏洞，因為任何資料外洩都會破壞對專案的信心。
然而，我們已經擁有一個重要的優勢：我們的信使是去中心化的（資料儲存在區塊鏈上），員工無權存取帳戶。 只有用戶擁有加密金鑰，對話者的公鑰可在區塊鏈上獲取，以防止 MITM 攻擊。
在推播通知的第一個版本中，我們決定盡可能安全，完全不傳送訊息文字。 推播服務沒有從節點接收到訊息的文本，而只是收到了有關其已收到的事實的訊號。 因此，用戶看到「新訊息已到達」通知。 只能在 Messenger 中閱讀。
.
之後，我們了解到蘋果最新版本的通知具有新的安全功能。 他們 UNNotificationServiceExtension，允許開發人員透過 APNS 發送完全加密的通知資料。 然後，最終用戶裝置上的應用程式執行解密（或下載其他資料）並顯示通知。 我們將其作為第二版推播通知的基礎。
我們現在已經開發了 iOS 推播通知的第二個版本，它允許您顯示訊息文字而不存在安全風險。 在新概念中，邏輯如下：
- 推播服務會發送帶有交易號碼的推播通知（加密訊息可能非常大，且通知的大小非常有限）
- 當裝置收到通知時，它會啟動我們的NotificationServiceExtension - 一個微應用程序，透過ID從節點請求事務，使用已儲存的密碼對其進行解密，並向系統發送新的通知。 密碼儲存在安全記憶體中。
- 系統顯示帶有解密訊息或翻譯的通知。
- 密鑰不會去任何地方，就像純文字訊息一樣。 推播服務無法解密訊息。
我們接受了該版本，並在 iOS 應用程式的最新更新中實現了它。
對技術方面感興趣的可以查看原始碼： .
來源： www.habr.com