Top Tweets for #Keyvault

我们为什么兼容第三方硬件钱包 ？ 这话，得从挺早之前说起。 当 Huobi 巅峰时期管理资产大几百亿美元（用户+自有），每周至少要给老板汇报一次资产数据和钱包安全。 那时候我们制定了有可能是有史以来最严格的核心资产管理要求：所有私钥必须确保离线，所有链路必须确保无法篡改，所有交易必须所见即所签，所有数据必须自然语言解析，所有业务流程必须确保有二次自校验能力，所有上链数据必须即刻完成对账，所有执行操作必须有双“人”四眼机制 …… 那时候也调研了一些软硬件供应商，可能是时间比较早，当时市面上钱包成熟产品并不算多，能满足这些要求的根本就没有，所以采用了自研。当时的自研方案还是比较笨重的，但相比这个资产量级来说，这样的方案也就不显笨重了。 后来钱包市场逐步成熟，软件硬件的可选择性也多了起来，我们也想把这套方案从“笨重”变的“轻便”一些，所以也在市场上做了一些选型，但一直没有找到一个产品能把当时我们的安全需求以一体化的方式集成在一起。这其实都是因为安全架构和业务架构之间的冲突所导致的，说白了，没有产品能满足我们“既要、又要”的需求，这也很正常。 后来老板告诉我 Huobi 准备卖掉，我在筹备和执行交接期间连轴几天没睡，那时候晚上没事就想：公司卖了、我失业了、以后干什么，所以又想起了钱包这个事，我想试试，能不能搞出来一个产品满足我们的“既要、又要”。 当然，任何想两头吃的人都不会有好结果，所以刚开局没多久我就差点踩进坑去。 多签并不难，但多签后面加个“冷”字就不好搞了，为此我们调研了硬件，后来甚至都走到了接近首批样品的地步。但就那时候我意识到，手中那么几杆枪根本就腾挪不开，要么全投到软件里，继续做我们熟悉的事情，要么去到硬件里，探索我们没涉足过的领域。我不知道是否明智，反正我是退回来了。 退回来了，难题就来了，因为自己没有硬件，就有很多问题。 首先怎么让多签变“冷”，这个倒是很快找到了答案，市面上开放性比较好的 #ledger #onekey #trezor，都能支持原生多签。 但是，问题也没有那么简单，兼容一两条链好搞，我们起手就是12条链，不好搞，未来我们还想整到20条链，更难。 除此之外，还有很多业务体验和安全保障之间的平衡问题。 所见即所签、防篡改、交易自校验、签名环境安全 …… 等等，很多很多，只靠 NexVault 作为平台去整合第三方钱包还是不现实，所以后来又自研了 KeyVault —— 这个从一开始我们就没把它定义为钱包的东西，我们一直管它叫“签名工具”，它只需要做好 钱包生成、保存、解析、签名 就可以了。 加入了 KeyVault 之后，我们的钱包业务状态和签名链路就变成了插图的样子： * 对于常见的3-of-5多签来说，选择两个软件（KeyVault）+ 三个硬件（选择不同品牌或同一品牌均可）组成； * 使用 KeyVault + 任一款硬件完成日常的签名，另两个硬件做容错备份； * 链上交互的安全问题交给 NexVault 解决； * 端上签名的问题交给 KeyVault 解决，比如，合约钱包 ledger 不能所见即所签，但两个 KeyVault 都可以，就解决了风险； 这种组合方式看似一个“缝合怪”，但至少目前为止达到了我们想要的一个平衡态： * 日常签名便利性上，KeyVault 使用二维码交互签名（AirGap），理解和使用成本都很低，外加一个 ledger 硬件操作，整体操作下来不算复杂； * 日常签名安全性上，ledger 作为硬件兜底，即便你不相信我们的 KeyVault，两个 KeyVault 也没有达到最小签名阈值（3个），也不会耽误安全性； * KeyVault 端的安全性上，钱包生成过程使用外部随机数发生器，本地存储使用SoC安全隔离区做安全保障，还支持离线模式的钱包生成、存储、签名； * 在整体安全性上，分散配置签名钱包，就实现了没有任何一个单一品牌能达到最小签名阈值 3 ，也就避免了因随机数或软硬件 bug 而导致钱包被人“隔空盗窃”的风险； 当然，这些只是签名方面，在链上交互和签名内容中，我们还做了很多“手脚”，比如，钓鱼地址，你不需要翻链上和交易记录，几种常见钓鱼地址我们都是基于业务逻辑和交易行为做识别和风险提示，而不是简单的黑白名单匹配方式，这种细节有很多，有机会我再慢慢说，也有机会你来多多体验。 所以最后说回来，不是我们要兼容第三方硬件钱包，是第三方硬件钱包帮我们解决了燃眉之急，让我们离“既要、又要”更近了一步。 #Crypto #CryptoSecurity #WalletSecurity