在Web開(kāi)發(fā)這件事上談到JavaScript密碼算法與網(wǎng)絡(luò)安全我聽(tīng)到最多的質(zhì)疑就是“前端加密有什么意義數(shù)據(jù)反正會(huì)到后端后端驗(yàn)不就行了”這個(gè)想法不能算錯(cuò)但它忽略了一大類(lèi)真實(shí)存在的場(chǎng)景。比如你的應(yīng)用需要校驗(yàn)第三方回調(diào)的數(shù)據(jù)有沒(méi)有被中途篡改需要在不暴露明文的情況下把敏感字段傳給數(shù)據(jù)分析平臺(tái)甚至需要直接在瀏覽器端做文件的分塊加密上傳讓服務(wù)器只保存密文。這些需求靠純粹的傳輸層加密解決不了必須真正把JavaScript密碼算法用起來(lái)。這篇內(nèi)容不是教科書(shū)式的概念羅列而是我在幾個(gè)真實(shí)項(xiàng)目里蹚過(guò)坑之后的總結(jié)包含瀏覽器原生Web Crypto API的完整實(shí)操、密鑰管理的取舍、以及一系列調(diào)試經(jīng)驗(yàn)。適合正在做Web安全改造、加密存儲(chǔ)、數(shù)據(jù)防篡改需求的開(kāi)發(fā)者也適合那些拿到需求卻不知道從哪兒下手的同學(xué)。我會(huì)盡量把每一步為什么這么做講清楚你可以直接拿去復(fù)用。1. 密碼學(xué)基礎(chǔ)為什么前端加密讓我又愛(ài)又恨1.1 對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密的核心邏輯先把最基礎(chǔ)的東西說(shuō)透。對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密名字聽(tīng)著唬人本質(zhì)區(qū)別就一句話加密和解密用的密鑰是不是同一個(gè)。對(duì)稱(chēng)加密典型代表是AES加密和解密用同一把鑰匙。就好比你家的門(mén)鎖用鑰匙鎖上門(mén)也用同一把鑰匙打開(kāi)。它的優(yōu)點(diǎn)是速度快、算力開(kāi)銷(xiāo)小適合加密大量數(shù)據(jù)。缺點(diǎn)也很致命鑰匙怎么送到對(duì)方手里如果兩個(gè)人通過(guò)網(wǎng)絡(luò)通信總得先把這把密鑰傳過(guò)去傳輸過(guò)程中一旦被截獲后面所有密文都等于裸奔。非對(duì)稱(chēng)加密典型代表是RSA和橢圓曲線ECC它用一對(duì)鑰匙公鑰和私鑰。公鑰可以公開(kāi)誰(shuí)都能拿私鑰自己保管絕不外傳。這個(gè)設(shè)計(jì)更像街邊的公共信箱——任何人都能把信投進(jìn)信箱用公鑰加密但只有握著信箱鑰匙的人能打開(kāi)用私鑰解密。非對(duì)稱(chēng)加密解決了密鑰分發(fā)問(wèn)題但性能比對(duì)稱(chēng)加密慢幾個(gè)數(shù)量級(jí)不適合直接加密大段數(shù)據(jù)。所以在真實(shí)項(xiàng)目里兩者從來(lái)不是二選一而是搭配使用用非對(duì)稱(chēng)加密協(xié)商出一把臨時(shí)對(duì)稱(chēng)密鑰再用這把對(duì)稱(chēng)密鑰加密業(yè)務(wù)數(shù)據(jù)。這也就是TLS握手的核心思路之一。前端場(chǎng)景里如果你不需要跟別人協(xié)商密鑰更多時(shí)候直接使用對(duì)稱(chēng)加密就夠了密鑰從用戶口令派生根本不落到服務(wù)器上。1.2 瀏覽器端的威脅模型加密到底保護(hù)了什么很多開(kāi)發(fā)者對(duì)前端加密的最大誤解是拿它當(dāng)HTTPS的替代品這是大忌。HTTPS解決的是傳輸鏈路被竊聽(tīng)和篡改的問(wèn)題它保證的是“數(shù)據(jù)從瀏覽器到服務(wù)器之間沒(méi)人看得懂”而JavaScript密碼算法解決的是“數(shù)據(jù)在業(yè)務(wù)層落庫(kù)、傳遞、校驗(yàn)”時(shí)的安全問(wèn)題。兩者是不同層級(jí)的防護(hù)不是二選一的關(guān)系。舉個(gè)我實(shí)際見(jiàn)過(guò)的例子某個(gè)系統(tǒng)的網(wǎng)關(guān)會(huì)記錄請(qǐng)求日志用于排障但日志里包含用戶身份證號(hào)等敏感字段。即使整個(gè)鏈路是HTTPS日志一旦落到存儲(chǔ)系統(tǒng)就變成了明文數(shù)據(jù)庫(kù)安全審計(jì)直接不過(guò)關(guān)。后來(lái)改成前端先用AES加密敏感字段后端只把密文交給日志系統(tǒng)日志查詢時(shí)再解密。這就是應(yīng)用層加密的真實(shí)價(jià)值。再比如一個(gè)云筆記應(yīng)用用戶寫(xiě)的內(nèi)容同步到服務(wù)器。如果服務(wù)器本身可以解密數(shù)據(jù)那運(yùn)維人員、被拖庫(kù)時(shí)攻擊者都能看到全部筆記。這時(shí)候就需要端到端加密前端加密后上傳服務(wù)器只負(fù)責(zé)存儲(chǔ)密文解密永遠(yuǎn)發(fā)生在用戶自己的瀏覽器里。這類(lèi)需求單純指望HTTPS和服務(wù)器端防護(hù)是不夠的。我把前端加密的真實(shí)作用總結(jié)成三件事第一數(shù)據(jù)完整性校驗(yàn)確保密文或明文在傳輸、存儲(chǔ)過(guò)程中沒(méi)有被篡改第二敏感字段的端到端加密讓中間環(huán)節(jié)看不到明文第三防重放和防偽造比如用HMAC驗(yàn)證回調(diào)請(qǐng)求確實(shí)來(lái)自受信任方。想清楚這三件事你就不會(huì)被“前端加密是否安全”這類(lèi)問(wèn)題困住。1.3 哈希、消息認(rèn)證碼與加密三者千萬(wàn)別混用在講代碼之前必須把哈希、消息認(rèn)證碼和加密這三個(gè)概念掰開(kāi)。我見(jiàn)過(guò)太多項(xiàng)目把SHA256叫“加密”實(shí)際上SHA256算出來(lái)的摘要根本解不回去。哈希函數(shù)是單項(xiàng)通道它把你的一段數(shù)據(jù)映射成固定長(zhǎng)度的指紋數(shù)據(jù)稍微改一個(gè)bit指紋就面目全非。哈希的作用是校驗(yàn)完整性不是保密。消息認(rèn)證碼MAC和哈希的最大區(qū)別是它需要一把密鑰。哈希誰(shuí)都能算MAC只有持有密鑰的人才能算得出來(lái)。所以在第三方回調(diào)驗(yàn)簽、API防篡改這些場(chǎng)景里用HMAC而不是普通哈希攻擊者沒(méi)有密鑰偽造不了正確的校驗(yàn)值。加密則是可逆的它能保護(hù)機(jī)密性讓明文變成看不懂的密文接收方用密鑰還原。哈希、MAC、加密三者的定位分別是完整性、認(rèn)證性、機(jī)密性。真正項(xiàng)目里往往是組合拳先用哈希或MAC保證數(shù)據(jù)沒(méi)被改過(guò)再用加密讓數(shù)據(jù)不被別人看到。腦子里有了這個(gè)框架后面看代碼就不會(huì)暈。有一個(gè)很直觀的類(lèi)比哈希像驗(yàn)毒試紙只能告訴你這包藥材有沒(méi)有被動(dòng)過(guò)MAC像是在試紙上再加一層私人暗號(hào)只有你和對(duì)方知道暗號(hào)規(guī)則加密則是把藥材整個(gè)鎖進(jìn)保險(xiǎn)箱鎖是密碼鎖沒(méi)有密碼連看都看不到。三件事互相獨(dú)立但經(jīng)常一起用。2. JavaScript加密實(shí)戰(zhàn)瀏覽器原生API的正確打開(kāi)方式2.1 Web Crypto API為什么原生實(shí)現(xiàn)值得信賴(lài)先亮明態(tài)度新項(xiàng)目做JavaScript密碼算法優(yōu)先用瀏覽器原生的Web Crypto API而不是各種第三方加密庫(kù)。理由很簡(jiǎn)單原生API是瀏覽器內(nèi)核實(shí)現(xiàn)的運(yùn)行時(shí)有硬件加速密鑰材料在底層做管理JavaScript環(huán)境本身接觸不到完整的密鑰細(xì)節(jié)從源頭上減少被XSS腳本竊取密鑰的風(fēng)險(xiǎn)。第三方純JS庫(kù)雖然方便但很多實(shí)現(xiàn)存在歷史包袱。Web Crypto API的核心對(duì)象是crypto.subtle提供摘要、加解密、簽名、密鑰派生等能力。注意subtle這個(gè)名字官方文檔說(shuō)得很直白這是一套強(qiáng)大的低級(jí)API越強(qiáng)大越容易用錯(cuò)所以把“subtle”寫(xiě)進(jìn)了命名里。先來(lái)一個(gè)最基礎(chǔ)的哈希操作對(duì)字符串算SHA256摘要async function sha256(input) { const data new TextEncoder().encode(input); const digestBuffer await crypto.subtle.digest(SHA-256, data); const hashArray Array.from(new Uint8Array(digestBuffer)); return hashArray.map(b b.toString(16).padStart(2, 0)).join(); }這段代碼有兩個(gè)新手常犯的坑。第一digest方法不直接接受字符串必須先把字符串編碼成Uint8Array我用的是TextEncoder。第二crypto.subtle.digest返回的是ArrayBuffer不能直接打印需要轉(zhuǎn)成Uint8Array再逐字節(jié)轉(zhuǎn)十六進(jìn)制字符串。很多人天真的console.log(digest)打出來(lái)永遠(yuǎn)是[object ArrayBuffer]還以為是自己寫(xiě)錯(cuò)了。哈希用的算法名是SHA-256這里也可以用SHA-1和SHA-384但SHA-1已經(jīng)不安全除非做兼容老系統(tǒng)的完整性校驗(yàn)否則一律不要用。新項(xiàng)目無(wú)腦選SHA-256。2.2 AES-GCM對(duì)稱(chēng)加密實(shí)戰(zhàn)封裝瀏覽器端做對(duì)稱(chēng)加密我的首選永遠(yuǎn)是AES-GCM。原因有三個(gè)一是GCM模式同時(shí)提供加密和完整性認(rèn)證既保證了機(jī)密性又防止密文被篡改二是Web Crypto API原生支持不需要額外引入庫(kù)三是一個(gè)模式解決兩件事代碼結(jié)構(gòu)更簡(jiǎn)單。AES-GCM有兩個(gè)關(guān)鍵參數(shù)密鑰和IV初始化向量。IV不需要保密但絕對(duì)不能重復(fù)。同一把密鑰下如果IV重復(fù)攻擊者可以通過(guò)密文的異或關(guān)系還原出明文信息。我用crypto.getRandomValues生成12字節(jié)的隨機(jī)IV這是一個(gè)比較標(biāo)準(zhǔn)的做法12字節(jié)是GCM模式推薦的長(zhǎng)度太長(zhǎng)或太短都會(huì)帶來(lái)額外的兼容性問(wèn)題。下面是一組可以直接復(fù)用的封裝加密函數(shù)返回{ iv, ciphertext }async function aesGcmEncrypt(secretKey, plaintext, additionalData) { const iv crypto.getRandomValues(new Uint8Array(12)); const encrypted await crypto.subtle.encrypt( { name: AES-GCM, iv: iv, tagLength: 128, additionalData: additionalData }, secretKey, new TextEncoder().encode(plaintext) ); return { iv: iv, ciphertext: new Uint8Array(encrypted) }; } async function aesGcmDecrypt(secretKey, iv, ciphertext, additionalData) { const decrypted await crypto.subtle.decrypt( { name: AES-GCM, iv: iv, tagLength: 128, additionalData: additionalData }, secretKey, ciphertext ); return new TextDecoder().decode(decrypted); }這中間有個(gè)很容易被忽略的細(xì)節(jié)additionalDataAAD。它是什么它是一段不加密但要參與認(rèn)證的數(shù)據(jù)典型用法是綁定上下文。比如你加密一條消息可以把消息的ID、發(fā)送人、版本號(hào)放進(jìn)AAD這樣如果攻擊者把一條合法密文換個(gè)ID插到別處解密時(shí)AAD校驗(yàn)不過(guò)立刻失敗。等于給密文加了一層“防移花接木”的保險(xiǎn)。crypto.subtle.encrypt返回的密文里已經(jīng)包含了GCM的認(rèn)證標(biāo)簽不需要你再單獨(dú)拼接tag解密時(shí)也是自動(dòng)校驗(yàn)。如果密文被篡改decrypt會(huì)直接拋OperationError異常。這一點(diǎn)對(duì)排查問(wèn)題很重要下面第4章還會(huì)展開(kāi)講。2.3 PBKDF2與口令派生密碼存儲(chǔ)的正確姿勢(shì)接下來(lái)是另一個(gè)高頻場(chǎng)景用戶密碼。很多人拿到需求“密碼加密存數(shù)據(jù)庫(kù)”直接對(duì)密碼算一個(gè)SHA256就存進(jìn)去這是巨大的錯(cuò)誤。SHA256速度太快攻擊者拿到數(shù)據(jù)庫(kù)后用GPU暴力跑幾億次哈希毫無(wú)壓力弱口令一跑一個(gè)準(zhǔn)。正確的做法是什么要么用專(zhuān)門(mén)的慢哈希算法比如bcrypt、scrypt、Argon2要么用密鑰派生函數(shù)PBKDF2把密碼加上隨機(jī)鹽經(jīng)過(guò)成千上萬(wàn)次迭代派生出定長(zhǎng)密鑰或哈希值。慢哈希的本質(zhì)是讓每次猜測(cè)的成本變得很高從而提高暴力破解的代價(jià)。在瀏覽器端Web Crypto API支持PBKDF2。下面是一個(gè)加鹽派生的完整示例async function deriveKeyFromPassword(password, salt, iterations 310000) { const baseKey await crypto.subtle.importKey( raw, new TextEncoder().encode(password), PBKDF2, false, [deriveBits] ); const derivedBits await crypto.subtle.deriveBits( { name: PBKDF2, salt: salt, iterations: iterations, hash: SHA-256 }, baseKey, 256 ); return new Uint8Array(derivedBits); } // 調(diào)用示例 const salt crypto.getRandomValues(new Uint8Array(16)); const derivedKey await deriveKeyFromPassword(用戶密碼, salt);鹽的作用是防預(yù)計(jì)算攻擊和彩虹表。即使兩個(gè)用戶設(shè)置相同密碼只要鹽不同最終派生結(jié)果也不同。鹽必須是隨機(jī)生成、長(zhǎng)度足夠16字節(jié)以上并且可以明文存儲(chǔ)不需要保密。迭代次數(shù)決定了慢哈希的成本安全社區(qū)目前的共識(shí)是PBKDF2-HMAC-SHA256至少30萬(wàn)次迭代硬件環(huán)境允許的話做到60萬(wàn)次也不過(guò)分。在低端移動(dòng)設(shè)備上迭代次數(shù)太高的體驗(yàn)會(huì)明顯變慢需要根據(jù)自己的用戶設(shè)備畫(huà)像平衡。這里我必須強(qiáng)調(diào)一個(gè)邊界瀏覽器端運(yùn)行PBKDF2主要是為了“客戶端派生密鑰”比如做端到端加密時(shí)從用戶口令生成本地密鑰口令永遠(yuǎn)不離開(kāi)設(shè)備。而真正的密碼庫(kù)校驗(yàn)依然強(qiáng)烈建議放在服務(wù)器端用專(zhuān)門(mén)的密碼哈希方案處理。如果只是在瀏覽器里算個(gè)PBKDF2然后當(dāng)密碼哈希存到數(shù)據(jù)庫(kù)那就失去了服務(wù)端慢哈希的專(zhuān)業(yè)算法優(yōu)勢(shì)安全強(qiáng)度反而打折。3. 真實(shí)項(xiàng)目落地一個(gè)加密同步方案的完整拆解3.1 場(chǎng)景設(shè)定與整體架構(gòu)理論講再多不落地等于零。我拿一個(gè)做過(guò)多次的方案來(lái)拆解云筆記的加密同步。需求很簡(jiǎn)單筆記內(nèi)容要加密后上傳到服務(wù)器服務(wù)器只存密文即使數(shù)據(jù)庫(kù)被拖走攻擊者拿到的也是一堆無(wú)法解讀的字節(jié)。這里采用的架構(gòu)是“密鑰層級(jí)”思想。直接用用戶口令加密所有筆記并不可行因?yàn)槿我庖粭l筆記更新時(shí)都要重新派生密鑰而且口令一旦修改所有數(shù)據(jù)都要重加密。更合理的方案是引入兩層密鑰數(shù)據(jù)加密密鑰DEK為每一條筆記隨機(jī)生成真正用于AES-GCM加密筆記內(nèi)容。密鑰加密密鑰KEK由用戶口令加鹽通過(guò)PBKDF2派生用于加密DEK。整體流程是用戶輸入口令瀏覽器本地派生出KEK每新建一條筆記生成隨機(jī)DEK加密筆記內(nèi)容DEK本身再用KEK加密后和筆記密文一起上傳服務(wù)器。用戶查看筆記時(shí)先用口令派生KEK解包出DEK再用DEK解密筆記。服務(wù)器全程只接觸密文和包裹后的密鑰沒(méi)有能力還原明文。這個(gè)架構(gòu)帶來(lái)一個(gè)直接收益用戶修改口令時(shí)只需要用新KEK重新包裹所有DEK不需要把幾十萬(wàn)條筆記重新加密一遍。操作成本從“重寫(xiě)全庫(kù)”降為“重寫(xiě)密鑰表”量級(jí)完全不同。3.2 關(guān)鍵實(shí)現(xiàn)與代碼走讀密鑰包裝可以借助Web Crypto API的wrapKey和unwrapKey原生支持AES-GCM作為包裝算法。下面是核心代碼邏輯。生成一條新筆記的加密過(guò)程// 第一步生成隨機(jī)DEKAES-GCM 256位 const dataKey await crypto.subtle.generateKey( { name: AES-GCM, length: 256 }, true, [encrypt, decrypt] ); // 第二步用DEK加密筆記內(nèi)容 const iv crypto.getRandomValues(new Uint8Array(12)); const ciphertext await crypto.subtle.encrypt( { name: AES-GCM, iv: iv }, dataKey, new TextEncoder().encode(plaintext) ); // 第三步用KEK包裹DEK const wrappedKey await crypto.subtle.wrapKey( raw, dataKey, kek, { name: AES-GCM, iv: iv } );讀取筆記時(shí)的解包過(guò)程// 第一步從服務(wù)器拿到包裹后的密鑰 // 第二步用KEK解包DEK const unwrappedKey await crypto.subtle.unwrapKey( raw, wrappedKeyBuffer, kek, { name: AES-GCM, iv: iv }, { name: AES-GCM, length: 256 }, true, [encrypt, decrypt] ); // 第三步用DEK解密筆記 const decrypted await crypto.subtle.decrypt( { name: AES-GCM, iv: iv }, unwrappedKey, ciphertext );注意到一個(gè)問(wèn)題沒(méi)有包裹DEK時(shí)用了和加密筆記相同的iv。這里要特別小心如果完全復(fù)用同一個(gè)DEK和同一個(gè)IV加密兩份數(shù)據(jù)是災(zāi)難性的。但在密鑰包裹場(chǎng)景中包裹DEK用的是KEK加密筆記用的是DEK兩把密鑰不同復(fù)用IV并不會(huì)造成安全風(fēng)險(xiǎn)。不過(guò)為了保險(xiǎn)起見(jiàn)我建議還是分別為wrapKey和encrypt生成獨(dú)立的IV避免后續(xù)有人重構(gòu)代碼時(shí)混淆密鑰上下文。實(shí)現(xiàn)這個(gè)方案時(shí)DEK是否標(biāo)記為extractable也是關(guān)鍵決策。包裹密鑰之后本來(lái)可以把DEK設(shè)置為false即不可導(dǎo)出這樣JavaScript環(huán)境根本無(wú)法取出DEK的原始字節(jié)只能用它加解密。但在實(shí)際存儲(chǔ)場(chǎng)景中一旦KEK丟失或用戶忘記口令不可導(dǎo)出的DEK意味著數(shù)據(jù)徹底無(wú)法恢復(fù)?？紤]到用戶找回口令的需求我通常會(huì)保留extractable: true但伴隨更嚴(yán)格的口令策略和提醒機(jī)制讓用戶知道忘記口令等于放棄數(shù)據(jù)。3.3 密鑰管理與輪換的教訓(xùn)說(shuō)到密鑰管理我在真實(shí)項(xiàng)目里踩過(guò)不少坑這里集中說(shuō)幾個(gè)。第一不要為了方便把密鑰存進(jìn)localStorage。localStorage對(duì)同源下的所有腳本開(kāi)放一個(gè)XSS漏洞就能把密鑰偷走。哪怕你把密鑰先做一層編碼再存也只是掩耳盜鈴攻擊者只需要照貓畫(huà)虎解碼一次。密鑰的最好歸宿是“不落盤(pán)”每次使用前由口令重新派生。第二IndexedDB比localStorage更適合存密鑰主要原因不是安全性而是它支持結(jié)構(gòu)化克隆和更大的數(shù)據(jù)容量可以存CryptoKey對(duì)象并且存取是異步的。但要注意IndexedDB對(duì)XSS同樣沒(méi)有免疫力它只是工程上更合理不代表密鑰就安全了。第三密鑰輪換。很多項(xiàng)目上線時(shí)做了加密卻完全沒(méi)有輪換機(jī)制。一旦懷疑密鑰泄露或者安全合規(guī)要求定期更換你總不能讓人改一次密鑰就重加密所有歷史數(shù)據(jù)。所以設(shè)計(jì)數(shù)據(jù)模型時(shí)就要預(yù)留密鑰版本字段。我現(xiàn)在的做法是在每條密文記錄里額外存一個(gè)keyVersion字段。輪換時(shí)生成新的KEK批量解包-重新包裹DEK更新版本號(hào)。解密時(shí)根據(jù)記錄的版本號(hào)選擇對(duì)應(yīng)的KEK歷史數(shù)據(jù)平滑過(guò)渡。整個(gè)過(guò)程用戶無(wú)感知數(shù)據(jù)量也不需要全量重加密這是密鑰層級(jí)架構(gòu)另一個(gè)很大的優(yōu)勢(shì)。第四永遠(yuǎn)不要在前端日志里打印密鑰或口令。調(diào)試時(shí)開(kāi)發(fā)者也難免手滑把console.log(wrappedKey)留在線上代碼里。我在代碼規(guī)范里直接加了要求涉及密鑰對(duì)象的日志一律使用console.log([key] omitted)避免思維方式上就養(yǎng)出隨手打的習(xí)慣。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 安全上下文與兼容性為什么我的crypto.subtle是undefinedWeb Crypto API有一個(gè)硬性條件必須在安全上下文中可用。所謂安全上下文簡(jiǎn)單說(shuō)就是HTTPS頁(yè)面或localhost環(huán)境。如果你直接在某個(gè)HTTP內(nèi)網(wǎng)地址打開(kāi)頁(yè)面window.crypto.subtle大概率是undefined所有加密代碼都會(huì)報(bào)錯(cuò)。排查這個(gè)問(wèn)題最快的方式是看一眼瀏覽器控制臺(tái)錯(cuò)誤。如果是“Cannot read properties of undefined (reading digest)”先確認(rèn)是不是在HTTP環(huán)境。開(kāi)發(fā)階段建議用localhost進(jìn)行聯(lián)調(diào)因?yàn)闉g覽器把localhost視為安全上下文不需要配HTTPS證書(shū)。生產(chǎn)環(huán)境則必須上HTTPS這本身也是Web安全的基本要求。Node.js環(huán)境下情況略有不同。Node.js 20開(kāi)始全局的crypto對(duì)象默認(rèn)包含subtle可以直接使用更早版本需要從require(crypto).webcrypto取。前后端共用同一套Web Crypto API代碼是可行的但要注意兩端默認(rèn)支持細(xì)節(jié)存在差異比如某些算法名、哈希算法清單可能不一致。兼容性方面還有一個(gè)必須提的坑老版本瀏覽器IE時(shí)代遺產(chǎn)比如某些企業(yè)瀏覽器內(nèi)核根本不支持crypto.subtle。如果產(chǎn)品明確需要支持這類(lèi)環(huán)境要么引入降級(jí)方案要么干脆在功能設(shè)計(jì)上做分流不要試圖用同一個(gè)代碼路徑硬兼容否則你會(huì)被一串又一串的環(huán)境判斷折磨到崩潰。4.2 二進(jìn)制數(shù)據(jù)的編碼轉(zhuǎn)換ArrayBuffer、Uint8Array與Base64做密碼學(xué)開(kāi)發(fā)二進(jìn)制數(shù)據(jù)的編碼轉(zhuǎn)換幾乎是每天都要處理的事。crypto.subtle的輸入輸出全是ArrayBuffer和Uint8Array但網(wǎng)絡(luò)傳輸、數(shù)據(jù)庫(kù)存儲(chǔ)、URL傳參都要求字符串或Base64。很多新手在這里翻車(chē)我見(jiàn)到最多的報(bào)錯(cuò)是“byte length mismatch”或“invalid key length”仔細(xì)一查全是編碼沒(méi)轉(zhuǎn)對(duì)。下面這組工具函數(shù)我?guī)缀趺總€(gè)項(xiàng)目都會(huì)粘一份function bytesToHex(bytes) { return Array.from(new Uint8Array(bytes)) .map(b b.toString(16).padStart(2, 0)) .join(); } function base64ToBytes(base64) { const binaryString atob(base64); const bytes new Uint8Array(binaryString.length); for (let i 0; i binaryString.length; i) { bytes[i] binaryString.charCodeAt(i); } return bytes; } function bytesToBase64(bytes) { let binary ; const uint8 new Uint8Array(bytes); for (let i 0; i uint8.length; i) { binary String.fromCharCode(uint8[i]); } return btoa(binary); }這里有一個(gè)容易懵的點(diǎn)Uint8Array和ArrayBuffer是兩種不同的東西。Uint8Array本質(zhì)是一個(gè)“視圖”它里面有一個(gè)buffer屬性指向底層的ArrayBuffer。你如果傳給crypto.subtle一個(gè)從ArrayBuffer上切出來(lái)的Uint8Array通常沒(méi)問(wèn)題因?yàn)閃eb Crypto API接受BufferSource也就是它倆都行。但當(dāng)你需要精確控制長(zhǎng)度時(shí)務(wù)必用byteLength而不是length因?yàn)閁int8Array的長(zhǎng)度可能只是底層ArrayBuffer的一部分。另一個(gè)和服務(wù)器通信時(shí)的典型問(wèn)題后端返回Base64字符串前端直接JSON.parse解出字符串后忘了轉(zhuǎn)回字節(jié)數(shù)組就傳給crypto.subtle.importKey結(jié)果密鑰導(dǎo)入報(bào)錯(cuò)。處理JSON傳輸時(shí)密鑰和密文一律用Base64字符串承載拿到前端先轉(zhuǎn)字節(jié)再參與運(yùn)算。4.3 AES-GCM解密失敗逐層排查清單AES-GCM解密失敗拋OperationError這是最典型的加密報(bào)錯(cuò)。我把自己總結(jié)的排查思路列成清單按下面的順序查大多數(shù)問(wèn)題五分鐘內(nèi)能定位。第一檢查IV是否和解密時(shí)一致。很多人只保存了密文忘記保存IV。AES-GCM解密必須使用加密時(shí)的同一個(gè)IV否則GCM認(rèn)證必然失敗。所以存儲(chǔ)時(shí)一定要把iv和ciphertext放在一起保存甚至可以把IV直接拼在密文前面然后統(tǒng)一轉(zhuǎn)為Base64?，F(xiàn)象最可能原因處理建議解密報(bào)OperationError密文被篡改、IV不對(duì)、AAD不一致逐項(xiàng)比對(duì)密文、IV、AAD密鑰導(dǎo)入失敗密鑰字節(jié)長(zhǎng)度不對(duì)或編碼錯(cuò)誤確認(rèn)Base64轉(zhuǎn)字節(jié)無(wú)殘留、長(zhǎng)度符合算法要求頁(yè)面打開(kāi)即報(bào)錯(cuò)crypto.subtle不可用檢查HTTPS、localhost、瀏覽器版本服務(wù)器與前端互通失敗編碼規(guī)則不一致比如前端hex、后端base64統(tǒng)一編碼格式建立轉(zhuǎn)換工具函數(shù)數(shù)據(jù)偶爾解密失敗并行加密時(shí)IV生成沖突或隨機(jī)源退化確認(rèn)用crypto.getRandomValues避免自實(shí)現(xiàn)隨機(jī)數(shù)第二確認(rèn)IV字節(jié)數(shù)是否為12字節(jié)。GCM標(biāo)準(zhǔn)推薦12字節(jié)太長(zhǎng)在某些實(shí)現(xiàn)里要額外做IV哈希處理容易出現(xiàn)兼容性問(wèn)題。我見(jiàn)過(guò)有人用了16字節(jié)IVNode.js 和瀏覽器某一邊能解、另一邊不行查到最后是IV長(zhǎng)度處理規(guī)則不一致。第三檢查additionalData。如果你在加密時(shí)傳了AAD解密時(shí)也必須傳一模一樣的AAD順序和字節(jié)都不能錯(cuò)。這里最坑的是AAD在傳輸過(guò)程中如果被序列化成了不一樣的編碼比如字符串編碼從UTF-8變成UTF-16解密也會(huì)失敗。第四確認(rèn)導(dǎo)出導(dǎo)入密鑰時(shí)沒(méi)有改變字節(jié)順序。密鑰的raw導(dǎo)出直接對(duì)應(yīng)字節(jié)序列不應(yīng)該有任何處理。有些代碼為了顯示好看把密鑰轉(zhuǎn)成hex字符串再次解碼中間一旦出現(xiàn)大小寫(xiě)處理誤差密鑰就廢了。4.4 大數(shù)據(jù)量加密的性能取舍前面講的所有示例都是對(duì)小數(shù)據(jù)量直接加密但真正做文件同步、圖片加密這類(lèi)需求時(shí)直接把整個(gè)文件塞進(jìn)crypto.subtle.encrypt會(huì)讓內(nèi)存瞬間爆炸。瀏覽器里加密一個(gè)幾百M(fèi)B的文件你幾乎能聽(tīng)到風(fēng)扇狂轉(zhuǎn)的聲音。標(biāo)準(zhǔn)做法是分塊加密把文件切成固定大小的分塊比如1MB一塊依次加密后傳給服務(wù)器。但GCM模式有分塊安全邊界分塊太小會(huì)擴(kuò)大密文膨脹率分塊太大則內(nèi)存占用高。我實(shí)測(cè)下來(lái)1MB到4MB是一個(gè)比較舒服的區(qū)間密文膨脹率約為密文長(zhǎng)度的0.8%GCM各分塊都要加一個(gè)認(rèn)證標(biāo)簽通常16字節(jié)在可接受范圍內(nèi)。分塊加密時(shí)每個(gè)分塊必須使用獨(dú)立的IV并且不能以任何可預(yù)測(cè)的方式遞增。最穩(wěn)妥的是每塊都用crypto.getRandomValues生成隨機(jī)IV同時(shí)把分塊序號(hào)、IV、密文長(zhǎng)度作為存儲(chǔ)元數(shù)據(jù)保存。注意分塊序號(hào)的意義它防止攻擊者刪除或調(diào)換分塊順序結(jié)合每個(gè)分塊的GCM認(rèn)證標(biāo)簽可以有效保證數(shù)據(jù)的完整性和順序。const CHUNK_SIZE 1024 * 1024; // 1MB async function encryptFile(file, key) { const chunks []; for (let offset 0; offset file.size; offset CHUNK_SIZE) { const slice file.slice(offset, offset CHUNK_SIZE); const buf await slice.arrayBuffer(); const iv crypto.getRandomValues(new Uint8Array(12)); const enc await crypto.subtle.encrypt( { name: AES-GCM, iv: iv }, key, buf ); chunks.push({ index: chunks.length, iv: bytesToBase64(iv), data: bytesToBase64(new Uint8Array(enc)) }); } return chunks; }在這個(gè)例子里我先對(duì)每個(gè)分塊獨(dú)立加密再把分塊元數(shù)據(jù)傳給服務(wù)器。如果不做Web Worker主線程中循環(huán)加密1MB分塊會(huì)讓頁(yè)面出現(xiàn)明顯的卡頓。更合理的方式是把加密任務(wù)扔進(jìn)Web Worker把主線程騰出來(lái)給用戶交互。我在項(xiàng)目中通常會(huì)創(chuàng)建一個(gè)專(zhuān)門(mén)的加密Worker接收ArrayBuffer返回加密結(jié)果主線程只維護(hù)任務(wù)狀態(tài)和進(jìn)度條。整體體驗(yàn)?zāi)軓摹包c(diǎn)擊保存后頁(yè)面凍結(jié)三秒”變成“后臺(tái)默默加密、界面絲滑不減”。最后分享一個(gè)調(diào)用習(xí)慣多次調(diào)用crypto.subtle的異步方法時(shí)不要在循環(huán)里無(wú)腦await串行執(zhí)行逐個(gè)排隊(duì)會(huì)拖慢總時(shí)長(zhǎng)。在任務(wù)粒度小、相互獨(dú)立的前提下可以考慮用Promise.all并發(fā)控制但要注意并發(fā)量一次性發(fā)幾十個(gè)加密任務(wù)同樣能把CPU踩滿。我的經(jīng)驗(yàn)是維護(hù)一個(gè)并發(fā)池同時(shí)運(yùn)行4到6個(gè)加密任務(wù)既充分利用多核資源又不至于讓頁(yè)面失去響應(yīng)。加密性能優(yōu)化本質(zhì)上是個(gè)資源調(diào)度的活在瀏覽器這種單線程表象下需要多試幾種策略找到適合自己場(chǎng)景的平衡點(diǎn)。踩過(guò)幾次坑之后我現(xiàn)在做前端加密方案已經(jīng)形成了一套固定動(dòng)作先確認(rèn)威脅模型想清楚要防誰(shuí)再選算法能走Web Crypto API就不引第三方庫(kù)然后設(shè)計(jì)密鑰層級(jí)預(yù)計(jì)未來(lái)的輪換需求最后把編碼轉(zhuǎn)換工具函數(shù)寫(xiě)好放在公共模塊里。這個(gè)流程讓我從“寫(xiě)出一段能跑的加密代碼”進(jìn)化到“做出一個(gè)幾年后依然經(jīng)得起推敲的加密設(shè)計(jì)”中間省下來(lái)的排查時(shí)間非?？捎^。如果你正好在做一個(gè)新的加密功能我建議先從第2章的AES-GCM封裝入手把它內(nèi)置到項(xiàng)目工具庫(kù)里再逐步疊加PBKDF2派生、密鑰包裹和分塊加密。不要一開(kāi)始就上大而全的加密框架瀏覽器密碼學(xué)最危險(xiǎn)的地方恰恰是那些看起來(lái)很省事的封裝它們隱藏了太多細(xì)節(jié)而安全這件事最怕的就是細(xì)節(jié)失守。