信息安全三要素 

1. 保密性：信息在传输时不被泄露

2. 完整性：信息在传输时不被篡改

3. 身份认证：用于确定你数据的来源是你预想的

普通的秘钥加密数据是用于解决保密性问题。

数字签名是用于解决完整性和身份认证问题。

密码算法分类

1. 受限制的算法：算法的保密性基于保持算法的秘密。

2. 基于秘钥的算法：算法的保密性基于对秘钥的保密。（现代密码理论）

基于秘钥的算法

1. 对称密码算法

又称传统密码算法，单秘钥算法，加密秘钥和解密秘钥相同。

常用算法：AES（Advanced Encryption Standard），DES（Data Encryption Standard)，RC6。

对称加密算法

2. 非对称秘钥算法

加密秘钥和解密秘钥不相同，并且是成对出现它，们可以互相加解密。

其中对外公开的秘钥称为公钥，需要保密的秘钥称为私钥。

常用于数字签名，身份认证。

缺点是加密解密速度慢。

公钥加密，私钥解密常用于 数据加密。优点是公钥可以对外公开，加密者不需要知道私钥，不适合大量数据。私钥加密，公钥解密常用于 数字签名。

常用算法：RSA。

非对称加密算法

3. 对比

非对称加密与对称加密相比，其安全性更好：对称加密的通信双方使用相同的秘钥，如果一方的秘钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对秘钥，一个用来加密，一个用来解密，而且公钥是公开的，秘钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥。

4. 实际应用

在实际应用中，通常采取数据本身的加密和解密使用对称加密算法(AES)。 

RSA算法多用于加密并传输对称算法所需的密钥，数字签名。

数字签名

数字签名流程

现实生活中，签名有什么作用？在一封信中，文末的签名是为了表示这封信是签名者写的。计算机中，数字签名也是相同的含义：证明消息是某个特定的人，而不是随随便便一个人发送的（身份认证）；除此之外，数字签名还能证明消息没有被篡改（完整性）。

用私钥加密的消息称为签名，只有拥有私钥的用户可以生成签名。

用公钥解密签名这一步称为验证签名，所有用户都可以验证签名(因为公钥是公开的)

一旦签名验证成功，根据公私钥数学上的对应关系，就可以知道该消息是唯一拥有私钥的用户发送的，而不是随便一个用户发送的。

由于私钥是唯一的，因此数字签名可以保证发送者事后不能抵赖对报文的签名。由此，消息的接收者可以通过数字签名，使第三方确信签名人的身份及发出消息的事实。当双方就消息发出与否及其内容出现争论时，数字签名就可成为一个有力的证据。（不可抵赖性）

生成签名

一般来说，不直接对消息进行签名，而是对消息的哈希值进行签名，步骤如下。

对消息进行哈希计算，得到哈希值

利用私钥对哈希值进行加密，生成签名

将签名附加在消息后面，一起发送过去

验证签名

收到消息后，提取消息中的签名

用公钥对签名进行解密，得到哈希值1。

对消息中的正文进行哈希计算，得到哈希值2。

比较哈希值1和哈希值2，如果相同，则验证成功。

数字证书

数字签名中公开的公钥有可能会被伪造，数字证书实际上就是对公钥进行数字签名，它是对公钥合法性提供证明的技术。

一个数字证书包括公钥，对公钥的数字签名（标识该证书的确是本CA颁发出去的），和描述信息（用户身份信息，版本号、证书序列号、有效期、颁发者身份等）。

数字证书还有一个重要的特征就是只在特定的时间段内有效。

数字证书是一种权威性的电子文档，可以由权威公正的第三方机构，即CA（例如中国各地方的CA公司）中心签发的证书，也可以由企业级CA系统进行签发。

如何生成证书？

服务器将公钥A给CA（公钥是服务器的）

CA用自己的私钥B给公钥A加密，生成数字签名A

CA把公钥A，数字签名A，附加一些服务器信息整合在一起，生成证书，发回给服务器。

注：私钥B是用于加密公钥A的，私钥B和公钥A并不是配对的。

如何验证证书？

客户端得到证书

客户端得到证书的公钥B（通过CA或其它途径）

客户端用公钥B对证书中的数字签名解密，得到哈希值

客户端对公钥A进行哈希值计算

两个哈希值对比，如果相同，则证书合法。

注：公钥B和上述的私钥B是配对的，分别用于对证书的验证（解密）和生成（加密）。

颁发过程

数字证书颁发过程一般为：用户首先产生自己的秘钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布。数字证书各不相同，每种证书可提供不同级别的可信度。可以从证书发行机构获得您自己的数字证书。

CA

电子商务认证授权机构（CA, Certificate Authority），也称为电子商务认证中心，是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

证书的层级结构

用户需要使用认证机构的公钥，对证书上的数字签名进行验证。

那么，对于用来验证数字签名的认证机构的公钥，怎样才能判断它是合法的呢？对于认证机构的公钥，可以由其他认证机构施加数字签名，从而对认证机构的公钥进行验证，即生成一张认证机构的公钥证书。

一个认证机构来验证另外一个认证机构的公钥，这样的关系可以迭代好几层。这样一种认证机构之间的层级关系，我们可以用某公司内部PKI来类比。例如某公司的组织结构如下，每一层组织都设有认证机构。

假设Bob是札幌办事处的一名员工，札幌办事处员工的公钥由札幌办事处认证机构颁发的（因为这样更容易认证本人身份）。

对于札幌办事处认证机构的公钥，则由北海道分公司认证机构颁发证书，而对于北海道分公司认证机构的公钥，则由东京总公司认证机构颁发证书，以此类推......。不过这个链条不能无限制延伸，总要有一个终点，如果这个终点就是东京总公司认证机构（即不存在更高一层的认证机构）的话，该认证机构一般就称根CA（Root CA）。而对于东京总公司认证机构，则由东京总公司认证机构自己来颁发证书，这种对自己的公钥进行数字签名的行为称为自签名。

现在假设Alice要验证札幌办事处员工Bob的数字签名，那么Alice需要执行如下步骤进行验证。

首先从最高层认证机构（根CA）开始。如果连根CA的公钥都不合法的话，那么就无法验证证书了，因此我们假设Alice所持有的东京总公司认证机构的公钥是合法的。

接着，Alice取得北海道分公司认证机构的公钥证书，这个证书上面带有东京总公司认证机构的数字签名。Alice用合法的东京总公司认证机构的公钥对数字签名进行验证。如果验证成功，说明Alice取得了合法的北海道分公司认证机构的公钥。

再接下来，Alice取的札幌办事处认证机构的公钥证书，这个证书上面带有北海道分公司认证机构的数字签名。Alice用合法的北海道认证机构的公钥对数字签名进行验证。如果验证成功，则说明Alice获得了合法的札幌办事处认证机构的公钥。

最后，Alice取得札幌办事处员工Bob的公钥证书，这个证书上面带有札幌办事处认证机构的数字签名。Alice用合法的札幌办事处认证机构的公钥对数字签名进行验证。如果验证成功，则说明Alice获得了合法的札幌办事处员工Bob的公钥。

上面就是Alice对Bob的数字签名进行验证的整个过程。当然，如此复杂的验证过程不会是由人来操作的，而是由电子邮件或者浏览器等软件自动完成的。

数字认证过程

数字认证过程

所示的事件序列，如下：

1.Alice 将一个签名的证书请求发送到 CA，该证书包含有她的姓名、公共密钥以及可能的附加信息。

2.CA 根据 Alice 的请求创建一个消息。CA 使用自己的专用密钥对消息进行签名，以创建一个单独的签名。CA 将消息和签名返回给 Alice。Alice 的证书中包含了消息和签名。

3.Alice 将她的证书发送给 Bob，让他有权访问她的公共密钥。

4.Bob 使用 CA 的公共密钥验证证书的签名。如果证明签名有效，则他会接受证书中的公共密钥作为 Alice 的公共密钥。

哈希

Hash，一般翻译做“散列”，也有直接音译为“哈希”的，就是把任意长度的输入（又叫做预映射pre-image）通过散列算法变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。

1.MD5

2.SHA

应用1.      密码加密

单纯使用MD5之所以不好，并不是说MD5这种方法容易遭到破解，而事实上对于MD5求原象或者第二原象，也就是“逆计算”这种破解，没有什么很好的方法。只能通过预先计算知道许多MD5的对应关系，存在数据库中，然后使用的时候反查，例如我知道'password'的MD5值是5f4dcc3b5aa765d61d8327deb882cf99，那么我就用一个数据库存起来，只要我看到5f4dcc3b5aa765d61d8327deb882cf99，我就知道这个是口令'password‘使用MD5处理之后的值，原来的口令就是'password'。MD5在身份鉴别系统中用于口令保护已经是很久了事情了，大部分黑客也有针对这种Hash方式准备相应的数据库进行反查，这种数据库称为彩虹表。

应用2.      文件校验

通过hash值对比，判断文件是否是同一个文件（或者文件是否被修改过）。

加盐

加盐加密是一种对系统登录口令的加密方式，它实现的方式是将每一个口令同一个叫做”盐“（salt）的n位随机数相关联。可以防御彩虹表攻击。

彩虹表（词典攻击）

彩虹表是一个用于加密散列函数逆运算的预先计算好的表, 为破解密码的散列值（或称哈希值、微缩图、摘要、指纹、哈希密文）而准备。一般主流的彩虹表都在100G以上。 这样的表常常用于恢复由有限集字符组成的固定长度的纯文本密码。

HTTPS

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 

HTTPS通信流程

1.https请求

客户端向服务端发送https请求;

2.生成公钥和私钥

服务端收到请求之后，生成公钥和私钥。公钥相当于是锁，私钥相当于是钥匙，只有私钥才能够打开公钥锁住的内容;

3.返回公钥

服务端将公钥(证书)返回给客户端，公钥里面包含有很多信息，比如证书的颁发机构、过期时间等等;

4.客户端验证公钥

客户端收到公钥之后，首先会验证其是否有效，如颁发机构或者过期时间等，如果发现有问题就会抛出异常，提示证书存在问题。如果没有问题，那么就生成一个随机值，作为客户端的密钥，然后用服务端的公钥加密;

5.发送客户端密钥

客户端用服务端的公钥加密密钥，然后发送给服务端。

6.服务端收取密钥，对称加密内容

服务端收到经过加密的密钥，然后用私钥将其解密，得到客户端的密钥，然后服务端把要传输的内容和客户端的密钥进行对称加密，这样除非知道密钥，否则无法知道传输的内容。

7.加密传输

服务端将经过加密的内容传输给客户端。

8.获取加密内容，解密

客户端获取加密内容后，用之前生成的密钥对其进行解密，获取到内容。

SSL

用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。目前一般通用之规格为40 bit之安全标准，美国则已推出128 bit之更高安全标准，但限制出境。只要3.0版本以上之I.E.或Netscape浏览器即可支持SSL。

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

证书标准X.509

X.509 是密码学里公钥证书的格式标准。 X.509 证书己应用在包括TLS/SSL（WWW万维网安全浏览的基石）在内的众多 Intenet协议里.同时它也用在很多非在线应用场景里，比如电子签名服务。

openSSL

OpenSSL 是一个强大的安全套接字层密码库，包括了加密算法，常用密钥和证书管理，SSL协议等功能。

CSR后缀文件

CSR是Certificate Signing Request的英文缩写，即证书请求文件。在申请者向CA申请证书时使用，包含申请者的公钥和申请者的基本信息。

DER格式和PEM格式

DER格式: Distinguished Encoding Rules，用二进制DER编码，不可读，不常用。

PEM格式: Privacy-Enhanced Mail，DER编码后再用ASCLL(BASE64)编码，可读。

CRT，CER后缀文件

证书文件，只有公钥没有私钥。存储格式可以是PEM和DER。CRT大多数为PEM编码，CER大多数为DER编码。一般Linux下面叫CRT，Windows下面叫CER。CRT和CER可以互相转换。

PEM后缀文件

可以存放证书或私钥，或者都有，如果只有私钥，一般使用KEY文件格式。

DER后缀文件

可以存放证书。（不常用）

PFX

一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这个文件包含了证书及私钥)这样会不会不安全？应该不会,PFX通常会有一个"提取密码",你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX使用的时DER编码。

PFX，DER，PEM可以互相转换。

PKCS1～12

公钥加密的标准。

P12

PKCS12的简写，二进制格式，P12文件中包含了CRT和KEY两部分内容，需要提取密码才能提取相关的内容。

KEY

私钥文件。

中间人攻击

https也不是绝对安全的，中间人可以获取到客户端与服务器之间所有的通信内容。

中间人截取客户端发送给服务器的请求，然后伪装成客户端与服务器进行通信;将服务器返回给客户端的内容发送给客户端，伪装成服务器与客户端进行通信。

通过这样的手段，便可以获取客户端和服务器之间通信的所有内容。

使用中间人攻击手段，必须要让客户端信任中间人的证书，如果客户端不信任，则这种攻击手段也无法发挥作用。

中间人攻击的预防

1 、针对安全性要求比较高的 app，可采取客户端预埋证书的方式锁死证书，只有当客户端证书和服务端的证书完全一致的情况下才允许通信，如一些银行类的app，但这种方式面临一个问题，证书过期的问题，因证书有一定的有效期，当预埋证书过期了，只有通过强制更新或者要求用户下载证书来解决。

2 针对安全性要求一般的app，可采用通过校验域名，证书有效性、证书关键信息及证书链的方式。

HTTPS单向验证

TCP连接建立好后，对于HTTP而言，服务器就可以发数据给客户端。但是对于HTTPS，它还要运行SSL/TLS协议，SSL/TLS协议分两层，第一层是记录协议，主要用于传输数据的加密压缩；第二层是握手协议，它建立在第一层协议之上，主要用于数据传输前的双方身份认证、协商加密算法、交换密钥。SSL验证过程就是SSL握手协议的交互过程。

客户端会有一个信任库，里面保存了该客户端信任的CA（证书签发机构）的证书，如果收到的证书签发机构不在信任库中，则客户端会提示用户证书不可信。

若客户端是浏览器，各个浏览器都会内置一些可信任的证书签发机构列表，在浏览器的设置中可以看到。

如果不在信任表中，则浏览器会出现类似下面的警告页面，提示你不安全。（当然，你可以选择继续访问）

若客户端是程序，例如Java中，需要程序配置信任库文件，以判断证书是否可信，如果没设置，则默认使用jdk自带的证书库（jre\lib\security\cacerts,默认密码changeit）。如果证书或签发机构的证书不在信任库中，则认为不安全，程序会报错。（你可以在程序中设置信任所有证书，不过这样并不安全）。

HTTPS双向验证

单向验证过程中，客户端会验证自己访问的服务器，服务器对来访的客户端身份不做任何限制。如果服务器需要限制客户端的身份，则可以选择开启服务端验证，这就是双向验证。从这个过程中我们不难发现，使用单向验证还是双向验证，是服务器决定的。

一般而言，我们的服务器都是对所有客户端开放的，所以服务器默认都是使用单向验证。如果你使用的是Tomcat服务器，在配置文件server.xml中，配置Connector节点的clientAuth属性即可。若为true，则使用双向验证，若为false，则使用单向验证。如果你的服务，只允许特定的客户端访问，那就需要使用双向验证了。