密码学基础概论
散列函数
散列函数的特点是单向不可逆、输入数据敏感(细微改动输出变化也很大)、输出长度固定,常用于校验数据的完整性;
常见的散列函数:
- MD5
- 输出散列值的长度固定为128bit
- SHA-1/SHA-256/SHA-384/SHA-512
SHA1输出散列值的长度固定为160bit;SHA256输出散列值的长度固定为256bit;SHA512输出散列值的长度固定为512bit;
散列函数术语:消息摘要、数据哈希
应用:检测文件是否被篡改、口令加密(将口令和盐混合后计算散列值作为密钥)、消息认证码(HMAC,通过在消息中加入共享密钥来生成可认证的散列值)、伪随机数生成器等;
密码学的6个重要工具分别是:对称加密,非对称加密、单向散列函数、消息认证码(与密钥关联单向散列函数)、数字签名(私钥生成签名,公钥验证签名)、伪随机数生成器
对称加密
对称加密算法的特点是使用相同的密钥对信息进行加密和解密,信息的传输模式是1对1,服务器和N个客户端通信,需要维持N个密钥,密钥的安全是信息安全的基础;
-
DES(短时间可破解)
DES是一种将64bit的明文加密成64bit密文的对称加密算法,DES的密钥长度是64bit,但是由于每隔七位设置一位错误校验位,因此实质上其密钥长度是56bit;
DES加密是分组加密的一种,加密时明文以64bit为一组;如果明文较长时,就需要对DES加密进行迭代(反复),迭代的方式又称为模式; -
3DES
3DES是为了增强DES强度,将DES重复3次所得的一种加密算法,明文经过三重DES算法处理才能变为密文,3DES算法的密钥长度为192(3个密钥,每个密钥64bit,64x3);如果使用的三个密钥都不相同,3DES又称3DES-EDE3;
3DES并不是对明文进行三次DES加密,而是加密 -> 解密 - > 加密,其目的是为了兼容DES,当使用的三个密钥都相同时,3DES就相当于普通的DES加密了; -
AES
Rijndael加密算法,又称AES,是一种分组密码算法,其分组的长度为128bit(标准,同样也可以按后续规则选择,分组长度和密钥长度可以不相同),密钥的长度可以以32bit为单位,在128bit到256bit的范围内进行选择(规范的密钥长度只有128、192、256三种);
非对称加密
非对称加密算法的特点是密钥是成对出现,一般称为公钥(公开)和私钥(保密),公钥加密的数据只能私钥解开,私钥加密的数据只能公钥解开,服务器只需要维持一个私钥就可以和多个客户端通信;该算法的加密计算复杂,加密速度较慢;
- RSA
- ECC
- DH
分组密码模式
分组加密算法都只能加密固定长度的明文,如果明文的长度是任意的,那么只能通过分组迭代的方式反复加密,而分组迭代方法就称为分组密码的模式;一旦分组密码模式选择不恰当,攻击者很可能会根据密文中的规律来破解密文;
-
ECB模式(Electronic Code Book 电子密码本模式)
将明文分组直接加密输出密文分组的方式就是ECB模式;
-
CBC模式(Cipher Block Chaining密文分组链接模式)
CBC模式是将前一个密文分组和当前明文分组的内容混合起来进行加密;
CBC模式块与块之间耦合性很强,无法直接对中间某一块加解密,如果密文中某一块数据损坏了,那么后面的内容都无法正确解密;
-
CFB模式(Cipher FeedBack密文反馈模式)
CFB模式是将前一个密文分组再次加密后与本次明文分组内容异或产生本次的密文分组;
由于明文分组和密文分组之间只是进行了一次异或操作,因此明文数据可以被逐比特位加密,我们可以将CFB模式看做是一种使用了分组密码来实现流密码的方式;
CFB的数据块之间依然存在很大的耦合性;
-
OFB模式(Output-Feedback,输出反馈模式)
OFB模式通过对初始化向量多次加密,并且依次将加密输出与明文分组内容异或产生密文分组;
-
CTR模式(CounTeR,计数器模式)
CTR模式通过将逐次累加的计数器进行加密后与明文分组异或后生成密文分组;
加密时会生成一个值来作为计数器的初始值,加密每组数据时该值会逐次累加;
CTR的优点是通过组序号可以以任意顺序处理分组,这就意味着能够实现并行计算;
分组密码是每次只能处理特定长度数据的一类密码算法,无需记录加解密的内部进度;流密码是对数据流进行连续处理的一类密码算法,流密码中一般以1bit、8bit或32bit为单位进行加密和解密,需要记录加解密的内部进度;
密钥配送
当对数据使用对称加密算法加密时,一定会遇到密钥配送的问题,解决密钥配送问题的方法有以下几种;
-
事先共享密钥
配送密钥最简单的一种方式,事先用安全的方法将密钥共享给对方; -
密钥中心分配
通过密钥分配中心来获取通信密钥; -
Diffie-Hellman密钥交换
通信前,通信双方需要交换一些信息(各自随机生成的私钥使用相关算法后计算出的公钥),根据交换的信息,双方各自可以生成相同的密钥(离散对数原理); -
公钥密钥
使用非对称加密的方式配送密钥,持有加密密钥的一方将密钥加密后,只有持有解密密钥的一方才能解密;
证书
证书的作用和颁发
主要是确保公钥的合法性以解决服务器身份验证的问题。
证书的颁发需要引入第三方机构CA,CA负责核实公钥拥有者的相关信息,并颁发认证证书,同时能够为使用者提供证书认证服务,即PKI体系;其基本的原理是:CA负责审核信息,然后对关键信息利用私钥进行"签名",公开对应的公钥,客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书,基本的方式包括两类 CRL 文件(证书吊销列表文件)和 OCSP(证书状态在线查询协议)。
证书的颁发和使用流程:
(1)服务方S向第三方机构SA提供公钥、组织信息、个人信息(域名)等相关信息并申请认证;
(2)SA审核服务方相关信息,并颁发证书,证书包含如下明文信息:申请者的公钥、申请者相关信息、证书颁发机构、有效时间、证书序列号等;同时证书包含一个密文签名(使用散列函数计算公开明文信息的摘要,然后采用CA的私钥对摘要加密);
(3)客户端向服务方申请证书,并读取证书的相关明文信息,采用相同的散列函数计算信息摘要,然后使用CA提供的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性;然后客户端会验证证书相关的域名信息和有效时间;
(4)客户端会内置信任CA的证书信息(包含CA公钥),如果CA不被信任,则找不到对应CA的证书,证书也被判定为非法(内置CA对应证书称为根证书,颁发者和申请者相同都为CA,自己为自己签名,即自签名证书,内置CA证书是为了验证CA公钥的合法性,以此来解密服务方证书的签名信息);
(5)总结:证书=服务方公钥+申请者与颁发者信息+签名(CA签署的凭证);
注:如果是在内部测试,或是测试https加密传输,可以使用openssl生成自签证书
流程图如下:
证书文件
csr文件:证书请求文件,用于申请证书。
crt文件:CA认证后的证书文件。
key文件:服务方使用的私钥
证书相关总结
TSL/SSL协议
TSL/SSL工作原理
TLS/SSL的功能实现主要依赖于三类基本的算法:散列函数 Hash、对称加密和非对称加密,其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性。
TSL/SSL握手
SSL握手流程图:
1.信息交互部分
< client_hello >
客户都安发送明文请求信息,包含了版本信息(SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3)、加密套件选择列表(每个套件包含认证算法 Au [身份验证]、密钥交换算法 KeyExchange[密钥协商]、对称加密算法 Enc [信息加密]和信息摘要 Mac[完整性校验])、压缩算法选择列表、随机数RandomC、扩展字段等信息;
< server_hello >
(1)返回服务端协商的结果(使用什么版本什么加密算法等等以及用于生成密钥的随机数RandomS);
(2)服务端配置对应的证书链(获取本地证书信息,发送证书Certificate给客户端,用于身份验证与密钥交换;);
(3)通知客户端hello结束;
< 证书校验 >
客户端验证服务器提供证书的合法性,如果验证通过才会进行后续通信;
2.密钥协商部分(采用非对称加密交换密钥,TLS1.3前)
< client >
client_key_exchange:客户端产生随机数Pre-master,采用公钥加密后发送给服务器;
change_cipher_spec:生成加密密钥enc_key = Func(randomC,randomS,Pre-Master);告知服务器后续通信采用刚生成密钥;
encrypted_handshake_message:客户端根据之前获取的相关信息生成hash数据后采用协商的密钥加密,并发给服务器握手验证;
< server >
change_cipher_spec:服务器使用私钥解密Pre-master,使用同样的算法生成加密密钥;验证客户端发送的握手数据后,告知后续通信都采用该密钥;
encrypted_handshake_message:服务器根据之前获取的相关信息生成hash数据采用协商的密钥加密,发送给客户端握手验证
< client >
当客户端验证成功后,握手成功;
3.会话缓存
会话缓存有两种模式,会话标识(Session ID)和会话记录(Session ticket);
Session ID由服务端支持,是协议中的标准字段,服务端可以保存会话ID以及协商的通信内容;
Session ticket需要服务端和客户端都支持,属于一个扩展字段,将协议的协商通信内容加密后发送给客户端保存,服务端保存密钥;
二者的差别主要再保存协商信息的位置与方式不同,类似于http的session(服务器保存)和cookie(浏览器保存),二者共存时优先使用ticket;
Session ID的过程:
(1)如果客户端和服务器之间曾经建立了连接,服务器会在握手成功后返回 session ID,并保存对应的通信参数在服务器中;
(2)如果客户端再次需要和该服务器建立连接,则在 client_hello 中 session ID 中携带记录的信息,发送给服务器;
(3)如果服务器未检索到对应的缓存记录,走正常握手流程,反之则返回 change_cipher_spec 与 encrypted_handshake_message 信息(当前的通信参数与 对称加密密钥的hash 值);
(4)如果客户端能够验证通过服务器加密数据,则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息;
(5)服务器验证,握手成功;
Session ticket的过程:
(1)如果客户端和服务器之间曾经建立了连接,服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息,客户端保存;
(2)如果客户端再次需要和该服务器建立连接,则在 client_hello 中扩展字段 session_ticket 中携带加密信息,一起发送给服务器;
(3)服务器解密 sesssion_ticket 数据,如果能够解密失败,则按照正常的握手过程进行;
(4)如果解密成功,则返回 change_cipher_spec 与 encrypted_handshake_message 信息,两个信息作用与 session ID 中类似;
(5)如果客户端能够验证通过服务器加密数据,则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;
(6)服务器验证,握手成功;
(ssl部分文字及图片摘录自http://www.wosign.com/faq/faq2016-0309-03.htm)