公开密钥 on 有点稳

公开密钥加密在SSH远程登录中的应用

Wed, 12 Oct 2016 00:00:00 +0000

一直以来，都在享受着SSH免密码登录的远端服务器的好处，但总觉得对背后的逻辑不是太清楚，或者说，根本没有细想过，因为网上充斥了大量的，如何做，却不告诉为什么，下一次再去做的时候，又费半天功夫，所以有必要熟悉完整的流程。近来有了“深入理解加密、解密、数字签名和数字证书”这篇文章做底子，SSH免密码登录背后的逻辑也容易理解很多。

SSH协议的设计初衷是为rsh、rlogin、rcp等命令提供更佳安全的实现方案，需要对一切传输的数据进行加密、检验一致性。公钥系统中对大块的数据加密往往使用运算速度较快的对称密钥，在SSH协议中称作会话密钥。让彼此双方获得会话密钥，并且保证会话密钥不被窃听的过程称作建立安全会话。SSH-1建立安全会话的流程如下：

客户端发起访问远端服务器的请求；
服务器发回主机密钥、服务器密钥、加密算法、校验序列等信息；
客户端接到传回信息后，进行服务器认证，如果传回的主机未知，需要人工判断是否信任这些信息，如果不信任，那么会话结束，否则，会话继续；
服务器认证通过后，客户端随机生成会话密钥，用主机密钥和服务器密钥依次对会话密钥加密后发给服务器；
服务器接到加密的会话密钥，用私有密钥依次解密得到会话密钥。

自此客户端和服务器都得到了会话密钥，接下来还需要进行客户端认证。客户端认证的方式有两种：口令认证和公钥认证。口令认证的方式流程如下：

服务器没有找到用户密钥，就询问用户输入口令；
用户输入口令后，经过会话密钥加密传回给服务器；
服务器验证用户身份。

口令认证的方式简洁方便，但对每天需要登录很多不同的服务器的人而言，一遍遍重复输入口令比较繁琐，这种情况下采用公钥认证的方式会轻松许多，也更佳安全。公钥认证的方式流程如下：

客户端将用户密钥传给服务器；
服务器在认证过的密钥库中查找，如果没有找到，那么请求失败，如果找到则生成一段随机序列，称作质询，用用户密钥加密后，发回给客户端；
客户端拿私有密钥解密得到质询，附带结合上会话的标识（主机密钥、服务器密钥和校验序列通过MD5散列后得到的序列）通过MD5散列后的序列作为响应传回给服务器；
服务器用同样的方式如果计算出相同的MD5序列，则验证通过。

客户端在使用私有密钥时，需要私有密钥的口令，这个口令可以为空，这样就相当于免密码，但这种方式让私有密钥的安全性降低，不推荐这种做法。最佳实践是借助SSH代理，可以记住不同私有密钥的口令，当客户端查找私有密钥时，只需要通过SSH代理去完成，这样就避免了重复私有密钥口令。

以上文章只说明了公钥认证背后的流程，并未涉及为何要这样设计流程，比如为什么需要同时有主机密钥和服务器密钥，为什么需要会话标识，这一系列的设计背后都有原因，能够搞明白这些原因，才能更好理解安全是什么。本文只是粗略的总结，对每次传输的细节有些省略，也没有涉及SSH-1和SSH-2的差别以及一些更加丰富的客户端验证方法，更加深入的内容可以参考相关阅读的第一篇。

数字签名在安卓包发布中的应用

Tue, 11 Oct 2016 00:00:00 +0000

安卓包发布前必须要有正式签名才能在应用商店发布，对照公开密钥基础设施图解的常规流程而言，安卓包签名仅是个子集，只有数字签名，不涉及加密。

数字签名中核心的要素是私有密钥、公钥证书、原始摘要和签名摘要。涉及的参与者有应用开发者、应用商店和用户（操作系统）。逐一了解了每个核心要素和参与者也就清楚了整个签名的动机和操作步骤。

数字签名是拿私有密钥对原始摘要（不管是文件还是对称密钥本质上都是字符串）进行加密，利用大素数的一些特性对原字符串进行变换，得到签名摘要。这个签名摘要，只有用对应的公开密钥才能恢复为原始摘要。

公开密钥是公钥证书的主要内容，但不是全部。公钥证书中还写明了应用开发者的基本信息包括开发者组织名称、组织所在地、证书失效时间等信息。公钥证书又叫数字证书和身份证书。身份证书的称谓也反映了这个证书是用来识别应用来源身份的。公钥证书需要被权威机构认证，对于安卓而言，这个组织就是Google Play和国内各大应用商店。各大应用商店需要验证应用开发者每次的公钥证书是否一致，不一致的证书就可能遭到拒绝。除此以外，还需要对签名摘要拿公开密钥解密获得原始摘要，并且同原始摘要进行比对，但凡发现不一致的地方，就可能是文件遭到了篡改，同样会拒绝应用发布。实际上操作系统同样会验证公钥证书的一致性和签名摘要的完整性，仅会提醒，但不拒绝安装有风险的安卓包。是否安装有风险的包就取决于用户自己了。

前面的描述中提到对比解密后的签名摘要和原始摘要可以发现文件是否遭篡改。很容易产生的疑问是为什么比对摘要就可以发现这点？要回答这个问题，就需要了解摘要是什么。安卓包中的原始摘要是一个字符串的集合，每个字符串对应包中的一个文件，每个字符串都是通过哈希散列算法对文件计算出的一个短序列。这个字符串的集合要求包中的文件一个都不能少，也一个都不能多。这个集合中不包含原始摘要文件自己、签名摘要和公钥证书。签名摘要也是类似于原始摘要的一个字符串集合，只是每个短序列是都用公开密钥签名后的结果，此外还增加了原始摘要文件的短序列和签名序列。

私有密钥由开发者秘密保存，公钥证书、原始摘要和签名摘要随签名包一起发布。实际上签名包和未签名包的差别就是公钥证书、原始摘要和签名摘要。在签名包中，一般放在META-INF中，后缀一般是CER、MF和SF。

安卓包签名示意图：

公开密钥基础设施图解

Fri, 30 Sep 2016 00:00:00 +0000

很久以来，一直搞不清楚各种加密算法、哈希函数的应用场景，直到读了“深入理解加密、解密、数字签名和数字证书”这篇博文后，一切概念立刻变得明朗起来，于是赶快画了一张图捋清了思路，方便自己和看到这篇文章的朋友回顾。因为原文作者写得足够精彩，逻辑性很强，所以在此只简略叙述图中所画内容。

A要通过网络将文件（Original File）发送给B，为了能让B安全收到，避免传输过程中被截获、窃听或伪造，目前相对安全的做法是图中描述的流程。

A需要执行的操作：

(1) 用对称密钥（Symmetric Key）通过对称加密算法把文件加密成为密文文件（Encrypted File, or Cypher Text）；
(2) 用B的公开密钥（Public Key）通过非对称加密算法把对称密钥加密成为加密的对称密钥（Encrypted Symmetric Key）；
(3) 通过哈希算法生成文件的短摘要（Short Digest）；
(4) 用自己的私有密钥（Private Key）通过非对称加密算法对短摘要签名，生成签名摘要；
(5) 将自己的公开密钥和个人信息交付CA机构认证获取数字证书（Certificate）。

最后将密文文件、加密的对称密钥、签名摘要和数字证书通过网络传给B。

B收到A发来的文件需要执行的操作：

(1) 用自己的私有密钥对A发来的加密的对称密钥解密，获得解密的对称密钥（Decrypted Symmetric Key）；
(2) 用解密的对称密钥解密密文文件，获得解密文件（Decrypted File）；
(3) 用相同的哈希算法，生成解密文件的短摘要作为待测摘要（Tested Short Digest）；
(4) 用A发来的数字证书获取A的公开密钥；
(5) 用A的公开密钥对签名摘要解密得到解密的摘要（Decrypted Short Digest）；
(6) 对比待测摘要和解密摘要，如果完全一致，说明解密文件就是原始文件，如果不一致，说明解密文件是伪造文件。

公开密钥 on 有点稳

公开密钥加密在SSH远程登录中的应用

相关阅读

数字签名在安卓包发布中的应用

安卓包签名示意图：

相关阅读：

公开密钥基础设施图解