密钥分配问题,你学会了吗?

安全 应用安全
A 和 B 都是 KDC 的登记用户,A 和 B 在 KDC 登记时就已经在 KDC 的服务器上安装了各自和 KDC 进行通信的主密钥(master key) 的 KA 和 KB,下面统称主密钥为密钥。

密钥分配

我们上面所介绍到的很多加密机制和加密算法都是公开的,所以不存在网络安不安全的问题,公开的就意味着不安全,因此对于安全性来说就体现在密钥的安全保护上了,所以密钥管理就成为一个非常重要且不可忽视的问题。密钥管理主要包括密钥的产生和分配、验证以及使用问题。

密钥分配是网络安全中一个很重要的问题,在计算机网络中,密钥应该通过一个安全的链路进行分配。之前早期的互联网多采用网外分配的方式,外网分配就是由信使把密钥分配给相互通信的用户;但是随着用户的增多和流量的增大,这种方式不再适用,因为每次需要更换密钥都需要派信使更换一遍。现在更多采用的是网内分配方式,也即密钥自动分配。

对称密钥的自动分配

我们上面说到了,对称密钥的一种分配方式是设立 密钥分配中心 KDC(Key Distribution Center) ,KDC 是一个权威的密钥分配中心,他能解决密钥数量日趋增大的问题,也能解决共享密钥之间的安全性问题。

KDC 的主要作用就是给需要通信的用户临时分配一个会话密钥,这个会话密钥的生命周期在会话开始时结束,会话结束时失效。

比如下面这个 KDC 的分配示例:

图片图片

A 和 B 都是 KDC 的登记用户,A 和 B 在 KDC 登记时就已经在 KDC 的服务器上安装了各自和 KDC 进行通信的主密钥(master key) 的 KA 和 KB,下面统称主密钥为密钥。

首先,用户 A 向密钥中心 KDC 发送时用明文,来表明自己想要和主机 B 建立通信,明文中包含了 A 和 B 在 KDC 登记的身份(此时 A 是知道 B 的登记信息的)。

KDC 用随机数产生一次一密的会话密钥 KAB 来让 A 和 B 这次会话使用(这个密钥 KAB 就是给通信用户分配的临时密钥),然后向 A 发送回答报文,回答报文用 A 的密钥 KA 加密,除此之外,这个报文中还包含这次会话使用的密钥 KAB 和请 A 转给 B 的一条消息,这条消息用 B 的密钥 KB 加密,因为 A 并没有持有 KB,所以 A 并不知道这条消息的内容。

A 收到这条消息后会把 KB 加密的消息发送给 B,在 B 收到消息后就知道 A 想要和他通信,同时也知道了会话密钥 KAB ,于是 A 和 B 就可以安全的对话了。这就是这个会话密钥 KAB 的作用。

那可能有同学有疑惑了,假如此时还有一个 C 来冒充了 A ,把 A 发给 B 的报文截获,然后伪造成 B 与 C 进行通信呢?

由于 C 并不知道 A 的登记密钥 KA,所以就算截获了报文也不知道 KAB 会话密钥,其次 KDC 还可以在报文中增加时间戳,来防止 C 使用之前截获的报文进行攻击,除此之外 KDC 中的 KA 和 KB 登记信息也要定期更换才行。

目前业界比较出名的密钥分配协议就是 Kerberos V5,它是一种基于 Ticket 的身份验证协议,而且也是 KDC,它已经变得很普及,现在是互联网标准。Kerberos 使用比 DES 更加安全的高级加密 AES 进行加密,下面会介绍 Kerberos V4 的工作原理,V5 和 V4 的原理是一样的, V4 还稍微简单些。

图片图片

这里首先先认识 Kerberos 的两个服务器,一个是鉴别服务器(Authentication Server)AS,一个是票据授予服务器(Ticket-Granting Server)TGS。

  • 鉴别服务器 AS:进行用户信息验证,为客户端提供 Ticket Granting Tickets(TGT)。
  • 票据授予服务器 TGS:验证 TGT 和身份,为客户端提供 Service Tickets。

在上图中,A 是请求服务的客户,B 是被请求的服务器,A 通过 Kerberos 向 B 请求服务,Kerberos 需要通过下面几个步骤鉴别的确是 A 在向 B 请求服务,而不是冒充 A 的冒充者,请求服务后,才向 A 和 B 分配会话使用的密钥。

  1. A 通过明文(包括登记的身份)向鉴别服务器 AS 表明自己的身份。AS 就是 KDC 的一种,它掌握着实体登记的身份和相应的口令。当 A 向 AS 表明身份后,AS 会对 A 进行身份验证,验证正确后才会走到下一步。
  2. AS 验证完成后,AS 会向 A 发送用 A 的对称密钥 KA 加密的报文,这个报文包含 A 和 TGS 通信的会话密钥 KS 以及 AS 要发送给 TGS 的 Ticket 票据,这个 Ticket 是用 TGS 的对称密钥 KTG 加密的。当报文到达 请求者 A 时,A 就会根据口令和适当的算法生成 KA 密钥,密钥 KA 会对 AS 发送过来的报文进行解密(A 并不会保存 KA 密钥),解密过后就提取出会话密钥 KS(这是 A 和 TGS 通信要使用的)以及要转发给 TGS 的 Ticket (这是用 KTG 加密的)。总的来说这一步就是 AS 把消息发送给 A,A 根据口令生成解密密钥 KA,然后解密报文提取 KTG 加密报文的过程。
  3. 此后 A 需要向票据服务器 TGS 发送报文,包括上一步 A 提取的会话密钥 Ks,还有 AS 发给 A 的 KTG 加密报文,还有 A 需要告诉 TGS 通信的目标 B ,还有能预防重放攻击的 Ks 加密的时间戳 T。
  4. TGS 发送两个 Ticket,每一个都包含 A 和 B 通信的会话密钥 KAB。给 A 的 Ticket 用 Ks 加密,发给 B 的票据用 KB 加密。
  5. 然后 A 向 B 转发 TGS 发给 A 的 Ticket,同时发送用会话密钥 KAB 加密的时间戳 T。
  6. B 把时间戳 T + 1 来证实收到了 Ticket,同时这个时间戳也会用 KAB 加密。

在这之后,A 和 B 就可以使用 TGS 给出的会话密钥 KAB 进行对话了。

公钥的分配问题

公钥分配的问题主要谈论的就是公钥分配的权威性问题,如果用户 A 拥有 B 的公钥,就可以实现安全通信,这就好像用户 A 假如拥有攻击者 C 的公钥也就能实现安全通信了,其实不然,这个公钥需要有权威机构认证的,这个权威认证机构就是CA(Certification Authority) ,它由政府出资建立,每个实体都需要有 CA 发来的证书,CA 包含公钥和标识拥有者的信息,证书会由 CA 数字签名,拥有 CA 颁发的证书后才能够实现安全通信。

责任编辑:武晓燕 来源: 程序员cxuan
相关推荐

2022-11-09 07:20:43

调用日志502报错nginx

2024-09-30 09:05:46

Linux网络延迟

2023-06-27 07:21:51

前端开发坑点

2024-02-04 00:00:00

Effect数据组件

2024-01-19 08:25:38

死锁Java通信

2023-01-10 08:43:15

定义DDD架构

2023-07-26 13:11:21

ChatGPT平台工具

2024-01-02 12:05:26

Java并发编程

2023-08-01 12:51:18

WebGPT机器学习模型

2023-06-05 08:36:04

SQL函数RANK()

2024-07-31 08:39:45

Git命令暂存区

2022-07-08 09:27:48

CSSIFC模型

2023-01-30 09:01:54

图表指南图形化

2024-08-06 09:47:57

2024-05-06 00:00:00

InnoDBView隔离

2023-10-10 11:04:11

Rust难点内存

2022-06-16 07:50:35

数据结构链表

2023-01-31 08:02:18

2023-10-06 14:49:21

SentinelHystrixtimeout

2023-05-05 06:54:07

MySQL数据查询
点赞
收藏

51CTO技术栈公众号