Internet安全协议与分析Notes
IPSec
通信保护协议
AH
- 通信提供数据源认证、抗抵赖性、数据完整性和反重播保证，但不提供机密性保护
AH传输模式
- 源IP地址、目的IP地址是不能修改的，否则会被检测出来，因此AH在传输模式下和NAT冲突
AH隧道模式
- AH验证的范围也是整个IP包，因此AH和NAT的冲突在隧道模式下也存在
ESP
- 为IP提供机密性、数据源认证、抗重播以及数据完整性等安全服务，但不提供抗抵赖性
- 对IP头部不进行认证，因此不会和NAT冲突
ESP传输模式
ESP隧道模式
密钥交换管理协议IKE
- 安全机制
- 前向安全性：一个密钥被破解不影响其他密钥的安全性
- 数据验证
- DH交换和密钥分发
阶段1
主模式协商
野蛮模式协商
两种模式对比
阶段2
SSL
- 安全机制
- 数据机密性：对称加密
- 身份验证机制：基于证书的数字签名
- 消息完整性：MAC算法
- SSL连接和会话
- 连接是点对点的、暂时的
- 会话是客户端和服务器之间持久的关联
SSL分层结构
- 上层协议
- SSL握手协议：协商加密套件，交换密钥，身份认证
- SSL password变化协议：修改新的加密套件和密钥
- SSL警告协议：当其他过程中出现错误或发送异常时，向对方报告告警信息
- 下层协议
- SSL记录协议：对上层数据分块、压缩、加密、传输
SSL握手协议
阶段1：建立安全能力
- 协商加密套件
阶段2：服务器鉴别与密钥交换
阶段3：客户端鉴别与密钥交换
- 服务器和客户端分别发送自己的证书并交换密钥信息以便进行身份认证
阶段4：完成
- 检验双方是否获得同样的安全参数
SSL记录协议
为每个SSL连接提供：
- 机密性
- 完整性
SSL协议安全性分析
- 鉴别机制：公开密钥机制和数字证书
- 加密机制：混合密码体制
- 完整性机制：定义了共享的、可以用来形成报文鉴别码MAC的密钥
- 抗重放攻击：序列号，用随机数标记握手
SSL脆弱性分析
- 客户端假冒
- 无法提供基于UDP的应用的安全保护
- 不能对抗通信流量分析：SSL只对数据进行保护，数据包的IP头和TCP头暴露在外
- SSL进程存储空间中的主密钥泄露
SET
双重数字签名
- 订单信息OI：客户给商家
- 支付信息PI：客户给银行
SET电子支付流程
-
支付初始化：持卡人选择商品，下订单，选择银行卡
- 初始请求：持卡人发送请求指定交易环境
- 初始应答：商家回复交易环境信息，以及证书等，并附上签名
-
购物请求：
- 持卡人检查商家初始应答发送的签名信息，确保数据完整性
- 持卡人发送PReq
-
商家验证持卡人的身份和授权
- 商家将相关信息发送给支付网关
-
支付网关认证
- 网关将信息发送给银行
-
收单银行处理
-
确保PI和AuthReq的一致性
-
校验持卡人和商家对于订购行为的一致性
-
发送AuthRes给商家
-
-
支付完成
- 通过捕获令牌(Capture Token)完成支付
-
下单回复
SET核心技术
- 公开密钥加密
- 数字签名
- 数字信封：公钥算法加密对称密钥
- 电子安全证书
PGP
- 提供可用于电子邮件和文件存储应用的保密与鉴别服务
PGP数字签名与认证
PGP保密性
- 邮件的存储转发特性不适合用DH算法交换密钥
- 使用公钥算法对每个消息生成一次性会话密钥
PGP保密和认证结合
PGP压缩
- 使用ZIP算法
- 先签名后压缩
- 只需要存储原始报文和签名
- 易于更换压缩算法
PGP密钥环
- 每个结点都有存储密钥的结构
- 私钥环：存储该结点拥有的公/私钥对
- 公钥环：存储该结点拥有的其他所有用户的公钥
PGP信任网
- PGP中没有认证机构，而是由用户互相对对方的公钥进行数字签名
- 确认是否信任
- 通过自己的数字签名
- 通过自己完全信任的人的数字签名
- 通过自己有限信任的多个人的数字签名
Kerberos
- 采用传统加密算法(非公钥算法)
基本概念
- Principle：安全个体，有名字和口令
- KDC：网络服务，提供ticket和临时会话密钥
- Ticket：客户用来向服务器证明身份的票据
- 其大多数信息被服务器的密钥加密
- Authenticator：包含最近产生的信息的记录，需要用到会话密钥
- Credentials：一个Ticket加上秘密的会话密钥
- AS：Authentication Server
- 通过long-term key认证用户
- 授予用户ticket granting ticket和short-term key
- 认证服务
- TGS：Ticket Granting Server
- 通过ticket granting ticket和short-term key认证用户
- 发放service granting ticket给用户以访问其他服务器
- 授权和访问控制服务
Kerberos工作流程
1. 认证服务交换：获得票据许可票据(ticket granting ticket)
2. 票据许可服务交换：获得服务许可票据(service granting ticket)
3. 客户/服务器认证交换：获得服务
Kerberos跨域认证
- 获得本地TGS访问权
- 请求一张远程TGS的票据许可票据
- 向远程TGS请求其域内的服务
Kerberos优缺点
优点
- 密码不在网上传输，不易被窃听，难以猜测
- 单点登录机制，只用输入一次口令
- 票据被盗之后难以使用，因为需要配合认证头来使用
缺点
- 缺乏撤销机制
- 密钥管理复杂
- 跨域认证复杂
- 需要始终同步
- 需要始终在线的AS和TGS
BAN
所用符号
-
A, B, S：泛指参与协议的主体
-
P, Q, R：主体变量
-
X, Y: 公式变量
-
K: 密钥变量
-
Kab, Kbs, Kas: 主体之间的共享密钥
-
Ka, Kb, Ks: 主体的公钥
-
Ka-1, Kb-1, Ks-1: 主体的私钥
-
Na, Nb, Ns：主体各自生成的用于确认新鲜性的随机数Nonce
-
{X}k：用密钥k加密X的结果
-
<X>Y：X和Y的组合
-
P->Q:(X)：P发送消息X给Q
-
bel(P,Q)：主体P相信X
-
sees(P,X)：P接收到X
-
said(P,X)：P发送X
-
cont(P,X)：P拥有对X正确与否的判决权
-
fresh(X)：X是新鲜的
-
skey(P,K,Q)：K是P,Q的共享密钥
-
goodkey(P,K,Q)：K是P,Q共享的良好密钥
-
pubkey(P,K)：K是P的公钥
-
secret(P,X,Q)：X是P和Q的共享秘密
推理规则
消息意义规则
从加密消息所使用密钥以及消息中包含的秘密来推断消息发送者的身份
- 例如对于共享密钥：bel(P,goodkey(P,K,Q)) and sees(P,{X}k) => bel(P,said(Q,X))
随机数验证规则
如果P相信X是新鲜的，并且P相信Q曾经发送过X，那么P相信Q相信X
- bel(P,fresh(X)) and bel(P,said(Q,X)) => bel(P,bel(Q,X))
仲裁规则
如果P相信Q对X是有仲裁权的，并且P相信Q相信X，那么P相信X
- bel(P,cont(Q,X)) and bel(P,bel(Q,X)) => bel(P,X)
信仰规则
-
bel(P,X) and bel(P,Y) => bel(P,(X,Y))
-
bel(P,(X,Y)) => bel(P,X) or bel(P,Y)
-
bel(P,bel(Q,(X,Y))) => bel(P,bel(Q,X)) or bel(P,bel(Q,Y))
接收规则
- 如果P接收到一个消息，那么P也接收到这个消息的一部分
- sees(P,(X,Y)) => sees(P,X)
- sees(P,<X>Y) => sees(P,X)
- 如果P收到加密消息，那么以下三种情况P可以读出消息原文
- bel(P,goodkey(P,K,Q)) and sees(P,{X}K) => sees(P,X)
- bel(P,pubkey(P,K)) and sees(P,{X}K) => sees(P,X)
- bel(P,pubkey(Q,K)) and sees(P,{X}K-1) => sees(P,X)
新鲜规则
如果消息的一部分是新鲜的，则整个消息是新鲜的
- bel(P,fresh(X)) => bel(P,fresh(X,Y))
传递规则
如果P相信Q曾经发送过整个消息，那么P相信Q曾经发送过消息的部分
- bel(P,said(Q,(X,Y))) => bel(P,said(Q,X))