1. ECC 到底是什么從一條熱搜說(shuō)起ECC 這三個(gè)字母放在不同圈子里指向的東西完全不一樣。做密碼學(xué)的看到它第一反應(yīng)是Elliptic Curve Cryptography橢圓曲線(xiàn)密碼學(xué)做企業(yè)信息化的看到它想到的是SAP ECCERP Central Component那套跑了十幾年的老牌 ERP 核心系統(tǒng)做證書(shū)和合規(guī)的人看到它腦子里蹦出來(lái)的是P-384 這條 NIST 曲線(xiàn)以及各種 CA 機(jī)構(gòu)的名字。所以當(dāng)我看到ECC這個(gè)標(biāo)題再掃一眼熱搜詞里同時(shí)出現(xiàn)了trustwave holdings、p384 certification authority、affaan-m/ecc、sap ecc lsmw操作我基本可以判斷這不是一個(gè)單一話(huà)題而是一個(gè)被多個(gè)領(lǐng)域共用的縮寫(xiě)每個(gè)方向都有人在搜、在踩坑。這篇東西我打算按一個(gè)縮寫(xiě)四條主線(xiàn)來(lái)拆。主線(xiàn)一是密碼學(xué)層面的 ECC講清楚它為什么能在更短的密鑰長(zhǎng)度下提供同等安全強(qiáng)度P-384 又處在什么位置主線(xiàn)二是證書(shū)與信任鏈層面P-384 CA 是怎么簽發(fā)和驗(yàn)證的為什么有些機(jī)構(gòu)會(huì)專(zhuān)門(mén)強(qiáng)調(diào)自己支持 P-384主線(xiàn)三是 SAP ECC 這條完全不同的線(xiàn)尤其是 LSMW 這個(gè)批量導(dǎo)入工具在 ECC 環(huán)境下的實(shí)操主線(xiàn)四是affaan-m/ecc這類(lèi)代碼倉(cāng)庫(kù)它代表的是 ECC 在工程實(shí)現(xiàn)層面的落地。四條線(xiàn)看似無(wú)關(guān)但都圍繞ECC這個(gè)入口適合不同背景的人各取所需。如果你是被某個(gè)具體問(wèn)題卡住才搜到這里的——比如證書(shū)鏈報(bào)錯(cuò)、SAP 里 LSMW 跑不通、或者想搞明白 P-384 到底比 P-256 強(qiáng)在哪——那你可以直接跳到對(duì)應(yīng)章節(jié)。如果你只是對(duì)這個(gè)縮寫(xiě)好奇想一次性把它的全貌摸清楚那就從頭看。我會(huì)盡量把每個(gè)方向的為什么講透而不是只丟結(jié)論。畢竟這類(lèi)跨領(lǐng)域縮寫(xiě)最坑人的地方就是你以為在聊同一件事其實(shí)兩個(gè)人根本不在一個(gè)頻道上。2. 密碼學(xué)視角的 ECC為什么短密鑰也能很硬2.1 橢圓曲線(xiàn)密碼學(xué)的基本直覺(jué)要理解 ECC先得接受一個(gè)反直覺(jué)的事實(shí)密鑰短不等于不安全。傳統(tǒng)的 RSA 想達(dá)到 128 位安全強(qiáng)度密鑰得拉到 3072 位而 ECC 只需要 256 位就能達(dá)到同等強(qiáng)度。這個(gè)差距不是靠壓縮得來(lái)的而是因?yàn)閮烧咭蕾?lài)的數(shù)學(xué)難題根本不同。RSA 的安全性建立在大整數(shù)分解難之上ECC 建立在橢圓曲線(xiàn)離散對(duì)數(shù)難之上。后者的已知最優(yōu)攻擊算法復(fù)雜度更高所以同樣的安全目標(biāo)需要的密鑰位數(shù)就少得多。打個(gè)生活化的比方。RSA 像是讓你在一座巨大的迷宮里找出口迷宮越大越難找所以你得把迷宮修得特別大密鑰特別長(zhǎng)。ECC 則是把迷宮換成了一個(gè)結(jié)構(gòu)更扭曲的空間雖然面積小但路徑的復(fù)雜度呈指數(shù)級(jí)上升找出口的難度反而更高。這就是為什么在移動(dòng)設(shè)備、物聯(lián)網(wǎng)、智能卡這些算力和存儲(chǔ)都吃緊的場(chǎng)景里ECC 幾乎是默認(rèn)選擇——密鑰短握手快功耗低證書(shū)體積也小。具體到曲線(xiàn)參數(shù)業(yè)界常用的就那么幾條P-256也叫 secp256r1、P-384secp384r1、P-521secp521r1這是 NIST 系列還有 Curve25519、Curve448 這類(lèi)后來(lái)被廣泛采用的曲線(xiàn)。P-256 對(duì)應(yīng)約 128 位安全強(qiáng)度P-384 對(duì)應(yīng)約 192 位P-521 對(duì)應(yīng)約 256 位。熱搜里出現(xiàn)的p384就是中間那檔它在足夠安全和性能可接受之間取了個(gè)平衡點(diǎn)所以很多對(duì)合規(guī)有要求的場(chǎng)景會(huì)點(diǎn)名要 P-384。2.2 P-384 的定位它到底比 P-256 強(qiáng)在哪很多人會(huì)問(wèn)既然 P-256 已經(jīng)夠安全了為什么還要上 P-384答案通常不在技術(shù)本身而在合規(guī)要求和信任周期。P-256 的 128 位安全強(qiáng)度在當(dāng)下是夠用的但如果你簽發(fā)的是一張有效期十年甚至更久的根證書(shū)你就得考慮未來(lái)十年計(jì)算能力增長(zhǎng)這件事。安全強(qiáng)度是有保質(zhì)期的128 位在可預(yù)見(jiàn)的將來(lái)依然難以被暴力破解但一些高保障級(jí)別的標(biāo)準(zhǔn)比如某些政府、金融、國(guó)防相關(guān)的合規(guī)框架會(huì)直接要求 192 位起步這時(shí)候 P-384 就成了最低門(mén)檻。從性能角度看P-384 的運(yùn)算確實(shí)比 P-256 慢簽名和驗(yàn)簽的耗時(shí)大概會(huì)高出幾倍密鑰和簽名長(zhǎng)度也更長(zhǎng)P-256 的簽名約 64 字節(jié)P-384 約 96 字節(jié)。但這點(diǎn)開(kāi)銷(xiāo)在大多數(shù)場(chǎng)景下可以忽略尤其是證書(shū)簽發(fā)這種低頻操作。真正需要權(quán)衡的是 TLS 握手這種高頻、對(duì)延遲敏感的場(chǎng)景——在那里P-256 依然是主流P-384 更多出現(xiàn)在根證書(shū)、中間證書(shū)或者對(duì)安全等級(jí)有硬性要求的鏈路里。提示選曲線(xiàn)不是越大越好。P-521 雖然安全強(qiáng)度最高但性能和兼容性都會(huì)打折扣很多老系統(tǒng)對(duì)它支持不佳。P-384 是高保障場(chǎng)景里性?xún)r(jià)比最穩(wěn)的一檔這也是它頻繁出現(xiàn)在合規(guī)討論中的原因。2.3 密鑰長(zhǎng)度與安全強(qiáng)度的對(duì)照為了讓你有個(gè)直觀概念我把常見(jiàn)算法和它們達(dá)到同等安全強(qiáng)度所需的密鑰長(zhǎng)度列一下。這張表在選型時(shí)非常實(shí)用尤其是當(dāng)你需要在兼容老系統(tǒng)和滿(mǎn)足新合規(guī)之間做取舍的時(shí)候。安全強(qiáng)度對(duì)稱(chēng)密鑰等效RSA 密鑰長(zhǎng)度ECC 曲線(xiàn)典型用途80 位1024 位160 位已淘汰不建議使用112 位2048 位224 位過(guò)渡期逐步棄用128 位3072 位P-256TLS 主流、通用場(chǎng)景192 位7680 位P-384高保障、長(zhǎng)周期根證書(shū)256 位15360 位P-521極高保障、特殊合規(guī)看這張表你會(huì)發(fā)現(xiàn)一個(gè)很明顯的規(guī)律ECC 的密鑰長(zhǎng)度增長(zhǎng)遠(yuǎn)慢于 RSA。從 128 位到 192 位安全強(qiáng)度RSA 要從 3072 位跳到 7680 位翻了一倍多而 ECC 只是從 256 位到 384 位漲了 50%。這個(gè)特性在資源受限的環(huán)境里價(jià)值巨大也是 ECC 能在嵌入式、車(chē)聯(lián)網(wǎng)、物聯(lián)網(wǎng)領(lǐng)域快速鋪開(kāi)的核心原因。3. 證書(shū)與信任鏈P-384 CA 是怎么工作的3.1 認(rèn)證機(jī)構(gòu)在信任鏈里的角色熱搜里出現(xiàn)了trustwave holdings和p384 certification authority這指向的是證書(shū)體系里的一個(gè)核心角色CACertification Authority認(rèn)證機(jī)構(gòu)。CA 干的事說(shuō)白了就是擔(dān)?！米约旱乃借€給你的公鑰簽名簽發(fā)一張證書(shū)證明這個(gè)公鑰確實(shí)屬于這個(gè)主體。瀏覽器和操作系統(tǒng)內(nèi)置了一批受信任的根 CA只要你的證書(shū)能沿著信任鏈一路追溯到某個(gè)根 CA并且每一環(huán)簽名都驗(yàn)證通過(guò)瀏覽器就認(rèn)。信任鏈的結(jié)構(gòu)是分層的根證書(shū)Root CA→ 中間證書(shū)Intermediate CA→ 終端實(shí)體證書(shū)Leaf/End-entity。根證書(shū)的私鑰通常離線(xiàn)保管極少動(dòng)用日常簽發(fā)靠中間證書(shū)完成。這樣設(shè)計(jì)的好處是萬(wàn)一中間證書(shū)出問(wèn)題可以吊銷(xiāo)它而不影響根證書(shū)風(fēng)險(xiǎn)被隔離在局部。P-384 在這條鏈里的典型位置是根證書(shū)或高保障級(jí)別的中間證書(shū)——因?yàn)樗鼈兩芷陂L(zhǎng)、影響面大值得用更高的安全強(qiáng)度。3.2 P-384 證書(shū)的簽發(fā)與驗(yàn)證流程一張 P-384 證書(shū)從申請(qǐng)到被信任走的是這么一條路。第一步是生成密鑰對(duì)主體在自己的環(huán)境里生成一對(duì) P-384 的私鑰和公鑰私鑰絕不外傳。第二步是構(gòu)造 CSRCertificate Signing Request把公鑰、主體信息域名、組織名等打包用自己的私鑰簽名證明我持有對(duì)應(yīng)的私鑰。第三步是CA 驗(yàn)證并簽發(fā)CA 核驗(yàn)主體身份后用自己的私鑰對(duì) CSR 里的信息簽名生成證書(shū)。驗(yàn)證的時(shí)候順序反過(guò)來(lái)?？蛻?hù)端拿到證書(shū)先看簽發(fā)者是誰(shuí)去找對(duì)應(yīng)的中間證書(shū)用中間證書(shū)的公鑰驗(yàn)證終端證書(shū)的簽名再往上驗(yàn)證中間證書(shū)的簽名直到根證書(shū)。根證書(shū)是內(nèi)置在信任庫(kù)里的不需要再往上驗(yàn)證。整條鏈上任何一環(huán)簽名對(duì)不上、或者證書(shū)過(guò)期、或者被吊銷(xiāo)驗(yàn)證就失敗。P-384 在這里的意義是每一環(huán)的簽名都用 P-384 曲線(xiàn)整條鏈的安全強(qiáng)度就統(tǒng)一在 192 位這個(gè)級(jí)別。實(shí)操中有一個(gè)很容易踩的坑曲線(xiàn)不匹配。如果根證書(shū)是 P-384中間證書(shū)是 P-256終端證書(shū)又是 P-384雖然理論上都能驗(yàn)證通過(guò)但一些嚴(yán)格的合規(guī)檢查會(huì)要求整條鏈的強(qiáng)度一致。更麻煩的是某些老舊的客戶(hù)端或庫(kù)對(duì) P-384 支持不完整可能直接握手失敗。所以部署前一定要在目標(biāo)客戶(hù)端上實(shí)測(cè)別只在開(kāi)發(fā)機(jī)上跑通就上線(xiàn)。3.3 用 OpenSSL 檢查證書(shū)鏈的實(shí)操命令行里排查證書(shū)問(wèn)題OpenSSL 是最順手的工具。下面這幾條命令我?guī)缀趺看闻挪樽C書(shū)都要用你可以直接抄。# 查看一張證書(shū)的詳細(xì)信息包括簽名算法和公鑰曲線(xiàn) openssl x509 -in cert.pem -text -noout # 只看公鑰部分確認(rèn)曲線(xiàn)類(lèi)型 openssl x509 -in cert.pem -noout -pubkey | openssl ec -pubin -text -noout # 驗(yàn)證證書(shū)鏈需要提供中間證書(shū)和根證書(shū) openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem # 檢查 TLS 握手時(shí)服務(wù)端實(shí)際下發(fā)的證書(shū)鏈 openssl s_client -connect example.com:443 -showcerts第一條命令的輸出里你會(huì)看到Signature Algorithm和Public Key Algorithm兩行前者告訴你簽名用的什么算法比如ecdsa-with-SHA384后者告訴你公鑰是什么類(lèi)型。如果簽名算法里出現(xiàn)SHA384基本可以確認(rèn)用的是 P-384 這一檔。第二條命令專(zhuān)門(mén)看公鑰輸出里會(huì)明確寫(xiě)出ASN1 OID: secp384r1這就是 P-384 的正式名字。注意openssl verify驗(yàn)證失敗時(shí)報(bào)錯(cuò)信息往往很含糊比如 unable to get local issuer certificate。這時(shí)候別急著懷疑證書(shū)本身先確認(rèn)中間證書(shū)有沒(méi)有正確提供。服務(wù)端配置里漏掉中間證書(shū)是最常見(jiàn)的信任鏈斷裂原因。4. SAP ECC 與 LSMW另一條完全不同的 ECC 線(xiàn)4.1 SAP ECC 是什么為什么還在被大量使用聊完密碼學(xué)我們換個(gè)頻道。熱搜里的sap ecc lsmw操作指向的是企業(yè)信息化領(lǐng)域。SAP ECC 是 SAP 的 ERP Central Component也就是那套經(jīng)典的企業(yè)資源計(jì)劃系統(tǒng)。雖然 SAP 后來(lái)推出了 S/4HANA但全球仍有海量企業(yè)在跑 ECC原因很現(xiàn)實(shí)遷移成本太高業(yè)務(wù)邏輯太復(fù)雜很多定制開(kāi)發(fā)在 ECC 上跑了十幾年動(dòng)一發(fā)牽全身。所以 ECC 的運(yùn)維、數(shù)據(jù)遷移、批量操作至今仍是大量顧問(wèn)和 IT 人員的日常。在 ECC 里做數(shù)據(jù)導(dǎo)入繞不開(kāi)一個(gè)工具LSMWLegacy System Migration Workbench遺留系統(tǒng)遷移工作臺(tái)。它的定位是把外部數(shù)據(jù)批量灌進(jìn) SAP。你可以把它理解成一個(gè)數(shù)據(jù)搬運(yùn)工——從 Excel、CSV、文本文件里讀數(shù)據(jù)按你定義的規(guī)則轉(zhuǎn)換然后通過(guò) BAPI、IDoc、批輸入Batch Input等方式寫(xiě)進(jìn) SAP 的標(biāo)準(zhǔn)表或自定義表。對(duì)于沒(méi)有開(kāi)發(fā)資源、又需要頻繁導(dǎo)數(shù)據(jù)的團(tuán)隊(duì)LSMW 幾乎是唯一選擇。4.2 LSMW 的四種導(dǎo)入方式怎么選LSMW 支持多種導(dǎo)入技術(shù)選錯(cuò)了會(huì)白白折騰很久。我把常見(jiàn)的四種列出來(lái)附上適用場(chǎng)景你對(duì)著選就行。導(dǎo)入方式適用場(chǎng)景優(yōu)點(diǎn)缺點(diǎn)Batch Input批輸入模擬屏幕操作適合標(biāo)準(zhǔn)事務(wù)碼兼容性好幾乎萬(wàn)能慢依賴(lài)屏幕字段Direct Input直接輸入直接寫(xiě)數(shù)據(jù)庫(kù)適合有專(zhuān)用程序的場(chǎng)景快不依賴(lài)屏幕只支持特定對(duì)象BAPI調(diào)用標(biāo)準(zhǔn)業(yè)務(wù)接口規(guī)范帶校驗(yàn)需要對(duì)象支持 BAPIIDoc系統(tǒng)間異步傳輸適合接口集成配置復(fù)雜調(diào)試麻煩新手最容易上手的是Batch Input因?yàn)樗举|(zhì)上是錄制一遍手工操作然后批量重放。你在 LSMW 里錄一個(gè)事務(wù)碼比如 MM01 創(chuàng)建物料把每個(gè)字段對(duì)應(yīng)到源文件的列之后 LSMW 就會(huì)對(duì)每一行數(shù)據(jù)模擬一遍這個(gè)操作。缺點(diǎn)是慢數(shù)據(jù)量大的時(shí)候跑起來(lái)很熬人而且一旦某個(gè)字段的屏幕邏輯變了錄制的腳本就可能失效。Direct Input和BAPI更快更穩(wěn)但前提是你要導(dǎo)入的對(duì)象有對(duì)應(yīng)的程序或接口支持。比如導(dǎo)入物料主數(shù)據(jù)、客戶(hù)主數(shù)據(jù)這些標(biāo)準(zhǔn)對(duì)象通常都有現(xiàn)成的 BAPI 可用優(yōu)先選它們。IDoc更適合系統(tǒng)與系統(tǒng)之間的對(duì)接單次手工導(dǎo)數(shù)據(jù)一般用不上。4.3 LSMW 完整操作流程拆解下面我把 LSMW 的標(biāo)準(zhǔn)流程走一遍。這套流程我跑過(guò)很多次每一步的坑我都標(biāo)出來(lái)。第一步是創(chuàng)建項(xiàng)目Project、子項(xiàng)目Subproject和對(duì)象Object。事務(wù)碼LSMW進(jìn)去按層級(jí)建。項(xiàng)目名和子項(xiàng)目名隨便起但要能看懂因?yàn)楹竺婢S護(hù)的人可能不是你。對(duì)象名建議直接對(duì)應(yīng)業(yè)務(wù)比如MATERIAL_UPLOAD。第二步是維護(hù)對(duì)象屬性Maintain Object Attributes。這里要選導(dǎo)入方式Batch Input / Direct Input / BAPI / IDoc和對(duì)應(yīng)的業(yè)務(wù)對(duì)象。選 Batch Input 的話(huà)要填事務(wù)碼比如MM01。第三步是維護(hù)源結(jié)構(gòu)Maintain Source Structures。定義你的源文件長(zhǎng)什么樣有哪些字段。這一步?jīng)Q定了后面字段映射的骨架字段名盡量和源文件列名一致省得后面繞。第四步是維護(hù)源字段Maintain Source Fields。把源結(jié)構(gòu)里的字段逐個(gè)定義出來(lái)指定類(lèi)型和長(zhǎng)度。這里有個(gè)坑長(zhǎng)度一定要給夠尤其是文本字段短了會(huì)截?cái)喽医財(cái)嗤粓?bào)錯(cuò)數(shù)據(jù)靜默丟失事后排查極其痛苦。第五步是維護(hù)結(jié)構(gòu)關(guān)系Maintain Structure Relationships。把源結(jié)構(gòu)和目標(biāo)結(jié)構(gòu)關(guān)聯(lián)起來(lái)。Batch Input 模式下目標(biāo)結(jié)構(gòu)通常是錄屏生成的。第六步是維護(hù)字段映射和轉(zhuǎn)換規(guī)則Maintain Field Mapping and Conversion Rules。這是最核心的一步把源字段一一對(duì)應(yīng)到目標(biāo)字段。需要轉(zhuǎn)換的地方比如日期格式、代碼值映射在這里寫(xiě) ABAP 代碼。我見(jiàn)過(guò)太多人卡在這一步因?yàn)樵磾?shù)據(jù)的格式和 SAP 期望的格式對(duì)不上。第七步是指定文件Specify Files。告訴 LSMW 源文件在哪是什么格式制表符分隔、逗號(hào)分隔等。第八步是分配文件Assign Files把文件和源結(jié)構(gòu)綁定。第九步是讀取數(shù)據(jù)Read DataLSMW 會(huì)把源文件讀進(jìn)來(lái)生成一個(gè)預(yù)覽。這一步一定要仔細(xì)看確認(rèn)列沒(méi)錯(cuò)位、編碼沒(méi)亂。第十步是顯示讀取的數(shù)據(jù)Display Read Data肉眼核對(duì)幾行。第十一步是轉(zhuǎn)換數(shù)據(jù)Convert Data執(zhí)行字段映射和轉(zhuǎn)換規(guī)則。第十二步是顯示轉(zhuǎn)換后的數(shù)據(jù)Display Converted Data再核對(duì)一遍。最后是創(chuàng)建批輸入會(huì)話(huà)Create Batch Input Session然后到SM35里運(yùn)行這個(gè)會(huì)話(huà)。運(yùn)行的時(shí)候建議先選僅顯示錯(cuò)誤模式跑一遍確認(rèn)沒(méi)問(wèn)題再正式執(zhí)行。提示LSMW 跑大批量數(shù)據(jù)前務(wù)必在測(cè)試環(huán)境用全量數(shù)據(jù)跑一遍。生產(chǎn)環(huán)境直接上一旦中途出錯(cuò)回滾會(huì)很麻煩尤其是涉及財(cái)務(wù)憑證的場(chǎng)景。4.4 LSMW 常見(jiàn)報(bào)錯(cuò)與排查跑 LSMW 最常遇到的幾類(lèi)問(wèn)題我整理成一張速查表方便你對(duì)癥下藥。報(bào)錯(cuò)現(xiàn)象可能原因排查方向數(shù)據(jù)讀進(jìn)來(lái)是亂碼文件編碼不匹配確認(rèn)源文件是 UTF-8 還是 GBKLSMW 里對(duì)應(yīng)設(shè)置字段值被截?cái)嘣醋侄伍L(zhǎng)度定義過(guò)短檢查 Source Fields 的長(zhǎng)度設(shè)置轉(zhuǎn)換后數(shù)據(jù)為空字段映射沒(méi)對(duì)上回到 Field Mapping 逐步核對(duì)批輸入會(huì)話(huà)報(bào)錯(cuò)屏幕字段邏輯變化重新錄制或改用 BAPI日期格式錯(cuò)誤源格式與 SAP 格式不一致在轉(zhuǎn)換規(guī)則里加日期格式化代碼部分行成功部分失敗數(shù)據(jù)本身有臟值看 SM35 的錯(cuò)誤日志逐行定位我個(gè)人的經(jīng)驗(yàn)是八成的問(wèn)題出在字段映射和格式轉(zhuǎn)換上而不是 LSMW 本身。所以每次導(dǎo)入前先拿 5 到 10 行樣本數(shù)據(jù)跑通全流程確認(rèn)無(wú)誤再上全量。這個(gè)習(xí)慣能幫你省下大量返工時(shí)間。5. 工程實(shí)現(xiàn)視角affaan-m/ecc 這類(lèi)倉(cāng)庫(kù)意味著什么5.1 從倉(cāng)庫(kù)名看 ECC 的工程落地?zé)崴牙锏腶ffaan-m/ecc是一個(gè)典型的代碼倉(cāng)庫(kù)命名格式——用戶(hù)名/倉(cāng)庫(kù)名。這類(lèi)倉(cāng)庫(kù)通常是把 ECC 的算法實(shí)現(xiàn)、工具封裝或者示例代碼開(kāi)源出來(lái)供開(kāi)發(fā)者直接調(diào)用或參考。ECC 在工程落地時(shí)最大的痛點(diǎn)不是不懂原理而是不知道怎么正確調(diào)用。曲線(xiàn)參數(shù)選錯(cuò)、隨機(jī)數(shù)生成不安全、簽名格式不兼容任何一個(gè)細(xì)節(jié)出問(wèn)題整套加密就形同虛設(shè)。所以這類(lèi)倉(cāng)庫(kù)的價(jià)值在于把容易出錯(cuò)的底層細(xì)節(jié)封裝好讓上層開(kāi)發(fā)者用幾行代碼就能完成簽名、驗(yàn)簽、密鑰交換。但封裝也帶來(lái)風(fēng)險(xiǎn)——如果封裝層隱藏了關(guān)鍵參數(shù)開(kāi)發(fā)者可能根本不知道自己用的是哪條曲線(xiàn)、隨機(jī)數(shù)從哪來(lái)。我見(jiàn)過(guò)不少項(xiàng)目加密庫(kù)調(diào)用得挺順結(jié)果一審計(jì)發(fā)現(xiàn)用的是不安全的隨機(jī)源或者曲線(xiàn)參數(shù)被默認(rèn)成了弱曲線(xiàn)。5.2 調(diào)用 ECC 庫(kù)時(shí)的幾個(gè)關(guān)鍵檢查點(diǎn)不管你用哪個(gè)語(yǔ)言的 ECC 庫(kù)下面這幾個(gè)點(diǎn)必須確認(rèn)缺一個(gè)都可能埋雷。第一曲線(xiàn)選擇要顯式指定。別依賴(lài)默認(rèn)值不同庫(kù)的默認(rèn)曲線(xiàn)可能不一樣有的甚至是已經(jīng)不推薦的曲線(xiàn)。明確寫(xiě)secp384r1或P-384別讓庫(kù)替你決定。第二隨機(jī)數(shù)來(lái)源要安全。ECC 的私鑰生成依賴(lài)高質(zhì)量的隨機(jī)數(shù)如果隨機(jī)源可預(yù)測(cè)私鑰就能被推算出來(lái)。用操作系統(tǒng)提供的加密安全隨機(jī)源別用普通的偽隨機(jī)函數(shù)。第三簽名格式要統(tǒng)一。ECDSA 簽名有 DER 編碼和原始 r||s 兩種格式不同系統(tǒng)之間傳遞時(shí)經(jīng)常因?yàn)楦袷讲灰恢聦?dǎo)致驗(yàn)簽失敗。對(duì)接前先確認(rèn)雙方用的是什么格式。第四注意 nonce 的唯一性。ECDSA 簽名時(shí)用的隨機(jī)數(shù) k 絕對(duì)不能重復(fù)一旦兩條簽名用了同一個(gè) k私鑰就能被直接算出來(lái)。這是 ECC 實(shí)現(xiàn)里最致命的安全漏洞之一歷史上出過(guò)好幾次真實(shí)事故。# 以 Python 的 cryptography 庫(kù)為例顯式指定 P-384 曲線(xiàn) from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import hashes # 生成 P-384 密鑰對(duì) private_key ec.generate_private_key(ec.SECP384R1()) public_key private_key.public_key() # 簽名使用 SHA-384 哈希 data b需要簽名的內(nèi)容 signature private_key.sign(data, ec.ECDSA(hashes.SHA384())) # 驗(yàn)簽 public_key.verify(signature, data, ec.ECDSA(hashes.SHA384()))這段代碼里ec.SECP384R1()就是顯式指定曲線(xiàn)hashes.SHA384()指定哈希算法。注意曲線(xiàn)和哈希的搭配——P-384 通常配 SHA-384P-256 配 SHA-256這個(gè)對(duì)應(yīng)關(guān)系不是強(qiáng)制的但遵循它能讓你的實(shí)現(xiàn)更符合業(yè)界慣例減少互操作問(wèn)題。5.3 自研實(shí)現(xiàn) vs 使用成熟庫(kù)總有人想自己實(shí)現(xiàn) ECC覺(jué)得不就是幾個(gè)數(shù)學(xué)公式。我的建議很直接除非你是密碼學(xué)專(zhuān)業(yè)出身否則別自己造輪子。ECC 的實(shí)現(xiàn)里充滿(mǎn)了側(cè)信道攻擊的陷阱——你的代碼執(zhí)行時(shí)間、功耗、緩存訪(fǎng)問(wèn)模式都可能泄露私鑰信息。成熟庫(kù)經(jīng)過(guò)大量審計(jì)和實(shí)戰(zhàn)檢驗(yàn)這些坑都填過(guò)了。自己實(shí)現(xiàn)很可能功能上跑得通安全性上卻千瘡百孔。如果確實(shí)有特殊需求必須自研至少要做到使用常數(shù)時(shí)間實(shí)現(xiàn)的數(shù)學(xué)運(yùn)算、避免分支依賴(lài)私鑰、對(duì)中間結(jié)果做盲化處理。這些技術(shù)門(mén)檻很高不是看幾篇論文就能掌握的。工程上更務(wù)實(shí)的做法是在成熟庫(kù)之上做封裝把業(yè)務(wù)邏輯和密碼學(xué)操作隔離開(kāi)。6. 四條線(xiàn)怎么串起來(lái)給不同讀者的上手建議回到最開(kāi)始那個(gè)問(wèn)題ECC 這個(gè)縮寫(xiě)為什么能同時(shí)掛上這么多熱搜詞因?yàn)樗塘硕痰讲煌I(lǐng)域的人都能用它指代自己關(guān)心的東西。密碼學(xué)的人關(guān)心曲線(xiàn)和密鑰長(zhǎng)度證書(shū)運(yùn)維的人關(guān)心信任鏈和 P-384 的合規(guī)價(jià)值SAP 顧問(wèn)關(guān)心 LSMW 怎么把數(shù)據(jù)導(dǎo)進(jìn) ECC 系統(tǒng)開(kāi)發(fā)者關(guān)心怎么正確調(diào)用 ECC 庫(kù)。這四條線(xiàn)在搜索引擎里撞在一起但彼此之間幾乎沒(méi)有交集。所以我的建議是先搞清楚你自己站在哪條線(xiàn)上。如果你在排查證書(shū)問(wèn)題重點(diǎn)看第 3 章的 OpenSSL 命令和信任鏈原理P-384 的合規(guī)背景了解一下就行。如果你在做 SAP 數(shù)據(jù)遷移第 4 章的 LSMW 流程和報(bào)錯(cuò)表能直接拿去用密碼學(xué)那部分可以跳過(guò)。如果你是開(kāi)發(fā)者第 5 章的檢查點(diǎn)和代碼示例是重點(diǎn)尤其是隨機(jī)數(shù)和 nonce 那兩條踩過(guò)一次就知道有多疼。我個(gè)人在實(shí)際操作中的體會(huì)是跨領(lǐng)域的縮寫(xiě)最容易讓人走彎路——你以為搜到的是答案其實(shí)搜到的是另一個(gè)領(lǐng)域的答案。所以遇到這類(lèi)標(biāo)題先花兩分鐘確認(rèn)語(yǔ)境比急著往下看要值錢(qián)得多。ECC 是這樣其他縮寫(xiě)也一樣。