NSE Week 9: IKE and SSL/TLS

IKE (The Internet Key Exchange protocol)

IKE不仅仅只是关于密钥，更多的关于SA (security associations):

1. 协议的格式
2. 加密或者哈希的算法
3. 密钥

IKE十分的灵活，比如提供身份认证，并通过多种pre-shared secrets来实现

IKE又十分复杂，有很多的选项可以配置以及很多的子协议

IKE结合了 ISAKMP 的数据包格式，以及 OAKLEY 的协议，这两个东西都基于 Diffie-hellman protocol

PFS

如果我们已经能安全的交换YA,YB了，为什么还要套在这个Diffie-Hellman里面用呢？ 主要是为了实现PFS，perfect forward secrecy

PFS,perfect forward secrecy

• 为了确保协议做生成的临时key，session key不会因为用来产生这个session key所用到的key被破解了而导致session key也没破戒
• 用来加密传输数据的key不能用作产生其他的key，这样就会产生连带效应，一个key被破解了，其所产生的key也会被破解
• 同样的道理，如果产生当前的key需要通过其他keys来产生，那么那些key也不能用做其他key的产生
• 也就是说一个key被破解了，只会影响用其所加密的数据，其他都不会收到影响

因此在具体实现的时候的一个小技巧就是，每个session key都是随机产生的，并且在session结束之后就销毁，这样就都不会影响了，同时也会给密码分析带来负担。

IKE protocol

IKE可以为通信的双方来建立和维护SA

Typical key establishment protocol: 只有一个阶段，就是双方使用 master keys 来进行通信交换信息

Master keys

1. pre-shared secret (symmetric) keys
2. public encryption key (used only for encryption/decryption), 比如互相知道对方的public key，然后加密之后可以由对方的private key来进行解密
3. public signature key （用来进行验证）

IKE则有两个步骤：

• Phase 1: 通信的双方线协商一个SA，关于使用什么加密或者哈希算法
• Phase 2: Phase 1中产生的SA会继续产生 “child SAs"来进行加密和验证未来的通信

IKE phase 1

IKE的第一个阶段主要的目的是要建立一个安全的channel来给Phase 2进行通信交流

需要用到的概念有：

1. Cookies：用作初期的身份认证，推荐的实现方法是：
   • 通过一些较快的hash，例如MD5，将UDP的IP source/destination address/ports 以及保存在本地的一个 secret value 进行hash
   • 因为存在一个 secret value ，那么通过将自己生成的cookie发送给对方，再由对方发送回来，就可以进行验证，是否是自己曾经发出的内容
2. Identifiers, ID: 用来标识通信的双方的身份，可以是：
   1. IP address
   2. Fully-qualified domain name
   3. Certification
   4. E-mail address
   5. MAC address
3. Authenticators: 用于验证消息的数据

IKE Phase 1 提供两种模式

1. Main mode
   • 通过6条交换的信息来建立 Initiator(I) and Responder(R) 之间的安全channel
   • 通过互相的配置协商来实现
     1. Identify protection
     2. Considerable flexibility
2. Aggressive mode
   • 由于不提供保护因此能够更快的建立
   • 只需要3条信息的交换
   • 没有 提供 Identify protection 只有public-key加密所带来的authentication

根据选用的 authentication 方法的不同，每种模式都拥有4种变化

• Pre-shared key
• Digital signatures
• 2 public-key variants

我们的重点会放在Main mode上

1. I会生成Cookie_I 以及ISA_I (ISAKMP SA)其中包含了提出的提议（加密和哈希算法）
2. R在收到之后，会考虑I提出的proposal然后选择使用什么算法：ISA_R,接着返回自己生成的Cookie

以下就是一个例子，I会提出建议，然后由R来选择，因此ISA_I & ISA_R可能相同也可能不同，这将有R来决定

1. I收到R同意的条约之后，随机选择构建DH所需要的参数 g, p (g is the primitive root of p),
   • X = g^x mod p
   • 接着附上一个nonce，用来防止relay attack，keep freshness
2. R收到I发来的cookie之后，先对自己的C_R进行重新计算并验证
   • 接着计算Y = g^y mod p
   • 最后生成自己nonce N_R 返回给I
3. I收到R的Y之后，就可以用来计算 DH session key了，在此之前还会重新计算并验证自己的cookie C_I
   • 接着会将自己的ID以及 previous data通过约定好的 authenticator 计算好并和ID一起用DH session key进行加密并返回给R
4. R验证了自己的Cookie C_R 之后也会将自己的ID_R以及authentication data用DH session key进行加密后返回给I，I验证了R的ID之后也就完成了phase1

根据不同的authenticator也会有一些变种，但是步骤是不变的

IKE phase 2

IKE phase 2的通信会由之前在phase 1中达成的SA进行保护

IKE phase 2的目的就是利用之前建立的安全的通信，开始交换协商真正需要用在通信中的SAs

phase 2也有两种mode

1. Quick mode
   • 直接创造新的SAs (e.g., for ESP or AH)
2. New group mode
   • 用来修改存在的SAs的参数
   • 不产生新的SAs

我们主要关注Quick mode

如果被要求实现PFS，那么quick mode也会再次实现DH exchange

多个quick mode可以用不进行，并且会使用在phase1中用到过的ID

数据的加密会用到phase 1中的数据，用在phase 2中的新key

• SPI就是用来标识新的SA的 SPI fields

• k就是DH exchange所生成的session key

• 协商建立一个SA

• 生成IPsec key 用作将来ESP or AH 中

我们可以看到，这其实也是一个协商的过程，就是I发起倡议，然后还是由R来决定最终的SA是怎么样的

另一个例子

The second phase of the IKE protocol is done by three message exchanges. For the first and second messages I1 and R1, the initiator I and the responder R exchange IPSec SAs (IP SecSAIand IP SecSAR),nonces NI and NR(for replay attack protection), optional D -H values gI and gR, and hashes of these values and message IDs (to prove liveliness), HashI1 and HashR1.

After the initiator sends one more hash (HashI2) using both NI and NR and the message ID as the third message, both parties will agree on the IPSec symmetric key for use during ESP or AH encapsulation.

为了更好的保护长久的VPN session, IPsec 提供了定期刷新IKE key以及IPSec keys的机制

• IKE key的刷新需要重新跑两个phase
• 但是刷新IPsec只需要跑phase 2即可

SSL/TLS

SSL/TLS是用来保护Transport layer传输层的安全的，通过提供confidentiality and integrity来防止通信被窃听和篡改

目标是实现Confidentiality, integrity，有条件的话也可以实现authentication，通过单（双）向的认证channel来进行安全的通信，由public-key certificate所支持，因为是Transport layer上的安全，因此也可以被应用层的协议所利用，例如HTTP(S), SMTP, IMAP

SSL/TLS实现了两种协议

TLS Handshake protocol

TLS Handshake protocol 通过初始化或者恢复之前的connection然后搭建一个安全的channel来进行通信

1. Server certificate: B -> A: certificate(B, K_B)

Certificate是由 trusted third party 来进行认证的，包含了B的identity以及B的public key

1. client exchange
   • client certificate (option) A -> B: certificate (A, K_A) {PMS}_K_B
   • client key exchange A - > B: {PMS}_K_B
   • certificate verify (option) A-> B:{hash(message)}{K_A}^-1

PMS: pre-master secret是用来生成新的master key M的，M= PRF(PMS, Na, Nb), where PRF is pseudo-random function

Nonce信息可以是在hello信息中被确定的 最重要的就是两条消息就是

• Server certificate: B -> A: certificate(B, K_B)
• client key exchange A - > B: {PMS}_K_B

simplest SSL do not provide authentication of sender’s identity (it has options to prove)

TLS Record Protocol

TLS Record protocol是用来通信交换数据的，主要描述了应用层发出的数据应该如何被压缩，用MAC进行认证以及payload要如何加密

TLS Record Protocol 为每一个TLS connections提供了两种服务

1. Confidentiality
   • 由TLS Handshake protocol 所定义的密钥可以用来对TLS payload 进行加密
2. Message Integrity
   • 由TLS Handshake protocol 所定义的共享密钥（public key）可以用来组成MAC (message authentication code)来验证integrity

TLS connection and TLS session

TLS connection

1. 是一个短时间的概念transient
2. 每一个connection会关联一个TLS session TLS会话
3. connection是P2P的关系
4. TLS connection 本质上是一个session内的安全流 a secure stream within a session

TLS session

1. TLS session是一个长时间的概念，就算connection中断了，但是session依然存在
2. 其表示client and server之间进行安全通信的关系，协议，是一种类似Security association的东西
3. TLS session 由TLS Handshake Protocol所创造，由client and security双发协商达成共识
4. 每一个TLS session中都有很多关于安全的参数，可以同时被很多connection共享