一文搞懂支付安全體系建設

0 評論 2369 瀏覽 4 收藏 66 分鐘

“支付安全體系全解析,筑牢電子支付防線?!?在電子支付廣泛普及的當下,其安全體系涵蓋哪些關鍵技術與環節?如何應對各類潛在風險,確保支付過程安全可靠?

對于支付安全我自認比絕大部分支付行業的同行都專業,當年為了做統一密鑰管理和加解密加驗簽平臺,啃了好幾本密碼學和信息安全的大部頭書。但我今天以產品經理都能看懂的白話講清楚支付安全體系,不涉及復雜的數學知識。

內容有點長,可以考慮使用電腦閱讀,效果會好不少。

1. 前言

在電子支付的萬億級市場中,安全無疑是核心中的核心。大部分人都知道支付安全很重要,但支付安全具體包括哪些方面,面臨的問題,以及有哪些具體技術或方案來應對,包括在支付行業從業多年的老支付人,卻未必有全局而清晰的認知。

今天嘗試從在線支付面臨的主要安全問題,常見的技術手段如加密解密、簽名驗簽、安全證書等入手,嘗試講清楚支付安全體系。

通過這篇文章,你可以了解到如下內容:

  • 在線支付面臨的主要安全問題。
  • 常見的加密解密技術。
  • 常見的簽名驗簽技術。
  • 安全身份認證體系。
  • 常見的安全協議。
  • 密鑰存儲與統一安全服務。
  • 工程應用中的常見問題。

2. 在線支付面臨的主要安全問題

在線支付面臨的安全問題主要包括:

賬號或密碼等敏感信息被盜用。

用戶的賬號和密碼可能會被黑客獲取,導致個人資金被盜用。這種情況是用戶普遍感知較強的安全問題,常見于密碼泄露導致資金損失的情況。

交易信息被篡改。

這個對于一般用戶感知較少,常見就是支付金額被篡改,比如實付金額小于應付金額,還就是轉賬時的收賬賬號或金額被篡改。

比如在轉賬場景下修改收款賬號或金額,當轉賬請求被黑客截獲,把原收款賬號修改為另一個賬號,再發給支付平臺。如果支付平臺安全措施不到位,就可能把錢轉到一個錯誤的賬號上。

交易信息被抵賴。

這個比較少見。舉個場景,支付平臺請求銀行扣款200元,銀行實際扣款失敗,但是通知支付平臺成功,支付平臺也通知商戶發貨了。但是銀行說他們返回給支付平臺是扣款失敗,扣款成功的信息不是銀行發出來的。這種行為是抵賴。

欺詐交易

包括套現、洗錢等違規交易,以及因為用戶信息泄露導致盜刷等。

服務不可用攻擊。

這個出現的頻次非常高,只是一般人感覺不到。有興趣的同學可以搜索分布式拒絕服務DDoS(Distributed Denial of Service),攻擊者通過大量惡意流量占用支付系統的資源,使得合法用戶無法正常訪問支付平臺,從而影響用戶的交易體驗甚至造成財務損失。

3. 支付安全核心關注點

 

支付安全是一個很大的范疇,但我們一般只需要重點關注以下幾個核心點就夠:

敏感信息安全存儲。

對個人和商戶/渠道的敏感信息進行安全存儲。

個人敏感信息包括身份證信息、支付卡明文數據和密碼等,而商戶/渠道的敏感信息則涉及商戶登錄/操作密碼、渠道證書密鑰等。

交易信息安全傳輸。

確??蛻舳伺c支付系統服務器之間、商戶系統與支付系統之間、支付系統內部服務器與服務器之間、支付系統與銀行之間的數據傳輸安全。這包括采用加密技術等措施來保障數據傳輸過程中的安全性。

交易信息的防篡改與防抵賴。

確保交易信息的完整性和真實性,防止交易信息被篡改或者被抵賴。一筆典型的交易,通常涉及到用戶、商戶、支付機構、銀行四方,確保各方發出的信息沒有被篡改也無法被抵賴。

欺詐交易防范。

識別并防止欺詐交易,包括套現、洗錢等違規操作,以及通過識別用戶信息泄露和可疑交易來保護用戶資產的安全。這一方面通常由支付風控系統負責。

服務可用性。

防范DDoS攻擊,確保支付系統的穩定運行和服務可用性。通過部署防火墻、入侵檢測系統等技術手段,及時發現并應對可能的DDoS攻擊,保障支付服務的正常進行。

4. 極簡支付安全大圖

支付安全是一個綜合性的系統工程,除了技術手段外,還需要建立健全的安全制度和合規制度,而后兩者通常被大部分人所忽略。

下圖是一個極簡版的支付安全大圖,包含了支付安全需要考慮的核心要點。

說明:

制度是基礎。

哪種場景下需要加密存儲,加密需要使用什么算法,密鑰長度最少需要多少位,哪些場景下需要做簽名驗簽,這些都是制度就明確了的。制度通常分為行業制度和內部安全制度。行業制度通常是國家層面制定的法律法規,比如《網絡安全法》、《支付業務管理辦法》等。內部安全制度通常是公司根據自身的業務和能力建立的制度,小公司可能就沒有。

技術手段主要圍繞四個目標:

1)敏感數據安全存儲。

2)交易安全傳輸。

3)交易的完整性和真實性。

4)交易的合法性(無欺詐)。

對應的技術手段有:

  • 敏感信息安全存儲:采用加密技術對個人和商戶/渠道的敏感信息進行加密存儲,限制敏感信息的訪問權限,防止未授權的訪問和泄露。
  • 交易信息安全傳輸:使用安全套接字層(SSL)或傳輸層安全性協議(TLS)等加密技術,確保數據在傳輸過程中的機密性和完整性。
  • 交易的完整性和真實性:采用數字簽名技術和身份認證技術確保交易信息的完整性和真實性,對交易信息進行記錄和審計,建立可追溯的交易日志,以應對可能出現的交易篡改或抵賴情況。
  • 防范欺詐交易:通過支付風控系統,及時識別和阻止可疑交易行為。
  • 服務可用性:部署流量清洗設備和入侵檢測系統,及時發現并阻止惡意流量,確保支付系統的穩定運行和服務可用性,抵御DDoS攻擊。

下面詳細講解各技術手段。

5. 數據安全:加密與解密技術

加密和解密技術是數據安全的基礎,在支付安全技術的核心技術之一,無論是支付平臺與銀行之間的通信,還是支付平臺內部敏感數據的存儲,都需要用到加解密技術。

我盡量避免加解密技術背后高深的數學知識。

5.1. 什么是加密和解密

在數字通信中,加密是將明文通過一定的算法和密鑰轉換成無法識別的密文的過程。這樣即使數據被截獲,未經授權的第三方也無法理解其內容。比如把明文“123”轉成“aexyeffidfdfwsd”。

解密則是加密的逆向過程,通過一定的算法和密鑰將密文轉換成明文的過程。比如把密文“aexyeffidfdfwsd”轉成“123”。

5.2. 對稱加密算法

對稱加密是使用相同的密鑰(稱為對稱密鑰)進行加密和解密。這意味著發送方和接收方必須在通信之前共享相同的密鑰。對稱加密算法使用簡單且高效,但密鑰分發和管理是其主要挑戰之一。

以下是一些常見的對稱加密算法、特點和應用場景:

AES(Advanced Encryption Standard,高級加密標準):

特點:安全性高,速度快,密鑰長度可變。

應用場景:廣泛應用于網絡通信、文件加密、數據庫加密等領域。也是支付行業使用的主流對稱加密算法。

DES(Data Encryption Standard,數據加密標準):

特點:較為古老,密鑰長度較短(56位),安全性相對較弱。

應用場景:曾經廣泛應用于保護數據傳輸和存儲,但由于密鑰長度較短和安全性較弱,現已基本被AES取代。

3DES(Triple DES,三重數據加密標準):

特點:通過對數據使用三次DES算法加密來增強安全性,但速度較慢。

應用場景:曾被廣泛用于替代DES,但由于速度較慢,已經基本被AES取代。

RC4(Rivest Cipher 4):

特點:速度快,簡單易用。

應用場景:曾經用于保護網絡通信和SSL/TLS協議中的加密,但由于安全性存在問題,已經不推薦使用。

IDEA(International Data Encryption Algorithm):

特點:速度快,安全性高。

應用場景:曾經用于網絡通信和文件加密,但由于專利限制和更先進的算法出現,應用逐漸減少。

AES目前被認為是最安全和最常用的對稱加密算法,推薦在支付行業使用。密鑰長度建議使用256比特或以上。

有些銀行要求整個報文進行加密,這個時候一般都是使用AES 256來加密。

5.3. 非對稱加密算法

非對稱加密算法使用一對密鑰(公鑰和私鑰)進行加密和解密。這兩個密鑰是相關聯的,但不相同。公鑰用于加密數據,私鑰用于解密數據,一定不能反過來,因為公鑰大家都有,如果使用私鑰加密,公鑰解密,大家都可以解密,就沒有安全性可言。這種加密方式具有密鑰分離的特點,即公鑰可以公開分發,而私鑰則保密保存。

另外,非對稱加密算法也用于簽名驗簽,拿私鑰簽名,公鑰驗簽(不能反過來)。

以下是一些常見的非對稱加密算法、特點和應用場景:

RSA(Rivest-Shamir-Adleman):

特點:安全性高,可靠性強,廣泛應用。

應用場景:用于加密通信、數字簽名、密鑰交換等各種安全領域。支付行業用得非常多。

DSA(Digital Signature Algorithm):

特點:用于數字簽名,驗證速度快。

應用場景:主要用于身份驗證和數字簽名,例如在SSL/TLS協議中用于網站認證。

ECC(Elliptic Curve Cryptography):

特點:密鑰長度短,安全性高,加密效率高。

應用場景:適用于移動設備和資源受限環境,例如智能手機、物聯網設備等。

DH(Diffie-Hellman):

特點:用于密鑰交換,實現安全的密鑰協商。

應用場景:用于安全通信中的密鑰協商,例如SSL/TLS協議中的密鑰交換階段。

RSA當前在支付行業應用最廣泛,ECC則逐漸成為移動設備和物聯網設備中的首選算法,因其在資源受限環境下的高效性能而備受青睞。RSA推薦密鑰長度為2048比特或以上,ECC推薦密鑰長度為256比特或以上。

5.4. 數字信封加密算法

數字信封加密算法組合了對稱加密、非對稱加密、數字簽名和驗簽等多種加密技術,用于在網絡通信中保護數據的安全性和完整性。傳輸的數據就像放在信封里面,只有收件人才能打開信封查看明文,所以被形象稱為數字信封加密。

它的原理是使用對稱加密算法對要傳輸的數據進行加密,然后再使用接收方的公鑰對對稱密鑰進行加密,再使用自己的私鑰進行簽名,最后將加密后的對稱密鑰和加密后的數據一起發送給接收方。接收方先使用對方的公鑰進行驗簽,再使用私鑰解密對稱密鑰,最后使用對稱密鑰解密數據。

不過大家日常聽得更多的可能是PGP(Pretty Good Privacy)。PGP是一種加密軟件套件,用于保護電子通信的安全性和隱私性。它由Philip Zimmermann于1991年創建,并成為了一種標準的加密工具,最開始用于保護電子郵件,后面被廣泛用于保護文件傳輸,比如支付平臺和銀行之間的文件。

PGP通常推薦使用RSA 2048和AES 256,前者用于加密對稱密鑰和簽名,后面用于加密大數據塊。

下圖是數字信封加解密算法的完整過程:

現在很多銀行的打款文件要求使用PGP加密,因為文件里面有卡號等敏感數據。

5.5. 加密算法和密鑰長度選擇

在加密應用中,算法和密鑰長度對安全性(破解難度)和性能(運算快慢)都有重要影響:

安全性:

非對稱加密算法通常比對稱加密算法更安全。比如RSA(非對稱加密)好于AES(對稱加密)。

同類算法,新算法通常比老算法更安全。比如AES和DES都是對稱加密算法,但是AES的安全性優于DES。

相同算法,密鑰越長,越安全,因為密鑰越長,密鑰空間越大,破解的難度就越大。比如AES 256(密鑰長度)的安全性優于AES 128(密鑰長度)。

性能:

對稱加密算法通常比非對稱加密算法運算更快。比如AES(對稱加密)好于RSA(非對稱加密)。

相同算法,密鑰越長,運算越慢,性能越差。比如AES 256(密鑰長度)就比AES 128(密鑰長度)要慢。因為密鑰長度增加了加密操作的復雜度和計算量,需要更多的計算資源和時間來執行加密和解密操作。

因此,在選擇加密算法和密鑰長度時,需要綜合考慮安全性和性能之間的平衡。一般來說,應選擇安全性較高的加密算法,并根據應用場景和性能要求選擇適當長度的密鑰。

當前支付行業推薦的算法和密鑰長度如下:

  • 算法選擇:對稱加密算法(如AES)適用于對大量數據進行快速加密和解密,而非對稱加密算法(如RSA)適用于密鑰交換和數字簽名等場景。
  • 密鑰長度選擇:AES建議選擇256比特或以上。RSA建議選擇2048比特或以上。5.6. 常見加密解密算法推薦

前面我們介紹了對稱加密和非對稱加密算法,兩者有不同的使用場景,在支付行業推薦的算法如下:

  • AES:當前最廣泛使用的對稱加密算法,速度快,適用于高速加密大量數據。密鑰長度推薦256比特或以上。
  • RSA:廣泛使用的非對稱加密算法,安全性比AES更高,但是加密速度慢,適用于小量數據或做為數字簽名使用。密鑰長度推薦2048比特或以上。

在一些場景里面,需要同時組合使用AES和RSA,比如大數據加密使用AES,AES密鑰通過RSA加密后傳輸,并通過RSA進行簽名,這樣既解決了安全性,又解決了加密速度的問題。

特別強調一點:千萬千萬不要自己去發明一種【私有的】,【自己認為很安全】的算法,并應用到生產環境。因為業界推薦的這些算法的安全性是經過大量數字家和計算機科學家論證過的,也經過工業界持續地驗證。

除了上面推薦的AES和RSA,各個國家基于特殊安全考慮,還有一些特別的加密算法,這些算法同樣經過大量數字家和計算機科學家論證過,但是有一定的使用門檻,有興趣的同學可以去找加密機廠家的資料了解。

5.7. 典型應用場景

支付系統做為一個安全系數非常高的系統,加解密技術在里面起到了極其重要的作用。

通常以下幾個核心應用場景都會用到加解密技術:

1)傳輸加密;

2)存儲加密。

傳輸加密:保護交易數據在互聯網上傳輸過程中的安全,防止數據被竊聽或篡改。

具體的實現通常有兩種:

1)通道加密:比如使用HTTPS,或者VPN、專線等,實現數據傳輸端到端的加密。

2)報文數據加密:部分字段單獨加密,比如把卡號等關鍵信息進行加密后再發出去。整體報文單獨加密,先組裝業務報文,然后對整個報文加密再發出去。

存儲加密:對敏感數據比如信用卡信息、用戶身份證信息、密碼等需要進行加密后存儲到數據庫中,以防止數據泄露。

具體的實現通常也會分兩種:

1)直接加密:原始信息直接加密。通常用于信用卡、身體證等常規數據的加密。

2)加鹽值(SALT)后再加密:原始信息先加上鹽值,然后再進行加密。通常用于密碼管理。所謂鹽值,就是一串隨機生成的字符串,比如:329713kud3s,9ds9jd9sj3es。

5.8. 登錄與支付密碼的特殊處理

登錄和支付密碼的傳輸和存儲都比較特殊,值得單獨說一說。

5.8.1. 登錄與支付密碼傳輸的特殊處理

登錄和支付密碼都是用戶輸入,如何保證在輸入時不被盜???如何保證傳輸的安全性?

輸入時一般會有安全控件,直接獲取輸入,其它應用無法在輸入盜取。然后使用公鑰加密,傳輸到后端后,再使用私鑰解密,再進行轉加密,最后保存到數據庫,或和數據庫的密碼對比判斷。

5.8.2. 登錄與支付密碼存儲的特殊處理

上一章節里,提到登錄或支付密碼需要加上鹽值后,再進行加密存儲。那為什么密碼管理需要使用鹽值?為了提高密碼安全性。

防止彩虹表攻擊。彩虹表是一種預先計算出來的哈希值數據集,攻擊者可以使用它來查找和破譯未加鹽的密碼。通過為每個用戶加鹽,即使是相同的密碼,由于鹽值不同,加密后的密文也是不一樣的。

保護相同密碼的用戶。如果多個用戶使用了相同的密碼,沒有鹽值情況下,一個被破解后,就能找到使用相同密碼的其它用戶。每個用戶不同的鹽值,確保生成的密文不同。

增加破解難度。尤其是密碼較弱時,顯著增加攻擊者難度。

在實現時,需要留意加鹽策略:

  • 隨機和唯一:每個用戶都是隨機和唯一的。
  • 存儲鹽值:每個用戶的密碼和鹽值都需要配對存儲。因為在加密密鑰更新時,需要使用鹽值一起先解密再重新加密。
  • 鹽值足夠長:增加復雜性,推薦至少128位。

5.9. PCI認證

如果要保存用戶的卡明文數據(比如用戶名和卡號),就一定要經過PCI(Payment Card Industry)認證,在PCI認證范圍內的域叫PCI域。

PCI安全標準(PCI DSS)是由PCI安全標準委員會(PCI SSC)制定和管理的一組安全標準,旨在保護持卡人數據的安全性和機密性。

簡單地說,PC規定了一個單獨的區域(簡稱PCI域),可以處理用戶的卡明文數據,包括加密后存儲,或使用明文,這個區域的網絡安全部署、數據訪問控制、數據加密、日志打印、安全策略等全部都有由PCI DSS規定,并定期接受相關認證組織的審查。

特別注意的是,PCI標準要求所有的域都不能打印用戶敏感信息,所有的域都不能存儲明文用戶敏感信息,比如卡只能打印前6后4,只有PCI域范圍內的應用才能使用卡明文數據。5.10. 加解密在工程應用中的常見問題

  • 密鑰管理不規范:把密鑰加密后保存在數據庫,但是加密密鑰用的密鑰是123456。
  • 算法選擇不合適:大批量數據選擇使用速度極慢的非對稱的RSA算法。
  • 兼容性算法不對:尤其是模式、填充方式是直接影響加解密結果的。比如AES下面仍然細分為:ECB,CBC,CFB,OFB,CTR,GCM等模式,以及PKCS7/PKCS5填充,零填充等填充方式。具體的可以找密碼學相關資料參考。
  • 異想天開地使用自己創造的私有算法:以為很安全,其實太傻太天真。
  • 管理機制不完善:沒有制定嚴格的規范,或有規范執行不嚴重,導致密鑰能被輕易訪問。

6. 防篡改與防抵賴:簽名與驗簽技術

防篡改與防抵賴一般也稱為數據的完整性和真實性驗證問題,通常使用簽名驗簽技術解決。

6.1. 什么是簽名與驗簽

簽名驗簽是數字加密領域的兩個基本概念。

  1. 簽名:發送者將數據通過特定算法和密鑰轉換成一串唯一的密文串,也稱之為數字簽名,和報文信息一起發給接收方。
  2. 驗簽:接收者根據接收的數據、數字簽名進行驗證,確認數據的完整性,以證明數據未被篡改,且確實來自聲稱的發送方。如果驗簽成功,就可以確信數據是完好且合法的。

下面是一個極簡的簽名驗簽數學公式。

假設被簽名的數據(m),簽名串(Σ),散列函數(H),私鑰(Pr),公鑰(Pu),加密算法(S),解密算法(S^),判斷相等(eq)。

簡化后的數學公式如下:

簽名:Σ=S[H(m), Pr]。

驗簽:f(v)=[H(m) eq S^(Σ, Pu)]。

流程如下:

簽名流程:

  1. 散列消息:對消息(m)應用散列函數(H)生成散列值(h)。
  2. 加密散列值:使用發送方的私鑰 ( Pr ) 對散列值 ( h ) 進行加密,生成簽名 ( Σ )。 Σ = S(h, Pr)
  3. 把數字簽名(Σ)和原始消息(m)一起發給接收方。

驗簽流程:

  1. 散列收到的消息:使用同樣的散列函數 ( H ) 對消息 ( m ) 生成散列值 ( h’ )。 ?h’ = H(m)
  2. 解密簽名:使用發送方的公鑰 ( Pu ) 對簽名 (Σ ) 進行解密,得到散列值 ( h )。 h = S^(Σ, Pu)
  3. 比較散列值:比較解密得到的散列值 ( h ) 與直接對消息 ( m ) 散列得到的 ( h’ ) 是否一致。 驗證成功條件: h = h’ 。
  4. 如果兩個散列值相等,那么驗簽成功,消息(m)被認為是完整的,且確實來自聲稱的發送方。如果不一致,就是驗簽失敗,消息可能被篡改,或者簽名是偽造的。
  5. 現實中的算法會復雜非常多,比如RSA,ECDSA等,還涉及到填充方案,隨機數生成,數據編碼等。

6.2. 支付系統為什么一定要做簽名驗簽

銀行怎么判斷扣款請求是從確定的支付平臺發出來的,且數據沒有被篡改?商戶不承認發送過某筆交易怎么辦?這都是簽名驗簽技術的功勞。

簽名驗簽主要解決3個問題:

  1. 身份驗證:確認支付信息是由真正的發送方發出,防止冒名頂替。
  2. 如果無法做身份驗證,支付寶就無法知道針對你的賬戶扣款99塊的請求是真實由你樓下小賣部發出去的,還是我冒充去扣的款。
  3. 完整性校驗:確認支付信息在傳輸過程中未被篡改,每一筆交易都是完整、準確的。

如果無法校驗完整性,那么我在公共場景安裝一個免費WIFI,然后截獲你的微信轉賬請求,把接收者修改成我的賬號,再轉發給微信,微信就有可能會把錢轉到我的賬號里。

防抵賴性:避免任何一方否則曾經進行過的交易,提供法律證據支持。

比如微信支付調用銀行扣款100塊,銀行返回成功,商戶也給用戶發貨了,幾天后銀行說這筆扣款成功的消息不是他們返回的,他們沒有扣款。而簽名驗簽就能讓銀行無法抵賴。

流程:

  1. 雙方先交換密鑰,可以通過線下郵件交換,也可以通過線上自助平臺交換。
  2. 請求方發出交易報文前使用自己的私鑰進行簽名,接收方接收報文后先進行驗簽,驗簽通過后再進行業務處理。
  3. 接收方處理完業務,返回前使用自己的私鑰進行簽名,請求方接收返回報文后先進行驗簽,驗簽通過后再進行業務處理。

6.3. 常見數字簽名算法及推薦算法

常見的數字簽名算法包括:

  • RSA(Rivest-Shamir-Adleman):RSA是一種基于大素數因子分解難題的非對稱加密算法,被廣泛應用于數字簽名和密鑰交換等領域。
  • DSA(Digital Signature Algorithm):DSA是一種基于離散對數問題的數字簽名算法,主要用于數字簽名領域。
  • ECDSA(Elliptic Curve Digital Signature Algorithm):ECDSA是一種基于橢圓曲線離散對數問題的數字簽名算法,具有比RSA更短的密鑰長度和更高的安全性。
  • EdDSA(Edwards-curve Digital Signature Algorithm):EdDSA是一種基于扭曲愛德華斯曲線的數字簽名算法,具有高效性和安全性,被廣泛用于加密貨幣等領域。

目前主流的數字簽名算法是RSA和ECDSA。RSA推出較早,且安全性足夠,現在使用非常廣泛。而ECDSA由于其較短的密鑰長度和更高的安全性,逐漸成為新興的數字簽名算法,特別適用于資源受限環境和移動設備等場景。

在支付場景來說,RSA使用最為廣泛,密鑰長度推薦2048比特。RSA1024以前使用得多,但因為密鑰長度較短,安全性不足,也已經不再推薦使用。

6.4. 一些與防篡改有關的技術

6.4.1. 數字摘要

數據摘要是一種通過對數據進行計算(也稱為哈希、摘要、散列計算),生成固定長度的唯一數據串(通常稱為摘要或哈希值),用于驗證數據的完整性和一致性的技術。數據摘要通常用于驗證數據在傳輸或存儲過程中是否發生了更改。

上面有個缺陷,就是在傳輸過程中,報文被黑客截獲,然后把100萬字的文章和摘要報文全部替換,服務端發現不了的。這個缺陷在下面的HMAC算法中會解決。

常見的數據摘要算法包括:

  • MD5(Message Digest Algorithm 5): MD5是一種常用的哈希算法,產生128位的哈希值。然而,由于MD5存在嚴重的安全性缺陷,已經不推薦用于安全性要求較高的場景。
  • SHA-1(Secure Hash Algorithm 1): SHA-1是一種較為安全的哈希算法,產生160位的哈希值。然而,由于SHA-1也存在一些安全性問題,如碰撞攻擊,因此在一些安全性要求較高的場景中也不推薦使用。
  • SHA-256、SHA-384、SHA-512: 這些是SHA-1的后續版本,分別產生256位、384位和512位的哈希值。它們提供了更高的安全性,通常被用于對安全性要求較高的數據進行摘要。
  • RIPEMD(RACE Integrity Primitives Evaluation Message Digest): RIPEMD系列是一組與MD4和MD5相似的哈希算法,產生128位、160位、256位和320位的哈希值。雖然不如SHA系列算法流行,但在某些場景下仍然有用。
  • BLAKE、Keccak、Whirlpool等: 這些是一些新興的哈希算法,設計更加安全和高效,被廣泛用于密碼學和區塊鏈等領域。

當前在支付行業推薦的摘要算法是SHA256。

需要說明的是,數字簽名需要用到數字摘要算法,但是數字摘要算法不能替代數字簽名。因為數字摘要只能證明數據是否完整,無法證明數據一定是某個人或某個機構發出來的。但是在國外很多支付機構,仍然使用MD5或SHA256這種摘要算法來代替驗名驗簽。

6.4.2. HMAC算法

HMAC(Hash-based Message Authentication Code)是一種基于哈希函數(摘要)和密鑰的消息認證碼算法,通常用于驗證消息的完整性和真實性。

HMAC算法結合了哈希函數和密鑰,通過對消息進行哈希運算,并使用密鑰進行加密,生成一個唯一的摘要。這個摘要就是消息的認證碼,用于驗證消息的完整性和真實性。

HMAC因為使用摘要算法和對稱加密,運算簡單而快速,所以許多場景下,HMAC是一種簡單而有效的選擇,也被用作消息的完整性保護和身份驗證。所以在支付場景下,也經常用于簽名驗簽。

但需要說明的是,HMAC解決了純摘要算法的部分問題,但仍不是嚴格意義上的數字簽名算法,因為HMAC使用的是雙方都擁有的對稱密鑰,無法證明消息一定是對方發出的,因為也有可能是某方偽造的。

6.4.3. 數字時間戳

數字時間戳是一種用于確定特定事件發生時間的數字簽名或哈希值,通常由數字時間戳服務(DTS:digital time-stamp service)頒發。數字時間戳將特定事件的時間信息與數字簽名或哈希值綁定在一起,以確保該事件在特定時間之前已經存在,從而防止后續的篡改或偽造。

比如兩個科學家都聲稱自己先于對方完成了某個證明或實驗,如果雙方把相關的材料通過數字時間戳服務進行了數字時間戳簽名,那么就可以輕而易舉解決這個問題。

數字時間戳的應用場景主要在文件證明,電子郵件,數字證書等,比如法律文件、合同、知識產權、證書等,以證明在某個時間之前就存在了這份文件。

不過在支付系統中,目前比較少使用數字時間戳。

6.4.4. 雙重數字簽名

雙重數字簽名是安全電子交易協議 (Secure Electronic Transaction, 簡稱SET協議)中引入一個概念。因為SET協議過于復雜,且互聯網出現了新的更簡便的安全協議,比如SSL(Secure Sockets Layer)/TLS(Transport Layer Security)/HTTPS(Hypertext Transfer Protocol Secure),SET實際沒有大規模應用。所在當代支付系統中,目前比較少見雙重數字簽名。

雙重數字簽名原理有點繞,我嘗試講清楚:

說明:

  • 用戶、商戶、銀行分別向CA機構申請證書,這個在圖中已經省略。
  • 用戶選購后,先把訂單信息生成摘要,然后把支付信息也生成摘要,把兩個摘要拼接起出新的摘要,最后使用自己私鑰簽名,也就是雙重簽名信息。
  • 用戶把“訂單信息 + 支付信息摘要 + 雙重簽名串”發給商戶,商戶根據訂單信息生成摘要,并與支付信息摘要拼接后,拿用戶的公鑰進行驗簽。
  • 用戶把“支付信息密文 + 商戶信息摘要 + 雙重簽名串”發給銀行(也可以通過商戶發給銀行),銀行先使用自己的私鑰解密出支付信息明文,生成摘要,再與訂單信息摘要拼接后,拿用戶的公鑰進行驗簽。
  • 上述過程中,商戶不知道用戶的支付信息,比如卡號等,銀行不知道用戶的訂單信息,比如買了什么,但是商戶和銀行能判斷對方是真實的。

7. 身份合法性判斷:身份認證技術

在互聯網支付中,怎么證明你是你?這就是身份認證技術。下面講的證書、CA、PKI等都相對比較專業的概念,這里只做入門介紹,有興趣的同學可以找專業的文章深入學習,基本每個模塊都可以寫一本書。

7.1. 什么是身份認證

在支付安全領域,身份認證就是確認支付交易的參與者是否是其聲稱的身份。簡單地說,就是證明你是你。這個功能最重要的當然是保護用戶賬戶安全,減少欺詐交易或盜刷,以及遵守合規要求。

7.2. 常見的身份認證方法

身份認證通常分為個人身份認證和企業/機構身份認證。

常見的個人身份認證方法包括以下幾種:

  • 用戶名和密碼認證。這沒什么好說的,最常見的身份認證方式,但安全性相對較低,容易受到密碼猜測、密碼泄露等攻擊。
  • 多因素認證(MFA)。就是要求用戶同時使用2種方式驗證身份,包括密碼、短信驗證碼、指紋識別、人臉識別、硬件令牌等。一般是后臺風控識別有風險時,才會這樣。也經常叫風控挑戰。
  • 生物特征認證。使用個體的生物特征(如指紋、虹膜、聲紋、人臉等)來進行身份驗證。這種認證方式通常需要專門的硬件設備來捕獲生物特征,并使用算法進行比對。
  • 單點登錄(SSO)與Oauth。用戶只需在一個系統登錄,就可以授權訪問其它系統。比如大家可以使用微信或支付寶來登錄微博、小紅書等。
  • 數字證書。由CA機構頒發個人數字證書,這個比較少見。

當涉及到企業或機構之間的身份認證時,常見的方法包括使用數字證書和雙向TLS認證(也稱為客戶端證書認證)。數字證書可參考下一章節“數字證書”的說明,雙向TLS認證可參考“TLS”章節的說明。

7.3. 數字證書

數字證書(Digital Certificate)是一種用于在網絡通信中進行身份驗證和數據加密的安全技術。它是由一家被稱為證書頒發機構(Certificate Authority,CA)的可信任實體頒發的電子文檔,用于證明某個實體(如網站、個人或組織)的身份和公鑰。

數字證書包含以下主要信息:

  • 公鑰: 數字證書中包含了一個實體的公鑰,用于加密和解密通信數據。
  • 持有者信息: 數字證書中包含了證書持有者的身份信息,如姓名、電子郵件地址等。
  • 頒發者信息: 數字證書中包含了頒發該證書的證書頒發機構的信息,包括機構名稱、聯系方式等。
  • 有效期限: 數字證書中包含了證書的有效期限,即證書的生效日期和失效日期。
  • 數字簽名: 數字證書中包含了頒發者對證書內容的數字簽名,用于驗證證書的真實性和完整性。

在網絡通信中,當客戶端與服務器建立安全連接時,服務器會向客戶端發送自己的數字證書??蛻舳耸盏椒掌鞯臄底肿C書后,會使用證書中的公鑰來驗證服務器的身份和證書的真實性。如果驗證通過,客戶端就可以使用服務器的公鑰加密通信數據,并將加密后的數據發送給服務器。

比如你訪問以https開頭的網站,瀏覽器就會驗證網站服務商的證書。

在支付系統中,某些銀行在對接時會要求雙向證書認證。

7.4. 數字證書頒發機構CA

我們憑什么相信一個證書是可信的呢?那就是由CA來證明。那我們憑什么相信一個CA機構?通常由政府或大型組織聯盟來做信用背書。

在數字證書領域,CA指的是Certificate Authority(證書頒發機構)。CA是一種可信的第三方機構,負責頒發、管理和驗證數字證書,以確保數字證書的合法性和可信度。

CA的主要職責包括:

  • 頒發數字證書: CA頒發數字證書給證書申請者,并確保證書的有效性和真實性。在頒發數字證書之前,CA會對證書申請者進行身份驗證,以確保其身份的合法性。
  • 證書管理: CA負責管理已頒發的數字證書,包括證書的更新、吊銷和查找等操作。CA會定期檢查數字證書的有效性,并對已過期或失效的證書進行吊銷操作。
  • 證書驗證: CA提供數字證書的驗證服務,用于驗證數字證書的真實性和完整性。通過驗證數字證書的簽名和證書鏈,可以確保數字證書的合法性,并確認證書持有者的身份。
  • 信任鏈管理: CA維護一個信任鏈,用于建立數字證書的信任關系。信任鏈包括根證書、中間證書和終端證書,每個證書都由上級證書簽名,直至根證書,確保數字證書的信任可靠性。

常見的CA包括全球性的CA,如VeriSign、GeoTrust、DigiCert等,以及國家或地區性的CA,如中國電子認證服務(CFCA)、中國互聯網絡信息中心(CNNIC)等。這些CA都遵循國際標準和行業規范,提供可信賴的數字證書服務,用于保障網絡通信的安全和可信度。

上面有提到一個信任鏈管理,這個是一個很重要的概念。頂級的證書機構不可能為所有用戶提供服務,但是它可以為下級機構簽發證書,然后由下級機構再給終端用戶簽發證書。如果驗證證書有效性,只需要依次驗證簽發的CA機構即可。

7.5. PKI

上面提到的數字證書的理論基礎就是公鑰基礎設施(Public Key Infrastructure,簡稱PKI),是一種用于管理和驗證公鑰的框架和體系結構。PKI提供了一套標準化的方法,用于生成、存儲、分發和撤銷公鑰,以確保安全的網絡通信和身份驗證。

PKI體系結構包括以下主要組件:

  • 數字證書: PKI使用數字證書來證明實體的身份,其中包含了實體的公鑰以及其他相關信息,如證書的頒發者、有效期等。數字證書由證書頒發機構(CA)頒發,并通過數字簽名保證其真實性和完整性。
  • 證書頒發機構(CA): CA是負責頒發、管理和驗證數字證書的可信機構。CA通過數字簽名對數字證書進行簽名,以證明證書的真實性,并提供證書撤銷服務(CRL或OCSP)來吊銷已失效的證書。
  • 注冊機構(RA): RA是CA的輔助機構,負責用戶身份驗證和數字證書的申請處理。RA通常收集用戶的身份信息,并將其提交給CA進行審批和頒發數字證書。
  • 證書存儲庫: 證書存儲庫用于存儲和管理已頒發的數字證書,以便用戶和應用程序檢索和驗證證書。
  • 密鑰管理: PKI提供了密鑰生成、分發和管理的功能,包括公鑰和私鑰的生成、存儲和交換。

PKI通過數字證書和公鑰加密技術,實現了安全的身份驗證、數據加密和數字簽名等功能,是保障網絡通信安全的重要基礎設施。也是支付安全體系的重要基礎設施。

證書、CA、PKI等都是基于公私鑰理論之上,有興趣的同學可以去深入了解一下公私鑰理論及背后的數字知識。

8. 數據傳輸安全:常見的傳輸安全協議

在互聯網上,所有的數據都通過網絡傳輸,在線支付的安全也繞不開數據傳輸安全。這里簡單介紹一下各種常見的安全協議。

所有數據全部經過加密后再傳輸比較麻煩,能不能簡單一點,我們直接把傳輸的管道進行加密,然后傳輸明文數據?答案當然沒有問題,比如SSL,TLS,HTTPS,VPN,專線等都是這個范疇。

這部分內容大部分都是安全工程師關注的范圍,大家只需要了解即可。

8.1. SSL

SSL(Secure Sockets Layer,安全套接層)是一種用于保護網絡通信安全的協議。它最初由網景公司(Netscape)開發,并于1994年首次發布。SSL協議通過在應用層和傳輸層之間建立安全通道,提供了加密、完整性驗證和身份認證等功能,用于保護網絡通信的安全性。

SSL協議的主要功能包括:

  • 加密通信: SSL協議使用加密算法對通信數據進行加密,以防止被竊聽者竊取敏感信息。它支持多種加密算法,包括對稱加密算法(如DES、3DES、AES)和非對稱加密算法(如RSA、Diffie-Hellman)等。
  • 完整性驗證: SSL協議使用消息認證碼(MAC)或數字簽名來驗證通信數據的完整性,以防止數據被篡改。接收方可以通過驗證MAC或數字簽名來確保收到的數據未被篡改。
  • 身份認證: SSL協議支持服務器和客戶端之間的身份認證,以確保通信雙方的身份是合法的。服務器通常會提供數字證書來證明其身份,客戶端可以使用證書來驗證服務器的身份。SSL還支持雙向身份認證,即客戶端和服務器都可以進行身份認證。
  • 會話管理: SSL協議支持會話復用,以減少握手過程的開銷和提高通信效率。

SSL協議最初廣泛應用于Web瀏覽器和Web服務器之間的安全通信,用于保護網頁傳輸的敏感信息,如用戶名、密碼和信用卡信息等。隨著SSL協議的發展和演進,它逐漸被TLS協議所取代,但人們通常仍將TLS協議統稱為SSL。

8.2. TSL

TLS(Transport Layer Security,傳輸層安全)協議是一種用于保護網絡通信安全的協議。它建立在SSL(Secure Sockets Layer,安全套接層)協議的基礎上,并在SSL的基礎上進行了改進和擴展。TLS協議提供了數據的加密、完整性驗證和身份認證等功能,用于保護網絡通信的安全性。

TLS協議的主要功能和SSL一致,這里不重復說明。另外,隨著網絡安全威脅的不斷增加,TLS協議也在不斷發展和完善,以提供更強大的安全保護機制。

8.3. HTTPS

HTTPS(Hypertext Transfer Protocol Secure)是一種用于安全傳輸超文本的通信協議。它是在HTTP協議的基礎上加入了SSL/TLS協議進行數據加密和身份驗證,用于保護網絡通信的安全性。

HTTPS協議的工作原理如下:

  • 建立安全連接: 客戶端向服務器發送連接請求時,服務器會返回自己的數字證書,證明自己的身份和公鑰??蛻舳耸盏椒掌鞯臄底肿C書后,會驗證證書的真實性和有效性。
  • 協商加密算法: 客戶端和服務器在建立連接時會協商使用的加密算法和密鑰長度,以確保通信數據的機密性和安全性。
  • 數據加密傳輸: 客戶端使用服務器的公鑰加密通信數據,并將加密后的數據發送給服務器。服務器收到加密數據后,使用自己的私鑰解密數據。
  • 身份驗證: 在建立連接時,服務器發送的數字證書可以用于驗證服務器的身份。如果證書驗證通過,客戶端就可以信任服務器,并繼續進行安全通信。

簡單地理解,就是HTTP全部是明文傳輸,HTTPS構建在SSL/TSL之上,所有傳輸的數據是經過加密的。

除了HTTPS之外,還有其它一些傳輸協議是構建在SSL/TSL之上的,比如文件傳輸協議FTP是明文傳輸,SFTP也是基于SSL/TSL之上的加密傳輸。

8.4. VPN與專線

VPN(Virtual Private Network)和專線(Dedicated Line)都是用于建立安全、可靠的網絡連接的技術,但它們之間存在一些區別。

VPN:

VPN是通過公共網絡(如互聯網)建立的虛擬私有網絡,用于安全地連接遠程地點或用戶到企業內部網絡。

VPN使用加密和隧道技術,將數據在公共網絡上進行加密和傳輸,以確保通信的安全性和隱私性。

VPN通常依賴于軟件或硬件設備(如VPN服務器、VPN客戶端和VPN路由器)來建立和管理安全連接。

專線:

專線是一種物理連接,通常由電信提供商提供,用于在兩個或多個地點之間建立私有的、專用的網絡連接。

專線可以是光纖、電纜或其他物理媒介,通常具有固定的帶寬和可靠的連接質量。

專線不依賴于公共網絡,因此通常具有更高的安全性和穩定性,適用于需要高可靠性和低延遲的應用場景。

簡單地說,VPN更靈活和成本更低,適用于遠程訪問、移動辦公和跨地域連接等場景。專線則很貴,更適用于需要高帶寬、低延遲和高安全性的應用,如數據中心互連、企業網絡內部連接等。

像支付寶與銀聯、網聯就是通過專線連接。以前一些大支付公司和大銀行直連時,一般也是通過專線連接,而一些小銀行因為成本考慮就會選擇VPN,甚至直接公網走https解決。

9. SET協議:過于復雜的設計

需要終端用戶參與的產品,一定是越簡單越好,否則一定會被時代淘汰,比如SET協議。

SET(Secure Electronic Transaction)協議是由Visa和MasterCard等信用卡組織于1996年提出,并得到了IBM、Microsoft等大公司支持,旨在提供更安全、更可信的在線支付體驗。

SET協議的設計目標是解決傳統網絡上的信用卡交易存在的安全隱患,如信用卡號被竊取、篡改、重放攻擊等問題。為了實現這一目標,SET協議引入了許多安全機制和加密技術,包括數字證書、數字簽名、對稱加密和公鑰加密等。

SET協議的主要特點包括:

  • 雙重身份認證: SET協議要求商家和消費者之間進行雙重身份認證,以確保雙方的身份是合法的。商家需要向信用卡機構提供數字證書以證明其身份,而消費者需要使用數字證書和PIN碼來驗證其身份。
  • 加密通信: SET協議使用加密算法對通信數據進行加密,以防止被竊聽者竊取敏感信息。它采用了對稱加密和公鑰加密相結合的方式,保護交易數據的安全性。
  • 數字簽名: SET協議使用數字簽名來驗證交易的完整性和真實性,防止交易數據被篡改。商家在向消費者發送訂單信息時使用自己的私鑰進行簽名,消費者在確認訂單時可以驗證商家的簽名以確保訂單的真實性。
  • 安全證書管理: SET協議使用數字證書來驗證交易參與者的身份,確保其合法性和可信度。商家和消費者都需要持有有效的數字證書,并通過信任的證書頒發機構(CA)進行驗證。

如前面所說,盡管SET協議的起點很高,不但有Visa和MasterCard兩大卡組聯手推出,還得到IBM、微軟等巨頭支持,在安全性方面具有較高水平,但由于其復雜性和高成本,仍然敗走麥城,并沒有得到廣泛采用,而是被后來出現的其他安全支付解決方案(如SSL/TLS協議和3D Secure)所取代。當然,它在在線支付安全技術的發展過程中仍起到了重要的推動作用,為后續安全支付標準的制定和實現奠定了基礎。

10. 網絡流量安全:防火墻與入侵檢測

網絡安全和入侵檢測是保護計算機網絡和系統安全的重要組成部分,它們涉及各種技術和工具,包括防火墻、入侵檢測系統(IDS)、入侵防御系統(IPS)、漏洞掃描器等。

這些內容通常歸屬于網絡工程師、系統工程師、及安全工程師的工作范圍,下面只做一個簡單介紹:

  • 防火墻(Firewall): 防火墻是一種網絡安全設備,用于監控和控制網絡流量,阻止未經授權的訪問和惡意流量進入網絡。它可以根據預先定義的安全策略過濾和阻止來自Internet或內部網絡的流量,從而保護網絡免受攻擊和入侵。
  • 入侵檢測系統(IDS): 入侵檢測系統是一種監視網絡流量和系統活動的安全設備,用于檢測和警報可能的安全威脅和入侵行為。IDS可以根據事先定義的規則或行為模式檢測異?;顒?,并生成警報或采取措施來應對潛在的威脅。
  • 入侵防御系統(IPS): 入侵防御系統是一種進一步加強網絡安全的設備,它不僅能夠檢測和警報安全威脅,還可以主動阻止和防御入侵行為。IPS可以根據IDS的警報自動采取措施,如阻止惡意流量、更新防火墻規則等,以加強網絡的安全性。
  • 漏洞掃描器(Vulnerability Scanner): 漏洞掃描器是一種用于檢測計算機系統和網絡中存在的安全漏洞和弱點的工具。它可以自動掃描系統和網絡,發現潛在的漏洞,并提供建議和修復措施,以減少系統受到攻擊的風險。

這些工具更多的是從數據包的維度來處理安全問題。數據包處理完成之后,才會組裝成業務數據,才能被用于加解密、簽名驗簽等。

11. 防欺詐交易:支付風控

支付風控是針對支付系統中的風險進行管理和控制的一種措施,旨在降低欺詐交易和財務損失的風險。

風控系統最核心最寶貴的資源是風控策略,因為如果知道一家支付公司的風控策略,就意味著可以想辦法繞過支付系統的風控系統,進行欺詐交易。所以一般來說,研發風控系統的研發工程師往往不知道風控策略是怎么配置的。

下圖是一個極簡的風控系統架構圖。

雖然風控的策略是高度機密,但是有些公開的策略,大家可以了解一下,比如說下面這些就屬于行為異常,大概率會被風控:

你一直在中國小額支付,突然在國外支付2萬。

平時一直使用IPHONE(風控會保存你的設備詳細信息),突然使用Android機器支付2000塊。

一般都是10天買件商品,實然10分鐘內支付50筆。

現代的風控系統不僅僅是策略,還有很多機器學習算法。但總的來說,仍然圍繞:當次支付行為,歷史交易數據,配置的規則策略,規則引擎,機器學習等展開。

12. 進階擴展:統一密鑰存儲與安全服務

12.1. 為什么需要統一安全存儲密鑰

明文數據被加密存儲,安全了,那加密明文數據的密鑰怎么辦?

加密密鑰有多重要呢?有一個公式是這樣的:密鑰的價值 = 密文的價值。比如你加密存儲的密文價值10億,那對應的密鑰價值也有10億。

密鑰的管理涉及4個方面:密鑰存儲、更新、備份和恢復、廢止和銷毀。如果想要管好這些密鑰,就需要建設一個統一的密鑰存儲服務,否則密鑰很容易被泄露。

密鑰存儲:

安全存儲環境:密鑰保存在特殊的安全環境中,包括服務器、網絡環境、硬件加密機等。

最小權限原則:管理密鑰的人越少越好。

密鑰分為主密鑰和工作密鑰,其中工作密鑰用來加解密普通的業務數據,而主密鑰用來加解密工作密鑰。

一般來說主密鑰應該存儲在專門的硬件安全模塊(HSM)中,俗稱:硬件加密機,安全性極高。但是相對來說性能有限,且價格昂貴,管理復雜。

工作密鑰一般由主密鑰加密后保存在DB中,在需要的時候調用主密鑰解密后,緩存在內存中,然后再去加解密普通的業務數據。

密鑰更新機制:

需要定期更新,減少被破解的風險。

自動定時更新,減少人為失誤。

版本控制和回滾:要有版本號,要能快速回滾。

12.2. 統一密鑰平臺系統架構

說明:

需要使用硬件加密機HSM生成并保存主密鑰。

工作密鑰被主密鑰加密后,保存到DB中。

各應用調用密鑰管理系統進行加密解密、簽名驗簽,保證密鑰不被業務應用讀取,減少泄露風險。

13. 結束語

支付安全是一個很龐大且非常專業的領域,隨便拿一個加解密或簽名驗簽算法就可以寫一本厚厚的書,但對于我們大部分人來說,不需要掌握密碼學專家或專業安全工程師那么多知識,文章中介紹的知識點已經足以超過90%的支付行業從業人員對支付安全的理解。

如果一定要濃縮一下精華,只需要記住下面6點:

  1. 大數據塊加解密:使用對稱加密算法AES,密鑰長度256比特,簡稱AES256。
  2. 小數據塊及簽名驗簽:使用非對稱加密算法RSA,密鑰長度2048,簡稱RSA2048。
  3. 摘要算法:使用SHA256。且摘要算法不推薦用于需要簽名驗簽的場景。
  4. 個人登錄/支付密碼:一定要加鹽值進行混淆。
  5. 網絡傳輸和文件傳輸:需要使用HTTPS和SFP提高數據傳輸安全性。
  6. 整體的安全性,需要同時用到對稱加密、非對稱加密,數字簽名,數字證書等。

本文由人人都是產品經理作者【隱墨星辰】,微信公眾號:【隱墨星辰】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于 CC0 協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!