CryptoKitties如何安全地签名和发送以太坊交易
尽管工程师在开发区块链应用程序时了解了安全性的重要性，但通常会忽略导致细微不同的安全性影响的细微细节。请继续阅读以了解CryptoKitties如何在签名和发送以太坊交易期间防御各种攻击媒介。
CryptoKitties最特别的猫一直是Gen 0。在游戏开始的第一年，每十五分钟就有一个被我们称为Kitty Clock的帐户铸造。时至今日，第0代代币仍然是市场上最受欢迎的一些代币-许多通常以ETH或更高的价格出售。
用技术术语来说，这个Kitty Clock是一个具有特殊权限的帐户，该帐户已编码到CryptoKitties智能合约中，我们称之为合约COO。一项特殊特权是能够通过调用createGen0Auction智能合约功能来创建具有某些基因的全新Gen 0 CryptoKitties以及对该资产进行拍卖。由于此功能仅向COO公开（请参见onlyCOO修饰符），因此有必要使用其私钥对调用此功能的事务进行签名。这意味着CryptoKitties需要满足两个主要要求：
- 使用COO（小猫时钟）的私钥签署交易的能力，以及
- 将签名的交易发送到以太坊网络的能力。
在本文中，我们将在实践中设计CryptoKitties时要考虑的因素。
不要把所有的鸡蛋都放在一个篮子里
私钥应始终进行安全管理。由于拥有私钥意味着绝对的签名能力，因此攻击向量可能会根据关联的钱包类型对用户产生严重影响。对于诸如Metamask帐户的分层确定（HD）钱包，泄露的私钥将允许恶意行为者简单地消耗掉关联钱包所拥有的所有资产。对于像Dapper这样的智能合约钱包，泄露的私钥将同样允许恶意行为者签署交易以transfertransfer资产，但是由于智能合约规定的多重签名方案要求Dapper共同签署所有交易，因此可以利用欺诈预防机制来标记可疑的用户行为。尽管CryptoKitties COO不拥有任何铸造的Gen 0（它们立即被拍卖，拍卖合约拥有它），但受损的COO私钥仍将允许恶意参与者通过调用来严重破坏游戏createGen0Auction。
在本地开发过程中，通常会从.env文件中加载私钥，以简化调试和测试过程。但是，根据应用程序的运行方式，这可能是将应用程序逻辑作为环境变量作为私钥暴露给私钥的一种不太安全的方法。如果使用Docker容器，则攻击者仅需要访问容器本身即可破坏秘密。我们都知道这种攻击媒介被滥用了多少次（只要给它一个Google）。结果，任何形式的Docker化，私钥即环境方法在生产中都不可行。
一种替代方法是不将私钥公开为环境变量，而是将其嵌入源代码中。尽管这种方法似乎更安全，但根据编程语言的不同，现有的工具能够将机器代码/字节码反编译回源代码。尽管很困难，但这种程度的反向工程并不是不可能的，最终将使攻击者能够恢复内存中的私钥。此外，由于无法将秘密直接提交给版本控制系统，因此这种方法会阻碍CryptoKitties工程师之间的协作。
到目前为止，我们描述的方法涉及在与应用程序逻辑相同的位置管理秘密，这凸显了被泄露秘密的安全漏洞。确实，另一个攻击向量针对了应用程序本身-如果应用程序盲目地信任运行时环境中提供的私钥，那么受感染的应用程序也实际上意味着受感染的机密。因此，更安全的体系结构应将敏感实体分开，并尝试尽可能地隔离私钥以明文形式存在的环境。简而言之，不要把所有的鸡蛋都放在一个篮子里。
这是促使CryptoKitties使用自托管的Geth节点的基本原理。
自托管的Geth节点
Geth节点的便捷功能是用户通过其界面维护节点上未锁定帐户的接口。输入正确的密码短语以解密帐户的私钥后，完整节点便能够使用此私钥对交易进行签名，并将更新的链状态传播到网络中-特别是，完整节点将已签名的交易置于其自己的矿池中并传达该状态更改为其他节点矿池。对于CryptoKitties而言，这是一个在Geth节点上维护未锁定的COO帐户的绝好机会-秘密不会通过某些环境变量公开，并且安全模型现在的私钥与应用程序逻辑完全独立。为了增强安全性，Geth节点在隔离的环境中运行，并且对节点的访问进行了控制以防止未知请求到达该节点。虽然这个模型是仍然容易受到受到威胁的应用程序向Geth节点发出恶意请求的攻击，由于存在以下细微差别，它比以前更加安全：
- 当应用程序内存在私钥时，受感染的应用程序将导致受害密钥。
- 如上所述，当私钥与隔离环境中的应用程序分开存在时，受感染的应用程序将允许恶意行为者签署交易，但私钥仍然可以防止渗透。
换句话说，前者是一个单一的利用，而后者则要求恶意行为者坚持可检测的危害。
此外，由于CryptoKitties现在能够通过同一自托管的Geth节点进行签名并将事务发送到区块链，以及查询最新的全球网络状态，因此该方法在工程复杂性和安全性之间进行了明智的权衡。
不幸的是（或者幸运的是），由于许多性能和存储原因，它的寿命很短：
- 维护完整的Geth节点很快消耗的内存超过分配给运行该实例的VM的500GB。为了解决此问题，每当其中一台虚拟机用完磁盘空间时，CryptoKitties便尝试维护另外两个完整节点以进行故障转移。解决了这个特定问题后，涉及的手动开销却远非理想—故障切换经常发生，从Geth清除链数据，然后从头开始干净同步的过程将使该节点在1天后无法使用。这是必要的，因为Geth节点当时缺少自动数据库压缩。
- 通过Geth节点读取区块链是不可靠的，因为它们通常很慢并且与最新的全球网络状态不同步。
- 由于CryptoKitties应用程序（启动后数月）缺乏一种可靠的机制来解决由于天然气相关问题（例如，网络高峰期间的天然气不足）而被“阻塞”的交易，因此写入区块链也不可靠。阻止了所有后续交易通过解锁的COO帐户发送。
由于解锁帐户仅在由CryptoKitties维护的Geth节点上才有意义，因此该模型也无法完全移植到Alchemy等区块链基础架构提供商。为了利用Alchemy的API可靠地将签名的以太坊交易发送到区块链，必须将签名交易与发送交易分离开来。
在这里签名，发送到那里
如今，COO不再铸造Gen 0s CryptoKitties，而是通过giveBirth迅速召集怀孕的小猫来生子，从而在游戏中保持着不可或缺的作用。这是通过利用带有Cloud HSM（硬件安全模块）的Google Cloud KMS（密钥管理服务）来签署交易来实现的，这可以防止任何私钥暴露给任何客户端-数据总是传递到模块中以进行私有签署键。确实，CryptoKitties然后将这些已签名的事务发送给Alchemy，而对签名和发送机制的解耦提供了一种更加灵活，可扩展且不太复杂的体系结构，而无需管理自托管基础结构。