網路家庭(8044-tw)於日前推出的 PChome IM (中文名：連絡)，遭網友連日在網路爆料其設計有資訊安全問題，除了明碼在本機端的記憶卡存取資料、傳輸過程未經加密、大量主機私鑰存於手機 App 本機端外，又遭爆其簡訊認證機制與傳輸推播機制設計異於大多數目前的手機程式設計邏輯，因此恐會造成嚴重的中間人問題。由於簡訊認證、推播訊息、主機金鑰認證、傳輸、行動裝置本機端儲存都是現有行動裝置 App 設計所必備的項目，且被認定是無論何種 App 服務的基礎，故會引起開發者與資訊安全研究社群的持續關注與研究，並不令人意外。
行之有年的行動裝置推播機制
推播 Push Notification 是一個現今行動應用平台常見的功能；最早由 Apple 在 2009 於 iOS 平台上推出，是一種可以讓行動裝置使用者在沒有打開行動裝置主要操作介面前，就可以收到行動裝置作業系統商透過基礎網路強制推往裝置上的通知服務。一般而言還會搭配行動裝置內設計有通知中心來整理這些通知，這些通知主要包含有未接來電、新訊息(SMS 或其它任何 IM)、交易通知、App 內容更新、系統更新訊息等等，是今日行動裝置使用者不可或缺的其中一項訊息統整服務，幾乎所有 App 都會用到這個基礎服務。
關於推播機制的設計流程，Apple 在 iOS 的開發者教程其實是有很仔細的教學這段定義的。(iOS 開發者平日的其中一項痛苦就是只要弄錯 Apple 對程式設計的邏輯，就有可能沒有辦法通過 iOS 上架驗證，所以一定要讀 Developer Guide 啊！)
(圖說：Apple 在 iOS 開發者教程裡講解從服務提供端推送遠端通知到裝置 app 上的流程，數位時代翻拍自蘋果 iOS 教程)
Apple 的 iOS 開發者教程，把推播機制分成服務提供端與裝置端，介於 APNs (Apple Push Notification Service) 的兩邊，在 Apple 的定義裡，服務提供端不限制只有一個機器或裝置，但必須能夠與 APNs 建立穩定且安全的連接。透過這個連接，服務提供端將通知透過 APNs 送到裝置上。
PChome IM 詭異的推播機制設計
PChome IM 這次的設計讓人感到意外的主要是服務提供端與 APNs 建立連接的部分。
(圖說：一般 IM 推播機制與 PChome IM 推播機制設計的異同，數位時代製圖)
大部分服務提供端的設計，為了建立穩定且安全的連接，會將這段連接設計在自家的伺服器端與 APNs 之間。這樣的設計考量，可以保證以下的好處：
- 以主機的安全性維護，來保有與 APNs 通訊所需金鑰的安全性(不需要公開)
- 主機與 APNs 連接過程不會容易被發現、竊聽
- 由主機建立與 APNs 的連接，絕對遠比一般行動裝置所處的實體環境網路 (3G/4G/LTE/Wifi) 等的連線品質還穩定。
- 保障接收對象的 APNs token 不被外界輕易得知
PChome IM 的設計是將與 APNs 的連線交給使用者行動裝置自己直接與 APNs 建立連線。因此會有以下問題：
- 裝置本機端勢必有 APNs 連線所需的認證金鑰，無論是事先儲存或當下下傳(這問題更大，還好 PChome IM 設計選擇了前者)，都比較危險。
- 行動裝置本身與 APNs 連接品質視行動裝置所處網路連線環境而定
- APNs token 以明碼回傳，且存於本機端裝置內。
也因此，惡意使用者有機會透過這中間的任何一個環節假造 PChome IM 的推播通知，推送訊息給已經被知道 APNs token 的使用者。一般而言，因為偽造訊息的惡意使用者介在實際受害使用者的兩端，因此這樣的資訊安全問題又被稱做中間人攻擊。
(圖說：PChome IM 準備送出推送需求時的指令，可見以明碼向 PChome IM 主機要求，DevCore 資訊安全顧問 Anfa Sam 提供)
(圖說：PChome IM主機在收到上述推送需求後，回給PChome IM本機端的資料，其中有被通知者 token 明碼的詳細欄位資訊，DevCore 資訊安全顧問 Anfa Sam 提供)
由於行動裝置的普及，包含手機、平板甚至部分物聯網裝置、輕型電腦深度應用已經深入到許多尋常百姓家。行動程式設計與資訊安全對人們生活的實際影響，將會越來越劇烈，影響範圍與損失可能性也隨之升高。無論對一般人或業主而言，這類的行動程式設計常識也將越來越普及。不得不說，筆者與數位時代也藉由 PChome IM 程式設計有資訊安全問題的這次機會，再次上了一堂行動程式設計的資訊安全課。
