Reading on Lutong's Homepage

论文笔记| Concurrent Entanglement Routing for Quantum Networks: Model and Designs

Fri, 14 Aug 2020 15:55:59 +0800

Brief

Authors: Shouqian Shi and Chen Qian
University of California
SIGCOMM 2020

量子互联网中的路由问题。现有的量子互联网模型中，一个典型的应用场景就是秘钥分发，也就是两个节点之间通过量子信道来进行秘密共享，这样能够实现信息论上的安全。但是基于量子的秘钥分发通常是基于纠缠或者是单光子的，有一个问题是纠缠对的传输距离短、持续时间短，因此相聚很远的节点之间就很难进行直接的纠缠分发。

现有的量子网络中的做法是使用一个可信中继来进行传输距离的扩展（比如京沪量子干线中有济南和合肥的可信中继），可是这个可信中继的引入使得网络的安全性似乎不那么强了。为了解决这种问题，一个新的被称为 Swapping 的量子纠缠操作被引入。Swapping 是指将两个纠缠对耦合在一起，形成一个长距离纠缠对的操作。这样只需要可信中继和通信双方分别建立量子纠缠对，而后进行一次 Swapping 操作即可实现通信双方的纠缠对的构造；此时，可信中继也无法干预秘钥分发，从而保障了系统的安全。

一个量子互联网场景下，任意两个量子节点之间都可以进行秘钥交换，只需要进行多次 Swapping 操作即可。但是，每一个量子节点的能力是有限的：量子纠缠对的信道数量是有限的、量子比特存储能力是有限的、量子纠缠对的持续时间是有限的。在这种情况下，路由和资源分配就变成了一个问题。怎么样选取中间节点，使得网络的吞吐量最大化呢？

文章将秘钥分发离散称为若干的周期进行，每个周期分为四阶段进行：

网络接收需要进行秘钥分发的通信双方的申请，也就说接收多个 SD 对（Source-Destination）
网络根据拓扑结构和 SD 对进行选路，选择若干个候选路径
网络根据选路情况建立纠缠对（有概率失败）
网络根据局部纠缠对的建立情况，来进行 Swapping 操作，从而构成完整的量子信道建立。

文章提出了两种具体的路由算法，分别是：

Q-PASS，这种算法在四阶段前引入了一个离线阶段，预先计算出了每两个通信双方之间的可能路径，而后在第二阶段进行竞争性地选路，选取优先级最高的若干条路径，之后进行量子纠缠的建立。
Q-CAST，这种路由算法没有离线阶段，每次根据输入的 SD 对来及时的计算可能的路径。而后，使用一个贪婪算法（扩展的迪姐斯特拉算法）进行主要路径和保留路径的选取，选取一条路径后直接分配所需要的资源，尽力而为的建立连接。

作者进行了模拟实验，发现 Q-CAST 相比已有算法有更好的吞吐量、鲁棒性和扩展性。

论文笔记| Come as You Are: Helping Unmodified Clients Bypass Censorship with Server-side Evasion

Thu, 13 Aug 2020 10:57:28 +0800

Authors: Kevin Bock, George Hughey, Louis-Henri Merinno et. al.
conference: SIGCOMM 2020

这篇文章主要讲着这么一件事情，大部分的对抗审查的方案都需要在客户端做文章，但是这也会有一些问题：比如客户端运行一个代理程序可能不安全、代理程序不够通用、大部分用户对于审查是无感知的 …

那么可不可以只在服务器一端通过对 TCP 报文的修改整合来实现绕过审查呢？文章利用 Geneva 这样一个基于遗传算法的流量分析工具来寻找只在服务端对流量进行修改来绕过审查的方案并且发现了一系列这样的绕过的方案。文章说自己的主要贡献是发现了有服务端发起绕过也是可以的。

根据文章的模型，大部分的审查都是 Man on the middle，也就是审查者可以观察和分析通信双方的所有流量，同时可以在连接中插入 RST 等报文来干扰连接。更加强的攻击是 Man in the middle, 也就是审查者直接位于通信链路的中间位置，可以直接阻断连接双方（通常有巨大的延迟影响？）。在 MotM 的情况下，就有很多客户端可以绕过手段了。

在不同的上层应用和不同的审查机制下，这些绕过方案可能会有一些不同。举个客户端绕过的例子，比如通过客户端和服务器发起一个 TCP 连接的头两个报文是 SYN 和 ACK+SYN 报文。此时，客户端构造一个精心设计的 RST 报文。这个报文的 TTL 只能到达审查处而无法到达服务器端。这样，审查认为这个链接被终止了，但是实际上服务器并没有收到 RST 报文。这样就建立了连接。再举一个服务器发起绕过的方案：服务器在收到客户端发起的 SYN 报文后，分别单独地发送 ACK 报文和 SYN 报文。由审查过滤 ACK 报文后， SYN 报文继续和客户端重新建立三次握手。

文章进行了大量的实验。他们针对不同的防火墙（四个国家）以及不同应用（DNS over TCP、HTTP、HTTPS、FTP）等场景下，企图使用 Geneva 来寻找绕过的方案，并最终给出了绕过的方法。文章还对结果进行了分析，给出了兼容性测试以及对审查防火墙本身进行了一些讨论。

（作者补充：这个团队的博客上分析了近期对于 ESNI 的封锁，同时也给出了针对 ESNI 封锁的绕过办法。）

论文笔记| NDSS 2020 的几篇论文通读

Mon, 16 Mar 2020 15:44:37 +0800

SYMTCP: Eluding Stateful Deep Packet Inspection with Automated Discrepancy Discovery

作者： Zhongjie Wang
NDSS 2020

TCP等有状态的网络协议的实现需要使用状态机模型。但是由于文档使用自然语言描述，导致不同的网络协议实现的状态机之间会有差别。深度包检测也需要使用类似的状态机。通过利用状态机之间的差异，可以实现数据包非预期的被过滤或者放行。

文章形式化的构建了上述的操作，并符号执行的方法来自动发掘一个linux网络协议栈和特定DPI之间的状态机差异。最终实现了对于 Zeek, Snort 或者GFW的绕过。

Let’s Revoke: Scalable Global Certificate Revocation

Trevor Smith et al.
NDSS 2020

提供了一种高效、隐私、可扩展的证书撤销和查询机制。使用一个 CRV 数组来表示特定CA特定截止日期下的所有证书撤销信息。每一个证书有一个RID（CA、过期时间、统一过期时间下的递增撤销号RN）例如：RID = Let’s Encrypt : March 1, 2018 : 24561 。当撤销的时候，CRV的对应 RN的位置1。更新CRV时候，可以使用AND和OR进行增量更新、或者使用NEW操作来全量更新CRV列表。

好处是：

过期之后的CRV可以直接丢弃
时间窗口较小（1day）
网络流量较少、本地存储较小、具有较小的计算消耗
具有隐私性、不保留特定证书信息
具有可审计性等

Post-Quantum Authentication in TLS 1.3: A Performance Study

Post-Quantum Authentication in TLS 1.3: A Performance Study
作者 Dimitrios Sikeridis
NDSS 2020

文章主要将目前NIST文档中的一些候选的PQ算法结合到 TLSv1.3 中，并分析其安全性、性能等。

论文笔记| On Using Application-Layer Middlebox Protocols for Peeking Behind NAT Gateways

Sun, 15 Mar 2020 21:26:28 +0800

Teemu Rytilahti et al.
Ruhr University Bochum
NDSS 2020

背景

网络扫描是一种互联网上的普遍攻击手段。由于 NAT 协议的使用，使得很多设备无法被扫描到。但是许多设备需要使用端对端协议，因此使用了各种NAT穿透手段。这些代理手段安全性不足可能导致攻击的发生。

Contribution

建立不同的方法扫描和分析网络请求。
分析持久性NAT传统协议及其不足：UPnP IGD and NAT-PMP/PCP
分许临时性NAT穿透协议及其不足：Socks以及HTTP代理

NAT 穿透协议分析

UPNP

首先通过互联网发送构造的SSDP消息找到暴露在公网中的接入点。
通过接入点获取端口映射信息
也可以通过接口建立新的端口转发关系来绕过 NAT

目前发生已有攻击的迹象，并构造蜜罐来明确攻击途径。

NAT-PMP AND PCP

NAT-PMP 提供了查询网关外部地址、建立新映射的功能。PCP是其继任者，提供了IPv6和外部映射的功能。但是这个协议不提供直接查询已有端口映射的接口。

尽管发现了部分服务被暴露在了公网，但是大部分都提示无认证、并无法进行下一步攻击。

Proxy 分析

文章的第二个工作点非常明朗，就是HTTP/SOCKS代理有没有配置漏洞，导致可以代理到本地的服务。发现 3% 的开放代理中有 23% 存在此漏洞。

论文笔记| Encrypted DNS --Privacy-A Traffic Analysis Perspective

Sat, 14 Mar 2020 15:36:35 +0800

Authors: Sandra Siby et al.
From: NDSS 2020

1.Introduction

文章考察了当今世界对抗DNS攻击的两种主要方法DOH、DOT。介绍这两种方法在real world 中存在问题。

这两个方法TLS/HTTPS封装的方式，提供DNS记录的加密和完整性。保护通过传输层复用和padding的方式来对抗流量分析。

文章实现了如下工作：

实现了通过流量分析来监控浏览行为
可以实现对于环境的自适应
使用 EDNS0 混淆时，unless EDNS0 padding overhead is large, current padding strategies cannot completely prevent our attack

2.Threat Model

攻击者位于client 和 DNS resolver直接，而不在 client 和 server 之间。证明了即便是如此，也可以做到非常可靠的分析，并且比分析HTTPS流量成本更低：

所需进行攻击的报文较少（on average 124 times）
DoH resolver 目前比较少

3.DNS Based fingerpoint

不变的特征：浏览网页的时候，由于资源或者子页面加载的特征或者先后顺序也会反映在 DNS 查询上。变化的特征：网页的变动、资源的变动、Local DNS、DNS Cache 、CDN等

4.Feature and Algorithm

特征：选取了包的方向和大小作为参数，扩展成单个报文和报文对的向量。发现时间特征并不显著。算法：使用了一百个trees的随机森林算法（RF）

5.Conclusion

具有较高识别准确率：close world 能够较精确识别特定网站；open world 能够识别是否是黑名单上
与其他方案比较：在DNS识别上比其他方案准确率高且训练集小；也能识别HTTPS流量。
训练集较小：由于DNS流量相比HTTPS流量更加稳定
鲁棒性：具有一定的对抗时间、空间、客户端和服务器平台的鲁棒性
对抗EDNS(0)扩展：EDNS-128,EDNS-468 具有较小的 overhead 但是其有较大概率被识别。使用DoT或者Tor则由较大overhead但是较为混淆。
论证了如何构建审查机制：通过文章方案，在使用的数据集中，使用整个DoH流量的前 15%的报文就能使得识别概率达到50%。 7. 较为严格的审查策略可能造成较大误伤，反之亦然

论文笔记| CA 体系中的 Certificate Transparency

Fri, 06 Dec 2019 19:47:04 +0800

什么是 CT ？

在原始的 KPI/CA 体系中，并没有 CT 这样一个角色的存在。而引入这样一个角色，是为了解决 CA 体系在结构上的弊端。

这篇博文讲述了 CT 的基本体系结构，而后简要介绍 CSS 2019 的论文 Certificate Transparency in the Wild: Exploring the Reliability of Monitors。

现有 CA 体系的弊端

当前的 CA 体系，提供了一个用于确认公钥与实体对应关系的手段，是现代非对称密码学的基石之一。但是这个体系的核心信任模型就是要相信“可信第三份”，也就是 CA 。换句话说，整个 TLS 体系要求整个互联网信任几百个 CA 实体可靠诚实的工作，这个条件看起来似乎是有一点好笑的。

当发生了一些安全事件，暴露出 CA 往往不能改按照我们预想的情况可靠的工作的时候，这个问题就变得非常明显了。但是 CA 机制是非常封闭的，原始 PKI/CA 体系不能提供任何对于 CA 的审计手段。唯一的监督措施就是这样一条基本原理 ———— 当 CA 犯错的时候，由根 CA 撤销其证书。这个惩罚其实是非常弱的，而且有一种事后诸葛的感觉。

如果一个 CA 由于主观或者客观的因素，签发了一张非法证书。那么攻击者可以使用这样的一张证书来假冒受害网站，或者发起中间人攻击，从而破坏了 TLS 体系身份认证的安全性。

所以 CT （Certificate Transparency）的机制就是用于给 CA 体系补充这个审计的过程。

CT 体系的工作原理

CT 体系的工作原理是：当 CA 需要颁发一个证书的时候，需要将证书发送给 CT；由CT签名后，生成一个 SCT （签名证书时间戳）；CA 得到 SCT 后将证书颁发。与此同时，CT 将证书信息记录在一个公开日志 log 上，以备用户和使用者查询。

QUIC专题| Quic Protocal Part 1：基本结构

Tue, 19 Nov 2019 00:00:00 +0000

Quic 协议——第一部分

一、简介

QUIC 协议最初是由 Google 开发并使用在 Chrome 中的新一代 web 协议。之后被 IETF 的 QUICWG 工作组接管，目前发布的版本为 24th。

QUIC 协议是一个包含传输层、安全垫片和应用层的复合协议族。QUIC 协议基于 UDP 协议，在此之上实现了可控有序到达、拥塞控制、流量控制等传输层功能；提供了对于包和连接的完整性和机密性功能；提供了 http3.0 等的应用层功能。

二、QUIC 协议基本结构

QUIC 协议是基于 UDP 的协议，其最基本包的格式为 UDP 报文（package），由 package number 来提供有序到达的功能。在一个 QUIC 报文之中，有多个独立功能的 QUIC 帧（frame），每一个帧都用于实现不同的功能，比如传输帧，错误帧，校验帧等。

在报文和帧的基础之上，QUIC 协议构成了一个双方共享连接状态的有状态协议，因此有连接（connection）的概念。通过 connection id来区别不同的 QUIC 连接。 QUIC 连接具有完整的生命周期（建立、撤销、关闭等）

在连接之上，QUIC协议使用了连接复用的概率，在连接之上建立了多个有状态的流（steam），每一个流也是具有独立状态的。每一个流对应了上层的不同应用，比如 id 为 1 的流用于负责握手协议和密码学参数的协商。

+---------+---------+---------+
| stream1 | stream2 | stream3 |
+---------+---------+---------+
| connection |
+-----------------------------+
| packages (frame1 || frame2 )|
+-----------------------------+

三、 QUIC 协议版本协商

QUIC 报文头部的内容主要有协议的版本（version）和connection id 等。其中 version 协商是建立 QUIC 协议首先需要做的工作。

QUIC专题| Quic Protocal Part 2：连接和流

Tue, 19 Nov 2019 00:00:00 +0000

QUIC Protocal —— Part 2

QUIC 流和连接是有状态的，因此发送方和接收方需要建立对应的状态机，也需要完成一定的握手和关闭动作。

一、QUIC Stream

1.1 流的基本结构

QUIC 流是有状态的。每一个 QUIC 连接中可以复用多个流，每个流有一个独立的 stream id 来标记不同的流。其中 stream id 的最低有效位决定流是客户端建立的还是服务器建立的；次低有效位决定了流是单向的还是双向的。

同一个连接中，stream id 不允许复用。

QUIC 的流就像 TCP 协议一样，上层应用对于流的感知是连续的消息流，没有明显的边界（也就是说上层应用对于报文要有自然分割，否则可能发生粘包）。

1.2 流的帧表示

一个 stream 可能使用如下一些 QUIC 帧（frame）：

STREAM 帧：发送数据
RST_STREAM: 接收流，收到对应 ACK 后关闭对应流。
STREAM_DATA_BLOCK: 阻塞
FIN: 发送结束
MAX_STREAM_DATA: 提示数据大小
STOP_SENDING: 接收方提示不再接收数据，后续可能被忽略

二、流量控制

QUIC 协议使用了基于 stream 和基于 connection 的两层流量控制。

2.1 基于字节的流量控制

接收方可以发送 MAX_STREAM_DATA 或者 MAX_DATA 来提示流和连接的字节最大偏移量。当达到发送最大字节的时候，发送方发送 STREAM_DATA_BLOCK 或 DATA_BLOCK 来提示阻塞。

2.2 基于stream 数量的流量控制

通信双方可以通过 MAX_STREAMS 帧来告知对端最大可以建立的 stream 的个数，以此来进行流量控制。

QUIC专题| Quic Protocal Part 3：包和帧

Tue, 19 Nov 2019 00:00:00 +0000

Quic 协议——第三部分

QUIC 的通信采用了包（Package）和帧（frame）的双重结构。

一个 UDP 包中可能包含有多个 QUIC 包，其中每一个 QUIC 包中可以包含多个帧（frame）。

一个 UDP 报文包的 QUIC 包必须是同一个连接中的多个 QUIC 数据包。

帧是完整某项功能的基本单位，比如之前所述的 STREAM 帧用于发送流数据、CONNECTION_CLOSE 帧用于关闭连接等。

一、 QUIC Package

如前所述，QUIC 协议有长报文头和短报文头两种，在建立连接过程中使用的长报文头。这包括如下一些报文：初始数据包、0RTT数据包、握手数据包、重试数据包等。

除了版本协商数据包和重试数据包之外，其他数据包均使用 AEAD 算法提供机密性、完整性和身份认证保护。

包的 Package Number 是 0-2^62-1 的序列号，在实际报文中，可能被重新映射到 1-4字节。

Package Number 被分配为：初始空间、握手空间和应用空间三个部分。每次都从对应空间的 0 号开始，而后以此递增。

当 2^62 -1 时，必须关闭连接。

1.1 长包头数据包

长包头中包括了版本号，Package Number，源和目的 Connection ID 以及子类型，有如下几种类型：

1.1.1 版本协商包 Version Negotation Package

当客户端版本不被接收的时候，由服务器端发送。

1.1.2 初始数据包 Initial Package

它携带客户端和服务器发送的第一个CRYPTO帧来执行密钥交换，并携带两个方向的ACK。

1.1.3 0RTT 数据包

0-RTT数据包使用类型值为0x1的长报头，后跟长度和数据包号字段。第一个字节包含保留和数据包号长度位。它用于在握手完成之前，将“早期”数据从客户端传送到服务器，作为第一次传输的一部分。作为TLS握手的一部分，服务器可以接受或拒绝此早期数据。

QUIC专题| Quic Protocal Part 4：出错校验、拥塞控制

Tue, 19 Nov 2019 00:00:00 +0000

Quic 协议——第四部分

QUIC 协议的出错校验

由于 QUIC 协议基于不可靠的 UDP 协议，因此需要实现校验、纠错和拥塞控制机制。(流量控制机制已经大致在前面说过了)。

如前所述，其 Package Number 被划分成了三个子空间，每个空间指示了报文的安全级别。

一、ACK 特性

QUIC 报文可以延迟 ACK 但必须在最大确认延时（max_ack_delay, mostly 25ms) 给出ACK 确认。

无序分组、有拥塞控制分组以及密码报文应当尽快确认。RTT 估值可参加 RFC6298。

二、丢失检验

2.1 基于ACK的丢失检验

使用了类似TCP Early Retransit，Quick Retransit，SACK，FACK，RACK 等机制。

当收到后续包ACK但没有收到当前包ACK时重传。
达到数据包阈值（Packet Threshold）或者时间阈值（Time Threshold）

2.2 加密超时重传

对于加密数据需要使用更灵活的机制来进行丢失检验

2.3 探测超时（Probe Timeout)

探测超时（PTO）在ack引出数据处于传输状态但在预期的时间段内未收到确认时触发探测数据包。

当发送数据包超过 PTO 时间后，发送探测数据包。

当PTO计时器到期时，新的或先前发送的数据可能无法发送，并且数据包可能仍在发送中。如果数据包在发送中，可以阻止发送方未来发送新数据。在这些条件下，发件方应该将仍在发送中的任何数据包标记为丢失。如果发送方希望保证仍在运行中的数据包送达，它可以发送一个ack-eliciting数据包并重新设置PTO定时器。

当接收到新确认一个或多个分组的ACK帧时，就可以确认传输中的分组的已经送达或丢失。

三、拥塞控制

QUIC的拥塞控制基于TCP NewReno（RFC6582）。 NewReno是基于拥塞窗口的拥塞控制。 NewReno中的拥塞避免使用加法增加乘法减少（AIMD）的方法将每个确认的拥塞窗口增加一个最大数据包大小.当检测到丢失时， NewReno减半拥塞窗口并将慢启动阈值设置为新的拥堵窗口。

此外 QUIC 支持显示拥塞控制 ECN (参加 transport 草案中的 ACK 帧)。

QUIC专题| Quic Protocal Part 5：TLS 1.3 in QUIC

Tue, 19 Nov 2019 00:00:00 +0000

Quic 协议——第五部分

谷歌的 QUIC 协议中使用了自己的安全握手协议。而后 IETF 将 TLS 1.3 引入 QUIC 协议，并作为安全握手协议使用。

一、TLS 1.3 协议简介

TLS 是一个分层协议，包括下层的记录协议和上层的握手协议、告警协议和应用数据。

!! QUIC 不支持 TLS 的密码变更协议

TLS 1.3 提供了支持 1-RTT 的完整验证流程和 0-RTT 的快速回复机制。 TLS 报文有 0RTT 和 1RTT 两种安全级别。前者使用上次连接过程中建立的 psk。后者使用 DH 秘钥交换等派生出 master key 后派生加密。

 客户端 服务端

 客户端请求
 (0-RTT 应用数据) -------->
 服务端请求
 {加密扩展}
 {完结的}
 <-------- [应用程序数据]
 {完结的} -------->

 [应用程序数据] <-------> [应用程序数据]

 () 受早期数据(0-RTT)键保护的指示消息
 {} 使用握手密钥保护的指示消息
 [] 使用应用程序数据保护的指示消息(1-RTT)键

二、 QUIC 协议中 TLS 概述

QUIC 协议中不再使用 TLS 协议的记录协议，而是直接由 QUIC 协议提供消息传递。
TLS 协议中的告警协议和握手协议直接作为 QUIC 的一个 STREAM 来完成。
QUIC 协议不兼容 TLS 协议的密码变更协议
QUIC 协议直接使用 TLS 协议所派生的秘钥对整个连接进行保护，而不再使用 TLS 的应用数据协议

+--------------+--------------+ +-------------+
| TLS | TLS | | QUIC |
| handshake | alert | | application |
+--------------+--------------+-+-------------+
| QUIC Transport |
+---------------------------------------------+
| QUIC Data Package Protect |
+---------------------------------------------+

三、TLS 交互流程（个人理解）

QUIC 使用 CRYPTO 帧将 TLS 握手协议打包并发送，在传输过程中保证可靠达到。
QUIC 将 TLS 告警协议中的错误值取出后封装在 CONNECTION_CLOSE 帧中。
QUIC 将 HelloRetryRequest 用于纠错时，取出并改为发送 Retry_Package。
QUIC 使用短头部中的 KEY_PHASE 来代替TLS中的KeyUpdate 消息来进行秘钥变更。

握手协议流程（作者理解）：

论文阅读| Safely Exporting Keys from Secure Channels: On the Security of EAP-TLS and TLS Key Exporters

Sun, 22 Sep 2019 15:23:49 +0800

Safely Exporting Keys from Secure Channels: On the Security of EAP-TLS and TLS Key Exporters

Christina Brzuska, Håkon Jacobsen, and Douglas Stebila

Define: ACCE

ACCE protocal: authenticated and confidential channel establishment (ACCE)

Examples: TLS,SSH,QUIC(TLS-like)

理论上已经证明了这些协议所派生出来的主秘钥是 indistinguishability 的。

Define: TLS-like

TLS-like protocal:

双方产生随机数
协商出一个 master key
Session key 由 master key 派生

Define: AKE

AKE: authenticated key exchange

指在认证的信道上进行秘钥交换和派生的协议。

主要工作

主要是两方面工作：

理论证明了在最广泛情形下 ACCE 安全的信道上，使用 master key 派生进行秘钥交换是 indistinguishability 的且可以独立于master key。以往的工作是在给定的（如TLS1.2基础之上的安全证明）
给出了在通用 TLS-like 的协议上的最一般 AKE 协议的形式。
具体应用与 EAP-TLS 协议

论文笔记：The use of TLS in Censorship Circumvention

Wed, 18 Sep 2019 15:56:49 +0800

The use of TLS in Censorship Circumvention

Network and Distributed Systems Security (NDSS) Symposium 2019
Sergey Frolov, Eric Wustrow.
University of Colorado Boulder

Abstract

collect and analyze TLS Client Hello messages
analyze existing censorship circumvention projects that use
develop a library, uTLS, that allows developers to easily mimic arbitrary TLS handshakes of popular implementations

真实访问TLS的特征

Client Hello
Server Hello
Connection-specific information
BroserStack

获取了诸如 chrome 等ssl客户端的tls指纹。

Client Hello fingerpoints

99.96% of all connections use one of top 5000 Client Hello fingerprints, and one of top 1310 Server Hello fingerprints.

论文笔记| maTLS: How to Make TLS middlebox-aware?

Wed, 18 Sep 2019 15:55:49 +0800

maTLS: How to Make TLS middlebox-aware?

Hyunwoo Lee, Zach Smith, Junghwan Lim†, Gyeongjae Choi, Selin Chun, Taejoong Chung, Ted “Taekyoung” Kwon
Network and Distributed Systems Security (NDSS) Symposium 2019

Current Solution

MITM:

Client: fake root certificate
Server: CDNs request server private keys.

=> Increased risks in MITM attack
=> How to work honestly?
 1. encryption-based
 2. TEE-based
 3. TLS extension-based

SplitTLS:

authentication: client can not authenticate the intend server
Confidentiality: weak ciphersuite
Integrity：Not behaved Middlebox

maTLS:

论文阅读| Hybrid key exchange in TLS 1.3 or SSH

Tue, 17 Sep 2019 15:55:49 +0800

Hybrid key exchange in TLS 1.3 or SSH

Draft-stebila-tls-hybrid-design-01

Motivation of hybrid key exchange

tranditional algorithms: have risks in face of quantum computers and cryptanalytic advances
next-generation algorithms: have less confidence in security (due to less studies)

Prototyping post-quantum and hybrid key exchange and authentication in TLS and SSH

hybrid key exchange and hybrid signatures

1.Key Exchange is listed above. 2.Authentication：

extension signature_algorithms_cert and signatur_algorithms

both algorithms should sign the same message.

RFC 8446| Transport Layer Security 1.3

Wed, 11 Sep 2019 21:04:49 +0800

Transport Layer Security 1.3 (RFC 8446)

1. Major differences from TLS 1.2

All legacy algorithms have been deprecated. TLS 1.3 uses AEAD instead.
0-RTT (zero round-trip time) mode was added.
All public-key based key exchange mechanisms now provide forward secrecy.
Simplified the handshake state machine (removed ChangeCipherSpec in most common cases).
Cryptographic improvements.
- KDF: HMAC-based KDF
- RSA padding
- DSA removed
- Ephemeral Diffie-Hellman removed
Session resumption has beed replaced by a simple PSK exchange

AEAD: Authenticated Encryption with Associated Data

论文笔记| Proof-of-Stake Sidechains

Mon, 15 Jul 2019 00:00:00 +0000

Brief

Authors: Peter Gazˇi,Aggelos Kiayias and Dionysis Zindros
conference: S&P2019

系统定义区块链中的 side 链的概率，1️以提高区块链的伸缩性和冗余。证明其非常适合使用POS作为共识机制。并将其实现和推广到多个区块链系统中去。

使用 sidechain 可以解决数据拷贝、扩容、升级区块链协议等。

形式化定义了什么是sidechain。以及如何将一个账单中的信息转换成另一个账单。定义了其安全性。

其中用到了一个聚合签名算法 ATMS AD-HOC THRESHOLD MULTISIGNATURES 是一种基于门限的聚合签名算法。

论文笔记| Redactable Blockchain or Rewriting history in Bitcoin and friends

Fri, 12 Jul 2019 00:00:00 +0000

brief

这篇文章主要引入了 Chameleon Hash 函数。这个函数引入了一对公私钥。使用公钥和消息来产生hash函数。如果不知道私钥，则很难碰撞，但是如果知道私钥，就很容易进行碰撞。

应用于区块链中，则开始产生这样一对秘钥，公钥共享，私钥按照秘密共享的机制使得监督组的部分节点拥有部分私钥。当需要恢复的时候，使用多方安全计算的算法，恢复出私钥，对数据修改后，维持区块链的性质。

论文笔记| Redactable Blockchain in the Permissionless Setting

Wed, 10 Jul 2019 00:00:00 +0000

Brief

Author：Dominic Deuber, Bernardo Magri and Sri Aravinda Krishnan Thyagarajan
IEEE S&P 2019

Introductoin

一种基于共识机制的协议，用于解决区块链中非法信息进行预警和和可审计的操作，要求可以很好的兼容当前的 bitcoin。

由于区块类的写入是不可撤回的、在写入前又无法审计，所以对于没有访问控制的区块链来说很难做到过滤和预警。

通过投票，多数同意来实现一个 editable 的区块。

感觉就是有协议的硬分叉。读完 intro 后个人感觉可能有诸多问题

大致协议

对要修改的区块，通过某一个策略函数 P 来决定是否通过，有 accept reject 和vote 三种结果。如果最终接受修改，则由全体成员执行修改的过程。如果投票，则经过多轮投票过程后决定结果

如果要对之前某一个区块修改，则保留其原始数据，并对对其进行修改。此时需要对于验证区块和区块链的算法进行一定修改。

实现和评估

最后在bitcoin 上加以实现，而后对安全性和性能进行了评估和分析。

论文笔记| Towards Practical Differentially Private Convex Optimization

Wed, 10 Jul 2019 00:00:00 +0000

Brief

Roger Iyengar Carnegie Mellon University
Om Thakkar Boston University
Joseph P. Near University of California, Berkeley
Abhradeep Thakurta University of California, Santa Cruz
Dawn Song University of California, Berkeley
Lun Wang Peking University

将差分隐私用于凸优化问题中，并处理实际数据集合。文中给出了一个新的训练算法。

论文笔记| True2F: Backdoor-resistant authentication tokens

Tue, 09 Jul 2019 00:00:00 +0000

Brief

author: Emma Dauterman, Henry Corrigan-Gibbs, David Mazières, Dan Boneh, Dominic Rizzo
From: Stanford and Google

Introduction

双因子认证是目前对抗弱密码等恶意攻击的有效手段。其中一种是使用 U2F 硬件认证。但是使用硬件也可能给系统带来新的安全隐患（后门等）。

由于 U2F 在分发过程中需要在服务器中记录 seed，一旦攻击装获取seed就可以恢复公私钥，进而破坏系统安全性。

使用主秘钥和会话秘钥分离也可能发生cache和 swap 攻击等。

U2F 认证过程

U2F 双因子认证设计三个对象：U2F 硬件、浏览器和可靠服务器。

协议要求

防止恶意的token
防止 compromised browser
Protect against token fingerprinting.
对服务器端透明
不改变硬件条件

密码学技术

1. 数字签名

Sig.KeyGen() → (sk, pk). Output a secret signing key sk and a public verification key pk.
Sig.Sign(sk, m) → σ. Output a signature σ on the message m ∈ M using the secret key sk.
Sig.Verify(pk, m, σ) → {0, 1}. Output “1” iff σ is a valid signature on message m under public key pk.

2. Verifiable random function (VRF)

VRF.KeyGen() → (skVRF, pkVRF). Output a secret key and a public key.
VRF.Eval(skVRF, id) → (y, π). Take as input the secret key skVRF, and an input id ∈ I, and output a value y ∈ Z∗q along with a proof π.
VRF.Verify(pkVRF, id, y, π) → {0, 1}. Take as input the public ∗ keypkVRF,apurportedinput-outputpair(id,y)∈I×Zq,and a proof π. Return “1” iff π is a valid proof that (id, y) is an input-output pair.

3. New tool: Verifiable identity families (VIFs)

作者在 VRF 的基础上加以修改，成为 VIFs

论文笔记| Why Does Your Data Leak? Uncovering the Data Leakage in Cloud from Mobile Apps

Tue, 09 Jul 2019 00:00:00 +0000

Brief

author: Chaoshun Zuo, Zhiqiang Lin, Yinqian Zhang
IEEE S&P 2019

Introduction

系统评估移动终端使用云存储时候的数据泄露
编写程序自动化完成评估
对各种软件进行评估，给出风险报告

Background

为什么要使用 Cloud API？

减少成本，无需自己搭建后端或租用服务器，无需考虑鲁棒性和伸缩性。

Cloud API 的两种秘钥

app key：有限权限，用于访问公开数据并可以隔离资源，防止在用户app中。
root key：完整的访问权限，用于开发和管理

系统分析

秘钥误用，将两种秘钥混用
访问控制配置错误

自动化分析框架

方法：根据 API 的句柄、输入输出参数来判断。

包括：Cloud API identification、String Value identification 和 Vulnerability Identification。

评估

对大量程序进行了分析，分析结果略

论文笔记| Resident Evil: Understanding Residential IP Proxy as a Dark Service

Mon, 08 Jul 2019 00:00:00 +0000

Brief

Meeting: S&P 2019
Authors: Xianghang Mi, Xuan Feng, Xiaojing Liao, Baojun Liu, XiaoFeng Wang, Feng Qian, Zhou Li, Sumayah Alrwais, Limin Sun, Ying Liu

Background

分布式反射拒绝服务攻击体现了一种利用新型的家用IP代理的攻击方式。

Residential IP Proxy as a Service (RPaaS) 指代了控制了大量家用终端（自愿加入）的提供代理网络的服务。一些公司提供这样的服务。这种服务可以用于 DoS，爬虫，恶意破坏 SEO 等非法攻击。

Conclusions

这种网络分布在 238 个国家，52905 个独立IP。其中 95% 是家庭设备。
发现大量设备并非自愿加入网络。即使是部分设备也是妥协的结果
正在运行在代理网络之上的有 67 个程序，其中 50 个可能是恶意的程序。
只有 9.36% 的终端检测到了这种恶意流量，更有部分安全检测主机是 RPaaS 的一员。
代理商可能使用其他代理商的网络（多级零售），有些代理商没有背景审查并接受比特币。
鉴别了后台网关。这些网关部分被检测到而已并被屏蔽。

Method and Dataset

这些网络通过 http/https 等方式发起请求。

一个实验用的客户端发起某一个域名的请求。这些域名中包括了时间戳，uuid等信息。
一个dns服务器，用于由网络中的host查询dns时候，记录发送方的ip等信息，并返回接收器的ip
一个接收器，用于接收最终的请求。

为了对流量进行伪装。作者使用了多个位于不同地域的服务器。并对流量使用 aes128 加密。

论文笔记| YODA: Enabling computationally intensive contracts on blockchains with Byzantine and Selfish nodes

Tue, 14 May 2019 17:20:14 +0800

YODA: Enabling computationally intensive contracts on blockchains with Byzantine and Selfish nodes

Sourav Das, Vinay Joseph Ribeiro and Abhijeet Anand
Network and Distributed Systems Security (NDSS) Symposium 2019

Introduction

传统公开链的结构并不适合用于大批量的计算场景（比如深度学习和零知识证明）。主要有如下几个原因：

每一个合约的执行需要缴纳手续费。计算量大意味着昂贵的手续费。
每个验证计算需要花费大量的时间，节点可能会选择跳过验证，以快速开始下一个区块的计算，导致安全性下降

有两种一直的改进方法，但都有缺点：

将重度计算过程分散成多步骤，发在多个区块中
离线的执行智能合约

文章实现了一种离线 CIC 的执行策略，能在公开链上实现有效的重度计算协约的执行。方案允许低于 50% 的节点是拜占庭的，剩下的节点都是 quesi-honest 的。

Threat Model

考虑两种节点:

Byzantine Node 受到恶意节点控制，可能会随意添加、删除数据，可能会不正确的执行协议
Quesi-Honest node 基本可信的节点。如实完成协议。但是如果有可能的话，就引入已有的计算量，以减轻自己的计算负担。

方案选取了一部分 Execution Set 的节点集合，由这些节点来进行 CIC 计算。Yoda 使用一种叫做 MultI-Round Adaptive Consensus using Likelihood Estimation (MIRACLE) 的共识机制来保证计算的可靠性。

We achieve this by making the digest dependent on a set of pseudo-randomly chosen intermediate states of a CIC execution.

论文笔记| Sajin Sasy, Sergey Gorbunov, Christopher W. Fletcher. ZeroTrace: Oblivious Memory Primitives from Intel SGX.

Tue, 14 May 2019 17:15:53 +0800

Sajin Sasy, Sergey Gorbunov, Christopher W. Fletcher. ZeroTrace: Oblivious Memory Primitives from Intel SGX. Network and Distributed Systems Security (NDSS) Symposium 2018

这篇工作主要是结合了密码学和可信硬件，设计和实现了一个 Oblivious Memory Primitives 系统，并进行了性能分析。这篇工作与之前的一篇工作较为相似。

这个系统主要是为了解决计算外包中的隐私保护问题。文中指出传统密码学的手段 overhead 极大且容易有信息泄漏，而完全使用 sgx 也有很多问题。比如代码需要修改带来 trade-off，此外 sgx 的 io 性能较弱。

文中主要贡献是设计一种通用的库，来加密和混淆用户数据。并提供了读取和写入的操作，而后在此基础之上实现了多种数据结构（如 list 等）。具体细节不提。最后给出了性能评估。

论文笔记| Understanding Open Ports in Android Applications: Discovery, Diagnosis, and Security Assessment

Sun, 07 Apr 2019 09:16:29 +0800

Understanding Open Ports in Android Applications: Discovery, Diagnosis, and Security Assessment

作者：Daoyuan Wu, Debin Gao, Rocky K. C. Chang, En He, Eric K. T. Cheng, and Robert H. Deng
收录会议： Network and Distributed Systems Security (NDSS) Symposium 2019

一、摘要

文章主要完成了如下几件事：

对 136 个国家的三千多 Android 设备进行测量。对流行应用和 Built-in 应用进行测量。
对这些数据进行聚合和诊断。
完成了三项安全评估：
- vulnerability analysis revealing five vulnerability patterns in open ports of popular apps
- inter-device connectivity measurement in 224 cellular networks and 2,181 WiFi networks through crowdsourced network scans
- experimental demonstration of effective denial-of-service attacks against mobile open ports

之前已有的工作是发现了移动设备也有开放的端口，以及对特定应用程序使用开放端口的测试（截屏软件、文件分享软件等），但是这些工作只在局部给出了结论，而缺少对于 Open Ports in Android Application 这一个问题的宏观结果。

论文笔记| Giving State to the Stateless: Augmenting Trustworthy Computation with Ledgers

Thu, 28 Mar 2019 11:53:11 +0800

Giving State to the Stateless: Augmenting Trustworthy Computation with Ledgers

Gabriel Kaptchuk, Matthew Green, Ian Miers

Network and Distributed Systems Security (NDSS) Symposium 2019

一、Introduction

该篇文章做了一次尝试，将可信计算平台（如 Intel SGX, ARM TrustZone 等）与区块链（如 BTC, ETH) 结合,期望实现无状态的可信计算。背景如下：

中心化和去中心化网络已经广泛使用，去中心化网络已被证明可以有更长的寿命和更高的可靠性。
有状态的可信计算环境可能会被攻击（需要外部存储非易失数据、以及监控网络流量等）
可信计算环境的硬件资源有限，特别是非易失存储资源的有限。

解决办法：将有状态的可信计算环境（TEE）变更为无状态的TEE。使用类似传统 http 的模式提供计算服务。同时引入分布式账单（Ledger)来记录状态。文章给出了一个Host、TEE 和 Ledger 之间的三方协议，来实现该方案。

对于通常的服务，可以用如下公式形式化描述：P是给定程序，对于输入Ii，当前状态Si和随机代价ri，产生确定输出Oi和新的状态Si+1。

$$ P(I_i,S_i,r_i) \rightarrow O_i,S_i+1 $$

文章对上述模型做了一下修正，以提高安全性：

Attempt 1: 加密程序状态，无法抵御重放攻击
Attempt 2: 使用 Ledger 存储状态信息，也无法抵御回放攻击
Attempt 3: 使用 Ledger 绑定程序的输入。通过向 Ledger 中提交输入，可以解决上述攻击。
Attempt 4: 随机化。为了防止恶意Host 复制程序执行，采用伪随机数发生器，产生随机代价？？？
Extension 1: 减少 Ledger 带宽 …
Extension 2: 增加公共输入输出
Extension 3: 指定程序

二、模型

文章给出模型的三个参与者：

论文笔记| Measurement and Analysis of Hajime, a Peer-to-peer IoT Botnet

Tue, 26 Mar 2019 15:04:11 +0800

Measurement and Analysis of Hajime, a Peer-to-peer IoT Botnet

Stephen Herwig, Katura Harvey, George Hughey, Richard Roberts, Dave Levin

Network and Distrubuted Systems Security(NDSS) Symposium 2019

这篇文章主要介绍了作者近距离的观察了一个基于 P2P 协议的物联网僵尸网络。该网络目前没有发动过攻击的记录。

文章指出，该网络与其他僵尸网络的有一下显著特征：

并非传统中心化 command-and-control（C&C）网络，而是分布式的。
对于多种物联网芯片架构有着广泛的支持：mips、arm等

文章中说：该网络的卓越之处不在于其已经发生的攻击，而在于其让研究人员深刻的认识到了物联网设备的脆弱性。

论文中主要有如下发现：

物联网特征使得僵尸网络的规模变得很大（超过 95000 活跃机器）
各种 CPU 架构都容易遭受攻击。但是架构的分布与国家有明显相关性（美国感染设备大部分是 arm5 架构，而巴西则主要是 mips 设备。
设备的平均在线时间大约是 5 小时，其暗示物联网设备会经常性重启和重新感染。
物联网僵尸网络传播速度极快。

历程

论文观察到了僵尸网络的多次更新，这些更新常常伴随着新的漏洞的利用，导致大量新设备的感染。僵尸网络通过 uTP 协议对更新进行广播，每次更新后，可以观测程序更新迅速在网络中传播。

其他特性

论文观察了僵尸网络大小变化、感染设备寿命、地理位置分布、设备架构、攻击频率等性质。

有趣的是，文中指出中国广泛存在多个设备公用一个IP（暗示 nat 的使用），而巴西则同一个设备分配了多个 IP 地址。IP地址分配不均匀非常显著！

结论

Hajime 作为新的超大物联网僵尸网络，其规模已经 incredibly（豆豆口气）的大，地理分布广泛，且高可靠。研究该僵尸网络有助于观察互联网的各种特征。

论文笔记| Countering Malicious Processes with Process-DNS Association.

Tue, 26 Mar 2019 12:03:49 +0800

Countering Malicious Processes with Process-DNS Association.

Suphannee Sivakorn, Kangkook Jee, Yixin Sun, Lauri Korts-Pa¨r, Zhichun Li, Cristian Lumezanu, Zhenyu Wu, Lu-An Tang, Ding Li.

Ndss 2019

这篇论文主要讲了如何在企业服务器上设置 DNS 监控器来监控所有进程级别的DNS查询，通过地理位置、IP、查询时间、whois 等信息来辨别恶意进程。文章中实现了 PDNS 的模型来监控进程 DNS 查询，而后由机器学习网络和传统方式结合来标示恶意进程，实现了较高的准确率和较低的假阳性和假阴性率。可能有一个问题在于其中获取了所有 DNS 查询的domain 、频率、IP 等信息，并发送给服务器，可能导致隐私的泄露。这里是一个可以改进的地方。

Background

传统基于 dns 的查询只能区分到机器级别存在有风险的dns查询
目前大量恶意进程使用类似 twitter, github 等正常网站的服务来隐藏其恶意性，给传统 dns 检测机制带来挑战。

Archtecture

PDNS 通过多种路径获取 Hosts 上的 DNS 查询记录。

客户机上 dns 查询情况及其他信息（IP 、domain、location 以及进程名、加载的动态链接库、查询频率、主机名、软件发布者签名及证书等信息）
网络上对于 DNS 链路的捕捉
Dns 服务器上的查询情况（记录的创建时间、生存时间、TTL、nameserver、域名、IP和域名的位置信息、whois信息等）

这些数据发送给 PDNS 服务器用于训练模型和预测。

论文笔记| OBLIVIATE:A Data Oblivious File System for Intel SGX

Tue, 26 Mar 2019 12:03:49 +0800

OBLIVIATE:A Data Oblivious File System for Intel SGX

Adil Ahmad, Kyungtae Kim, Muhammad Ihsanulhaq Sarfaraz, Byoungyoung Lee.

Ndss 2018

这篇主要讲了使用 SGX 技术实现了一个可用于web服务的混淆文件系统，用于在不可信服务器上提供隐私数据的 Web 服务。主要是用来对抗包括page failed等侧信道攻击。该方案亮点在于结合了 SGX 和 ORAM 算法来混淆文件读取的偏移量等信息，使用 cmov 条件转移指令来混淆读取内存内容。但是性能上有一定损失。

为了应对三种 Side-Channel Attacks：

Syscall Snooping Attacks: SGX 调用 ocall 过程中，向内核泄漏信息。
Page Fault Attacks: 当 EPC 页面第一次加载时，触发 Page Fault Attacks，可能泄漏信息。
Cache Based Attacks：各级缓存中泄漏信息。

方案： SGX 和 ORAM 算法结合，来混淆对文件系统读取时的偏离量。Path ORAM 算法简介：

采用完全二叉树结构。叶子节点数等于真实节点数。灰色标记的 abcd 节点为真实数据节点，efg为dummy 节点（随机填充）。另外有一张 Position map 表（加密存放于 SGX 中，指向真实节点位置。