我们知道明文数据在网络上传输是非常不安全的，想要实现数据传输的安全，需要考虑以下几个方面：
私密性：数据私密性就是对数据进行加密，即使数据被截获也不知道内容是什么。通过加密算法对数据进行加密。
完整性：数据完整性能够保证数据在传输过程中不篡改，通过散列函数算法对数据进行完整性检验。
源认证：源认证能够对数据的发送者进行验证，确保数据发送方是合法的，通过H-MAC或数字签名来对数据进行源认证。
不可否认性：又叫抗抵赖性，能够保证人们不能否认自己发送数据的行为和数据的内容，通过数字签名来实现不可否认性。
散列函数：
散列函数也叫HASH，用于验证数据的完整性，常见的有MD5、SHA。特点如下：
1.不等长的输入，等长的输出。通过HASH计算过的数据不管原始数据有多大，计算之后都是固定长度的，例如MD5计算之后都
是128位，SHA-1计算之后都是160位。同学们可以使用贝壳MD5进行计算试一下。
2.雪崩效应：原始数据只要有一点变得，得到的HASH就会不一样。
3.单向：HASH和加密是不同的，只能从原始数据得到HASH值，而不能从HASH推算原始数据。
4.冲突避免：几乎没有两个文件的HASH值是一样的，因此能够确保数据的唯一性。
如何使用散列函数进行完整性检验？
发送者首先将要发送的数据A进行HASH值计算，得到HASH值A；然后将数据A和HASH值一同打包发送给接收者，接收者收到数据
后将数据A进行HASH计算，得到HASH值B，将收到的HASH值A和计算出来的HASH值B进行计算，如果一样，则证明数据是完整的，
没有被篡改过。（这只是一个简单的过程讲解，实际计算中当然不会这么简单，其他问题在后面进行讲解。）
加密：
加密就是把数据由明文转换成密文的过程，发送者把明文加密后传送给接收者，接收者进行解密再得到明文，以保证数据在传
输过程即使被截获了，截获者也不能看到真实的数据，保证数据的安全。
加密算法分为对称加密算法和非对称加密算法。加密算法使用相同的密钥进行加解密，常见的算法有DES、3DES、AES等，非对
称加密算法每个设备有一对密钥，一个公钥和一个私钥，公钥加密私钥解密，私钥加密公钥解密，常见的算法有RSA、DH等。
注意：这里所说的密钥是设备随机产生的一串数字，并不是我们通常输入的密码，例如DES的密钥长度是56位，3DES是的密钥
长度是168位。
对称加密算法：
对称加密算法的优点是紧凑、速度快，通过对称加密算法加密的数据几乎和原来的数据一样大，只对原数据略大一点。对称加
密算法的加密速度很快，现在的硬件设备几乎可以达到线速转发。因此对称加密算法适合加密数据（即真实的要传输的数据）
。对称加密算法的第一个缺点是密钥传输不安全，发送者要把一个数据加密后发给接收者，以DES加密算法为例，它首先产生
一个56位的密钥，然后使用该密钥对该明文数据进行加密，然后把加密后的数据和56位的密钥一起打包发送给接收者；接收者
收到数据后，使用发送者传过来的密钥对密文数据进行解密得到明文。而在这个过程中，虽然数据是被加了密的，但密钥并没
有被加密，这跟使用明文传输数据就没有什么区别了。第二个缺点是每台设备需要维护的密钥数量太多，每两台设备维护一个
密钥，如果有5个用户，就需要5*（5-1）/2=10个密钥，对称密钥使用的密钥数量过多，不好管理和存储，并且，对称加密算
法不支持数字签名。因此在加密过程中不会单纯使用对称加密算法。
非对称加密算法：
非对称加密算法的特点是使用一个密钥加的密，必须使用另一个密钥进行解密。公钥加密，私钥解密；私钥加密，公钥解密。
公钥加密的数据私钥无法解密，私钥加密的数据私钥也无法密。每个非对称加密算法的参与者，都需要首先产生一对密钥，包
括一个公钥和一个私钥。其中私钥只能自己拥有，存储在安全的地方，公钥则分发给其他人。非对称加密算法可以用来加密数
据和对数据进行数字签名。
我们发现，对称加密算法和非对称加密算法都有各自的优点和缺点，那么解决方案就是使用非对称加密算法来加密对称加密算
法产生的密钥，十分安全；用对称加密算法来加密真实的数据，紧凑、速度快又安全，这就是我们通常在实际环境中使用的解
决办法。但这时还遇到一个问题，就是发送者如何拿到接收者的公钥？由于引入今天的主角，PKI。PKI用于解决大范围部署公
钥的场景，解决公钥分发的问题。
数字签名：
在说数字签名之前先说普通的签名，现实中,一般采用签名的方式,使信息不可抵赖,例如,合同谈判,银行取款等,都采用了用户
签名的形式,证明这个信息确实发生过。那么,在网络通信中,通常使用数字签名实现信息的不可否认性.表明这个信息确实发生
过。数字签名的过程就是发送者张三把要发送的数据进行HASH值A，然后把HASH后的数据用私钥进行加密，这个用私钥加密的
过程就是数字签名的过程，这个加密后的结果就叫做数字签名。接着把要发送的数据和数字签名发送给接收者，接收者用发送
者的公钥进行解密，得到HASH值B，如果HASH值A等于HASH值B,则证明这个数据一定是发送者张三发送过来的，张三不能抵赖他
没有发送过这个数据，这就是不可否认性。
PKI（Publice Key Infrastructure）PKI是一个技术框架，不是一项具体的技术，是为了支持大范围部署公钥，为颁发证书而
推出的一系列软、硬件措施。
CA(Certificate Authority)服务器是用来颁发证书的一台服务器。
证书（Certificates）中包含设备的公钥和CA的数字签名。证书可以分为为设备申请证书和为人人申请证书，为设备申请证书
就是为路由器、交换机、服务器、个人PC申请一张证书，是基于Device的证书，常见应用有VPN、802.1X认证等；而个人证书
是基于用户，例如银行网银使用的U盾、VPN使用的智通卡(SmartCard)等。
数字证书包含的主要内容：
1.个人信息（Identity）:姓名、公司、部门等信息
2.属性（Attributes）：
3.公钥（Public Key）：设备或个人的公钥
4.CA的数字签名（Signature）：CA对上述信息的HASH值做的数字签名
证书服务器证明某一公钥和某一实体之间有关联关系，并且限制这一证书的使用范围。（注意：公钥是明文的）
PKI相关标准：
X.509v3：X.509v3是一个互联网PKI标准，基于层次化的PKI模型，是IETF关于PKI的标准。
X.500：是一个目录命名标准。
PEM编码：PEM是一个标准的证书文件编码格式
SCEP：简单在线证书申请协议，主要为设备在线申请证书，原先是思科私有技术，后来公有化，特点如下：
1.主要用于在线证书申请
2.主要由Cisco设计的技术
3.VPN设备PKI证书申请的工业标准
4.使用HTTP协议传输
5.被大多数VPN和CA厂商支持
6.为VPN设备（VPN最终用户）提供简单而功能强大证书申请方式
PKCS#7：PKCS系列的标准是RSA Security公司的标准，并非工业标准。PKCS#7的文件扩展名是.p7b .p7c。PKCS#7是一个封闭
数据的标准，在一个PKCS#7封装里边，可以放置一个用户证书颁发服务器的根证书
PKCS#10：PKCS#10是一个编码方式，是离线申请证书的方法。
PKCS#12：用于在一个单一文件中交换公共和私有对象,它可以包含证书和关联的私钥。它提供 了一个加密机制，因此私钥是
能够被保护的。Cisco优先承载使用这种模式来承载PKI资料。在NVROM中，思科建议你把它进行保存，扩展名.p12(cisco)。在
微软的中扩展名为.pfx(microsoft)
证书服务器介绍：
证书服务器分为两种，一种是公共证书服务器，即它在全球范围内提供证书颁发，并且多数操作系统在出厂的时候即安装它们
的根证书。公共证书的优势是一旦申请，全局受信任；问题是需要付费使用，审核较严，且证书的内容和使用受到限制。另一
种证书服务器是私有证书服务器，它的优点是免费，且使用不受限制，问题是所要使用的实体都需要安装私有证书服务器的根
证书。
注册授权服务器（RA）介绍：
RA的主要作用是分担CA的压力，降低CA的负担，它是CA的前端代理。
RA的角色与功能：
1.接收证书请求
2.验证请求者身份
信任关系：
1.请求者和RA之间不需要建立信任关系，因为RA并不签名任何证书；
2.RA和CA之间需要有信任关系。
密钥和证书的存储：
一般系统使用密码保护私钥，当一个用户解锁私钥，并且加载到内存的时候，其他用户可以通过读取内存的方式来窃取私钥。
使用smartcards更为安全和灵活，颁发证书到用户而不是系统。
anyconnect用微软的证书存储，IPSEC VPN有自己的证书存储位置
在linux，每个运行程序有自己的存储位置
思科IOS证书与密钥通过文件被存储在NVRAM中，不存在FLASH中，做密码恢复操作，私钥被删除
在ASA OS中，证书与密钥通过隐藏文件存储在FLASH中。
PKI处理流程与步骤
第一步：同步时间
时间同步，必须要先确保参加PKI系统的设备和主机的时间同步，才能开始PKI的部署。
第二步：部署证书服务器
第三步：客户端产生密钥对（公钥、私钥）
第四步：验证证书服务器
每一个实体需要获取证书服务器的根证书，里边包含证书服务器的公钥。获取了根证书之后，可以通过fingerprint 离线验证证书服务器
第五步：申请个人证书
第六步：审核并签名证书
管理员对每一个证书请求进行审核，并且对个人信息和公钥内容进行数字签名，签名后的文件即为数字证书
第七步：颁发数字证书
证书服务器把个人证书进行颁发
本文出自 “杨森的IT之路” 博客，请务必保留此出处http://senyang.blog.51cto.com/3427514/1693488
原文地址：http://senyang.blog.51cto.com/3427514/1693488
