CERT-In 加密货币警告：5 项安全检查揭示个人防护的局限

CERT-In 警告称，尽管此前已采取补救措施，AI 辅助的攻击者仍在瞄准印度金融平台，包括加密货币交易所。2026 年 11 月 4 日发布的 CERT-In 加密货币警告，将关注点从极具迷惑性的诈骗信息，转向托管客户资产的基础设施。对印度加密货币用户而言，五项安全检查固然重要，但其局限性同样不容忽视。

核心矛盾在于个人控制与平台依赖之间。用户可以保护交易所登录账户，却仍要依赖自己无法审查的系统。将资产转入自托管——即用户自行控制签名密钥——会改变这种依赖关系，但也会引入不同的责任。

FBI 此前将 Bybit 失窃事件归因于朝鲜，为机构层面的风险敞口提供了历史参照。但这并不能证明该事件与 AI 有关联。当前的印度安全公告本身已提出问题：客户能够验证什么，以及服务提供商必须证明什么。

CERT-In 加密货币警告将托管列为首要检查项

印度计算机应急响应小组于 11 月 4 日发布最新公告，更新了 10 月份关于未经授权金融转账的警告。该公告将加密货币交易所列为受影响的金融服务类别之一，并描述了钱包密钥被盗的情况，称该攻击活动仍在持续。

CERT-In 将相关活动归因于一个名为 CRAFTY FALCON 的威胁行为者。根据其 AI 辅助攻击公告，攻击者曾瞄准机构系统，并利用支付接口转移资金。据报道，一些组织在补救措施不完整后再次遭到攻击。

第一项安全检查是确认谁控制资产，因为账户防护与托管防护解决的是不同问题。

托管型交易所控制着用于持有和转移客户资产的基础设施。客户通常通过受服务提供商系统约束的账户访问其持仓。他们的安全设置有助于保护账户访问，但并不能揭示机构签名密钥是如何受到保护的。

这一差异使得该警告即使对从不接触陌生代币或未经请求的投资信息的人也具有重要意义。谨慎的客户仍会受到服务提供商内部决策的影响。强有力的个人习惯无法替代服务提供商的运营控制。

眼下的问题是，用户是否了解自己的托管安排。熟悉的应用界面可能掩盖实质不同的责任。交易所余额、由用户控制的钱包，以及投资仪表盘，不应被视为资产控制权的可互换证明。

客户可以查看公开的托管说明、提款流程、事件公告和支持文档。这些材料无法证明基础设施安全，但可以显示服务提供商是否足够清晰地解释其责任，让客户作出知情决定。

如果服务提供商只描述客户的密码安全习惯，就留下了一个重要问题未答。客户还需要了解围绕机构转账设置的保障措施。有关安全性的营销语言无法说明哪些操作需要独立批准，或可疑活动将如何获得关注。

自托管是责任的转移，而非责任的消除。用户获得对签名凭据的直接控制，但也必须自行负责其保护与恢复。无法安全管理恢复信息的人，应在仓促变更前认识到这一限制。

实际含义是有意识地管理风险敞口。用户应了解哪些资产依赖于服务提供商，哪些依赖于自身流程。在警告带来的压力下作出的决定，如果目的地或恢复流程仍不熟悉，可能会引发新的错误。

因此，CERT-In 加密货币警告挑战了这样一种看法：个人检查清单能够为整个金融关系提供认证。检查清单依然有用，但它的首要任务是划定边界。客户需要先知道自己的控制权止于何处，才能判断额外保护措施能实现什么。

更强的登录防护保护客户，而非交易所的全部资产负债表

第二项检查涉及交易所账户及用于恢复该账户的电子邮箱。这些访问入口都应受到重视。保护了可见的登录入口，却忽略恢复设置，会形成不完整的账户安全图景。

多因素认证要求提供密码之外的额外证明，例如设备或认证代码。然而，不同的实现方式抵御的攻击类型也不同。一项标注为“双因素认证”的安全设置，并不能说明一个极具迷惑性的钓鱼网站能否窃取用户输入的信息。

CISA 的 抗钓鱼认证指南 将 FIDO/WebAuthn 认证列为一种广泛可用的抗钓鱼方案。这项技术将认证绑定到合法服务。在支持的情况下，兼容的通行密钥或安全密钥可提供不同于手动输入验证码的防护。

更强的登录防护可降低账户被接管的风险，但无法修复平台内部已受损的系统。

这一局限应当影响交易所如何传达安全改进。关于支持通行密钥的公告，与客户访问安全有关；但它并不能独立证明机构资产、内部审批或软件部署系统获得了同等保护。

客户应区分自己选择的认证方法与完整的恢复流程。恢复机制用于在出现问题时恢复合法访问，因此应与主要登录方式一并审查，而不应被视为次要的管理细节。

例如，客户可能使用通行密钥保护交易所账户，却没有充分保护关联的电子邮箱。交易所设置依然具有价值，但用户仍需检查通过电子邮箱或其他恢复渠道可完成哪些账户变更。

同样的区别也适用于活跃会话和已连接设备。成功登录只是账户生命周期的一部分。用户应了解哪些现有设备仍保留访问权限，以及服务如何传达变更，尤其是在怀疑账户已受损之后。

这些问题都与实际使用的服务有关。认证选项各不相同，用户应查阅服务提供商当前的文档。假定每家交易所都支持相同方法或以相同方式处理恢复流程，具有误导性。

因此，对服务提供商的比较应关注其实际行为，而非仅凭品牌熟悉度。一项服务可能会清晰说明恢复限制，另一项则强调便捷访问。这些差异会影响客户理解和管理账户风险敞口的能力。

其中存在现实的权衡。用户无法恢复或维持的安全措施，可能导致账户锁定和高风险的变通做法。缺少明确边界的便利性，则可能让他们无法识别哪些请求需要独立核验。

对交易所而言，压力在于将更安全的访问方式与易于理解的恢复流程结合起来。对用户而言，任务更为具体：核实实际可用的防护措施，并理解其局限。任何一方都不应将认证功能描述成全面保证。

正是在这里，机构警告改变了讨论重点。个人登录改进依然值得采取，但它们只解决了一条资产损失路径。客户应期待服务提供商以解释账户设置时同样清晰的方式，说明机构层面的保障措施。

AI 冒充使独立核验比视觉可信度更重要

第三项检查是，用户如何核验涉及资产的意外指令。这包括看似来自客服人员、同事、亲属或投资联系人的请求。关键问题是，该指令是否具有独立确认的来源。

生成式 AI 会依据学习到的模式生成文本、图像、音频或其他内容。它在欺诈中的作用并不需要破解钱包加密技术。它可以帮助攻击者让既有骗局看起来更可信。

FBI 在 2024 年 12 月的警告中描述，犯罪分子使用合成身份资料、投资内容、克隆语音和生成视频。其 AI 欺诈警告 还建议人们独立联系相关机构，而不是信任来电者自称的身份。该警告早于当前的印度攻击活动。

逼真的声音或精心制作的信息可以支撑一次对话，但不应授权任何金融操作。

分析上的区别在于表面真实性与经核验的授权之间。来电者的声音可能很熟悉，却未必有权重定向资产。一条消息可能包含准确的个人信息，却不一定来自它所声称的机构。

以一名交易所客户为例：来电者声称发生紧急安全事件，需要将资产转移至替代地址。客户最应关注的是独立核验过的指示，而不是声音是否足够令人信服。

这个例子是假设情景，并非归因于 CRAFTY FALCON 的事件。它说明了为何机构警告可能会被用于无关的冒充企图。一份真实的安全公告，并不能验证每一条援引它的信息。

更安全的边界，是通过与传入请求分离的联系方式进行确认。打开熟悉的应用，或使用先前核验过的支持信息，能够改变谁在掌控对话。跟随来电者提供的链接，则会保留攻击者定义下一步的能力。

即使没有 AI 参与，这种方法同样有用。用户无需在拒绝批准前判定是哪一种模型生成了消息。核验流程应当同时适用于普通冒充和合成媒体。

对于管理企业资金的雇主和知识工作者而言，这一区别尤为重要。熟悉的高管面孔不能取代审批流程。即使一场对话看似私人化，财务授权仍必须依附于既定角色和程序。

这对共同作出投资决策的家庭也同样重要。紧急请求会制造情绪压力，而单靠技术说明未必能够化解。预先约定独立确认流程，能让应对方式较少依赖压力对话中的临场判断。

现有引用材料并无证据表明每一条可疑加密货币信息都使用了 AI。AI 标签也不能衡量某一具体请求的可信度。将所有欺诈都视为一种新的技术现象，可能会分散人们对其底层授权决策的注意力。

对平台而言，这带来了沟通上的挑战。其合法的安全指引应能通过既有渠道轻松核验。客户不应需要信任一条未经请求的信息，才能判断这条信息本身是否真实。

钱包控制权改变风险，但批准仍然重要

第四项检查涉及恢复信息以及钱包授予的权限。当客户考虑减少对交易所的依赖时，这一点尤为重要。自托管改变了谁能够授权交易，但并不会让每项操作都变得安全。

恢复短语是一组用于恢复钱包签名凭证访问权限的词语。任何处理此类信息的人，都需要在存储或分享之前了解其作用。要求披露恢复短语的请求，应与普通账户问题得到不同的应对。

Ethereum 的钱包安全指南建议用户保护恢复短语、核验交易详情，并避免授予不必要的支出权限。该指南还说明了硬件钱包的价值：这类设备旨在让签名密钥与联网计算机保持隔离。

只有当用户同时保有对钱包凭证和授权的控制权时，钱包控制权才有价值。

智能合约是在区块链上执行的软件。某些交互会请求获得支出特定代币的权限，而不是立即转出全部余额。这一区别有助于解释：即使屏幕显示的内容不像传统付款，审查一项授权为何仍然重要。

连接钱包与授权支出并不是可以互换的操作。用户需要一个能够说明其被要求授予何种权限的界面。混淆这些步骤，会让人更难评估一次看似常规的交互将带来什么后果。

其核心关切在于可理解的授权。用户应能在批准一项操作前识别其中涉及的资产、接收方和权限。如果请求仍然不明确，熟悉的标志也无法消除这种不确定性。

硬件钱包可以增强密钥保护，但不应成为批准陌生请求的理由。设备的保护作用在一定程度上取决于用户如何操作它。将凭证隔离，并不意味着授权的含义无关紧要。

这也解释了为何在恐慌中转移资产需要谨慎。仓促迁移可能同时涉及陌生软件、新的恢复信息和未经核验的目的地址。这一转移本身也应被视为一项对安全敏感的流程来评估。

比较自托管产品与交易所时，需要承认两者的失效边界不同。交易所可以集中提供支持并承担运营责任。自托管钱包则赋予用户更直接的控制权，同时也要求用户对恢复和签名承担更直接的责任。

两种安排都不应被赋予无条件的安全标签。更有价值的比较在于，特定用户能够理解和管理哪些风险。技术经验丰富的人与偶尔购买者可能作出不同决定，而这并不意味着任一方忽视了安全。

对于 AI 产品用户而言，恢复短语应始终置于一般写作和知识工作流之外。工具在组织研究方面的实用性，并不能构成上传签名凭证的理由。将日常文档与金融秘密分开，是一条实用的边界。

更广泛的教训是减少不必要的权限。用户应质疑自己不理解的授权，正如机构应质疑过度的内部访问权限。二者运作于不同尺度，但都取决于对已批准操作实际能够实现什么的控制。

事件准备是第五项检查，而恢复仍充满不确定性

第五项检查是用户是否知道该如何在事件发生前作出应对。准备工作之所以重要，是因为疑似遭到入侵会让设备、账户、交易和支持渠道都变得令人困惑。临时应付每一个决定，会使独立核验变得更加困难。

印度的金融诈骗举报框架包括 1930 热线和国家网络犯罪举报门户。印度内政部将其列为举报金融网络诈骗的渠道。举报应与联系相关金融服务提供商同步进行。

有记录的应对路径能够改善协调，但任何举报渠道都无法保证加密资产可以被追回。

交易所账户事件与自托管事件所需的信息不同。前者涉及服务提供商的账户系统和内部响应；后者则可能涉及钱包地址、交易记录、权限以及用户签名环境的状态。

用户应保留自己能够获取的证据，其中可能包括消息、交易标识符、地址、账户通知和事件发生顺序。清晰的记录有助于区分实际发生的情况与最初恐慌时形成的猜测。

处理证据时应避免进一步扩散秘密信息。支持沟通可能需要交易详情，却不需要恢复短语。用户应将用于识别事件的信息，与能够授予剩余资产控制权的信息区分开来。

应对路径同样需要独立核验。一名承诺立即追回资产的新联系人，不应仅因情况紧急就自动获得信任。损失发生前适用的标准，在损失发生后依然适用。

对于服务提供商而言，事件沟通应区分已确认的发现与仍在进行的调查。服务恢复的声明本身，并不能回答有关最初入侵的所有问题。客户需要清楚了解受影响的功能，以及自己需要采取的任何行动。

这一差异是理解 CERT-In 加密货币警告的核心。该通知描述了持续存在的机构性风险敞口，而客户通常只能通过简短的运营更新获得信息。可用性与安全性有关，但并不是同一种主张。

公共证据也存在重要局限。该公告并未证明每一家印度加密货币交易所都已遭到入侵，也没有提供逐个平台的安全排名或客户损失的完整公开统计。

对于 AI 的归因也需要同样谨慎。CERT-In 报告了 AI 辅助活动，但公开通知并未独立证明每种工具对每起事件的具体贡献。读者应保留这一归因的限定，而不要将其变成 AI 单独导致每次入侵的说法。

这种不确定性并不会让警告失去意义。它改变了值得提出的问题。用户需要有关自身服务提供商的实用信息，而调查人员则需要支持具体技术结论的证据。

因此，事件准备是一项协调能力检查，而非获救承诺。客户应了解合法的举报渠道并保留可用记录。平台仍有责任说明其运营系统内发生了什么。

下一项检验是服务提供商是否让保护措施可被观察

CERT-In 加密货币警告提供了一个立即审查风险敞口的理由。未来数月，更有力的检验将是公开信息是否变得更有用。反复提醒客户并不能解答有关机构保障措施的问题。

最有意义的后续证据，是服务提供商已降低客户无法自行管理的风险。

第一个值得关注的信号是具体的补救披露。服务提供商可以说明其审查了哪些类别的系统或流程，同时不暴露敏感的实施细节。有价值的信息应包括已完成的变更、其覆盖范围，以及组织如何评估这些变更是否持续有效。

在范围明确的前提下，独立评估能够强化这些信息。如果没有说明审查了什么，“已完成安全审查”这一表述几乎没有意义。客户应区分对某个特定组件的评估，与针对托管运营的更广泛结论。

更详细的披露将增强人们对该警告已促成具体机构应对的信心。模糊的保证会让原有的不确定性大体保持不变。无论是沉默还是精心修饰的措辞，本身都无法证明某一特定服务提供商是否已被入侵。

第二个信号是，客户保护措施是否在日常使用中变得更加清晰。认证选项、恢复流程以及对提现控制措施的说明，都可以被直接评估。服务提供商的文档应帮助用户理解可用的保障措施，而不要求他们自行解读宣传语言。

最有力的改进，应将便利性与可理解的限制联系起来。客户需要了解账户保护功能覆盖什么，以及哪些内容仍由机构系统负责。即使服务提供商选择不同的设计，这种清晰度也能支持更好的决策。

若只关注客户密码，将削弱人们对响应广度的信心。它处理了一个重要问题，却让托管相关的问题仍未得到回答。公开警告关注的不只是单个账户持有人的行为。

第三个信号是关于重复事件和攻击归因的后续证据。更多官方发现可能澄清受影响的功能、补救失败之处，以及 AI 辅助所起的作用。这些发现应依据其具体性来判断，而非威胁标签的新颖程度。

如果再次发生事件，就需要审查潜在风险敞口是否仍未解决。没有新的公开报告则不那么具有决定性。举报实践、调查时间表和披露决定都可能限制外界所能了解的信息。

这也是国际比较开始变得有用的地方。FBI 对 Bybit 盗窃案的归因提供了大型交易所级别事件的既有案例。它为理解机构风险提供了背景，但并不能证明与这次印度活动有关的任何结论。

这种比较应保持有限范围。不同事件可能涉及不同的访问路径、控制措施和证据。将它们归类到同一个 AI 安全标签之下，会掩盖客户和调查人员需要辨别的差异。

对于印度用户而言，持久的决策在于接受多大程度的依赖，以及哪些证据为这一选择提供依据。个人安全功能可见且可操作；机构实践则更难评估，因此精确的服务提供商沟通更具价值。

在紧急信息迫使你作出决定之前，审查你的托管安排、账户访问、核验习惯、钱包权限和举报路径。向服务提供商提出能够区分个人保护措施与机构责任的问题。将已核验的联系方式和常规事件记录保存在易于访问的地方，同时将恢复短语排除在这些文档之外。如果某项请求要求你转移资产、披露秘密信息或批准一项陌生操作，请通过既有渠道核验其来源。利用 CERT-In 加密货币警告识别具体缺口，而不是仓促迁移。你的保护中，哪些部分可以自行核验，哪些仍依赖于服务提供商的说明？