1. 背景介紹
爲了控制風險，銀行、證券、保險等機構需要在傳統央行徵信系統之外獲取客戶消費，小額信貸等額外標籤數據作爲風險控制的補充數據。這就形成了金融客戶的外部數據採購需求。但是在數據採購時由於合規性要求以及保護自身商業機密的需要，金融機構往往無法輸出其客戶的ID、手機號等敏感信息（以下簡稱ID），否則客戶信息可能泄露，造成用戶信息爲不法分子或者競爭對手利用。而在沒有任何可關聯信息的情況下，數據的供應方又無法瞭解金融機構要買什麼數據，這就形成了供需的矛盾點。對於小型供應商而言，只能將自己所擁有的數據全數供應給銀行，而銀行獲得數據後往往覺得這些數據的價值不大。對於擁有高價值數據的大型供應商而言，將自身全量數據賣給銀行，風險和收益又不成正比。因此出現了數據供應方和需求方都想進行數據交易，而由於安全原因交易卻無法實現的局面。
這種情況使得金融行業用戶難以獲得高價值的外部數據源，進而制約了其通過數據創新驅動業務發展的能力。例如銀行開展小額信貸的場景中，如果依賴的外部數據源質量不高則會影響風控的效果。爲了解決金融數據共享的矛盾，我們(TalkingData)設計了一套基於密碼技術(cryptology)的既可以保護數據需求方商業機密又保障數據供應方數據安全同時還可以精確計量數據使用的數據共享方案。該方案具有安全、公平、實時、高效的特點，可以滿足金融機構實時採購外部數據的需求。
2. 概覽
2.1 問題分析
從上述背景介紹中可以看出，解決問題的關鍵是提供這樣一種機制，在數據需求方不提供任何查詢ID相關標識的情況下，數據供應方可以提供與待查ID相關的屬性（標籤）信息。那麼這就需要供應方要麼在每次查詢時實時返回全量數據，讓需求方自己挑；要麼將全量數據預置到需求方一側，讓需求方自己挑。由於效率的原因，第一種方式在實際場景中很難應用。第二種方式則會對數據供應方帶來以下挑戰：
a) 在滿足需求方使用要求的同時保證預置數據集中非銀行客戶的數據安全；
b) 雙方同時認可的精準數據使用量計量；
只有解決了上述挑戰，才能解除數據供應方的擔憂，爲金融行業的用戶引入高質量的數據源。
2.2 如何破局
爲了應對前述問題和挑戰，我們針對交付的數據集以及供需雙方必要的交互數據，提出瞭如下的設計。
首先，數據供應方需要對待交付的數據集進行預處理（爲了簡單起見，這裏假設數據供應方的數據只有設備ID和對應的若干標籤，其中設備ID可以以明文的方式給出，以便需求方進行選擇；數據需求方感興趣的數據是標籤）。預處理主要是使用只有供應方知道的密鑰對標籤進行加密，然後就可部署到數據需求方一側，完成交付。
其次，當數據需求方需要獲取感興趣的設備ID對應的標籤時，將挑選出來的標籤密文使用只有自己知道的密鑰再次進行加密並回傳給數據集對應的供應商，供應商對回傳數據進行解密處理並將中間結果作爲響應返給數據需求方；數據需求方在收到響應後再進行一次解密處理就可以獲取所需的標籤數據。
上述過程如下圖所示：
到這裏，各位看官就會有疑問了，既然供應商不知道數據內容，那麼他是如何做到正確解密？我們都知道乘除法滿足交換律，對一個數先乘後除還是反過來都不影響最終結果。假設明文是數字5，供應方先乘以4（加密），將得到的20交付給需求方，當需求方想知道20的明文時，先將20乘以8（二次加密），再將結果160提交給供應方；供應方這時顯然已經不知道160代表什麼，但是他知道這個數乘過4，所以他就用4除（解密），得到40返給需求方，需求方再將40除以8（二次解密）最終得到明文5。
可能各位又要問了，需求方只需比較一下提交給供應方的160和返回的結果40或者將明文5與收到的交付數據20進行比對不就可以知道供應方的祕密4了嗎？這裏先賣一個關子，我們實際實現時是通過選取兩種支持“交換律”的高強度算法，並通過一系列操作確保需求方無法反推出供應方的祕密的，感興趣各位可參考後面的原理部分。
2.3 效果分析
接下來我們簡單分析一下是否能夠達到設計預期，或者說能否解決數據共享中面臨的問題和挑戰：
-
部署到數據需求方一側的數據集是經過加密，所以只要選擇的加密算法強度足夠高且供應方不泄露自己的密鑰，數據需求方是無法破解標籤密文的；
-
在交互過程中數據需求方沒有主動泄露商業祕密，由於數據挑選的過程是在需求方一側內部完成，並且與供應方交互的數據也不是由ID生成，因此不存在泄露的風險；
-
數據供應商無法猜測交互數據對應的ID，因爲供應商收到的數據是經過需求方二次加密處理的，只要需求方選擇的加密算法強度足夠高且需求方不泄露自己的密鑰，供應方同樣是無法進行破解的，只要無法破解，供應商就無法根據自己的數據集去猜測需求方要查詢的ID；
-
供需雙方可以在毫無互信的情況下完成數據的交易，並且由於存在必要的交互，所以供應方可以做到精準計量；
-
交互過程中的數據經過了加密處理，而且沒有ID相關的信息，所以即使被第三方監聽到也毫無用處，而且第三方也無法進行篡改。這個機制也就保障了數據可以實時更新。
當然這裏還有一個遺留問題，供應方交付的數據集中包含了明文形式的ID，那麼如何解決供應方的ID也匿名化後，需求方還能正確挑選標籤的問題？由於篇幅的問題，這部分的介紹我們在另外的文章中給出。我們稱之爲供應方匿名方案。
3. 方案原理
本文前半部分簡單描述瞭如何實現在數據需求方不提供ID的情況下獲取相關數據的過程，後面的內容則是通過科學嚴謹的論述解釋其中的原理。
3.1 密碼基本概念
爲了論述方案的原理，我們首先定義幾個基本概念，這些概念可以幫我們更容易理解如何在不泄露自身信息的情況下，獲取外部信息。
3.1.1 加密算法
加密至少包括一個加密算法，一個解密算法。在密鑰key的幫助下，加密算法把明文m轉換成密文c，解密算法把密文c轉換回明文m。加解密可以用下面的公式表示：
加密(Encrypt)：E(m,key)->c解密(Decrypt)：D(c,key)=D(E(m,key),key)->m
3.1.2 同態加密
如果一個加密算法，對它輸出的密文做計算後再解密得到結果，與先加密再解密後進行同樣的計算得到的結果相同，則稱該加密算法具有同態性。
假設函數f()代表某種計算，對數據m有f(m)->n。如果加密算法(E,D)滿足：E(m,key)->c，f©->d，D(d,key)->n，則該加密算法爲同態加密算法。我們可以簡單把同態看做中學數學中的交換律，差別是交換律針對加法或者乘法這種只有一個步驟的簡單運算，同態可能有多步計算。進一步的，有兩個加密算法：
-
加密：E1(m,keya)->ca
解密：D1(ca,keya)->m -
加密：E2(m,keyb)->cb
解密：D2(cb,keyb)->m
對於經過E1和E2順序加密得到的密文cb=E2(E1(m,keya),keyb)，如果有m=D1(D2(cb,keyb),keyb)=D2(D1(cb,keya),keyb)，我們稱這兩個加密算法具有同態性，也就是說這兩個算法的解密順序可以交換。比如4個正整數a,b,c,d,我們有ab/c/d = ab/d/c
3.1.3 概率加密
使用概率加密算法對一個明文加密兩次後，會產生不同的密文。
第一次加密：E(m,key)->c1，對應的解密D(c1,key)->m
第二次加密：E(m,key)->c2，對應的解密D(c2,key)->m
第三次加密：E(m,key)->c3，對應的解密D(c3,key)->m
…
從外部看，拿到c1，c2是無法區分它們是一個明文m生成的還是另一個明文m’生成的。概率加密從語義上看是安全的，可以防止選擇明文攻擊。
3.2 具體實現
假設m1,…,mn代表供應方提供的供需求方選擇的標籤。
第一步，供應方使用加密算法E1對所有標籤加密生成與m1,…,mn對應的標籤c1,…,cn，key是它自己選擇的密鑰。c1,…,cn被髮給銀行。
第二步，需求方選擇它希望獲得的標籤mi對應的密文ci，使用加密算法E2對其加密生成二次加密後的密文ci*，並將ci*發給供應方。
第三步，供應方使用解密算法D1解密ci*得到ci**，並將ci發給需求方。假設兩個加密算法是同態的，則D1解密正好抵消E1加密，得到的結果ci相當於E2加密的密文。
第四步，銀行用D2解密ci**，獲得自己想要的mi。
注意，這裏描述的過程並不包含需求方如何知道哪個mi是自己要選擇的，這需要每個爲mi配ID，進而造成供應方信息的泄露。該問題會由供應方匿名方案解決。
我們把上面的加解密過程以簡單的“乘除法”來代替，方案的過程如下圖所示：
3.3 方案安全性分析
方案通過下面兩個性質保證在需求方獲取想要的mi的同時，供應方無法獲取任何需求方所選mi有關的信息。
-
不可區分性：給定任意兩個銀行用E2加密生成的密文ci和cj，以及生成他們的原始密文ci和cj，供應商無法區分ci和cj分別是由ci還是cj生成。
-
非關聯性：供應商在不關聯ci*的情況下可以生成ci**。
不可區分性通過概率加密實現：
只要方案中選用的加密算法(E2,D2)是概率加密算法即可保證供應商收到的密文c*是不可區分的。
非關聯性通過同態加密實現：
第一步E1加密的結果ci是與m關聯的部分，經過第二步E2加密後關聯性已經被概率加密消除，如果第二步的E2加密與第一步的E1加密具有同態性，則E2加密不影響第三部D1解密，進而供應商可以在無需關聯ci*與ci的情況下生成ci**。最後m再用 D2解密。這裏的m可以是標籤，也可以是後續操作中加密標籤的中間密鑰。
同樣的，只要方案中選用的加密算法(E1,D1)是概率加密算法即可保證銀行收到預置密文c和解密密文c**都是不可區分的。
由於每次獲取ci**需要供應商參與，數據交易的計量是精確的，也就是供應商雖然不知道銀行獲取了哪個mi，但它知道銀行獲取了一個mi。
3.4 相關算法選擇
我們選用支持同態乘特性的ElGamal算法和RSA算法作爲具體實現。由於兩種算法都是業界公開的算法，介紹的文章有很多，這裏就不展開，下面主要描述我們選擇這兩種算法的考量。
-
可行性：我們看這兩個算法的計算過程可以發現，ElGamal和RSA的加解密過程都只包含模乘法運算，對明文m先做ElGamal加密，再做RSA加密後的密文，先做ElGamal解密後做RSA解密和先做RSA解密後做ElGamal解密得到的結果是相同的。也就是說按照前面同態加密的定義，他們具有同態性，符合做(E1,D1)和(E2,D2)算法的條件。
-
安全性：ElGamal和RSA本身都是久經考驗的概率加密(樸素RSA雖然不是概率的，但可以通過隨機填充改造爲概率的)算法，無論是在理論界還是在工業界基本沒有人質疑他們本身的安全性。我們只使用ElGamal和RSA的組合而沒有爲我們的特定目標而創立算法的好處是我們自己不必去證明他的安全性；同時，即使是沒有任何安全基礎的用戶在明白原理後，也容易相信方案的安全性。此外，在需要取得相關安全認證時，我們只需去認證方案，而不用去認證新密碼算法。注意，這兩種認證的流程和難度是差別非常大的。在金融領域，特定公開機構的認證是採購流程所必須的。
-
效率：首先，方案的執行過程分爲預置和查詢兩個部分。在預置部分，供應方對數據做全量加密，將密文存儲並前置到需求方環境下（交付過程包括後續的增量更新支持在線和離線方式）。存儲量爲原始數據量的2倍(由於ElGamal加密的密文會膨脹爲明文的2倍)。在查詢部分，供應方對需求方的每次查詢請求做一次實時迴應。所以，方案的計算、通信效率都是正比於查詢數據量，存儲效率正比於總數據量。這裏可能有人會問，爲什麼不使用兩次RSA，把存儲效率再降低一倍呢？那是因爲RSA本身滿足同態性，但在JDK等公開的標準實現中卻不滿足。這就會造成RSA理論上是同態的，但程序員編程實現時卻又不滿足同態性。通常情況下，我們的程序實現要滿足客戶的代碼審查要求，而不能去隨意改動基礎庫的代碼。於是，2倍密文膨脹的ElGamal就變成了最佳選擇了。
4. 其它可能方案的對比
首先，我們看看現在現有金融領域是怎麼做的，然後再看看還有哪些可能的方案。目前，由於沒有有效的辦法來解決數據安全採購問題，需求方採取的是對數據源全量採購的辦法：即人工交付數據源在一段時間內的全部數據，再由相關數據部門做後續分析。其缺點除了小數據源效果不好，大數據源買不到之外，還有數據時效性不夠強，多源數據彙集困難等問題。在互聯網如此普及的時代只能採取離線方法實際上降低了需求方，尤其是小型銀行的市場競爭力。
對於一個信息安全領域的研究人員來說，當看到如何在需求方不出任何信息情況下補充外部標籤這一問題以後憑直覺想到的解決方案可能應該是：不經意傳輸。對我們來說同樣也是如此。這裏我們不介紹不經意傳輸的細節，只說原理。簡單以銀行舉例，每次銀行需要獲取標籤，供應方把自己所有的標籤對應的ID和標籤擺在銀行面前，銀行把所有的ID和標籤拿到自己那裏，選擇一個自己想要的，然後丟棄所有其它的。這樣供應商不知道銀行拿了哪個，銀行也只拿了他想要的那一個，既符合隱私保護需求，也可以精確計量。但是，這一方法的效率是非常低的，只是爲了讓銀行安全獲取一個標籤，就需要供應商負擔正比於數據總量的計算、通信、存儲開銷。對銀行來說，還不如直接購買全部數據來得快。所以，我們在實驗後得出的結論是，直接使用不經意傳輸在工程上是不合理的。於是，我們進一步結合k-匿名方法，對不經意傳輸做了改進，成百上千倍的提高了計算、通信、存儲開銷。我們可以通過在安全性和開銷之間做權衡，在客戶可接受安全性的前提下，儘量提高效率，但依然無法做到讓它們正比於在線查詢的次數。最終，我們使用了前面的基於同態的方法在保障數據安全的前提下實現效率的最優化。
下面的鏈接是我們針對這一方案的在線示例，分別模擬了需求方和供應方的操作。https://sdmk.talkingdata.com/#/home/datasecurity