来避免“回放攻击”并借助于对称加密算法来保证R的加密传输和解密从而实现身份认证的协议过程。

共享密钥问题与解决方案

我们知道对称加密算法在发送方/接收方使用的是同一共享密钥用该密钥加密同时也需要用该密钥解密。

**因此这里涉及到的一个问题就是发送方和接收方如何实现密钥的共享即两个实体在网上如何建立共享密钥。

**如果这个问题不能得到很好解决的话那么共享密钥在网络环境下实施起来就存在很大障碍和安全隐患。

解决方案

引入密钥分发中心KDC就是以它作为中介实现通信实体之间的共享密钥的分发。

密钥分发中心KDC

接下来我们就看一下作为密钥分发中心是什么样一个形式发挥什么样的作用。

我们仍然假设一个通信场景并以此为基础来介绍KDC在两个实体间通信时的作用机理。

Alice和Bob间通信需要使用共享对称密钥进行加密如何获取彼此的密钥呢

引入KDC一个服务器

每个注册用户很多用户共享其与KDC的秘密密钥。

也就是说每个用户如果需要使用密钥的话都需要在KDC上注册一个密钥该密钥只有用户自己和KDC知道。

Alice在KDC上注册一个只有Alice和KDC知道的密钥KA-KDC。

Bob在KDC上注册一个只有Bob和KDC知道的密钥KB-KDC。

Alice和Bob只知道自己与KDC之间的对称密钥用于分别与KDC进行秘密通信。

Alice在与Bob进行通信时为了把自己的密钥告知Bob就需要借助KDC来完成。

QKDC如何支持Bob和Alice确定用于彼此通信的共享对称密钥呢

Alice利用其与KDC之间共享的密钥KA-KDC将Alice和Bob的身份信息加密得到KA-KDCAB然后发送给KDC。

KDC利用与Alice间的共享密钥对该信息进行解密并且知道Alice期望与Bob进行通信。

为此KDC为Alice和Bob这次通信生成一个随机数R1。

KDC将R1和Alice本身的身份标识利用KDC与Bob之间的密钥KB-KDC进行加密得到KB-KDCA,

R1之后再将其与R1拼接后再次利用KA-KDC进行加密得到KA-KDCR1KB-KDCA,

R1。

将该加密的结果发送给Alice。

Alice收到该加密信息后利用KA-KDC密钥解密得到随机数R1该随机数R1就可以作为这次与Bob之间通信所使用的会话密钥。

对于KB-KDCA,

R1这个加密内容Alice是无法解开的。

因为她本次的目的通信对象是Bob因为在获得这个加密内容后她会转发给Bob。

Bob在收到KB-KDCA,

R1后可以利用他与KDC共享的密钥KB-KDC解密从而得到这个随机数R1。

此时Bob可以获知Alice的身份认证并且这次通信的会话使用的秘密的对称密钥就是R1。

接下里作为Alice和Bob之间就可以为这次的秘密通信使用R1作为会话密钥session

以上就是KDC在Alice和Bob之间通信过程中所起的作用和原理。

实际上可以看出KDC的角色相当于是作为一个大家都可以信任的权威机构每个通信方都需要向其注册申请自己的密钥。

在对称加密中由于需要通信双方共享对称密钥但实际上通信双方本身的密钥是不直接利用网络传输给对方的而是借助于KDC中介生成一个临时的共享密钥。

由这个临时共享密钥来实现通信双发本次会话的对称加密。

公钥认证中心

上面我们介绍了对称密钥在实际应用中需要借助KDC来实现密钥分发的基本原理和过程。

在这一节中我们针对上述对称密钥方法中存在的问题来介绍一种公钥会使用的机制认证中心CA。

在之前介绍的身份认证协议AP5.0中我们介绍了在Alice和Bob间使用对称密钥加密通信时会存在中间人攻击的问题。

事实上使用公开密钥除了存在这种问题外还有一个典型的场景就是比萨恶作剧。

比萨恶作剧

同样以Alice和Bob间的通信为例看看Trudy第三方入侵者可以在通信过程中实施怎样的比萨恶作剧。

Ttudy创建邮件订单Dear

上述邮件订单的意思就是以Bob的名字向Pizza店订购了4个pizza。

当比萨店索要Bob的公钥时Trudy向比萨店发送她自己的公钥但是她声称这是Bob的公钥。

由于没有其他机制来验证该公钥是不是真的属于Bob比萨店只能利用收到的公钥尝试去解密收到的以为是“Bob发送的签名订单。

当然这是能解密的因为这是一对Trudy的私钥和公钥因此基于非对称加密算法比萨店由于用该公钥解开了之前以为是真实Bob的私钥加密的订单所以认定该公钥就是属于Bob的。

事实上我们分析一下无论是之前的中间人攻击还是比萨恶作剧也好问题的发生就在于公钥这样一个系统存在一个主要的问题。

接下来我们详细对该问题进行探讨。

公钥问题

核心问题其实上面在讲比萨恶作剧时也提到了实际上就是当Alice或者比萨店当其获得了Bob的公钥时通过网站e-mail磁盘等她应该如何确定这是真的Bob的公钥而不是另一个第三方的公钥

上面的中间人攻击和比萨恶作剧事实上发生问题的原因都在于第三方使用了假的公钥来欺骗了接收方。

这个问题也就是公钥的主要问题。

如何解决

同样的我们可以借助第三方权威认证机构可信任的认证中心Certification

Authority

可信任的认证中心跟我们上面介绍的密钥分发中心KDC类似它也是一个服务器形式的基础设施它的主要目的是实现将网络中通信的实体与其真正的公钥进行绑定。

因此作为我们在网络通信中要使用公钥的每个人、路由器等都需要在CA上注册其公钥。

每个网络通信实体向CA提供“身份证明”CA利用其自己的私钥对通信实体的公钥进行签名进而创建绑定通信实体及其公钥的证书certificate证书包含了由CA签名的通信实体的公钥—CA声明这是**的公钥

有了证书之后将来任何实体需要获取Bob的公钥时就不会把一个“欺骗性”的密钥当作Bob的密钥因为它会核实这个密钥的证书是否由权威认证颁发的。

就像大学毕业出去找工作用人单位不会只听信你自己说我是***名牌大学毕业的而是会看你的毕业证书因为证书是由教育部权威机构颁发的。

上面的CA颁发证书也是类似的道理。

首先获取Bob的公钥证书从Bob或其他地方。

应用CA的公钥解密证书中签名的公钥从而获得Bob的实际公钥。

在示例中包含这样几部分

序列号认证中心会为每个证书编号是一个唯一的序列号。

证书持有者信息即对哪个实体的证书进行签名的。

包括算法和密钥值。

证书发行者信息证书有效期发行者的数字签名