HTTPS证书校验

HTTPS证书校验,第1张

首先私钥可以用口令保护。
你可以用U盘携带,不过你认为保险不?你想安全,就去正经的发密钥的公司取得那种不可直接复制的Ukey。(这玩意只能读不能写,自己写了也没用-没签发人签名)
或者,你就用你银行或社保等发的那种u-key
你有硬件就不泄露了?先是你总要有机会去插是吧,那时还不是能读,甚至有饶过的。

对称加密就是指,加密和解密使用同一个密钥的加密方式。需要用到的有加密算法和加密秘钥。例如加密算法可以类似这样的加密规则(a ->b,b->w,c->a)

发送方使用密钥将明文数据加密成密文,然后发送出去,接收方收到密文后,使用同一个密钥将密文解密成明文读取。

优点:加密计算量小、速度快,效率高,适合对大量数据进行加密的场景。
缺点:(1)密钥不适合在网上传输(容易被截取),(2)密钥维护麻烦

DES 、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES。

数据加密标准DES属于常规密钥密码体制,是一种分组密码。加密前,先对整个明文进行分组,每一组长为64位,然后对每一个64位二进制数据进行加密处理,产生一组64位密文数据。最后将各组密文串接起来,即得出整个的密文。使用的密钥为64位(实际密钥长度为56位,有8位用于奇偶检验)

DES的保密性取决于密钥的保密,而算法是公开的。尽管人们在破译DES方面取得了许多进展,但至今仍未能找到比穷举搜索密钥更有效的方法。DES是世界上第一个公认的实用密码算法标准,它曾对密码学的发展做出了重大贡献。目前较为严重的问题是DES的密钥长度,现在已经设计出搜索DES密钥的专用芯片。

DES算法安全性取决于密钥长度,56位密钥破解需要35到21分钟,128位密钥破解需要54 10^18次方年

注意的是:这里是没有密钥的情况下,直接穷举密钥尝试破解。如果密钥在传送过程中被人截取了,就相当于直接知道加密规则了,根本不需要破解,因此密钥在网络中传送还是不安全。

与对称加密算法不同,非对称加密算法需要密钥对,即两个密钥:公开密钥(公钥)和私有密钥(私钥)。

公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。

公钥和私钥是怎么来的?
*** 作系统随机生成一个随机数,将这个随机数通过某个函数进行运算,分成两部分,公钥和私钥

优点:安全性高
缺点:加密与解密速度慢。

RSA、ECC(移动设备用)、Diffie-Hellman、El Gamal、DSA(数字签名用)。

答案是不能
鉴于非对称加密的机制,我们可能会有这种思路:服务器先把公钥直接明文传输给浏览器,之后浏览器向服务器传数据前都先用这个公钥加密好再传,这条数据的安全似乎可以保障了! 因为只有服务器有相应的私钥能解开这条数据
然而 由服务器到浏览器的这条路怎么保障安全? 如果服务器用它的的私钥加密数据传给浏览器,那么浏览器用公钥可以解密它,而这个公钥是一开始通过明文传输给浏览器的,这个公钥被谁劫持到的话,他也能用该公钥解密服务器传来的信息了。所以 目前似乎只能保证由浏览器向服务器传输数据时的安全性 (其实仍有漏洞,下文会说)。

1、先通过非对称加密技术,把对称加密的密钥X传给对方,使得这个对称加密的密钥X是安全的
2、后面再通过对称加密技术进行数据传输

详细流程
(1)服务器端拥有用于非对称加密的 公钥A 私钥A’
(2)客户端向网站服务器请求,服务器先把 公钥A 明文给传输浏客户端
(3)客户端随机生成一个用于对称加密的 密钥X ,用 公钥A 加密后传给服务器端。
(4)服务器端拿到后用 私钥A’ 解密得到 密钥X
(5)这样双方就都拥有 密钥X 了,且别人无法知道它。之后双方所有数据都用 密钥X 加密解密。

数字签名是基于公钥密码体制(非对称密钥密码体制)的。

数字签名必须保证以下三点:

上图位用户A使用数字签名向用户B传输一份文件的过程:

什么时候使用这种不对文件加密,而对文件的摘要加密(对文件进行签名)的技术呢?

注意: 这里强调的是只有“A公钥” 上有认证机构CA的数字签名,意思是CA用它的私钥对“A公钥”的内容进行单向散列函数得到的 加密摘要(数字签名) ,该签名放在“A公钥”中(左上角那个),对于B用户来说,它从可靠的路径拿到CA的公钥,使用CA的公钥解密“A公钥”的内容得到的128位的摘要 和 “A公钥”的内容通过单向散列函数计算出来的是否一致,如果是表示认可这个“A公钥”

当用户A遗失或泄露了CA颁发的证书后,为了避免他人使用该证书冒充用户A,用户A向认证机构CA "挂失" 该证书。于是认证机构CA把该证书放入该认证机构的证书吊销列表(CRL)中,并在网上公示。

用户B在收到用户A的公钥时,除了要验证该公钥是否位认证机构颁发的,还要登录认证机构的网站查看该公钥是否已被认证机构吊销变为无效证书。

认证机构CA的作用:

1、>

网络上常常有对RSA、DH算法,以及中间人攻击的讨论。
一种说法是“RSA密钥协商(交换)不会受到中间人攻击”,听起来似乎RSA比DH做密钥协商更优。
这种说法有些不负责任。下面把这个问题中涉及到的概念都解释一下,再来看这个问题。

中间人攻击,可以这样解释:攻击者一定程度上控制了网络,成为网络双方通信的中间者,从而获取到双方的通信信息;而通信双方都感知不到中间人的存在。
这个话题往往和加密通信一起讨论:如果加密信道中存在中间人,那明文就会被中间人获取,而通信双方还不会知晓。

中间人攻击的根本,在于通信双方没有进行身份认证。即:不知道和自己直接通信的人是谁。如果双方能确认直接通信的人就是对方,也就不存在中间人攻击了。

RSA加密算法 是一种非对称加密技术。由一对密钥(公钥+私钥)组成。
可以利用私钥来生成公钥。

一般来说,私钥会被秘密保存起来,而公钥则分发出去。

公钥加密,私钥解密,称为RSA加密算法。 是为了保证公钥加密的内容,只有私钥持有者可以解密。常常用在客户端账密登录过程:客户端对密码进行公钥加密,发送到服务端后用私钥解密,这样即使请求被截获也不会泄露密码(实际上要更复杂一些)。

私钥加密,公钥解密,称为RSA签名算法。 是为了保证公钥持有者获取的内容,确实是来自私钥持有者的正确内容。比如服务器持有私钥,将一个重要信息计算hash再私钥签名后,和信息本身一起发送到客户端;客户端用公钥解密签名得到hash值,再计算信息的hash值,进行比对,就知道内容是否被篡改。由于私钥的保密性,攻击者无法伪造有效的签名。

DH密钥交换算法 并不是 加密算法,而是双方在不安全的网络中交换信息而生成双方仅有的密钥的一种方法。其结果是,交换的双方得到了一样的会话密钥,而其他任何人不能得到这个密钥。
由于算法的结果是通信双方拥有了一样的密钥,双方往往会利用这个密钥进行 对称 加密通信。

DH算法的过程可以简单解释如下:通信双方AB,各自生成一对DH密钥(Pa,Sa)和(Pb,Sb)(P代表公钥,S代表私钥)。双方交换各自的公钥P,于是A持有Sa、Pb,B持有Sb、Pa。通过某种计算,Sa、Pb可以生成会话密钥K,Sb、Pa也可以生成相同的K。

DH算法本身不包含身份认证机制,所以中间人攻击是其明显的问题。
设想:
在AB间,有一C。AB交换DH公钥P时,C在中间截获;C自己生成一对DH密钥(Pc,Sc),用Pc和A、B完成密钥交换。于是C与A间有了会话密钥Kac=f(Pa,Sc)=f(Pc, Sa),C与B间有了会话密钥Kcb=f(Pb,Sc)=f(Pc, Sb)。只要C从一方获得的信息,重新加密后传递给另一方,AB就都不会发现他们的通信被劫持了。

密钥协商(key establishment)包括“密钥传输”(key transmission)和“密钥交换”(key exchange)。

所谓RSA密钥协商实际是密钥传输,即一方生成密钥,传递给另一方,而不必双方交换。
具体来说,就是A自己生成一个密钥K,用自己的RSA公钥加密,再传递给B;B用RSA私钥解密得到K。仅就这个过程而言,不会存在中间人攻击。

但是这不是说RSA就比DH就更安全了。设想上面的情况,必须先要令A持有RSA公钥,B持有RSA私钥。这首先先进行一次RSA公钥传递,而这个传递过程是存在中间人攻击的。

设想:
B生成一对RSA密钥Pb、Sb,将公钥Pb发送给A。而AB中有C。C截获了Pb,而自己生成了一对RSA密钥Pc、Sc,将Pc发送给A。
A用Pc加密了会话密钥K,发送给B,被C截获。C用Sc解密得到K,再用Pb加密后给B。这时C完成了中间人攻击。

所以说: RSA的公钥在端与端间传递时,存在中间人攻击问题。

RSA最好的使用场景在服务端/客户端之间,服务端持有私钥,客户端直接内置好公钥,就不用担心中间人攻击了。

平时我们使用的,号称安全的>这个问题相当于是系统级别的了。
1、一般手机校验码换登录token
2、用token或者直接短信校验码零时属性换hash后的私钥
3、基于网络安全协议传输数据。
4、app端返回机器唯一码和获取成功参数和token。
这是比较简单的一个过程,可能还会涉及要签名、证书、散列函数等。
不知道你是做开发,还是只是想了解,我这有公钥实施的电子版数据,要的话私信我。
纯手工,忘采纳,不懂我再补充


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13434881.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-08-05
下一篇 2023-08-05

发表评论

登录后才能评论

评论列表(0条)