CERT-In 加密貨幣警告：5 項安全檢查揭示個人防護的局限
CERT-In 警告，儘管早前曾進行修復工作，AI 輔助的攻擊者仍正瞄準印度金融平台，包括加密貨幣交易所。CERT-In 於 2026 年 11 月 4 日發出的加密貨幣警告，將焦點由具說服力的詐騙訊息，轉向保管客戶資產的基礎設施。對印度加密貨幣用戶而言，五項安全檢查固然重要，但其局限同樣不可忽視。
核心矛盾在於個人控制與平台依賴之間。用戶可以保護交易所登入帳戶，卻仍須依賴自己無法檢視的系統。將資產轉入自託管錢包，讓用戶控制自己的簽署金鑰，會改變這種依賴關係，但亦會帶來不同責任。
FBI 早前將 Bybit 盜竊案歸因於北韓，為機構風險提供了歷史參考。這並不能證實該事件與 AI 有關。現時印度的警示本身已提出疑問：客戶能驗證甚麼，而服務供應商又必須證明甚麼。
CERT-In 加密貨幣警告令資產託管成為首項檢查
印度電腦緊急應變小組於 11 月 4 日發布最新警示，更新其 10 月就未經授權金融轉帳所發出的警告。通告將加密貨幣交易所列為受影響金融服務類別之一，並提及錢包金鑰遭竊，形容該攻擊活動仍在進行。
CERT-In 將有關活動歸因於名為 CRAFTY FALCON 的威脅行為者。根據其 AI 輔助攻擊警示，攻擊者曾針對機構系統，並利用支付介面轉移資金。據報部分機構在修復不完整後再次遭受攻擊。
首項安全檢查，是辨識誰控制資產，因為帳戶保護與託管保護解決的是不同問題。
託管型交易所控制用於持有及轉移客戶資產的基礎設施。客戶通常透過受供應商系統規管的帳戶存取其持倉。其安全設定有助保障帳戶存取權，但不會揭示機構簽署金鑰如何受到保護。
這一分野令警告即使對從不接觸陌生代幣或未經請求投資訊息的人亦具影響。一名謹慎的客戶仍會受制於供應商內部作出的決策。良好的個人習慣無法取代供應商的營運控制措施。
當前問題是，用戶是否了解自己的託管安排。一個熟悉的應用程式介面，可以掩蓋責任上實質不同的安排。交易所餘額、由用戶控制的錢包，以及投資儀表板，不應被視為可互換的資產控制證明。
客戶可以查閱已發布的託管說明、提款程序、事故通知及支援文件。這些資料無法證明基礎設施安全，卻可顯示供應商有否清楚說明其責任，讓客戶作出知情決定。
若供應商只談及客戶的密碼安全習慣，便有一項重要問題仍未獲解答。客戶亦需要了解圍繞機構轉帳的保障措施。關於安全的市場推廣語言，並不說明哪些操作需要獨立批准，或可疑活動如何獲得處理。
自託管是轉移責任，而非消除責任。用戶獲得對簽署憑證的直接控制權，但同時須負責保護及復原這些憑證。無法安全管理復原資料的人，應在倉卒作出改變前認清這一限制。
實際含意是審慎管理風險暴露。用戶應知道哪些資產依賴供應商，哪些則取決於自己的程序。在警告壓力下作出的決定，若目的地或復原流程仍然陌生，便可能帶來新的錯誤。
因此，CERT-In 加密貨幣警告挑戰了「個人清單可為整段金融關係作認證」這種想法。清單仍然有用，但第一項任務是劃定界線。客戶在決定額外保護措施可帶來甚麼作用前，必須知道自己的控制權止於何處。
更強的登入保護客戶，卻不能保護交易所整個資產負債表
第二項檢查涉及交易所帳戶，以及用作復原該帳戶的電郵帳戶。這些存取點值得一併關注。保護可見的登入方式，卻忽略復原設定，會形成不完整的帳戶安全圖像。
多重驗證要求密碼以外的額外證明，例如裝置或驗證碼。然而，不同實作方式可抵禦不同攻擊。一項標示為「雙重驗證」的安全設定，並不說明用戶輸入的資料會否被具說服力的偽造網站擷取。
CISA 的抗釣魚驗證指引指出，FIDO/WebAuthn 驗證是廣泛可用的抗釣魚方法。這項技術會將驗證程序綁定至合法服務。若服務支援，相容的 passkey 或安全金鑰可提供不同於手動輸入驗證碼的防護。
更強的登入可降低帳戶遭接管的風險，但無法修復平台內部已受入侵的系統。
這項限制應影響交易所如何傳達安全改善措施。支援 passkey 的公告與客戶存取相關，但並不能獨立證明機構資產、內部審批或軟件部署系統獲得同等保護。
客戶應區分自己選用的驗證方式，以及完整的復原流程。復原機制旨在於出錯時恢復合法存取權。因此，它應與主要登入方式一同受審視，而非被視為次要的行政細節。
例如，客戶可能以 passkey 保護交易所帳戶，卻未有妥善保護相關電郵。交易所設定仍然有價值。然而，用戶需要檢視透過電郵或其他復原渠道仍可進行哪些帳戶變更。
同樣分野亦適用於活躍工作階段及已連接裝置。成功登入只是帳戶生命週期的一部分。用戶應了解哪些現有裝置仍保有存取權，以及服務如何傳達變更，尤其是在懷疑帳戶受入侵後。
這些問題關乎實際使用中的服務。驗證選項各有不同，用戶應查閱供應商最新文件。假設每間交易所均支援相同方法，或以相同方式處理復原流程，會構成誤導。
因此，供應商比較應檢視行為，而不只看品牌熟悉程度。某項服務可能清楚說明復原限制，另一項則強調便利存取。這些差異會影響客戶理解及管理帳戶風險暴露的能力。
這是一項實際取捨。用戶無法復原或維持的安全措施，可能導致帳戶被鎖及採取高風險變通方法。缺乏清晰界線的便利，則可能令他們無法辨識哪些要求值得獨立核實。
對交易所而言，壓力在於將更安全的存取方式與可理解的復原機制連結起來。對用戶而言，任務較為聚焦：核實實際可用的保護措施，並了解其限制。任何一方都不應將一項驗證功能描述為全面保證。
這正是機構警告改變討論的地方。個人登入改善仍然值得採取，但只處理其中一條損失途徑。客戶應期望供應商以介紹帳戶設定時同樣清晰的方式，說明機構層面的保障措施。
AI 冒充令獨立驗證比表面可信更重要
第三項檢查，是用戶如何核實涉及資產的突發指示。這包括看似來自支援人員、同事、親屬或投資聯絡人的要求。關鍵問題是，該指示是否具有經獨立確認的來源。
生成式 AI 從學習所得的模式產生文字、圖像、音訊或其他內容。其在詐騙中的角色，毋須破解錢包的密碼學機制。它可以協助攻擊者令既有騙局看來更可信。
FBI 在 2024 年 12 月的警告中描述，罪犯使用合成身分、投資內容、複製聲線及生成影片。其 AI 詐騙警告亦建議獨立聯絡機構，而非相信來電者的身分。該警告早於目前印度攻擊活動。
逼真的聲線或精心製作的訊息，應促成對話，而非授權一項金融操作。
分析上的分野，在於表面真實性與已核實授權之間。一名來電者可以聲音熟悉，卻無權重新定向資產。一則訊息可以載有準確個人資料，卻未必來自它所聲稱的機構。
可考慮一個涉及交易所客戶的示例情境。來電者聲稱發生緊急安全事故，要求將資產轉至替代地址。客戶應作出的決定性提問，是有否經獨立核實的指示，而非聲音聽來是否可信。
此例屬假設，並非歸因於 CRAFTY FALCON 的事件。它說明為何機構警告可令不相關的冒充企圖變得重要。一項真實的安全公告，並不會驗證每一則援引該公告的訊息。
較安全的界線，是採用與來電要求分開建立的聯絡途徑。開啟熟悉的應用程式，或使用先前已核實的支援資料，會改變由誰控制對話。跟隨來電者的連結，則保留攻擊者界定下一步的能力。
即使沒有 AI 參與，這種做法同樣有幫助。用戶毋須先判斷由哪個模型生成訊息，才拒絕授權。核實程序應同時適用於一般冒充及合成媒體。
這項分野亦適用於管理商業資金的僱主及知識工作者。可辨識的高層面孔，不能取代審批流程。即使對話看來私人化，金融授權仍須依附既定角色與程序。
它亦適用於共同作出投資決定的家庭。緊急要求會造成情緒壓力，單靠技術解釋未必能化解。事先商定獨立確認程序，可令回應較少依賴人在壓力對話中的判斷。
引用資料並無證據顯示每一則可疑加密貨幣訊息均使用 AI。AI 標籤亦不衡量個別要求的可信度。將所有詐騙視為新技術現象，可能令人忽略其背後真正的授權決定。
對平台而言，這帶來溝通上的挑戰。其正當的安全指示應可透過既有渠道輕易核實。客戶不應需要相信一則主動發送的訊息，才可得知該訊息是否真確。
錢包控制權改變風險，但批准仍然重要
第四項檢查涉及復原資料及錢包授予的權限。當客戶考慮減少依賴交易所時，這一點尤其重要。自我託管改變了誰可授權交易，但不會令每項操作都變得安全。
復原短語是一組用於恢復存取錢包簽署憑證的詞語。任何處理這些資料的人，在儲存或分享前都需要了解其作用。要求披露復原短語的請求，應與一般帳戶問題得到不同處理。
Ethereum 的錢包安全指引建議用戶保護復原短語、核實交易詳情，並避免不必要的支出權限。指引亦說明硬件錢包的價值；這類裝置旨在讓簽署密鑰與連接互聯網的電腦分隔。
只有用戶同時保持對憑證及授權的控制，對錢包的控制權才有價值。
智能合約是在區塊鏈上執行的軟件。有些互動會要求獲授權花費特定代幣，而非立即轉移全部餘額。這種差異有助說明，即使畫面不像傳統付款，為何仍須審閱授權。
連接錢包與授權支出並非可互換的操作。用戶需要一個介面，清楚說明系統要求他們批准甚麼。混淆這些步驟，會令評估看似日常互動的後果變得更困難。
核心問題在於可理解的權限。用戶在批准操作前，應能識別所涉資產、收款方及權限。如請求仍不清楚，即使出現熟悉的標誌，也無法消除這種不確定性。
硬件錢包可加強密鑰保護，但不應成為批准不熟悉請求的理由。裝置的保護作用，部分取決於用戶如何操作它。將憑證分隔存放，並不代表授權內容是否合理變得無關重要。
這亦解釋了為何在恐慌期間轉移資產必須謹慎。倉促遷移可能同時涉及不熟悉的軟件、新的復原資料，以及未經核實的目的地。這項轉移本身應被視為對安全敏感的流程加以評估。
比較自我託管產品與交易所時，必須承認兩者的失效邊界不同。交易所可集中處理支援及營運責任。自我託管錢包讓用戶擁有更直接的權限，同時要求他們對復原及簽署承擔更直接的責任。
兩種安排都不應被無條件貼上安全標籤。有用的比較在於，某一特定用戶能否理解和管理當中的風險。技術經驗豐富的人與偶爾購買者，可能作出不同決定，而不代表任何一方忽視安全。
對 AI 產品用戶而言，復原短語應置於一般寫作及知識工作流程之外。工具在整理研究資料方面的實用性，並不構成上傳簽署憑證的理由。將一般文件與金融機密分開，是一條實際的界線。
更廣泛的啟示是減少不必要的權限。用戶應質疑自己不明白的權限，正如機構應質疑過多的內部存取權。兩者適用的規模不同，但都取決於控制已批准操作實際上能啟用甚麼。
事故應變準備是第五項檢查，而復原仍充滿不確定性
第五項檢查是用戶是否知道在事故發生前如何應對。準備工作很重要，因為懷疑遭入侵會引發對裝置、帳戶、交易及支援渠道的混亂。即場臨時決定每一步，會令獨立核實更困難。
印度的金融詐騙舉報框架包括 1930 熱線及 National Cybercrime Reporting Portal。印度內政部將其列為舉報金融網絡詐騙的渠道。舉報時亦應聯絡相關金融服務提供者。
有文件記錄的應對渠道可改善協調，但沒有任何舉報渠道保證可追回加密資產。
交易所帳戶事故與自我託管事故所需資料不同。前者涉及服務提供者的帳戶系統及內部應對。後者則可能涉及錢包地址、交易紀錄、權限，以及用戶簽署環境的狀況。
用戶應保留手上可取得的證據，包括訊息、交易識別碼、地址、帳戶通知及事件經過。清晰紀錄有助區分實際發生的事，與初期恐慌中形成的假設。
處理證據時應避免進一步散播機密。支援對話可能需要交易詳情，但不需要復原詞。用戶應分開處理可識別事故的資料，以及可授權操作餘下資產的資料。
應對渠道同樣需要獨立核實。新的聯絡人即使聲稱可立即協助追回資產，也不應只因情況緊急而自動獲得信任。損失前採用的相同標準，在損失後仍然適用。
對服務提供者而言，事故溝通應區分已確認的發現與仍在進行的調查。服務已恢復的聲明，本身並不能回答有關最初入侵的所有問題。客戶需要清楚了解受影響的功能，以及他們需要採取的行動。
這種區分是理解 CERT-In 加密貨幣警告的核心。該通知描述持續存在的機構性風險，而客戶通常只會透過簡短的營運更新獲取資訊。可用性與安全性互有關聯，但並非相同的主張。
公開證據亦有重要限制。該建議並未證明每一家印度加密貨幣交易所都已遭入侵。它亦沒有提供按平台劃分的安全排名，或客戶損失的完整公開統計。
關於 AI 的歸因同樣需要謹慎。CERT-In 報告了 AI 輔助活動，但公開通知並未獨立證明每項工具對每宗事故的貢獻。讀者應保留這種歸因的限定，而非將之演變為 AI 單獨造成每次入侵的說法。
這種不確定性不會令警告失去意義，而是改變了值得提出的問題。用戶需要其服務提供者的實際資訊，調查人員則需要支持具體技術結論的證據。
因此，事故應變準備是一項協調檢查，而不是獲救承諾。客戶應知道正當的舉報渠道，並保留可用紀錄。平台仍有責任說明其營運系統內發生了甚麼。
下一項檢驗是服務提供者能否讓保護措施變得可觀察
CERT-In 的加密貨幣警告帶來立即檢視風險的理由。未來數月，更嚴格的檢驗將是公開資訊會否變得更有用。反覆提醒客戶並不能解答有關機構保障的問題。
最有意義的後續發展，是有證據顯示服務提供者已降低客戶無法自行管理的風險。
首個值得留意的訊號是具體披露補救措施。服務提供者可說明其檢視過哪些系統或流程類別，而無須公開敏感的實作細節。有用的資訊包括已完成的改動、其涵蓋範圍，以及機構如何評估這些改動是否持續有效。
如評估範圍清楚，獨立評估將可加強這些資訊的可信度。「已檢視安全性」一語，若沒有說明檢查了甚麼，意義不大。客戶應區分針對特定組件的評估，與對託管營運作出的更廣泛結論。
更詳細的披露，將有助建立信心，證明警告促成了具體的機構應對。含糊的保證則會令原有的不確定性大致維持不變。單憑沉默或精心修飾的措辭，均不能證明某個服務提供者是否已遭入侵。
第二個訊號是日常使用中的客戶保護會否變得更清晰。驗證選項、復原程序及提款控制的說明，均可直接評估。服務提供者的文件應協助用戶理解可用的保障，而不需要他們解讀宣傳用語。
最有力的改進，應將便利性與可理解的限制連結起來。客戶需要知道帳戶保護功能涵蓋甚麼，以及哪些部分仍交由機構系統處理。即使服務提供者採用不同設計選擇，這種清晰度仍可支持更佳決策。
若只聚焦於客戶密碼，將削弱外界對應對措施廣度的信心。這會處理一個重要問題，卻令託管問題仍未獲解答。公開警告所關注的，不只是個別帳戶持有人的行為。
第三個訊號是有關重複事故及攻擊歸因的後續證據。新增的官方發現或可釐清受影響功能、補救失敗之處，以及 AI 輔助所扮演的角色。這些發現應按其具體程度評價，而非按威脅標籤的新穎程度評價。
再次發生事故，將需要檢視潛在風險是否仍未解決。沒有新的公開報告，則較難得出結論。舉報慣例、調查時程及披露決定，都可能限制外界所知。
這亦是國際比較變得有用的地方。FBI 對 Bybit 盜竊案的歸因，提供了一個大型交易所層面事故的既有例子。它為機構風險提供背景，但並不能證明與這次印度活動有關。
比較應保持狹窄。不同事故可涉及不同的存取途徑、控制措施及證據。若將它們一概歸入 AI 安全標籤，將掩蓋客戶及調查人員需要辨別的差異。
對印度用戶而言，長遠的決定是願意接受多少依賴，以及甚麼證據可支持這項選擇。個人安全功能可見且可採取行動。機構做法則較難評估，因此精確的服務提供者溝通更有價值。
在緊急訊息迫使你作出決定前，檢視你的託管安排、帳戶存取、核實習慣、錢包權限及舉報渠道。向服務提供者提出可區分個人保護與機構責任的問題。將已核實的聯絡資料及一般事故紀錄存放在容易取得的地方，同時將復原短語置於該等文件之外。如有請求要求你轉移資產、披露機密或批准不熟悉的操作，請透過既有渠道核實其來源。利用 CERT-In 的加密貨幣警告識別具體缺口，而非倉促遷移。你可以自行核實保護措施的哪些部分，而哪些部分仍取決於服務提供者的說明？
