浅析CA证书

    转载自 http://blog.sina.com.cn/s/blog_67908e4c0100w0ok.html

        众所周知,加密对于通信安全起到了不可以磨灭的作用,而最初的对称加密算法无法使用网络通信的加密要求(单一的密钥不可能通过网络直接传输),那么非对称加密就成为了最理想的加密机制,其原理为:
 
        1. A想要与B通信,那么A需要用B的公钥加密,然后B在收到这个加密的信息后,用自己的私钥解开。任何人(包括A)如果不知道B的私钥都不能解开这个加密文件。
        2. B想确定是A发送的(而不是其它人冒充A发送),那么A在发送这个加密的通信报文时,需要用自己的私钥对这个加密通信报文签名,在B收到加密文件后,先用A的公钥进行验证(只有用A的私钥签名,这个公钥才能验证通过),再用自己的私钥进行解密。
 
        但问题是A和B怎么知道手头上确实是对方的公钥呢?如果黑客在A和B进行交换公钥时就拦截并伪造了,给A和B的都是自己的公钥,那么问题就大了。
 
        因此,CA认证中心出现了,所谓CA(Certificate Authority)认证中心,它是采用PKI(Public Key Infrastructure)公开密钥基础架构技术,专门提供网络身份认证服务,负责签发和管理数字证书,且具有权威性和公正性的第三方信任机构,它的作用就像我们现实生活中颁发证件的公司,如护照办理机构。目前国内的CA认证中心主要分为区域性CA认证中心和行业性CA认证中心。
        所谓根证书,是CA认证中心与用户建立信任关系的基础,用户的数字证书必须有一个受信任的根证书,用户的数字证书才是有效的。简而言之根证书:未签名的公钥或自签名的证书,用于验证签发证书之用。签发证书证书其实包含三部分,用户的信息,用户的公钥,还有CA中心对该证书里面的信息的签名,要验证一份证书的真伪(即验证CA中心对该证书信息的签名是否有效),需要用CA中心的公钥验证,而CA中心的公钥存在于对这份证书进行签名的证书内,故需要下载该证书,但使用该证书验证又需先验证该证书本身的真伪,故又要用签发该证书的证书来验证,这样一来就构成一条证书链的关系,这条证书链在哪里终结呢?答案就是根证书,根证书是一份特殊的证书,它的签发者是它本身,下载根证书就表明您对该根证书以下所签发的证书都表示信任,而技术上则是建立起一个验证证书信息的链条,证书的验证追溯至根证书即为结束。所以说用户在使用自己的数字证书之前必须先下载根证书。
       同样的总结一下签发证书:包括用户信息、CA签发机构信息、用户公钥、有效日期、CA签发机构签名(CA签发机构用私钥签名,用于将用户信息+用户公钥等信息进行签名确保内容的真实性)、CA签发机构的公钥(用于让用户验证签发证书是否是CA签发机构签发的),这整个内容表示的是一个签发证书。
 
       对于两个用户进行加密通信而言,用户1首先从CA认证中心下载根证书,表示信任整个机构签发的证书(根证书就是一个公钥证书要来验证签发证书之用),然后用户1生成自己的公钥和私钥,然后将自己生成的公钥和用户1的信息等提交申请给CA认证中心,由CA认证中心完成签发证书(即值得信赖的用户1的公钥证书),CA签发给用户1的证书和CA根证书都导入用户1的软件,同理,用户2也导入了CA签发给用户2的证书和CA根证书,当用户1和用户2通信时,用户1会用CA根证书(和用户2同样认可的CA认证中心)来验证用户2的签发证书(证书里面包含用户2的公钥),验证用户2的签发证书通过后,然后用户2也会验证用户1的签发证书,即完成双方证书的验证,这叫双因子认证。如果用户1的签发证书是由用户2签发的(例如银行给客户的),而用户2 是由CA认证中心签发的,那么对于用户1而言用户2的证书是CA认证中心签发的,可以用CA的根证书进行验证,同时,用户1的签发证书是由用户2签发的,可以利用用户2的公钥进行验证。当双方证书都验证通过后,双方会协商出一个密钥进行对称的加解密的通信(原因是非对称加密算法的加解密速度较慢,因此最终还是采用协商后的对称加密密钥进行加密通信)。
 
        对于现实生活中的银行网银,如果你有USB key,其实用的就是如上提到的双因子认证,如果是普通网上银行,即通过https方式进行网上银行操作的,就是只认证服务器端的身份验证,而不对客户身份进行验证,自然安全性比双因子认证要差。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
ThreadLocal 是 Java 中的一个类,它提供了一种线程局部变量的机制。线程局部变量是指每个线程都有自己的变量副本,每个线程对该变量的访问都是独立的,互不影响。 ThreadLocal 主要用于解决多线程并发访问共享变量时的线程安全问题。在多线程环境下,如果多个线程共同访问同一个变量,可能会出现竞争条件,导致数据不一致或者出现线程安全问题。通过使用 ThreadLocal,可以为每个线程提供独立的副本,从而避免了线程安全问题。 ThreadLocal 的工作原理是,每个 Thread 对象内部都维护了一个 ThreadLocalMap 对象,ThreadLocalMap 是一个 key-value 结构,其中 key 是 ThreadLocal 对象,value 是该线程对应的变量副本。当访问 ThreadLocal 的 get() 方法时,会根据当前线程获取到对应的 ThreadLocalMap 对象,并从中查找到与 ThreadLocal 对象对应的值。如果当前线程尚未设置该 ThreadLocal 对象的值,则会通过 initialValue() 方法初始化一个值,并将其存入 ThreadLocalMap 中。当访问 ThreadLocal 的 set() 方法时,会将指定的值存入当前线程对应的 ThreadLocalMap 中。 需要注意的是,ThreadLocal 并不能解决共享资源的并发访问问题,它只是提供了一种线程内部的隔离机制。在使用 ThreadLocal 时,需要注意合理地使用,避免出现内存泄漏或者数据不一致的情况。另外,由于 ThreadLocal 使用了线程的 ThreadLocalMap,因此在使用完 ThreadLocal 后,需要手动调用 remove() 方法清理对应的变量副本,以防止内存泄漏。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值