跨銀行聯合訓練 AI 需要哪些安全技術組合？
原題
某跨銀行風控平台希望整合多家銀行的用戶行為資料，用於訓練信用風險預測模型。由於競爭與法規限制，各銀行僅願意提供加密後資料，且資料在任何時間不得被平台解密。同時，平台需建立安全通訊協議以確保資料在傳輸過程未被竄改或重放。下列哪一組技術最能完整對應上述需求？
白話
一個跨銀行平台要用多家銀行的加密資料訓練 AI，有兩個核心要求：一是平台永遠不能解密資料（即使在運算過程中也不行）；二是傳輸時資料不能被竄改或重放攻擊。
問你：哪一組技術組合能同時滿足「運算中不解密」和「傳輸安全」這兩個需求？
先自己選一個答案，再看完整解析。
一句話總結
跨銀行聯合訓練且資料不得解密，正確的技術組合是：同態加密（保證計算中不解密）+ 非對稱加密（安全金鑰交換）+ 單向雜湊（防竄改驗證）+ 對稱加密（高效傳輸加密），這四個各有明確分工。
情境
先感受問題：四個需求，需要四個不同工具
「全聯風控平台」要整合「北方銀行」、「中原信用社」、「南海金融」的用戶行為資料，三家機構有不同的法規義務和競爭顧慮。平台列出了四個具體的技術需求：
需求 1：「資料在傳輸和計算過程中，任何時候都不能被平台解密」
→ 需要：同態加密（允許在密文上直接運算，永遠不用解密）
需求 2：「各銀行和平台之間的安全金鑰交換」（確保通訊加密，沒有第三方能攔截）
→ 需要：非對稱加密（公鑰/私鑰機制，安全地交換對稱金鑰）
需求 3：「資料在傳輸過程未被竄改」（怎麼知道資料沒有被改動？）
→ 需要：單向雜湊（Hash 值驗證資料完整性）
需求 4：「防止重放攻擊」（舊的已授權封包不能被重複使用）
→ 需要：對稱加密（包含時間戳或序列號的訊息加密，防止重放）
選項 B 的四種技術恰好對應這四個需求，缺一不可。
舊方法
為什麼單一加密技術不夠？
- 只用對稱加密：傳輸時加密，但計算前必須解密，平台仍然可以看到原始資料。無法滿足「計算過程中不解密」的要求。
- 只用非對稱加密：安全，但非對稱加密計算很慢，不適合大量資料的傳輸加密，通常只用於金鑰交換或少量資料。
- 只用同態加密：能在密文上計算，但無法解決「傳輸過程竄改」或「重放攻擊」的問題。
- 只用雜湊函數：能驗證完整性，但無法保護資料機密性，雜湊值本身是公開的，只確認「有沒有被改」而非「看不看得到」。
- 差分隱私沒有回應「不解密」需求：差分隱私在輸出加雜訊，改變的是「結果的準確性」，不改變「計算過程是否需要解密原始資料」，無法滿足「任何時候不得解密」的核心要求。
新方法
四個技術各司其職，組成完整的安全架構
全聯風控平台採用選項 B 的四種技術組合：
同態加密：北方銀行用公鑰加密客戶資料，平台在密文上直接計算梯度，全程不解密
非對稱加密：各銀行用平台的公鑰加密自己的對稱金鑰，安全地傳送給平台，建立加密通道
單向雜湊：每筆資料傳輸前計算 Hash 值，接收方驗證 Hash 確認資料完整性，被竄改的資料 Hash 不符就拒絕
對稱加密：每個訊息包含時間戳和序列號，用對稱金鑰加密，防止舊訊息被重放（重放攻擊的封包序列號不連續，會被拒絕）
這就是選項 B 講的：同態加密（Homomorphic Encryption）+ 非對稱加密（Asymmetric Encryption）+ 單向雜湊（One-way Hash Function）+ 對稱加密（Symmetric Encryption）。
這四種技術在現代安全系統中有明確的功能分工：
同態加密（HE）負責「隱私運算」：讓計算在密文上進行，解決「資料使用方不能看到原始資料」的需求。代表性方案包括 CKKS（支持近似浮點數運算，適合 ML）、BFV/BGV（精確整數運算）。
非對稱加密負責「金鑰交換與身份驗證」：公鑰加密、私鑰解密的機制讓雙方在不安全通道上安全地交換對稱金鑰。RSA、ECC 是常見演算法。計算開銷大，通常只用於金鑰交換或數位簽章，不用於大量資料加密。
單向雜湊（Hash）負責「完整性驗證」：對相同輸入永遠輸出相同的固定長度摘要，且無法從摘要還原輸入。任何一個位元的改動都會導致完全不同的 Hash 值，因此用於偵測資料是否被竄改。SHA-256、SHA-3 是常見演算法。
對稱加密負責「高效大量資料加密」：同一把金鑰加密和解密，速度遠快於非對稱加密，適合保護傳輸中的大量資料。AES-256 是目前最常用的對稱加密標準。通常和非對稱加密搭配使用（非對稱傳遞對稱金鑰，對稱加密保護資料）。
錯選項
為什麼其他選項是錯的
A含差分隱私，缺乏回應「不解密」的技術
字面在說什麼
對稱加密 + 雜湊 + 非對稱加密 + 差分隱私可以滿足需求。
為什麼不對
差分隱私保護的是統計輸出的隱私，不保護「計算過程是否解密原始資料」。選項 A 沒有同態加密，資料在計算前必須解密，平台可以看到原始資料，直接違反「任何時候不得被平台解密」的核心需求。以差分隱私代替同態加密是功能錯位。
誰會選錯
把「差分隱私」和「不解密計算」混為一談的人，或者記得「差分隱私是隱私技術」就以為它能解決所有隱私問題。
C含差分隱私，邏輯同選項 A
字面在說什麼
差分隱私 + 對稱加密 + 同態加密 + 數位簽章能滿足需求。
為什麼不對
選項 C 有同態加密，但以「差分隱私」替換了「非對稱加密」，以「數位簽章」替換了「單向雜湊」。問題在於：差分隱私在這個組合中沒有對應到具體需求（題目要求的是「不解密計算」和「傳輸安全」，不是「統計輸出雜訊化」）；數位簽章確實包含雜湊功能，但它額外引入了身份驗證機制，比單純的雜湊更複雜，且題目沒有提到「身份驗證」需求。
誰會選錯
選項 C 看起來和 B 很像，容易讓人誤以為差別不大。關鍵分辨點是：差分隱私不等於「加密中的隱私保護機制」，它的位置不對。
D含安全多方計算（MPC），但缺少非對稱加密
字面在說什麼
同態加密 + 安全多方計算 + 雜湊 + 對稱加密能滿足需求。
為什麼不對
選項 D 以「安全多方計算（MPC）」替換了「非對稱加密」。MPC 確實是強大的隱私計算技術，但它解決的是「多方協作計算，但各方都不學到其他方的輸入」，其功能覆蓋面不同於非對稱加密的「安全金鑰交換」。更關鍵的問題是：題目明確說「各銀行僅願意提供加密後資料」，需要非對稱加密建立安全的金鑰交換和身份驗證機制，這是 MPC 不直接提供的。
誰會選錯
知道 MPC 是「跨機構安全計算」的工具，以為它可以替代非對稱加密的人。
變形題
同個考點下次怎麼變形
答案
只需要傳輸安全：非對稱加密（金鑰交換）+ 對稱加密（傳輸加密）+ 雜湊（完整性驗證），不需要同態加密。這就是 HTTPS/TLS 的基本架構。同態加密的加入是為了解決「計算時不解密」這個額外需求，沒有這個需求就不用承擔同態加密的計算開銷。
答案
雜湊函數：計算資料的摘要，驗證完整性，但「任何人都可以重新計算雜湊」，無法確認資料來源。數位簽章：用私鑰對雜湊值簽名，只有持有私鑰的人才能簽，驗證者用公鑰驗證，同時確認完整性和身份。需要驗證「誰發送」時用數位簽章；只需要驗證「有沒有被改」時用雜湊就夠。本題只需要防竄改，不需要身份驗證，單向雜湊足矣。
答案
TLS 握手階段用非對稱加密安全地交換對稱金鑰；資料傳輸階段用對稱加密（如 AES）高效加密；每個訊息包含 MAC（訊息認證碼，基於雜湊）確保完整性和防重放（透過序列號）。TLS 的設計和本題選項 B 的技術組合邏輯幾乎完全一致，差別只是 TLS 沒有同態加密（因為伺服器需要解密才能處理 HTTPS 請求）。
答案
MPC：多方協作計算，不需要把資料彙集到中央，各方輸入隱私。優點：比 FHE 計算效率更高；缺點：需要多輪通訊，網路延遲是瓶頸。同態加密（HE）：資料可以集中傳送到計算方，在密文上直接計算。優點：不需要多輪通訊；缺點：計算開銷極高（比 MPC 更慢）。實際系統常結合兩者：HE 處理批次計算，MPC 處理需要多方互動的部分。
答案
評估三個維度：（1）機密性（Confidentiality）：攻擊者能否從密文或中間計算結果中還原原始資料？用理論安全證明和攻擊模擬驗證。（2）完整性（Integrity）：資料在傳輸和計算過程中有沒有被篡改？用雜湊驗證。（3）可用性（Availability）：系統能否在安全保護下仍然正常運作？評估同態加密的計算開銷是否在可接受範圍。三個維度都達標才算真正安全。
延伸
想再往下看，這 5 個
- 同態加密（Homomorphic Encryption）
本題四技術中的核心：讓資料在加密狀態下完成計算，平台永遠看不到原始資料，是隱私計算的關鍵基礎。 - 差分隱私（Differential Privacy）
容易和同態加密混淆：差分隱私保護統計輸出，不保護計算過程，和本題的「不解密」需求不對應。 - 聯邦學習（Federated Learning）
解決跨機構訓練資料不離開本地的框架，和本題的同態加密方案是互補的隱私保護技術路線。 - 人工智慧安全（AI Safety）
本題的技術組合是 AI 系統安全架構的一部分，隱私保護機制是確保 AI 合規部署的必要條件。 - 均方誤差（MSE）
信用風險預測模型常用的迴歸評估指標，在安全計算框架下仍可透過同態加密在密文上計算。