前言
相信大家在開發(fā)中都遇到過,有些隱秘信息需要做加密傳輸?shù)膱?chǎng)景.
A:你就把 XXX 做一下base64加密傳過來就行
這些問題相信大家都遇到過,那么在實(shí)際開發(fā)中我們應(yīng)該如何選擇加密方法呢?
加密
這里我就直接拋出來幾個(gè)加密規(guī)則
-
AES對(duì)稱加密,雙方只有同一個(gè)秘鑰key -
RSA非對(duì)稱加密,生成一對(duì)公私鑰.
首先要明確一點(diǎn), 即使做了加密也不能保證我們的信息就是絕對(duì)安全的,只是盡可能的提升破解難度,加密算法的實(shí)現(xiàn)都是公開的,所以秘鑰如何安全的存儲(chǔ)是我們要重點(diǎn)考慮的問題.
關(guān)于這兩種加密算法大家可以網(wǎng)上查一下原理,這里我不介紹原理,只介紹給大家特定場(chǎng)景下如何選擇最優(yōu)的加密規(guī)則,以及一些小Tips.
AES
對(duì)稱加密,很好理解,生成唯一秘鑰key,雙方本別可以用key做加密/解密.是比較常用的加密首段,AES只是一種加密規(guī)則,具體的加密還有很多種,目前主流使用的是AES/GCM.
RSA
非對(duì)稱加密,生成一對(duì)秘鑰,public key/private key,
加解密使用時(shí): public key加密, private key解密.
簽名驗(yàn)證時(shí) : private key簽名 , public key 驗(yàn)簽
這里說一下實(shí)際案例:
某某公司,2B的后臺(tái)支付接口,突然有一天一個(gè)商家反饋為什么我賬戶里錢都沒有了,通過日志一查發(fā)現(xiàn)都是正常操作刷走了.而某公司并沒有辦法證明自己的系統(tǒng)是沒問題的.理論上這個(gè)接口的
key下發(fā)給商戶,但是某某公司也是有這個(gè)key的,所以到底是誰泄漏了key又是誰刷走了賬戶里的錢,誰也無法證明.
這里我們要想一個(gè)問題,我們要怎么做才能防止出現(xiàn)此類問題后,商戶過來說不是我刷的錢,尋求賠償?shù)臅r(shí)候, 拿出證據(jù)打發(fā)他們?
這個(gè)問題就可以利用RSA來解決,在接入公司生成APP key 要求接入方自己生成一對(duì)RSA秘鑰,然后講 public key上傳給我們, private key由接入方自己保存, 而我們只需要驗(yàn)證訂單中的簽名是否是由private key簽名的,而非其他阿貓阿狗簽名的訂單. 如果出現(xiàn)了上訴問題,那么說明接入方的private key泄漏與我們無關(guān),這樣我們就能防止接入方抵賴.
完整性校驗(yàn).防串改
很多情況下我們需要對(duì)數(shù)據(jù)的完整性做校驗(yàn), 比如對(duì)方發(fā)過來一個(gè)文件, 我們?cè)趺粗肋@個(gè)問題件就是源文件, 而非被別人惡意攔截串改后的問題?
早些年大家下載程序的時(shí)候應(yīng)該會(huì)看到,當(dāng)前文件的md5值是XXXXX,這個(gè)就是為了防止文件被修改的存在的.早期我們都是用md5/sha1來做完整性校驗(yàn),后來由sha1升級(jí)出現(xiàn)了sha256.大家可能不知道應(yīng)該如何選擇.
下面是一個(gè)經(jīng)典故事
Google之前公開過兩個(gè)不同的PDF,而它們擁有相同的sha1值
兩個(gè)不同的文件擁有相同sha1值,這意味著我們本地使用的程序sha1是源文件非串改后的,但實(shí)際上可能早已偷梁換柱.這是很可怕的.
所以推薦大家在用完整性校驗(yàn)時(shí)要使用sha256,會(huì)更安全些.
