雜說6 —— 嘗試自定義加密傳輸協(xié)議
gmssl在tlcp中使用了ecc-sm4-sm3 (0x0e13)
SM2是基于ECC橢圓曲線加密，對(duì)標(biāo)RSA，不是前向加密的
ECDHE 前向加密
-----------------------------------------------------------------
-----------------------------------------------------------------
????TLCP是基于TLS的，更多的是用于安全傳輸http等應(yīng)用協(xié)議，也可以安全傳輸自定義的應(yīng)用協(xié)議。
????既然要自定義，且TLCP也是應(yīng)用層協(xié)議，那就基于TLCP進(jìn)行自定義修改
密鑰協(xié)商算法 ：ECDHE? ? ? ? ? ? ? SM9
? ? ? ? 簽名算法：RSA??? ? ? ? ? ? ? ? ?SM2
? ? ? ? ? ? ? ?通信：AES-256-GCM? ?SM4
? ? ? ? 摘要算法：SHA384? ? ? ? ? ? ? SM3
密鑰交換/密鑰協(xié)商: SM9
????對(duì)于已經(jīng)無法去參悟高等數(shù)學(xué)的我去看 “橢圓曲線”、“群”、“G點(diǎn)”，真是頭都要炸了。
????直接看gmssl中sm9怎么用
????使用例子（命令行工具）為demos/scripts/sm9demo.sh
/opt/gmssl/GmSSL/demos/scripts$ export PATH=$PATH:`pwd`/../../build/bin
/opt/gmssl/GmSSL/demos/scripts$ ./sm9demo.sh?
sm9verify success
hello
看著還挺復(fù)雜的，還得看文檔
????有個(gè)重要的東西
GMT 0044.2-2016 SM9標(biāo)識(shí)密碼算法 第二部分：數(shù)字簽名算法
????3.6 密鑰生成中心 KGC
????????本部分中，負(fù)責(zé)選擇系統(tǒng)參數(shù)、生成簽名主密鑰并產(chǎn)生用戶簽名私鑰的可信機(jī)構(gòu)
GMT 0044.3-2016 SM9標(biāo)識(shí)密碼算法 第三部分：密鑰交換協(xié)議?
????3.9?密鑰生成中心 KGC
????????在本部分中，負(fù)責(zé)選擇系統(tǒng)參數(shù)、生成加密主密鑰并產(chǎn)生用戶加密私鑰的可信機(jī)構(gòu)
????為了驗(yàn)證客戶端或服務(wù)端的可信任性，需要可信第三方機(jī)構(gòu)，之前是CA，這里是KGC。
-------------------------------------
????和http等應(yīng)用不同，
我的環(huán)境：服務(wù)端、客戶端均應(yīng)該是自己的。
假設(shè)：服務(wù)端、客戶端自身保證了固件、運(yùn)行環(huán)境的安全性，不會(huì)泄漏內(nèi)部資源（如初始密鑰、加密函數(shù)等）
????我只要設(shè)定某種條件保存在服務(wù)端、客戶端中，外界不會(huì)得知，那么就可以認(rèn)為這個(gè)服務(wù)端、客戶端是自己的，可以信任。
????就像SM9中使用身份信息（如郵件、身份證ID等）作為公鑰一樣，服務(wù)端、客戶端的ID是可以公開的，那么就可以：
????? ? ? ? ? ? ?client? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?server
? ? ? ?? ? ?CID：客戶端ID? ? ? ? ? ? ? ? ? ? ? ? ? ? ?SID：服務(wù)端ID
? ?生成隨機(jī)數(shù)Rc，發(fā)送（CID，Rc）? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???接收到?(CID，Rc)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?使用函數(shù)M(SID, CID)生成信息密鑰Ki
?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??生成隨機(jī)數(shù)Rs，使用函數(shù)F(Rs, Rc)生成數(shù)據(jù)密鑰Kd
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???使用Ki加密(Rs, Kd)為Ei，使用Kd加密第一塊數(shù)據(jù)Ed0
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???發(fā)送（SID, Ei, Ed0）
? ??接收到?（SID, Ei, Ed0）
使用函數(shù)M(SID, CID)生成信息密鑰Ki
使用Ki解密Ei為(Rs, Kd)
使用函數(shù)F(Rs,?Rc)生成數(shù)據(jù)密鑰Kd‘，校驗(yàn)Kd和Kd’
校驗(yàn)成功，使用Kd解密第一塊數(shù)據(jù)Ed0
發(fā)送Kd加密的回復(fù)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 開始傳輸流
其中M()、F()：
就像密碼不要設(shè)置為弱密碼（如123456）一樣，不要設(shè)置為一想就能想到的“加、異或、直接AES/SM4”等
每次實(shí)現(xiàn)應(yīng)不同，這樣就類似前向加密
最好M ！= F
其中信息密鑰Ki、數(shù)據(jù)密鑰Kd：可想而知，對(duì)稱加密SM4密鑰
其中發(fā)送的包要做摘要以供校驗(yàn)，使用SM3
????至于SM2非對(duì)稱加密，可以使用到M()、F()中，但好像沒必要在小地方使用這重武器
淺層攻擊如何：（在假設(shè)條件完好且M()、F()夠復(fù)雜的情況下）
第三者當(dāng)作客戶端，?生成隨機(jī)數(shù)Rc、發(fā)送自己的（CID，Rc），然后服務(wù)端發(fā)送（SID, Ei, Ed0）。第三者接收到自己的（SID, Ei, Ed0），SID是公開的，不知道M()、F()，無法解密，也無法繼續(xù)
第三者截獲客戶端的（CID，Rc）、（SID, Ei, Ed0），CID、SID、Rc都是公開的，不知道M()、F()，無法解密，也就獲取不到數(shù)據(jù)密鑰Kd，無法繼續(xù)偽裝通信
深層攻擊：
????？？？
（只是了解過，不是做安全的，不知道他們是怎么測(cè)試攻擊的）
????這樣協(xié)議頭很簡(jiǎn)單
