【ProVerif学习笔记】6：握手协议（handshake protocol）建模

最新推荐文章于 2024-07-14 21:25:49 发布
最新推荐文章于 2024-07-14 21:25:49 发布
阅读量1.8k 收藏 11
点赞数 6
分类专栏： # ProVerif 文章标签： ProVerif 形式化 计算机网络 握手协议 协议验证
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/SHU15121856/article/details/116376508
版权

这节先不继续往下看，巩固一下对ProVerif建模握手协议的理解。

握手协议的流程如下：
在这里插入图片描述

ex_handshake.pv（只验证保密性）

手册里在引入security性质之前，握手协议的模型如下：

(* ------------------------对称加密相关------------------------ *)
(* 对称密钥 *)
type key.
(* 对称加密：传入要加密的内容和密钥，返回加密结果 *)
fun senc(bitstring, key): bitstring.
(* 对称解密：用于析构对称加密，传入加密结果senc(m,k)，用同一个密钥k可解密出原始信息m *)
reduc forall m: bitstring, k: key; sdec(senc(m,k),k) = m.


(* ------------------------非对称加密相关------------------------ *)
(* 非对称加密-私钥 *)
type skey.
(* 非对称加密-公钥 *)
type pkey.
(* 从私钥获取公钥：可以用于密钥配对 *)
fun pk(skey): pkey.
(* 非对称加密：传入要加密的内容和公钥，返回加密结果 *)
fun aenc(bitstring, pkey): bitstring.
(* 非对称解密：用于析构非对称加密，传入加密结果aenc(m,pk(sk))，用其私钥sk可解密出原始信息m *)
reduc forall m: bitstring, sk: skey; adec(aenc(m,pk(sk)),sk) = m.


(* ------------------------数字签名相关------------------------ *)
(* 数字签名-私钥 *)
type sskey.
(* 数字签名-公钥 *)
type spkey.
(* 从私钥获取公钥：可以用于密钥配对 *)
fun spk(sskey): spkey.
(* 数字签名：传入要签名的内容和私钥，返回签名结果 *)
fun sign(bitstring, sskey): bitstring.
(* 获取消息：无视签名用的私钥ssk，直接获取其中的消息m *)
reduc forall m: bitstring, ssk: sskey; getmess(sign(m,ssk)) = m.
(* 验证签名后获取消息：使用公钥spk(ssk)方能对使用ssk签名的消息验证，并成功取出m *)
reduc forall m: bitstring, ssk: sskey; checksign(sign(m,ssk),spk(ssk)) = m.


(* ------------------------全局声明相关------------------------ *)
(* 通信信道c，是一个公有的信道 *)
free c:channel.
(* 要传输的保密消息s，由于使用[private]修饰，所以攻击者无法直接获取 *)
free s:bitstring [private].


(* ------------------------查询相关------------------------ *)
(* 查询攻击者能否窃取s，即关于s的保密性 *)
query attacker(s).


(* ------------------------进程相关------------------------ *)
(* 客户端进程A：A公钥、A私钥、B公钥 *)
let clientA(pkA:pkey,skA:skey,pkB:spkey) =
	(* 将A公钥发送到通道c *)
	out(c,pkA);
	(* 从通道c取回B传来的结果x *)
	in(c,x:bitstring);
	(* 用自己的私钥skA对结果x解密得到y *)
	let y = adec(x,skA) in
	(* 用B的公钥pkB对y验证，验证结果需是(pkB, k)，第二项k即是对称密钥 *)
	let (=pkB,k:key) = checksign(y,pkB) in
	(* 使用对称密钥k对消息明文s加密并发送 *)
	out(c,senc(s,k)).

(* 服务器进程B：B公钥、B私钥 *)
let serverB(pkB:spkey,skB:sskey) =
	(* 从通道c取出公钥，是A的公钥 *)
	in(c,pkX:pkey);
	(* 新建一个对称密钥k *)
	new k:key;
	(* 将(pkB,k)用B的私钥skB签名，然后用A的公钥pkX加密，发到通道c *)
	out(c,aenc(sign((pkB,k),skB),pkX));
	(* 从通道c拿到A发来的消息x *)
	in(c,x:bitstring);
	(* 使用对称密钥k解密即可得到消息明文z *)
	let z = sdec(x,k) in
	0.

(* 总的进程 *)
process
	(* A的私钥 *)
	new skA:skey;
	(* B的私钥 *)
	new skB:sskey;
	(* A的公钥，生成后发到通道c上，攻击者可获取 *)
	let pkA = pk(skA) in out(c,pkA);
	(* B的公钥，生成后发到通道c上，攻击者可获取 *)
	let pkB = spk(skB) in out(c,pkB); 
	(* 实际行为是无限个客户端A和无限个服务器B的并发执行 *)
	( (!clientA(pkA,skA,pkB)) | (!serverB(pkB,skB)) )

整体就是两类进程，客户端clientA和服务器serverB。认为一个服务器B的进程实体是可以服务任何一个具体的客户端的，所以在它的macro里只传入了自己签名用的公钥和私钥。而一个客户端A的进程实体只会找一个具体的服务器，所以是在自己的macro里传入了想要服务自己的服务器B的公钥，在这里定死了。

这里希望有无数的进程在并发执行，对客户端和服务器都是做了replication（符号!）然后再并发。

还有要注意的就是之前学习的解构器（destructor） 和模式匹配（pattern matching） 的使用。

解构器本身如果传入的东西不匹配就会解构失败， 解构失败会走let-in-else的else路线，如果else被省略掉（像上面一样）就会把进程直接halt掉，所以一般解构器本身就能检查传过来的东西是不是按期望的合规的。

模式匹配可以和解构器一起用，这样不仅要求解构成功，还需要模式匹配成功才能走let-in-else的in路线，否则一律走else路线。比如

let (=pkB,k:key) = checksign(y,pkB)

这一行，不仅要求y是用pkB对应的私钥skB签名的（这样才能解构成功），而且要求解构后的内容能匹配到一个二元组形式（分别是签名方公钥和签名方提供的对称密钥），还要求二元组的第二项能匹配到一个key类型（对称密钥），二元组的第一项能匹配到公钥pkB上（和自己期望的pkB是相同的，这块只是签名方自己声明自己的身份，其实在密码学上还不够强，比如第二节里学习到可能遭受中间人攻击）。

这个是最原始的握手协议，因为可能遭受中间人攻击，所以验证结果是不通过的：

--------------------------------------------------------------
Verification summary:

Query not attacker(s[]) is false.

--------------------------------------------------------------

ex_handshake_annotated.pv（加入对认证性的验证）

手册里3.2节讲security性质的时候引用了这个case，这里“annotated”意思就是如果要证明authentication（一种security性质，表达认证关系，包括用correspondence断言和injective correspondence断言两种声明），那么是需要用event来标记程序点的：

To reason with correspondence assertions, we annotate processes withevents, which markimportant stages reached by the protocol but do not otherwise affect behavior.

因为correspondence断言就是用来捕获事件先后关系的：

“if an event e has been executed, then event e′ has been previously executed.”

这种标记不会影响进程本身的行为，也不会让攻击者的知识有任何的增加或者减少。添加了事件标记的模型如下：

type key.
fun senc(bitstring, key): bitstring.
reduc forall m: bitstring, k: key; sdec(senc(m,k),k) = m.

type skey.
type pkey.
fun pk(skey): pkey.
fun aenc(bitstring, pkey): bitstring.
reduc forall m: bitstring, sk: skey; adec(aenc(m,pk(sk)),sk) = m.

type sskey.
type spkey.
fun spk(sskey): spkey.
fun sign(bitstring, sskey): bitstring.
reduc forall m: bitstring, ssk: sskey; getmess(sign(m,ssk)) = m.
reduc forall m: bitstring, ssk: sskey; checksign(sign(m,ssk),spk(ssk)) = m.

free c:channel.
free s:bitstring [private].
query attacker(s).

(* 客户端认为自己在使用key对称密钥和服务器进行协议交互 *)
event acceptsClient(key).
(* 服务器认为自己在使用key对称密钥和pkey公钥标识的客户端进行协议交互 *)
event acceptsServer(key,pkey).
(* pkey标识的客户端认为自己使用key和服务器进行协议交互结束 *)
event termClient(key,pkey).
(* 服务器认为自己使用key对称密钥和客户端进行协议交互结束 *)
event termServer(key).

(*
对于每个以对称密钥x和服务器交互结束的客户端y
前面总是存在认定以对称密钥x和客户端y交互的服务器
*)
query x:key,y:pkey; event(termClient(x,y))==>event(acceptsServer(x,y)).
(*
对于每个以对称密钥x交互结束的服务器
前面总是存在一个区别于其它的“以对称密钥x和服务器交互的客户端”
即单射关系
*)
query x:key; inj-event(termServer(x))==>inj-event(acceptsClient(x)).

let clientA(pkA:pkey,skA:skey,pkB:spkey) = 
	out(c,pkA);
	in(c,x:bitstring); 
	let y = adec(x,skA) in
	let (=pkB,k:key) = checksign(y,pkB) in
	(* 客户端解密成功+验证成功后即认为接受了使用密钥k通信 *)
	event acceptsClient(k);
	out(c,senc(s,k));
	(* 客户端运行结束，本次是使用k通信，自己的公钥是pkA *)
	event termClient(k,pkA).

let serverB(pkB:spkey,skB:sskey,pkA:pkey) = 
	in(c,pkX:pkey);
	new k:key;
	(* 服务器收到客户端公钥pkX，并创建了密钥k，即认为接受了使用密钥k和客户端pkX通信 *)
	event acceptsServer(k,pkX);
	out(c,aenc(sign((pkB,k),skB),pkX));
	in(c,x:bitstring);
	let z = sdec(x,k) in
	(* 如果接收到的pkX确实是pkA，即认为服务器使用对称密钥k运行结束 *)
	if pkX = pkA then event termServer(k).

process
	new skA:skey;
	new skB:sskey;
	let pkA = pk(skA) in out(c,pkA);
	let pkB = spk(skB) in out(c,pkB);
	( (!clientA(pkA,skA,pkB)) | (!serverB(pkB,skB,pkA)) )

注意这一版不仅加入了event，而且在serverB的macro中传入了pkA，这是因为termServer本身需要判断自己交互的pkX是pkA。

这一版只是加了认证性质的验证，但是还是没有解决中间人攻击问题。

--------------------------------------------------------------
Verification summary:

Query not attacker(s[]) is false.

Query event(termClient(x_2,y_1)) ==> event(acceptsServer(x_2,y_1)) is false.

Query inj-event(termServer(x_2)) ==> inj-event(acceptsClient(x_2)) is true.

--------------------------------------------------------------

结果第一条表明，对消息s还是不满足的。

结果第二条表明，从B（服务器）到A（客户端）的认证是不满足的，也就是说如果客户端觉得自己和服务器完成了协议流程，不一定真的有这个服务器在和客户端走协议，这个也是因为中间人可以冒充服务器来和客户端通信。

结果第三条表明，从A（客户端）到B（服务器）的认证是满足的，也就是说如果服务器觉得自己走完了协议流程，一定至少有一个客户端是在和自己走协议的。

ex_handshake_annotated_fixed.pv（解决中间人攻击）

这里主要就是像第二节里说的那样，让服务器回传的信息中包含目标客户端的标识（这里是用公钥）来防止中间人攻击发生。

type key.
fun senc(bitstring, key): bitstring.
reduc forall m: bitstring, k: key; sdec(senc(m,k),k) = m.

type skey.
type pkey.
fun pk(skey): pkey.
fun aenc(bitstring, pkey): bitstring.
reduc forall m: bitstring, sk: skey; adec(aenc(m,pk(sk)),sk) = m.

type sskey.
type spkey.
fun spk(sskey): spkey.
fun sign(bitstring, sskey): bitstring.
reduc forall m: bitstring, ssk: sskey; getmess(sign(m,ssk)) = m.
reduc forall m: bitstring, ssk: sskey; checksign(sign(m,ssk),spk(ssk)) = m.

free c:channel.
free s:bitstring [private].
query attacker(s).

event acceptsClient(key).
event acceptsServer(key,pkey).
event termClient(key,pkey).
event termServer(key).

query x:key,y:pkey; event(termClient(x,y))==>event(acceptsServer(x,y)).
query x:key; inj-event(termServer(x))==>inj-event(acceptsClient(x)).

let clientA(pkA:pkey,skA:skey,pkB:spkey) = 
	out(c,pkA);
	in(c,x:bitstring); 
	let y = adec(x,skA) in
	(* 这里检查一下这个包确实是要发给自己pkA的 *)
	let (=pkA,=pkB,k:key) = checksign(y,pkB) in
	event acceptsClient(k);
	out(c,senc(s,k));
	event termClient(k,pkA).

let serverB(pkB:spkey,skB:sskey,pkA:pkey) = 
	in(c,pkX:pkey);
	new k:key; 
	event acceptsServer(k,pkX);
	(* 这里把要通信的客户端标识pkX放进去 *)
	out(c,aenc(sign((pkX,pkB,k),skB),pkX));
	in(c,x:bitstring); 
	let z = sdec(x,k) in
	if pkX = pkA then event termServer(k).

process 
	new skA:skey; 
	new skB:sskey;
	let pkA = pk(skA) in out(c,pkA);
	let pkB = spk(skB) in out(c,pkB);
	( (!clientA(pkA,skA,pkB)) | (!serverB(pkB,skB,pkA)) )

现在三条性质就都能验证通过了：

--------------------------------------------------------------
Verification summary:

Query not attacker(s[]) is true.

Query event(termClient(x_2,y_1)) ==> event(acceptsServer(x_2,y_1)) is true.

Query inj-event(termServer(x_2)) ==> inj-event(acceptsClient(x_2)) is true.

--------------------------------------------------------------
大桔骑士v
关注
  • 6
    点赞
  • 踩
  • 11
    收藏
    觉得还不错? 一键收藏
  • 5
    评论
专栏目录
握手协议(Handshake Protocol)
12-04
压缩包里面包含四个有关握手协议的文件： 1. app_note_zc001.pdf 2. handshake.ppt 3. pipe.doc 4. valid_ready.doc 希望对大家理解握手协议有所帮助！
握手协议（Handshake Protocol）
weixin_30877493的博客
11-21 1674
1、概念 通讯设备之间任何实际应用信息的传送总是伴随着一些控制信息的传递,它们按照既定的通讯协议工作,将应用信息安全、可靠、高效地传送到目的地。握手协议就是在两个设备在通信之前，要互相的认识一下，然后才能互相传送。 在计算机的概念中，握手（Handshaking）预示着硬件或软件确立或维持两个机器或程序在同步中。握手经常需要在两个系统之间的信息或数据的交换。在两台计算机之间的硬件握手信号...
通信协议 | 三次握手、七次握手、四次挥手
最新发布
叫好与叫座虽然不是对立面，但想在同一个作品中达到双重效果很难。
07-14 1082
客户端想要通过 HTTP 请求访问服务端时，需要经过三次握手；通过 HTTPS 访问服务端时，需要额外增加四次握手。TCP 协议需要通过三次握手建立可靠连接。想要建立 HTTPS 安全连接，需要在 TCP 可靠连接基础上使用 TLS 协议。TLS 协议需要四次握手才能建立安全连接。终止 TCP 可靠连接时需要四次挥手。需要注意的是，本文所说的三次握手、七次握手、四次挥手都是基于特定版本的协议，不同版本的协议所需握手次数可能不同。
【ProVerif学习笔记】1：基本使用流程
LauZyHou的笔记
08-11 6680
1 简介 ProVerif可以用来自动分析密码协议的Security性质，功能涵盖对称和非对称加密、数字签名、哈希函数、比特承诺、非交互式零知识证明。ProVerif可以证明可达性(reachability)，对应断言(correspondence assertion)，和可观察的等价性(observational equivalence)。这个能力使得它能对计算机安全领域中的机密性和认证性质进行分析，也可以考虑一些新兴的性质，如隐私性(privacy)、可追溯性(traceability)、可验证性(ve
【ProVerif学习笔记】4：信息安全性质(Security Property)
LauZyHou的笔记
08-13 1939
1 Reachability和Secrecy 证明Reachability是最基本的能力，因为需要知道攻击者能访问到哪些term，而Secrecy就可以根据这个来评估——能访问到的term不满足Secrecy。要测试项MMM在模型中是否满足Secrecy，在主进程前使用： query  attacker(M). \bold{query} \ \ attacker(M). query  attacker(M). 其中MMM是一个最基本的项，即不包含析构器，MMM可以包含
Handshake Protocol
wangyanchao151的专栏
03-11 486
DoIP学习笔记系列：（一）DoIP协议概述
08-12
【DoIP协议概述】 DoIP（Diagnostic over Internet ...这些资源对于理解DoIP协议、学习其实施方法以及了解行业发展趋势具有很高的价值。通过深入研读这些材料，可以全面掌握DoIP协议的原理、应用以及相关的工程实践。
配套学习资料：Java开发 - 尚硅谷JavaWeb学习笔记
06-22
学习笔记请看我写的文章： Java开发 - 尚硅谷JavaWeb学习笔记 - Part1： ...Java开发 - 尚硅谷JavaWeb学习笔记 - Part2： ...Java开发 - 尚硅谷JavaWeb学习笔记 - Part6： Java开发 - 尚硅谷JavaWeb学习笔记 - Part7：
安全：Web安全学习笔记
02-26
6年的web编程生涯，一直没有真正系统的学习web安全知识（认证和授权除外），这个月看了一本《Web安全设计之道》，书中的内容多是从微软官方文档翻译而来，这本书的含金量不高，不过也不能说没有收获，本文简单记录...
modbus协议学习笔记
01-06
学习并理解modbus协议笔记一.简介1.介绍2.协议描述二.关键知识点1.常用功能码寄存器的理解2.发送数据帧单元的理解3.对modbus协议检错（异常相应）的理解对于这个协议标准，还得完全吃透，先了解总的构架，在对其各个...
K210视觉识别模块学习笔记6： 识别苹果-图形化操作函数
06-26
K210视觉识别模块学习笔记6： 识别苹果_图形化操作函数_ 今日学习如何在识别到目标的时候添加图形化操作:(获取坐标、框出目标等) 在识别苹果的基础上 学习与添加 这些操作，获取苹果的坐标，框图等信息
RTSP 协议握手过程
07-19
网络视频RTSP协议握手过程，整理处理方便大家看看，参考参考
【ProVerif学习笔记】3：进程宏和进程书写的语法规则
LauZyHou的笔记
08-12 1936
1 进程宏 进程宏(Process Macros)用来定义子进程，因为在用ProVerif对协议进行建模时，直接一个大的主进程比较混乱，进程宏的形式为： let  R(x1:t1,...,xn:tn)=P. \bold{let} \ \ R(x_1:t_1,...,x_n:t_n)=P. let  R(x1​:t1​,...,xn​:tn​)=P. 其中RRR是宏的名字，PPP是子进程，x1,...,xnx_1,...,x_nx1​,...,xn​是PPP里面的fre
握手协议
sdd220的博客
10-23 2162
握手协议是客户机和服务器用SSL连接通信时使用的第一个子协议，握手协议包括客户机与服务器之间的一系列消息。SSL中最复杂的协议就是握手协议。该协议允许服务器和客户机相互验证，协商加密和MAC算法以及保密密钥，用来保护在SSL记录中发送的数据。握手协议是在应用程序的数据传输之前使用的。　　每个握手协议包含以下3个字段　　（1）Type：表示10种消息类型之一　　（2）Length：表示消息长度字节数
【ProVerif学习笔记】7：基本建模特性
LauZyHou的笔记
05-06 1227
1 constants 常量（constant）可以用参数量为0的函数（fun关键字声明的，在ProVerif里其实应该叫constructor ）来表示，也就是有一个类型名有一个返回值类型（就是常量的类型），也可以直接用const关键字来描绘常量。 const c1, ... , ck : t. 2 data constructors和type conversion 2.1 [data] constructor就是用fun声明的函数，用来对一系列数据做构造。data constructor是一种将构造器
【ProVerif学习笔记】2：协议建模中的声明
LauZyHou的笔记
08-11 2158
ProVerif验证的加密协议并发程序通过公共通道来进行信息较交互，最终实现一些目标。认为攻击者对这样的通道有完全的控制能力，包括阅读、修改、删除和注入消息，也可以解密自己持有密钥的消息（视解密为获取密文的唯一途径，不考虑攻击者用其它方式获取密文，所以如果自己没有解密的密钥就不行）。 1 握手协议 握手协议(Handshake protocol)是有一个客户端A和服务器B，假设每一方都有自己的公私钥对，然后A知道B的公钥pk(skB)，协议的目的是让客户端A能向服务器B分享自己的私密信息s。 协议按照如下的
【ProVerif学习笔记】5：理解验证后的输出
LauZyHou的笔记
08-14 1682
ProVerif的输出比较长，格式如下： 其中[Equations][Equations][Equations]给出了涉及的等式的内部表示。[Process][Process][Process]给出了将所有的进程宏展开之后的进程，在进程里面会看到一些标号为{n}\{n\}{n}的地方，这只是为了方便引用。[Query][Query][Query]部分就是开始评估用户给出的性质查询（对应输入文件中的query），也就是试图证明违反性质的状态是不可达的，然后在[Goal][Goal][Goal]这一行就会显示
SSL 握手协议详解
dellme99的专栏
01-28 3017
SSL 握手协议详解
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值