主要观点：约一周前，[3dbrew wiki 关于 3DS 卡带（carts）的页面]有了新增内容，阐述了 3DS 卡带控制器与 3DS 卡带相互通信的技术细节，包括 3DS 自身在其中的作用及设计决策起源，最后提出改进想法。
关键信息：

• 3DS AES 引擎可通过两种方式加载 128 位 AES 密钥，关键是密钥由硬件动态推导。
• 工厂生成三部分信息：ID1（含卡带类型等）、ID2（决定后续协议使用的密钥）、唯一 ID（16 字节，据说可在线验证）、标题密钥（对所有卡带实例固定）。
• 协议过程：包括启动、初始化、发送 ID、升级、数据传输等步骤，最终双方通过共享 RC4 状态通信，3DS 控制台无法获取这些密钥。
• 加密动机是防止资产和代码被获取，加密使用 SNOW 2.0 和 RC4 流密码，方案善于分割秘密，避免单个组件被破解。
• 存在四个突出问题：前导部分（初始密钥协商等）明文且未认证；消息认证仅用加密 CRC-32 作用有限；密码选择倾向软件-oriented 且 NIST 批准的密码；密钥更新由 3DS 控制台决定易受攻击。
  重要细节：
• 密钥推导公式AES key = (((keyX ROL 2) XOR keyY) + C1) ROR 41，常数C1已被发现。
• 协议中各方在不同阶段的具体操作，如控制台和卡带控制器的密钥生成步骤等。
• 对各个加密相关部分的特点和局限性的分析，如 SNOW 2.0 和 RC4 的特点，以及 AES 密钥推导函数的问题等。
• 提出的改进措施，如使用 Noise 协议框架解决前导和密钥更新问题，用 AES-OCB 替代 CRC 进行消息认证，改进 AES 密钥推导函数等。
• 有相关演示可查看https://git.winter-software.com/forbiddentempura/cartcrypto。