蚊章汇 - IPSEC
type: channel
link: https://linuxcn.bwsl.wang/tag/IPSEC/
items: netdev 第一天：IPsec！
items: 实例论证：NSA在安全标准中植入后门

netdev 第一天：IPsec！
type: item
date: 2018-08-16T06:54:38+08:00
description: 嗨！和去年一样，今年我又参加了 netdev 会议。（这里是我上一年所做的笔记）。在今天的会议中，我学到了很多有关 IPsec 的知识，所以下面我将介绍它们！其中 Sowmini Varadhan 和 Paul Wouters 做了一场关于 IPsec 的专题研讨会。本文中的错误 100% 都是我的错 :)。什么是 IPsec？IPsec 是一个用来加密 IP 包的协议。某些 VPN 已经是通过使用 IPsec 来实现的。直到今天我才真正意识到 VPN 使用了不只一种协议，原来我以为 VPN 只是一个通用术语，指的是“你的数据包将被加密，然后通过另一台服务器去发送“。VPN 可以使用一系列不同的协议（OpenVPN、PPTP、SSTP、IPsec 等）以不同的方式来实现。为什么 IPsec 和其他的 VPN 协议如此不同呢？（或者说，为什么在本次 netdev 会议会有 IPsec 的教程，而不是其他的协议呢？）我的理解是有 2 点使得它如此不同：它是一个 IETF 标准，例如可以在文档 RFC 6071 等中查到（你知道 IETF 是制定 RFC 标准的组织吗？我也是直到今天才知道的！）。它在 Linux 内核中被实现了（所以这才是为什么本次 netdev 会议中有关于它的教程，因为 netdev 是一个跟 Linux 内核网络有关的会议 :)）。IPsec 是如何工作的？假如说你的笔记本正使用 IPsec 来加密数据包并通过另一台设备来发送它们，那这是怎么工作的呢？对于 IPsec 来说，它有 2 个部分：一个是用户空间部分，另一个是内核空间部分。IPsec 的用户空间部分负责密钥的交换，使用名为 IKE （ 网络密钥传输 internet key exchange ）的协议。总的来说，当你打开一个 VPN 连接的时候，你需要与 VPN 服务器通信，并且和它协商使用一个密钥来进行加密。IPsec 的内核部分负责数据包的实际加密工作 —— 一旦使用 IKE 生成了一个密钥，IPsec 的用户空间部分便会告诉内核使用哪个密钥来进行加密。然后内核便会使用该密钥来加密数据包！安全策略以及安全关联（LCTT 译注：security association 我翻译为安全关联， 参考自 https://zh.wikipedia.org/wiki/%E5%AE%89%E5%85%A8%E9%97%9C%E8%81%AF ）IPSec 的内核部分有两个数据库：安全策略数据库（SPD）和安全关联数据库（SAD）。安全策略数据库包含 IP 范围和用于该范围的数据包需要执行的操作（对其执行 IPsec、丢弃数据包、让数据包通过）。对于这点我有点迷糊，因为针对不同 IP 范围的数据包所采取的规则已经在路由表（sudo ip route list）中使用过，但显然你也可以设定 IPsec 规则，但它们位于不同的地方！而在我眼中，安全关联数据库存放有用于各种不同 IP 的加密密钥。查看这些数据库的方式却是非常不直观的，需要使用一个名为 ip xfrm 的命令，至于 xfrm 是什么意思呢？我也不知道！（LCTT 译注：我在 https://www.allacronyms.com/XFMR/Transformer 上查到 xfmr 是 Transformer 的简写，又根据 man7 上的简介， 我认为这个说法可信。）# security policy database $ sudo ip xfrm policy $ sudo ip x p # security association database $ sudo ip xfrm state $ sudo ip x s 为什么 IPsec 被实现在 Linux 内核中而 TLS 没有？对于 TLS 和 IPsec 来说，当打开一个连接时，它们都需要做密钥交换（使用 Diffie-Hellman 或者其他算法）。基于某些可能很明显但我现在还没有理解（？？）的原因，在内核中人们并不想做密钥的交换。IPsec 更容易在内核实现的原因是使用 IPsec 你可以更少频率地协商密钥的交换（对于每个你想通过 VPN 来连接的 IP 只需要一次），并且 IPsec 会话存活得更长。所以对于用户空间来说，使用 IPsec 来做密钥交换、密钥的获取和将密钥传递给内核将更容易，内核得到密钥后将使用该密钥来处理每个 IP 数据包。而对于 TLS 来说，则存在一些问题：a. 当你每打开一个 TLS 连接时，每次你都要做新的密钥交换，并且 TLS 连接存活时间较短。 b. 当你需要开始做加密时，使用 IPsec 没有一个自然的协议边界，你只需要加密给定 IP 范围内的每个 IP 包即可，但如果使用 TLS，你需要查看 TCP 流…

实例论证：NSA在安全标准中植入后门
type: item
date: 2013-11-07T06:33:00+08:00
description: 前不久我写到NSA可能在安全标准中植入后门。今天，我们谈一谈NSA被指责在标准中植入后门的两个案例，然后通过它们来区分两种后门之间的不同。第一个案例是关于NIST标准，SP 800-90A，该标准详细说明了一种伪随机数生成器（PseudoRandom Generator 以下简称PRG）。一个RPG可以通过计算得到一小组不可预料的随机比特，并进而“延展”得到大量的随机比特数。在密码学中，PRG作为大多数密钥的源头，是必需的。因此，如果你能“破解”某些人的PRG，你就能预测其使用的密钥，进而击溃其整个加密算法。NIST标准中提供了一些核心算法供PRG选择。其中一个算法使用了一种叫做椭圆曲线的数学结构，在这里我并不打算展开介绍这个数学概念。总之，这个算法使用了两个“公开参数”P和Q，它们均在标准中有指定的值，因此说它们是公开的。密码学家相信，如果P和Q是随机的，PRG就是安全的。但是2006年，两个独立密码学家指出，通过某种方法选定P和Q后，它们之间就具有了某种特殊的关系。一个“局外人”可能并不知道这种特殊关系的存在，但是如果你知道了描述P和Q之间关系的“密钥”，就可以轻松击溃PRG的安全体系。知道了这一点，会发现很多事实突然变得有趣起来。首先，NSA看起来十分执意要将这种算法写入标准，即使它的运行效率很低；其次，NSA在标准中指定了P和Q的建议取值范围；第三，NSA并未解释这些给定的取值范围是如何得出的。怎么样，是不是有点儿意思？不仅如此，现在已经可以通过一些已公开的步骤，得出新的随机的P和Q，也就是说，以上三种问题都可以得到解决，但是NSA并没有这么做。值得注意的是，（也许是为了辟谣），前不久（9月10日），NIST重新开放了SP 800-90A的公开评论。第二个案例是由John Gilmore提出的，他在IPSEC标准中发现了问题。IPSEC被视为安全技术的一块基石，能够为因特网中的个人IP数据包提供完整可靠的加密。一个成功广泛部署的IPSEC协议可以大大强化因特网安全，为多种网络通信提供加密保护。John说，NSA及其代理部门始终在降低该标准的安全水平与执行效率，同时却不断提高其复杂程度和安全方面的实现难度。尽管John还没有掌握NSA植入后门的确凿证据，但是他发现，NSA的确在不断削弱该标准的效力，事实上，IPSEC已经没有人们想象中的那样安全可靠。上述案例向我们展示了两种不同类型的后门。第一个关于PRG的案例中，我们怀疑NSA尝试建立一个只有它能使用的后门，因为只有它知道关联P和Q的密钥。第二个关于IPSEC的案例中，NSA不断削弱用户的安全防护能力，这样它就能更轻易地访问你的数据，但同时其他所有人都具有了这样的机会。可以确定的是，一个私有后门很可能无法一直“私有”。如果真有这样一个magic密钥，能让NSA窥探所有人的秘密，那这把钥匙很可能会被滥用或泄露到外界。因此，NSA私有后门和公开后门之间的界限并不明显。但是，看起来这两种后门之间还是引起了不同的政策辩论。前者使得NSA能秘密地轻易访问每个人的数据，后者则赋予了每个人这种访问权限，后者的影响力要更加严重。同时，我们应该看到一个后门是如何创造出来的。在PRG的案例中，需要获得制定标准的专家们通过，NSA才能使其加密过程中那微小的缺陷“蒙混过关”。在IPSEC的案例中，则貌似需要在标准的整个制定过程中不断协调公关活动才有机会制造那小小的缺陷，在这个过程中，即使没有人发现某种模式，也应该能注意到某些单个步骤，（但是却没有）。也许有人会怀疑，这些案例真的是NSA有意而为之，还是只是空穴来风。对此，我们并不敢保证。但是只要NSA一直拥有参与制定安全标准的许可权限，我们就有必要，对他们所参与制定的任何标准保持怀疑。via: https://freedom-to-tinker.com/blog/felten/on-security-backdoors/本文由 LCTT 原创翻译，Linux中国 荣誉推出译者：Mr小眼儿 校对：Caroline