一、战争来临了比特币私钥如何保存

“有用户将明文私钥存放在网盘上。有人在网盘共享比特币的区块数据,贴吧某用户下载后直接覆盖使用。”

安全地保管比特币不是一个单纯的技术问题,它其实是一个策略问题。记得曾经有个密码学家说过,历史上所有试图让用户自己保管私钥的尝试都失败了。足见改变用户习惯绝非易事。

因此在币圈流传着一段话:“如果你不能拥有你的私钥,你就不能拥有比特币”,由此可见,妥善保存私钥的重要性!那到底应该如何保存私钥呢?Abtc爱比特和大家介绍三种方法,保护好自己的数字。

二、四、公钥和私钥,加密和数字签名

本文涉及到支付宝SDK的内容，均摘自支付宝开放平台。

因为支付宝SDK使用RSA来加密和生成数字签名，所以本文中涉及到的概念也都是针对于RSA的。

一对儿密钥生成后，会有公钥和私钥之分，我们需要把私钥保存下来，而把公钥发布出去。一对儿公钥和私钥，不能由其中一个导出另一个。

比如使用支付宝SDK的时候，我们商户端会生成一对儿密钥A和B，A是私钥，B是公钥，支付宝也会生成一对儿密钥C和D，C是私钥，D是公钥。我们商户端需要把商户端私钥A保存下来，而把商户端公钥B发布出去给支付宝，支付宝需要把支付宝私钥C保存下来，而把支付宝公钥D发布出去给我们商户端。

加密是指我们使用一对儿密钥中的一个来对数据加密，而使用另一个来对数据解密的技术，需要注意的是公钥和私钥都可以用来加密，也都可以用来解密，并不是规定死了只能用公钥加密私钥解密，但是加解密必须是一对儿密钥之间的互相加解密，否则不能成功。

加密的目的是为了保证数据的不可读性，防止数据在传输过程中被截获。

知道了加密这个概念，我们先看一下支付宝的加密过程，再引出数字签名这个概念。接着第1小节的例子，当我们商户端和支付宝互相发布了公钥之后，我们商户端手里就有商户端私钥和支付宝公钥两个密钥，支付宝手里也有商户端公钥和支付宝私钥两个密钥。现在假设我们商户端要给支付宝传输订单信息，那么为了保证传输订单信息时数据的安全性，结合我们商户端手里所拥有的密钥，可以有两套加密方案

貌似这两套加密方案都能达到对订单信息加密的效果，而且如果采用方案二，我们商户端甚至只需要存储支付宝公钥这一个密钥，都不用去申请一对儿商户端的公私钥来维护，支付宝也不用保存我们一堆商户那么多的商户端公钥了，这不是更简单吗，那为什么支付宝开放平台让我们采用的是方案一而不是方案二呢？下面来回答一下。

支付宝开放平台说明：当我们采用RSA（1024位密钥）来加密的时候，支付宝分配给所有商户的支付宝公钥都是一样的，即支付宝针对那么多的商户只负责维护一对儿支付宝公私钥，这就意味着支付宝公钥随便什么人拿到后都是一样的；而当我们采用RSA2（2048位密钥）来加密的时候，支付宝会分配给每个商户单独的一个支付宝公钥，即支付宝为每一个的商户单独的维护一对独立的支付宝公私钥，当然一个商户下的多个App的支付宝公钥是一样的。RSA是早就支持的，RSA2是最近才支持的。

知道了上面这段话，现在假设我们采用的是方案二，并且采用RSA加密（很多老业务并没有使用RSA2加密），业务逻辑将会是下面这样。

这就出问题了， RSA加密下，支付宝公钥是公开发布的，而且所有的商户用的都是同一个支付宝公钥（上面声明了RSA2加密下，支付宝才针对每个商户维护了一对儿公私钥），攻击者很容易就能获取到，而 notify_url也很容易被截获，那攻击者拿到这两个东西就可以做和商户一样的操作来发起支付请求，这样就会一直给小明充钱了。

所以支付宝就需要确认支付请求确实是商户发给他们的，而不是攻击者发给他们的。这就用到了数字签名，我们会通过方案一的实现流程来引出数字签名的具体概念。如果我们采用的是方案一，我们商户端保存的就是商户端私钥和支付宝公钥，而支付宝保存的就是需要存着商户端公钥和支付宝私钥的，业务逻辑将会是下面这样。

这样就可以保证交易的安全性了，我们也可以看出使用支付宝SDK保证交易的安全性注重的其实不是订单信息是否加密，而是如何确保商户端和支付宝能够互相确认身份，订单信息是明文的，但是后面拼接了数字签名。

数字签名其实就是明文数据加密之后得到的一个密文，只不过它是用私钥加密生成的而已，我们一般会把数字签名拼接在明文数据后面一起传递给接收方，接收方收到后用公钥解密数字签名，从而验证发送方的身份、以及明文数据是否被篡改。数字签名的生成过程其实就是一个加密过程，数字签名的验签过程就是一个解密过程。

数字签名的目的有两个：一、发送方和接收方互相验证身份；二、验证数据是否被篡改。

从上面第一部分我们知道为了确保商户和支付宝交易的安全性，约定采用的是给订单信息加数字签名传输的方式。支付宝也为我们提供了一键生成RSA密钥的工具，可以帮助我们很快的生成一对商户端公私钥。以下会对支付宝SDK的支付流程做个大概的解释，并点出实际开发中我们使用支付宝SDK时应该注意的地方。

由我们商户端自己生成的RSA私钥（必须与商户端公钥是一对），生成后要保存在服务端，绝对不能保存在客户端，也绝对不能从服务端传输给客户端。

用来对订单信息加签，加签过程一定要在服务端完成，绝对不能在客户端做加，客户端只负责用加签后的订单信息调起支付宝来支付。

由我们商户端自己生成的RSA公钥（必须与商户端私钥是一对），生成后需要填写在支付宝开放平台。

用来给支付宝服务端验签经过我们加签后的订单信息，以确保订单信息确实是我们商户端发给支付宝的，并且确保订单信息在传输过程中未被篡改。

这个和我们就没关系了，支付宝私钥是他们自己生成的，也是他们自己保存的。

用来对支付结果进行加签。

支付宝公钥和支付宝私钥是一对，也是支付宝生成的，当我们把商户端公钥填写在支付宝开放平台后，平台就会给我们生成一个支付宝公钥，我们可以复制下来保存在服务端，同样不要保存在客户端，并且不要传输给客户端。

用来让服务端对支付宝服务端返给我们的同步或异步支付结果进行验签，以确保支付结果确实是由支付宝服务端返给我们服务端的，而且没有被篡改，对支付结果的验签工作也一定要在服务端完成。

上面已经说过了：订单信息的加签和支付结果的验签是一定要在服务端做的，绝对不能在客户端做。

下面是在客户端对订单信息加签的过程，仅仅是为了模拟服务端来表明订单信息是如何通过加签最终转变为orderString的，千万不要觉得订单信息的加签过程也可以放在客户端完成。

假设我们服务端收到了来自支付宝服务端的支付结果，即：支付结果+数字签名。

那么我们服务端就会对支付结果进行验签，怎么个验法呢？

三、web服务器的私钥保存在什么地方

利用公钥和私钥方式加密的方法叫做非对称加密。公钥和私钥不仅是成对的，而且是一对多的。公钥是用来发放的，私钥是本机保留的。用法是：私钥和公钥都可以用来加密文件，公钥加密的文件只能由私钥解密，私钥加密的文件只能由公钥解密。灵活运用非对称加密可以实现各种效果。

例如，A和B想建立加密连接，通过对称加密的方式实现，密钥由A出具。但加密连接之前A和B是没有加密连接的，因此明文发送对称密钥是很危险的，一旦被截获，则加密连接的数据将被轻易截获。因此，B有一套公私钥，B将公钥发放给A，这时可能公钥会被盗取，但只要A收到公钥就可以。A用公钥加密对称加密的密钥，发送给B。此时即使数据被截获也没关系，因为黑客只得到了B的公钥，他无法用公钥解密公钥，因此截获数据无任何意义。B收到A发来的密钥，用私钥解密，此时A和B均具有了对称加密的密钥，且没有被截获，他们可以进行安全通讯。当然这只是非对称加密的用法之一。

非对称加密有良好的保密性。需要发送保密数据的一方（A）持有公钥，而获取保密数据的一方（B）持有公钥，这样保证了数据即使丢失也不会被破解。非对称加密结合数字签名技术，可以保证数据的完整性。

你可以到IE的工具-INTERNET选项-内容-证书这里查看你已经安装的证书。

附加：

你好，我看了你的问题补充，也查了一些资料。

根据我的了解，windows证书存放有3个方式：

1.单独文件形式。你可以查看

C:\Documents and Settings\Administrator\Application Data\Microsoft\SystemCertificates

当然，Administrator是当前用户，你需要根据情况更换。证书的存放在组策略里有相关设定。

2.注册表。注册表其实也是以文件形式存放的，不过并非一个文件，而是多个文件，且很多信息混杂在一起。而且，证书以字符方式存放。

3.组策略。组策略里存放的证书存放形式我还不知道，但它的确可以存放证书。

当然还有第三方证书容器证书存放方式，例如USB Key，但也是文件形式存在的，只不过在导入USB Key时被加密了，无法通过拷贝方式拷贝出来。

关于如何存放证书，微软应该是没有公布太多技术细节，我也知道得有限，只是趁这个机会一起研究探讨下。水平实在有限，还希望有高人指点！

四、区块链钱包的私钥如何备份有哪几种方法

    当你在创建一个区块链钱包的时候，创建成功之后，系统会自动生成钱包地址、公钥、私钥，然而这些需要你自己去备份，钱包不会帮你保存，那么大家应该如何备份这些信息呢？又有几种方法？

    第一，具备双倍安全性的钱包，并把私钥导入到Armory客户端（1）进行冷储存（2），用户可以在客户端中快速从冷储存中找到所需私钥，还有一个优点就是方便离线交易转账，不必每次都重新导入私钥。同时电脑的操作系统需要设置密码。

    第二，可以把钱包的私钥和公钥制作成电子版备份，同步到云端。你可以把它们复制粘贴为一个文档，标记好名字，文档可以以拼音的形式命名，可以乱码，但是要额外的保存在另一个文档里注明该文件是干什么用的。但是这样做的结果就是可能会忘记储存的文件是哪个，因此你需要在手机备注好信息，同时需要把复习私钥这件事安排为按时间重复的（如2个月复习一次）日程事件，时间到了手机或电脑提醒复习。而且不仅仅是回忆几遍就可以了，是要到备份上打开那个生成私钥的钱包中，重新登录一遍，看看私钥（和地址）是否正确。

    第三，用户可以在文档上写下钱包的私钥和公钥以及地址，命名的话，你自己看得懂就好，接着就把后缀名为jpg图片格式，使其看起来就像一个坏掉的打不开的图片，或者更甚，我们可以把这打不开的假图片压缩为zip格式并伪装为一个真正的图片，需要的时候再还原出来。具体更改方法可以上百度查找。

   第四，以上三种方法都是电子版的备份方法，还有一种简单粗暴的方法就是在日记本手抄私钥公钥，使其看起来不那么刻意、唐突，不过大家需要注意的是，抄写的时候记得要写得字体清晰、工整，避免字迹潦草而导致输入私钥错误。同时，保存的地方也是需要注意的，可以藏在家里隐私的地方（有条件可以存银行保险柜）。

备份区块链钱包私钥的方法有以上4种方法，当然如果你有更好的备份方法，也可以分享出来，不必按部就班地使用上述备份方法的哦。最后，给一个备份建议：可以结合上述2到4种方法来备份私钥，避免遗忘。

注释：

（1）Armory客户端：Armory是一个功能齐全的比特币客户端，提供了许多其他客户端软件所没有的创新功能！管理多个钱包（确定性和仅观看）、打印永久工作的纸张备份、导入或删除私钥等。

（2）冷储存：即比特币钱包的冷储存（Cold storage）。是指将钱包进行离线保存的一种方法。