大家好,欢迎来到IT知识分享网。
说起网络安全,最基本的策略就是走https。https仿佛一条神秘通道,有了它,万事无忧。
- 保密(Confidentiality) 。网购越来越普及,网上交易,信用卡和密码无疑要保密。
- 完整性(Integrity)。比如下载的软件被人修改,附加上木马病毒。
- 认证(Authentication)。最简单的,用户id和password
- 授权(Authorization)。比如用户授权容许第三方应用访问平台的(SNS/weibo)个人数据
- 不可否认(Non-Repudiation)。你从银行取了一笔钱,你说你没取或者说不是你取的,这便是否认。所以银行会让你出示身份证,并签名单据存根。
密码学(Cryptography)
一首藏头诗
Hello, cryptography
Symmetric Ciphers
常见的算法有
Data Encryption Standard (DES):
美国国家联邦1977年指定的标准,以64bit为块(block)来进行加密/解密,key的大小为56bit。随着计算机运算能力的增强,DES被激活成功教程的难度逐渐降低。
据称,1999年有人使用1万台pc不到一天的时间激活成功教程了DES加密的消息。1997年。美国国家标准与技术委员会又推出了AES(Advanced Encryptoin Standard),通过公开竞赛征集,最终选用了Rijndael的算法。
对称密码学有个很扰人的问题就是key的交换(key management)。通信双方必须采取一种安全的方式来交换密钥,比如通过电话交换–假定电话这个信息通道是安全可靠的。这样我们需要另外一个独立的通道(Channel)来安全的交换key。假如Bob除了和Alice通信,还需要和其他成千上百人进行通信,这时一一交换key变得难以管理和执行。
为了解决这个问题,
公钥密码学(Public-key_cryptography)或者是非对称密码学(Asymmetric Ciphers)应运而生。
Asymmetric Ciphers
消息的加密和解密。Bob要向Alice发送消息,他使用Alice的公钥(对所有人可见)对消息加密。Alice收到消息后,使用私钥(仅自己可见)对消息进行解密。
除了消息的加密与解密,公钥和私钥还可用在消息的签名上。Alice使用自己的私钥将消息加密,Bob使用Alice的公钥将其解密,则可验证其消息来自于Alice,而不是别人,否则其无法解密。在后面的数字签名(digit singature)中我们会介绍,除了加密,还必须保证数据的完整性(
Integrity).
常见的公钥算法有
RSA : 由
Ron Rivest, Adi Shamir, and Leonard Adleman1978年在论文中提出,RSA即以三人的首字母命名。
- key的生成
- 取两个不同的质数,p=61, q=53
- 计算n=p*q = 3233
- 计算两个质数的totient积(61-1)*(53-1)=3120. totient是所有小于给定正数且与其互质的自然数个数。
- 选择一个小于3120且与3120的互质的数, e = 17
- 计算e对于3120的模块逆数,d=2753. 模块逆数(Modular_multiplicative_inverse)是指 (d*e) mod 3210 = 1
- 公钥为(n=3233, e=17),私钥为(n=3233, d=2753)
- 加密
- 消息m, 密文为 m^17 mod 3233,例如,消息m=65,c = 6517 (mod 3233) = 2790
- 解密
- 密文c,明文为 c^2753 mod 3233, 例如,m = 27902753 (mod 3233) = 65
One-way hash functions
在介绍数字签名之前,我们介绍一下单向hash函数(one-way hash functions)。数据完整性的校验在网络传输和磁盘文件存储中早已有之。校验和(checksum),比如将所有bit进行异或,得到一个bit的校验码,还有循环校验码(CRC)等。这类校验一般是防止电路异常或者磁盘损坏。对于防止人为的篡改,更强劲的单向hash函数呼之而出。
单向hash函数,并不是说原文和hash值是一对一的映射关系,而是给定hash值后,很难找出(激活成功教程出)一条消息生成的hash值和其相等。进一步讲,对于单向hash函数,很难找到hash冲突–两条不同的消息产生相同的hash值。
单单使用hash function并不能保证数据的完整性,窃听者可以连同消息和hash值一同修改。在接下来介绍的数字签名中,对hash值使用私钥进行加密,保证了hash值的安全。
验证:Bob使用相同的hash算法生成文档的hash值;使用Alice的公钥对签名进行解密,得到原hash值,如果两个hash值相同,则表明文档没有被修改,而且该文档由Alice发送。
在数字签名中, 往往将Alice的公钥连同文档一同发给Bob,更准确的说,是将Alice的证书(certificate)连同文档一起发送,如下图。
Certificate
identity)和公钥进行绑定的证明。其采用真实世界中类似的方法,通过一个第三方权威(Certificate Authority)来签定。
假定大家都相信Charlie。Alice将其Public key和自己的身份信息(姓名,地址,web url)发给Charlie。Charlie通过一定的方式(比如派个特派员)验证一切信息无误后,生成一份Certificate文档(见下图)。Certificate文档包含Alice的名字,CA的名字,Alice的网址信息,Alice的公钥,最后一个是Charlie关于上面信息的数字签名。Charile将这份Certificate送回给Alice。在数字签名时,发送者会将认证连同文档、签名一块发送给接收者。接收者首先使用CA(Charlie)的公钥对其certificate进行验证(类同前文数字签名的验证过程),确认公钥和身份一致(见下图)。验证Alice的公钥没问题后,就可以使用Alice的公钥进行前文数字签名的验证(
Integrity和Authentication)
Certificate Chain:
前文说Certficate的验证是使用CA的公钥来进行校验。如何保证CA本身的公钥就一定和身份匹配?于是出现了Certicate Chain,如下图:Alice的公钥由Charlie来鉴定,Charlie的公钥又有Victor来签定,而Victor的公钥自己来签发。有自己来签发公钥的CA就叫Root CA。
SSL(Secure Socket Layer)
- 使用公钥和私钥交换一个共有密钥,这样保证了会话中密钥的安全性;每个人只需要维护自己的一套公钥和私钥,就可以彼此之间任意安全通信,解决了密钥管理的问题。
- 使用共有密钥来加密与解密消息,这样可以得到更快的加密解密速度。
SSL就是基于上面的思路来构建
SSL HandShake,
- 首先彼此say hello,交换CipherSuites信息(Client hello, Server Hello),商讨下面的协议
-
- key exchange algorithm: 如何交换key,以及身份的验证,比如使用RSA公钥证书(RSA public-key certificate)
- bulk encryption algorithm: 通信中采用的加密算法
- message authentication code: 完整性验证采用的hash函数
- pseudorandom function:伪随机数的生成算法 (is used to create the master secret, a 48-byte secret shared between the two peers in the connection)
- 例如 SSL_RSA_WITH_RC4_128_MD5 (authentication using RSA public-key certificate, data encryption using 128-bit RC4, and data integrity using an MD5 hash).
- 身份验证,Server将其公钥证书(certificate)发给client;client验证Server身份,确定server的公钥(public key)可靠
- clicent发送key交换的信息(ClientKeyExchange):可能是个随机数或者preMasterKey,使用server的公钥加密后发给server;client和server使用此随机数(只有双方知道)生成相同的主钥(Master key),之后通信中使用的key values由此主钥生成。
- ChangeCipherSpec,表示商谈完毕,可以进行消息的加密/解密
- Finish 从这个消息开始,双方使用商讨的加密函数和共有的密钥进行加密/解密
HTTPS(Hypertext Transfer Protocol Secure)
https即http + ssl。就是在不安全的网络中建立一个安全的信息通道。
浏览器在访问https打头的网址时,进行SSL中的握手,确定好密钥后,所有在网络传输的http请求和响应都是通过加密之后的密文。
在浏览器中,会预装几个root ca(
Verisign,
GlobalSign)的certificate(证书)。如果一个https网站的certificate不是由这些root ca来签发,则浏览器无法验证其certificate的有效性,因此弹出诸如你是否信任XX之类的警告。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/21299.html