最近接入pp助手的服務器端支付, 按照PP官方提供的文檔來看, 需要服務器做RSA的驗證.
首先我們來看下
RSA的幾個標準用法
非對稱加密解密
假設A要把內(nèi)容傳輸給B
1. B生成RSA的公鑰和密鑰, 這是成對出現(xiàn)的, 密鑰由B保存, 把公鑰告訴A
2. A用B的公鑰加密內(nèi)容, 并把密文內(nèi)容傳輸給B
3. B用密鑰解密
驗證
證明某個內(nèi)容是你發(fā)的, 而不是被別人冒名頂替, 例如git的push中就帶有這個功能
假設A有內(nèi)容, B要驗證內(nèi)容確實由A發(fā)出
1. A生成公鑰和密鑰
2. A將內(nèi)容做一個hash, 把hash碼用自己的密鑰加密并把這段密文發(fā)給B
3. B用A的公鑰對密文進行驗證, 即可確認密文是否由A發(fā)出
可以看出, 兩種用法都是典型的非對稱用法
但PP助手卻干了件神奇的事情:
非對稱當對稱算法加解密
在PP SDK官方文檔里, 我們找到了PHP語言的驗證方法, 方法里使用了這樣一個API
openssl_public_decrypt
從官方文檔看得出這個使用openssl的算法庫
類似的, 還有Java, C++, Python語言的處理方法
其中, C++也是用的openssl, Python則是需要預編譯C庫，在Ubuntu下需要手工patch M2Crypto的_ssl.c文件.
先不說這些非正規(guī)的編譯,patch方法會造成多大的問題, 單就這個用公鑰解密就很蛋疼
從之前的RSA算法中了解, 只有對公鑰進行驗證的方法, 也就是只能得到是還是不是的結(jié)果. 但PP的SDK則要求必須用公鑰解密…
解出的數(shù)據(jù)為一段json, 以對比是否有訂單篡改.
那么這種做法就等效于, 用最簡單的異或+一個公鑰進行訂單加密, 然后同樣用這個公鑰進行解密
只不過用RSA感覺很高級…
這種做法一旦公鑰在PP助手服務器或者玩家的開發(fā)服務器, 甚至源代碼泄露, 那么馬上就有很大的偽造訂單的危險
我把這個做法發(fā)給朋友看, 他們說, 其實PP助手的開發(fā)者只管用了RSA, 跟傳輸不是明文就好了, 至于什么信息安全, 都是屁!