对称加密和非对称加密,证书体系

对称加密

通信几方使用相同的密钥,发送者使用该密钥加密数据,接收者通过同样的密钥解密数据。缺点是在通信前双方需要持有同一个密钥,在密钥同步的过程中可能发生泄漏。

非对称加密

每个通信方都拥有一对公钥和私钥,公钥是对外界公开的,私钥仅通信方自己知道,二者是对应的,使用公钥加密的信息,必须是对应的私钥才能解密,反之使用私钥加密的信息,必须是对应的公钥才能解密。也就是说,通信的前提是双方持有对方的公钥即可,因为公钥本身就带有公开属性,所以就谈不上泄漏风险了。

举个例子:
李云龙给张大喵发信,写好信以后,李云龙还会使用摘要算法计算一份信件的摘要,这份摘要用李云龙的私钥加密,加密后的摘要叫做数字签名,接下来把信件和数字签名打包起来,使用张大喵的公钥加密,由于解密需要的私钥只掌握在张大喵手中,保证了整个信件包裹只有张大喵才能解密。

张大喵收到了李云龙发来的密文和数字签名,张大喵首先使用自己的私钥解密这份密文。

但他此时仍然无法确定这封信的来源到底是不是李云龙,万一是哪个刁民冒认身份也未可知,张大喵使用李云龙的公钥去尝试解密信件后面附的数字签名,如果解密成功,说明加密签名的一定是李云龙的私钥,信件的来源一定是李云龙。

但他此仍然无法确定信件有没有被人篡改,张大喵会自己计算一份新建的摘要,和数字签名中解密出的摘要进行对比,如果摘要一致说明信件内容可靠。

至此整个发信过程中保证了信件即使被中途截获,拦截者因为没有张大喵的私钥,里面的数据也不会泄露,也通过数字签名可以让张大喵确信件来源和内容的可靠性。

但整个过程是否就天衣无缝了呢?
答案是否定的,前面说过了,非对称加密通信的前提是拥有对方的公钥,因为其带有公开属性,理论上来讲世界上所有服务器的公钥都是可获取的。但你的计算机中不可能存储着全世界服务器的公钥,通常计算机或浏览器中存储的仅仅只有若干可信任的根证书签发机构的公钥。

要和某个服务器建立加密通信,终究还是要进行公钥的传输,最可靠的传输方式是什么?直接去服务器所在地拷一份回来,但这显然不现实。

如果我们直接发出明文申请,比如访问百度,让百度服务器发送公钥过来。传输的过程中可能会发生中间人攻击,攻击者把自己的公钥披上百度服务器的皮发给了你,你以为你拿到的是百度的公钥,放心地发送信息,但实际上你发出的信息都可以被攻击者获取,攻击者接管了你和“百度”的所有通信。

那么我们如何确认手中拿到的公钥到底是不是属于真正的接收人呢?
这时候就要引入证书体系。

证书

当我们访问一个网站,比如京东,我们明文申请京东的公钥,京东并不会直接发公钥过来,而是会发送京东的证书,公钥就在这个证书里面,同时证书中还包含其他信息,比如证书的签发机构,证书的有效期,网站信息等。

我们怎么确认证书是可以信任的呢?
发来的证书后会附一份证书的电子签名,这个签名来自于证书的签发机构CA,要解开数字签名我们知道要使用签名方的公钥,而我们浏览器中就集成了可信任的根证书CA的公钥,如果这份证书是由其中一个根证书CA签发的,那么我们使用它的公钥进行解密,成功解密的话我们认定证书来源可靠,然后对比摘要我们可以确定证书内容是否被篡改。经过这一套流程,我们可以判定这份证书是否可以信任,如果证书可靠,我们可以放心的取出证书中的公钥进行通信。

但往往给某个网站签发证书的不会是一个根证书CA,而是某个子证书CA,这里就涉及到一个证书的信任链问题。以京东的证书为例:
在这里插入图片描述
给京东签发证书的是子证书CA:

GlobalSign Organization Validation CA
浏览器表示不好意思,这个人我不认识,我只认识值得信赖的根证书CA,我也没存这种小歘歘的公钥。

此时浏览器会尝试获取GlobalSign Organization Validation CA的证书,GlobalSign Organization Validation CA服务器发来它的证书后,浏览器发现签发这个证书的是一个可以信任的根证书CA:

GlobalSign Root CA
浏览器表示,失敬失敬,您我是可以信任的,我这也存着您老的公钥。

浏览器或系统中集成了这些可以信任的根证书CA的公钥,浏览器使用GlobalSign Root CA的公钥解密GlobalSign Root CA发给GlobalSign Organization Validation CA的证书的数字签名,如果确认证书的来源没问题,内容也与签名中的摘要吻合,浏览器就会认定子证书CA GlobalSign Organization Validation CA是可以信任的。同样的,浏览器会使用GlobalSign Organization Validation CA的公钥去检验京东的证书的数字签名,如果来源可信,内容可靠,则说明京东的证书是可以信任的,可以放心的拿出其中的公钥进行通信。

总结起来证书体系的信任链就是:最开始浏览器只信任根证书CA,某个根证书CA告诉浏览器某个子证书CA是值得信任的,而这个子证书CA又告诉我们京东的证书是可以信任的,整个信任链条就由根证书CA逐级延伸到我们访问的网站。

所以证书相当于一个具有极高社会信誉的认证机构对这些信息背书,那么会不会有某些CA不经仔细审核就乱发证书呢?也有这种CA执照被吊销的案例,这种CA的信誉就一文不值,它发出去的证书也不会有谁鸟。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
提供的源码资源涵盖了安卓应用、小程序、Python应用和Java应用等多个领域,每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写,确保了在对应环境下能够无缝运行。同时,源码中配备了详细的注释和文档,帮助用户快速理解代码结构和实现逻辑。 适用人群: 这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生,还是对其他领域编程感兴趣的学生,这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码,你可以掌握各平台开发的基础知识,提升编程能力和项目实战经验。 使用场景及目标: 在学习阶段,你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码,你将深入了解各平台开发的技术细节和最佳实践,逐步培养起自己的项目开发和问题解决能力。此外,在求职或创业过程中,具备跨平台开发能力的大学生将更具竞争力。 其他说明: 为了确保源码资源的可运行性和易用性,特别注意了以下几点:首先,每份源码都提供了详细的运行环境和依赖说明,确保用户能够轻松搭建起开发环境;其次,源码中的注释和文档都非常完善,方便用户快速上手和理解代码;最后,我会定期更新这些源码资源,以适应各平台技术的最新发展和市场需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值