Android安全机制（一）

举几个例子：

保密：某人是一家上市企业的CEO，他有许多公司高端机密文件，肯定不希望别人知道，这就是保密需求。再比如互联网的信息都是public的，没办法跟现实一样去做物理隔离。

鉴别/认证：去银行取大额的钱，工作人员需要核对身份证。再比如两个特工接头，需要暗号。这些都是认证需求。

完整性：我借钱给朋友，要写一张借条，金额一般都用中文大写，为什么不直接用阿拉伯数字？因为容易修改，被修改后就失去了完整性，这就是完整性需求。

不可否认型：签合同需要按手印，对应it里的就是数字签名。

加密密钥和解密密钥一样的，也被称为shared key。

第一种，上图是典型的置换加密：明文不做任何改变，用新的信息去代替。

第二种，上图是典型的转置加密：没有新的信息去代替，但是改变了明文的顺序。143526就是密钥（key）。

第三种，乘积密码：其实就是置换加密和转置加密结合起来用。

DES，早期的一种加密算法，采用56位密钥，后来又出来了三重DES转置。

AES：有128位，256位等根据不同需求采用不同位的密钥。是当今应用最广泛的对称加密标准。

与对称加密相比，非对称加密的加密密钥和解密密钥不一样。加密密钥被称为公钥，可以public给所有人；解密密钥被称为私钥，是private的。

上图是一个应用场景，公钥和私钥都是老王产生的，把公钥public出去，当小张、小李、小林发送信息给老王的时候，用公钥加密，而老王收到后用私钥解密。

非对称加密（公钥加密）的基础：比如两个1024位质数相乘的值很容易获取，但是如果反过来，给出这个值，逆向分解出这两个质数，基本是不可能的。所以用乘积作为公钥，两个质数作为私钥。

RSA就是建立在这个基础上产生的，他的公钥/私钥长度至少1024位。

对称加密的优点：相比于公钥加密，速度更快。缺点：由于加密密钥和解密密钥是一样的，所以在交换信息的同时，密钥的交换就成问题了，如果在交换过程被人拦截呢？安全性也不如RSA高。但是256位的AES已经能胜任一般的加密。

公钥加密的优点：相比于对称加密，由于两个密钥不一样，所以没有密钥交换的问题。安全性也更高。 缺点：加密效率低。

上图中，会话传输基于AES 256位，而shared key基于其他足够安全的方式进行传输和交换。

双方的会话是通过AES 256位加密，而加密密钥和解密密钥（同一个，也就是shared key）是通过非对称加密的RSA来进行加密。

过程如下：老王把公钥给小李，小李用公钥把shared key加密，传给老王后，老王用私钥解密得到shared key，再用这个shared key来解密会话信息。

散列算法无论多长或多短的输入，输出长度都是固定的。

常见的散列算法有：MD5，输出长度固定是128位；SHA1 ，输出长度固定是160位。

易变性：原始信息只要有1bit的变化，输出的信息将会发生巨大的改变。

不可逆：通过散列散发的输出去逆推原始信息是不可能的。

下载的文件夹里会有一个MD5，用于跟已下载的文件经过散列算法后的输出做比较，如果一致说明文件未被篡改。

原始消息先用密钥加密，再进行散列算法，主要是为了防止：如果直接散列算法传输，黑客拦截后也向服务器发送相同的散列输出。如果先加密，那么服务器收到后会先解密，再对比散列输出。

Android电子签名

应用于电子签名的场景和之前的保密通信场景正好相反，老王用他的私钥去加密信息传给小林，小林用老王的公钥进行解密得到明文。但是并非所有非对称加密都支持，RSA正好可以支持。所以我们用RSA来进行电子签名。

我们会发现，老王用私钥加密后发给大家，所有人都可以用公钥解密，这样根本就没有起到保密的效果。对！这里的作用不是保密，而是签名。当大家用公钥能够解密消息时，说明发过来的消息肯定是经过私钥加密的，而私钥只有老王有，这样就能说明消息一定是老王发过来的。

然而，前面已经讲过，RSA的效率比较低，如果是1G的消息，加密的过程很漫长。所以要先对原始消息利用HASH算法先完成消息摘要，比如用MD5，那么1G的原始消息就变成了128bit的散列输出，这时候再进行非对称加密，也就是用私钥加密得到签名。

而大家收到1G的消息和签名以后，先把签名用公钥解密得到散列值A，再把收到的1G的消息进行散列算法得到散列输出B，如果散列值A和散列输出B一样，说明签名就是老王签的，原始消息也是老王发的。

所谓的数字证书其实是特定格式的文件，公钥作为一个字段存储于数字证书中。

证书的传输和交换即可实现公钥的传输和交换。

证书里面有一个字段是指纹，他是指证书的Hash的签名，也就是证书内容通过Hash算法获取Hash以后再用私钥加密最终得到的信息。这样就保证了证书的完整性和拥有者的真实性。

client已经预置了很多受信任的证书，如果某一个server端的证书刚好在client受信任的证书列表里，就可以与之通信

根证书就是已经预置在client里的受信任证书，位于信任链的顶端，从第二层开始自上往下都是非根证书，系统会一层一层从下往上进行check，比如一共3层，如果第3层的非根证书的签名是第二层颁发的，那么继续check第二层，如果第二层的签名是第一层也就是根证书颁发的，那么ok，第三层也会是受信任的。

根证书是由自己的私钥对证书内容的Hash进行加密得到签名（signature）的（也就是自签名），非根证书不是，否则链条就无法一层层往上走了。比如第三层的签名，是用第二层的私钥对第三层的证书内容的HASH进行加密得到的。那么同理，在验证的时候，也要用第二层的公钥进行解密。

基本约束：比如Subject Type End Entity(表示最后的实体)，所以他不允许再继续颁发证书。

有效期：如果过了有效期，那么证书就是不被信任的了。

密钥用法：规定了密钥的用法，不能用作其他

PKI：Public Key Infrastructure 公钥基础建设（体系）

比如用https访问一个server，server会deliver证书过来，然后client就开始check每一层证书的有效期、基本约束、signature等。直到根证书都没问题，就ok了。