最近接入pp助手的伺服器端支付, 按照PP官方提供的文件來看, 需要伺服器做RSA的驗證.

首先我們來看下

RSA的幾個標準用法

非對稱加密解密

假設A要把內容傳輸給B

1. B生成RSA的公鑰和金鑰, 這是成對出現的, 金鑰由B儲存, 把公鑰告訴A

2. A用B的公鑰加密內容, 並把密文內容傳輸給B

3. B用金鑰解密

驗證

證明某個內容是你發的, 而不是被別人冒名頂替, 例如git的push中就帶有這個功能

假設A有內容,  B要驗證內容確實由A發出

1. A生成公鑰和金鑰

2. A將內容做一個hash, 把hash碼用自己的金鑰加密並把這段密文發給B

3. B用A的公鑰對密文進行驗證, 即可確認密文是否由A發出

可以看出, 兩種用法都是典型的非對稱用法

但PP助手卻幹了件神奇的事情:

非對稱當對稱演算法加解密

在PP SDK官方文件裡, 我們找到了PHP語言的驗證方法, 方法裡使用了這樣一個API

從官方文件看得出這個使用openssl的演算法庫

類似的, 還有Java, C++, Python語言的處理方法

其中, C++也是用的openssl, Python則是需要預編譯C庫，在Ubuntu下需要手工patch M2Crypto的_ssl.c檔案.

先不說這些非正規的編譯,patch方法會造成多大的問題, 單就這個用公鑰解密就很蛋疼

從之前的RSA演算法中瞭解, 只有對公鑰進行驗證的方法, 也就是隻能得到是還是不是的結果. 但PP的SDK則要求必須用公鑰解密…

解出的資料為一段json, 以對比是否有訂單篡改.

那麼這種做法就等效於, 用最簡單的異或+一個公鑰進行訂單加密, 然後同樣用這個公鑰進行解密

只不過用RSA感覺很高階…

這種做法一旦公鑰在PP助手伺服器或者玩家的開發伺服器, 甚至原始碼洩露, 那麼馬上就有很大的偽造訂單的危險

我把這個做法發給朋友看, 他們說, 其實PP助手的開發者只管用了RSA, 跟傳輸不是明文就好了, 至於什麼資訊保安, 都是屁!