一文搞懂支付安全體系建設
對於支付安全我自認比絕大部分支付行業的同行都專業,當年爲了做統一密鑰管理和加解密加驗籤平臺,啃了好幾本密碼學和信息安全的大部頭書。但我今天以產品經理都能看懂的白話講清楚支付安全體系,不涉及複雜的數學知識。
- 前言 =====
在電子支付的萬億級市場中,安全無疑是核心中的核心。大部分人都知道支付安全很重要,但支付安全具體包括哪些方面,面臨的問題,以及有哪些具體技術或方案來應對,包括在支付行業從業多年的老支付人,卻未必有全局而清晰的認知。
今天嘗試從在線支付面臨的主要安全問題,常見的技術手段如加密解密、簽名驗籤、安全證書等入手,嘗試講清楚支付安全體系。
通過這篇文章,你可以瞭解到如下內容:
-
在線支付面臨的主要安全問題。
-
常見的加密解密技術。
-
常見的簽名驗籤技術。
-
安全身份認證體系。
-
常見的安全協議。
-
密鑰存儲與統一安全服務。
-
工程應用中的常見問題。
-
在線支付面臨的主要安全問題 ================
在線支付面臨的安全問題主要包括:
- 賬號或密碼等敏感信息被盜用。
用戶的賬號和密碼可能會被黑客獲取,導致個人資金被盜用。這種情況是用戶普遍感知較強的安全問題,常見於密碼泄露導致資金損失的情況。
- 交易信息被篡改。
這個對於一般用戶感知較少,常見就是支付金額被篡改,比如實付金額小於應付金額,還就是轉賬時的收賬賬號或金額被篡改**。**
比如在轉賬場景下修改收款賬號或金額,當轉賬請求被黑客截獲,把原收款賬號修改爲另一個賬號,再發給支付平臺。如果支付平臺安全措施不到位,就可能把錢轉到一個錯誤的賬號上。
- 交易信息被抵賴。
這個比較少見。舉個場景,支付平臺請求銀行扣款 200 元,銀行實際扣款失敗,但是通知支付平臺成功,支付平臺也通知商戶發貨了。但是銀行說他們返回給支付平臺是扣款失敗,扣款成功的信息不是銀行發出來的。這種行爲是抵賴。
- 欺詐交易
包括套現、洗錢等違規交易,以及因爲用戶信息泄露導致盜刷等。
- 服務不可用攻擊。
這個出現的頻次非常高,只是一般人感覺不到。有興趣的同學可以搜索分佈式拒絕服務 DDoS(Distributed Denial of Service),攻擊者通過大量惡意流量佔用支付系統的資源,使得合法用戶無法正常訪問支付平臺,從而影響用戶的交易體驗甚至造成財務損失。
- 支付安全核心關注點 ============
支付安全是一個很大的範疇,但我們一般只需要重點關注以下幾個核心點就夠:
- 敏感信息安全存儲。
對個人和商戶 / 渠道的敏感信息進行安全存儲。
個人敏感信息包括身份證信息、支付卡明文數據和密碼等,而商戶 / 渠道的敏感信息則涉及商戶登錄 / 操作密碼、渠道證書密鑰等。
- 交易信息安全傳輸。
確保客戶端與支付系統服務器之間、商戶系統與支付系統之間、支付系統內部服務器與服務器之間、支付系統與銀行之間的數據傳輸安全。這包括採用加密技術等措施來保障數據傳輸過程中的安全性。
- 交易信息的防篡改與防抵賴。
確保交易信息的完整性和真實性,防止交易信息被篡改或者被抵賴。一筆典型的交易,通常涉及到用戶、商戶、支付機構、銀行四方,確保各方發出的信息沒有被篡改也無法被抵賴。
- 欺詐交易防範。
識別並防止欺詐交易,包括套現、洗錢等違規操作,以及通過識別用戶信息泄露和可疑交易來保護用戶資產的安全。這一方面通常由支付風控系統負責。
- 服務可用性。
防範 DDoS 攻擊,確保支付系統的穩定運行和服務可用性。通過部署防火牆、入侵檢測系統等技術手段,及時發現並應對可能的 DDoS 攻擊,保障支付服務的正常進行。
- 極簡支付安全大圖 ===========
支付安全是一個綜合性的系統工程,除了技術手段外,還需要建立健全的安全制度和合規制度,而後兩者通常被大部分人所忽略。
下圖是一個極簡版的支付安全大圖,包含了支付安全需要考慮的核心要點。
說明:
- 制度是基礎。
哪種場景下需要加密存儲,加密需要使用什麼算法,密鑰長度最少需要多少位,哪些場景下需要做簽名驗籤,這些都是制度就明確了的。制度通常分爲行業制度和內部安全制度。行業制度通常是國家層面制定的法律法規,比如《網絡安全法》、《支付業務管理辦法》等。內部安全制度通常是公司根據自身的業務和能力建立的制度,小公司可能就沒有。
- 技術手段主要圍繞四個目標:
1)敏感數據安全存儲。
2)交易安全傳輸。
3)交易的完整性和真實性。
4)交易的合法性(無欺詐)。
對應的技術手段有:
-
敏感信息安全存儲:採用加密技術對個人和商戶 / 渠道的敏感信息進行加密存儲,限制敏感信息的訪問權限,防止未授權的訪問和泄露。
-
交易信息安全傳輸:使用安全套接字層(SSL)或傳輸層安全性協議(TLS)等加密技術,確保數據在傳輸過程中的機密性和完整性。
-
交易的完整性和真實性:採用數字簽名技術和身份認證技術確保交易信息的完整性和真實性,對交易信息進行記錄和審計,建立可追溯的交易日誌,以應對可能出現的交易篡改或抵賴情況。
-
防範欺詐交易:通過支付風控系統,及時識別和阻止可疑交易行爲。
-
服務可用性:部署流量清洗設備和入侵檢測系統,及時發現並阻止惡意流量,確保支付系統的穩定運行和服務可用性,抵禦 DDoS 攻擊。
下面詳細講解各技術手段。
- 數據安全:加密與解密技術 ===============
加密和解密技術是數據安全的基礎,在支付安全技術的核心技術之一,無論是支付平臺與銀行之間的通信,還是支付平臺內部敏感數據的存儲,都需要用到加解密技術。
我儘量避免加解密技術背後高深的數學知識。
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.1. 什麼是簽名與驗籤
簽名驗籤是數字加密領域的兩個基本概念。
簽名:發送者將數據通過特定算法和密鑰轉換成一串唯一的密文串,也稱之爲數字簽名,和報文信息一起發給接收方。
驗籤:接收者根據接收的數據、數字簽名進行驗證,確認數據的完整性,以證明數據未被篡改,且確實來自聲稱的發送方。如果驗籤成功,就可以確信數據是完好且合法的。
下面是一個極簡的簽名驗籤數學公式。
假設被簽名的數據(m),簽名串(Σ),散列函數(H),私鑰(Pr),公鑰(Pu),加密算法(S),解密算法(S^),判斷相等(eq)。
簡化後的數學公式如下:
簽名:Σ=S[H(m), Pr]。
驗籤:f(v)=[H(m) eq S^(Σ, Pu)]。
流程如下:
簽名流程:
-
散列消息:對消息 (m) 應用散列函數(H)生成散列值(h)。
-
加密散列值:使用發送方的私鑰 (Pr) 對散列值 ( h ) 進行加密,生成簽名 ( Σ )。 Σ = S(h, Pr)
把數字簽名(Σ)和原始消息(m)一起發給接收方。
驗籤流程:
-
散列收到的消息:使用同樣的散列函數 (H) 對消息 ( m ) 生成散列值 ( h')。 h' = H(m)
-
解密簽名:使用發送方的公鑰 (Pu) 對簽名 (Σ ) 進行解密,得到散列值 ( h )。 h = S^(Σ, Pu)
-
比較散列值:比較解密得到的散列值 (h) 與直接對消息 ( m ) 散列得到的 ( h') 是否一致。 驗證成功條件: h = h' 。
如果兩個散列值相等,那麼驗籤成功,消息(m) 被認爲是完整的,且確實來自聲稱的發送方。如果不一致,就是驗籤失敗,消息可能被篡改,或者簽名是僞造的。
現實中的算法會複雜非常多,比如 RSA,ECDSA 等,還涉及到填充方案,隨機數生成,數據編碼等。
6.2. 支付系統爲什麼一定要做簽名驗籤
銀行怎麼判斷扣款請求是從確定的支付平臺發出來的,且數據沒有被篡改?商戶不承認發送過某筆交易怎麼辦?這都是簽名驗籤技術的功勞。
簽名驗籤主要解決 3 個問題:
- 身份驗證:確認支付信息是由真正的發送方發出,防止冒名頂替。
如果無法做身份驗證,支付寶就無法知道針對你的賬戶扣款 99 塊的請求是真實由你樓下小賣部發出去的,還是我冒充去扣的款。
- 完整性校驗:確認支付信息在傳輸過程中未被篡改,每一筆交易都是完整、準確的。
如果無法校驗完整性,那麼我在公共場景安裝一個免費 WIFI,然後截獲你的微信轉賬請求,把接收者修改成我的賬號,再轉發給微信,微信就有可能會把錢轉到我的賬號裏。
- 防抵賴性:避免任何一方否則曾經進行過的交易,提供法律證據支持。
比如微信支付調用銀行扣款 100 塊,銀行返回成功,商戶也給用戶發貨了,幾天後銀行說這筆扣款成功的消息不是他們返回的,他們沒有扣款。而簽名驗籤就能讓銀行無法抵賴。
流程:
-
雙方先交換密鑰,可以通過線下郵件交換,也可以通過線上自助平臺交換。
-
請求方發出交易報文前使用自己的私鑰進行簽名,接收方接收報文後先進行驗籤,驗籤通過後再進行業務處理。
-
接收方處理完業務,返回前使用自己的私鑰進行簽名,請求方接收返回報文後先進行驗籤,驗籤通過後再進行業務處理。
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 機構申請證書,這個在圖中已經省略。
-
用戶選購後,先把訂單信息生成摘要,然後把支付信息也生成摘要,把兩個摘要拼接起出新的摘要,最後使用自己私鑰簽名,也就是雙重簽名信息。
-
用戶把 “訂單信息 + 支付信息摘要 + 雙重簽名串” 發給商戶,商戶根據訂單信息生成摘要,並與支付信息摘要拼接後,拿用戶的公鑰進行驗籤。
-
用戶把 “支付信息密文 + 商戶信息摘要 + 雙重簽名串” 發給銀行(也可以通過商戶發給銀行),銀行先使用自己的私鑰解密出支付信息明文,生成摘要,再與訂單信息摘要拼接後,拿用戶的公鑰進行驗籤。
-
上述過程中,商戶不知道用戶的支付信息,比如卡號等,銀行不知道用戶的訂單信息,比如買了什麼,但是商戶和銀行能判斷對方是真實的。
-
身份合法性判斷:身份認證技術 =================
在互聯網支付中,怎麼證明你是你?這就是身份認證技術。下面講的證書、CA、PKI 等都相對比較專業的概念,這裏只做入門介紹,有興趣的同學可以找專業的文章深入學習,基本每個模塊都可以寫一本書。
7.1. 什麼是身份認證
在支付安全領域,身份認證就是確認支付交易的參與者是否是其聲稱的身份。簡單地說,就是證明你是你。這個功能最重要的當然是保護用戶賬戶安全,減少欺詐交易或盜刷,以及遵守合規要求。
7.2. 常見的身份認證方法
身份認證通常分爲個人身份認證和企業 / 機構身份認證。
常見的個人身份認證方法包括以下幾種:
-
**用戶名和密碼認證。**這沒什麼好說的,最常見的身份認證方式,但安全性相對較低,容易受到密碼猜測、密碼泄露等攻擊。
-
**多因素認證(MFA)。**就是要求用戶同時使用 2 種方式驗證身份,包括密碼、短信驗證碼、指紋識別、人臉識別、硬件令牌等。一般是後臺風控識別有風險時,纔會這樣。也經常叫風控挑戰。
-
**生物特徵認證。**使用個體的生物特徵(如指紋、虹膜、聲紋、人臉等)來進行身份驗證。這種認證方式通常需要專門的硬件設備來捕獲生物特徵,並使用算法進行比對。
-
**單點登錄(SSO)與 Oauth。**用戶只需在一個系統登錄,就可以授權訪問其它系統。比如大家可以使用微信或支付寶來登錄微博、小紅書等。
-
數字證書。由 CA 機構頒發個人數字證書,這個比較少見。
當涉及到企業或機構之間的身份認證時,常見的方法包括使用數字證書和雙向 TLS 認證(也稱爲客戶端證書認證)。數字證書可參考下一章節 “數字證書” 的說明,雙向 TLS 認證可參考 “TLS” 章節的說明。
7.3. 數字證書
數字證書(Digital Certificate)是一種用於在網絡通信中進行身份驗證和數據加密的安全技術。它是由一家被稱爲證書頒發機構(Certificate Authority,CA)的可信任實體頒發的電子文檔,用於證明某個實體(如網站、個人或組織)的身份和公鑰。
數字證書包含以下主要信息:
-
公鑰: 數字證書中包含了一個實體的公鑰,用於加密和解密通信數據。
-
持有者信息: 數字證書中包含了證書持有者的身份信息,如姓名、電子郵件地址等。
-
頒發者信息: 數字證書中包含了頒發該證書的證書頒發機構的信息,包括機構名稱、聯繫方式等。
-
有效期限: 數字證書中包含了證書的有效期限,即證書的生效日期和失效日期。
-
數字簽名: 數字證書中包含了頒發者對證書內容的數字簽名,用於驗證證書的真實性和完整性。
在網絡通信中,當客戶端與服務器建立安全連接時,服務器會向客戶端發送自己的數字證書。客戶端收到服務器的數字證書後,會使用證書中的公鑰來驗證服務器的身份和證書的真實性。如果驗證通過,客戶端就可以使用服務器的公鑰加密通信數據,並將加密後的數據發送給服務器。
比如你訪問以 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 等都是基於公私鑰理論之上,有興趣的同學可以去深入瞭解一下公私鑰理論及背後的數字知識。
- 數據傳輸安全:常見的傳輸安全協議 ===================
在互聯網上,所有的數據都通過網絡傳輸,在線支付的安全也繞不開數據傳輸安全。這裏簡單介紹一下各種常見的安全協議。
所有數據全部經過加密後再傳輸比較麻煩,能不能簡單一點,我們直接把傳輸的管道進行加密,然後傳輸明文數據?答案當然沒有問題,比如 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 協議的工作原理如下:
-
建立安全連接: 客戶端向服務器發送連接請求時,服務器會返回自己的數字證書,證明自己的身份和公鑰。客戶端收到服務器的數字證書後,會驗證證書的真實性和有效性。
-
協商加密算法: 客戶端和服務器在建立連接時會協商使用的加密算法和密鑰長度,以確保通信數據的機密性和安全性。
-
數據加密傳輸: 客戶端使用服務器的公鑰加密通信數據,並將加密後的數據發送給服務器。服務器收到加密數據後,使用自己的私鑰解密數據。
-
身份驗證: 在建立連接時,服務器發送的數字證書可以用於驗證服務器的身份。如果證書驗證通過,客戶端就可以信任服務器,並繼續進行安全通信。
簡單地理解,就是 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 解決。
- 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)所取代。當然,它在在線支付安全技術的發展過程中仍起到了重要的推動作用,爲後續安全支付標準的制定和實現奠定了基礎。
- 網絡流量安全:防火牆與入侵檢測 ===================
網絡安全和入侵檢測是保護計算機網絡和系統安全的重要組成部分,它們涉及各種技術和工具,包括防火牆、入侵檢測系統(IDS)、入侵防禦系統(IPS)、漏洞掃描器等。
這些內容通常歸屬於網絡工程師、系統工程師、及安全工程師的工作範圍,下面只做一個簡單介紹:
-
防火牆(Firewall): 防火牆是一種網絡安全設備,用於監控和控制網絡流量,阻止未經授權的訪問和惡意流量進入網絡。它可以根據預先定義的安全策略過濾和阻止來自 Internet 或內部網絡的流量,從而保護網絡免受攻擊和入侵。
-
入侵檢測系統(IDS): 入侵檢測系統是一種監視網絡流量和系統活動的安全設備,用於檢測和警報可能的安全威脅和入侵行爲。IDS 可以根據事先定義的規則或行爲模式檢測異常活動,並生成警報或採取措施來應對潛在的威脅。
-
入侵防禦系統(IPS): 入侵防禦系統是一種進一步加強網絡安全的設備,它不僅能夠檢測和警報安全威脅,還可以主動阻止和防禦入侵行爲。IPS 可以根據 IDS 的警報自動採取措施,如阻止惡意流量、更新防火牆規則等,以加強網絡的安全性。
-
漏洞掃描器(Vulnerability Scanner): 漏洞掃描器是一種用於檢測計算機系統和網絡中存在的安全漏洞和弱點的工具。它可以自動掃描系統和網絡,發現潛在的漏洞,並提供建議和修復措施,以減少系統受到攻擊的風險。
這些工具更多的是從數據包的維度來處理安全問題。數據包處理完成之後,纔會組裝成業務數據,才能被用於加解密、簽名驗籤等。
- 防欺詐交易:支付風控 ==============
支付風控是針對支付系統中的風險進行管理和控制的一種措施,旨在降低欺詐交易和財務損失的風險。
風控系統最核心最寶貴的資源是風控策略,因爲如果知道一家支付公司的風控策略,就意味着可以想辦法繞過支付系統的風控系統,進行欺詐交易。所以一般來說,研發風控系統的研發工程師往往不知道風控策略是怎麼配置的。
下圖是一個極簡的風控系統架構圖。
雖然風控的策略是高度機密,但是有些公開的策略,大家可以瞭解一下,比如說下面這些就屬於行爲異常,大概率會被風控:
-
你一直在中國小額支付,突然在國外支付 2 萬。
-
平時一直使用 IPHONE(風控會保存你的設備詳細信息),突然使用 Android 機器支付 2000 塊。
-
一般都是 10 天買件商品,實然 10 分鐘內支付 50 筆。
現代的風控系統不僅僅是策略,還有很多機器學習算法。但總的來說,仍然圍繞:當次支付行爲,歷史交易數據,配置的規則策略,規則引擎,機器學習等展開。
- 進階擴展:統一密鑰存儲與安全服務 ====================
12.1. 爲什麼需要統一安全存儲密鑰
明文數據被加密存儲,安全了,那加密明文數據的密鑰怎麼辦?
加密密鑰有多重要呢?有一個公式是這樣的:密鑰的價值 = 密文的價值。比如你加密存儲的密文價值 10 億,那對應的密鑰價值也有 10 億。
密鑰的管理涉及 4 個方面:密鑰存儲、更新、備份和恢復、廢止和銷燬。如果想要管好這些密鑰,就需要建設一個統一的密鑰存儲服務,否則密鑰很容易被泄露。
密鑰存儲:
安全存儲環境:密鑰保存在特殊的安全環境中,包括服務器、網絡環境、硬件加密機等。
最小權限原則:管理密鑰的人越少越好。
密鑰分爲主密鑰和工作密鑰,其中工作密鑰用來加解密普通的業務數據,而主密鑰用來加解密工作密鑰。
一般來說主密鑰應該存儲在專門的硬件安全模塊(HSM)中,俗稱:硬件加密機,安全性極高。但是相對來說性能有限,且價格昂貴,管理複雜。
工作密鑰一般由主密鑰加密後保存在 DB 中,在需要的時候調用主密鑰解密後,緩存在內存中,然後再去加解密普通的業務數據。
密鑰更新機制:
-
需要定期更新,減少被破解的風險。
-
自動定時更新,減少人爲失誤。‘
-
版本控制和回滾:要有版本號,要能快速回滾。
12.2. 統一密鑰平臺系統架構
說明:
-
需要使用硬件加密機 HSM 生成並保存主密鑰。
-
工作密鑰被主密鑰加密後,保存到 DB 中。
-
各應用調用密鑰管理系統進行加密解密、簽名驗籤,保證密鑰不被業務應用讀取,減少泄露風險。
-
結束語 =======
支付安全是一個很龐大且非常專業的領域,隨便拿一個加解密或簽名驗籤算法就可以寫一本厚厚的書,但對於我們大部分人來說,不需要掌握密碼學專家或專業安全工程師那麼多知識,文章中介紹的知識點已經足以超過 90% 的支付行業從業人員對支付安全的理解。
如果一定要濃縮一下精華,只需要記住下面 6 點:
-
大數據塊加解密:使用對稱加密算法 AES,密鑰長度 256 比特,簡稱 AES256。
-
小數據塊及簽名驗籤:使用非對稱加密算法 RSA,密鑰長度 2048,簡稱 RSA2048。
-
摘要算法:使用 SHA256。且摘要算法不推薦用於需要簽名驗籤的場景。
-
個人登錄 / 支付密碼:一定要加鹽值進行混淆。
-
網絡傳輸和文件傳輸:需要使用 HTTPS 和 SFP 提高數據傳輸安全性。
-
整體的安全性,需要同時用到對稱加密、非對稱加密,數字簽名,數字證書等多種技術手段。
深耕境內 / 跨境支付架構設計十餘年,歡迎關注並星標公衆號 “隱墨星辰”,以獲取最新的更文,和我一起深入解碼支付系統的方方面面。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/Kw6HqYB3rdPz6xJZtTUzuQ