《SecCourse-06安全基础》由会员分享，可在线阅读，更多相关《SecCourse-06安全基础（75页珍藏版）》请在金锄头文库上搜索。
1、网络与信息安全 安全基础 (三)潘爱民，北京大学计算机研究所http:/ Computing EnvironmentLocal Computing EnvironmentEnclave BoundariesVia TSPsNetworks NONCE R - I: KE; NONCE I - R: IDI; AUTH (加密传输) R - I: IDR; AUTH (加密传输)前两条消息商定策略接下来两条消息交换密钥资料最后两条消息认证Diffie-Hellman Exchangeu用于phase 1IKE中的密钥交换Aggressive Modeu是ISAKMP的Aggressive Exc
2、hange的一 个实例 I - R: SA; KE; NONCE; IDI R - I: SA; KE; NONCE; IDR; AUTH I - R: AUTH (加密传输)前两条消息商定策略，交换Diffie-Hellman公 开的值，以及必要的辅助资料，和个人标识第二条消息也认证应答者第三条消息认证发起者u用于phase 1IKE Phase 1中的认证方案uIKE Phase 1 Authenticated With SignaturesuPhase 1 Authenticated With Public Key EncryptionuPhase 1 Authenticated Wit
3、h a Pre- Shared KeyIKE中的密钥交换Quick Modeu在ISAKMP中没有对应的交换类型 I - R: SA; NONCE; IDI, IDR, KE; HASH(1) R - I: SA; NONCE; IDI, IDR, KE; HASH(2) I - R: HASH(3) 以上消息都是加密传输u如果PFS不需要的话，则可以不传KEu只用于第二阶段IKE中的密钥交换New Group Modeu在ISAKMP中没有对应的交换类型 I - R: SA; HASH(1) R - I: SA; HASH(2) 以上消息都是加密传输u用于第一阶段之后IPSec和IKE小结
4、uIPSec在网络层上提供安全服务定义了两个协议AH和ESPuIKE提供了密钥交换功能利用ISAKMP提供的框架、以及Oakley和SKEME的密 钥交换协议的优点u通过SA把两部分连接起来u已经发展成为Internet标准u一些困难IPSec太复杂协议复杂性，导致很难达到真正的安全性管理和配置复杂，使得安全性下降实现上的兼容性攻击：DOS，网络层之下的协议、之上的协议的弱点还在进一步完善IPSec实现u一些网络设备厂商比如CISCO等u各种操作系统例如Linux、各种UNIX版本uIPv6实现u一些VPN软件包uWindows 2000和XP下的IPSecu文章http:/ Kerberos
5、包与L2TP结合起来提供安全的VPN远程访问不能与NAT协同工作仍然面临一些攻击：DOS，其他层上协议的攻击u对比FreeBSD的实现： http:/www.freebsd.org/doc/en_US.ISO8859- 1/books/handbook/ipsec.htmlWindows 2000和XP下的IPSec管理工具uIPSec Security Policies snap-in for the MMC (secpol.msc)uIPSecmon.exe回顾：公钥技术u公钥技术建立在非对称密码算法基础上公钥和私钥对服务：保密性和认证回顾：数字签名u两种数字签名方案密钥对的用法u用于加密
6、的密钥对用公钥加密 用私钥解密用私钥签名 用公钥验证u用于签名的密钥对PKI之动机u公钥技术如何提供数字签名功能如何实现不可否认服务公钥和身份如何建立联系为什么要相信这是某个人的公钥公钥如何管理u方案：引入证书(certificate)通过证书把公钥和身份关联起来密钥生命周期密钥产生证书签发Bob密钥使用Bob证书检验密钥过期密钥更新PKI(Public Key Infrastructure)u定义：用公钥原理和技术实施和提供安全服务的具有普适性 的安全基础设施u一个完整的PKI应该包括认证机构(CA)证书库证书注销密钥备份和恢复自动密钥更新密钥历史档案交叉认证支持不可否认时间戳客户端软件PK
7、I提供的基本服务u认证采用数字签名技术，签名作用于相应的数据之上被认证的数据 数据源认证服务用户发送的远程请求 身份认证服务远程设备生成的challenge信息 身份认证u完整性PKI采用了两种技术数字签名：既可以是实体认证，也可以是数据完整性MAC(消息认证码)：如DES-CBC-MAC或者HMAC-MD5u保密性用公钥分发随机密钥，然后用随机密钥对数据加密u不可否认发送方的不可否认 数字签名接受方的不可否认 收条 + 数字签名PKI的应用考虑u在提供前面四项服务的同时，还必须考虑性能尽量少用公钥加解密操作，在实用中，往往结合对称密码技 术，避免对大量数据作加解密操作除非需要数据来源认证才使
8、用签名技术，否则就使用MAC 或者HMAC实现数据完整性检验在线和离线模型签名的验证可以在离线情况下完成用公钥实现保密性也可以在离线情况下完成离线模式的问题：无法获得最新的证书注销信息证书中所支持算法的通用性在提供实际的服务之前，必须协商到一致的算法个体命名如何命名一个安全个体，取决于CA的命名登记管理工作PKI基本组件uRA(Registration Authority)把用户的身份和它的密钥绑定起来建立 信任关系uCA(Certificate Authority)发证u证书库/目录保存证书，供公开访问证书的注销机制u由于各种原因，证书需要被注销比如，私钥泄漏、密钥更换、用户变化uPKI中注
9、销的方法CA维护一个CRL(Certificate Revocation List)u基于Web的CRL服务检查CRL的URL应该内嵌在用户的证书中可以提供安全途径(SSL)访问URL返回注销状态信息其他的用法由浏览器决定PKI中的证书u证书(certificate)，有时候简称为certuPKI适用于异构环境中，所以证书的格式 在所使用的范围内必须统一u证书是一个机构颁发给一个安全个体的证 明，所以证书的权威性取决于该机构的权 威性u一个证书中，最重要的信息是个体名字、 个体的公钥、机构的签名、算法和用途u签名证书和加密证书分开u最常用的证书格式为X.509 v3X.509证书格式u版本1、
10、2、3u序列号在CA内部唯一u签名算法标识符指该证书中的签名算法u签发人名字CA的名字u有效时间起始和终止时间u个体名字X.509证书格式(续)u个体的公钥信息算法参数密钥u签发人唯一标识符u个体唯一标识符u扩展域u签名X.509证书示意图CA(Certificate Authority)u职责接受用户的请求(由RA负责对用户的身份信息进行验证)用自己的私钥签发证书提供证书查询接受证书注销请求提供证书注销表u各个组件和功能示意图健壮的数据 库系统无缝的目录接口CA硬件管理和运 行平台 安全的审计密钥PKI密钥备份和恢复进一步授权 (# 可定制)授权恢 复密钥RA最终用户PKI加密密钥的历史新的
11、签名密钥对 和证书Password?Help!CA密钥更新u保证透明性用于验证的CA公钥用于签名的CA私钥CA最终用户Sep 1998Oct 1998Nov 1998Dec 1998Jan 1999Feb 1999Mar 1999Apr 1999May 1999Jun 1999Jul1999Aug 1999CA密钥历史保证对于 最终用户和其他的PKI 是透明的新的CA签名 密钥对CA信任关系u当一个安全个体看到另一个安全个体出示的证书 时，他是否信任此证书？信任难以度量，总是与风险联系在一起u可信CA如果一个个体假设CA能够建立并维持一个准确的“个 体-公钥属性”之间的绑定，则他可以信任该CA
12、，该 CA为可信CAu信任模型基于层次结构的信任模型交叉认证以用户为中心的信任模型CA层次结构u对于一个运行CA的大型权威机构而言，签发证 书的工作不能仅仅由一个CA来完成u它可以建立一个CA层次结构根CA中间CACA层次结构的建立u根CA具有一个自签名的证书u根CA依次对它下面的CA进行签名u层次结构中叶子节点上的CA用于对安全个体进 行签名u对于个体而言，它需要信任根CA，中间的CA可 以不必关心(透明的)；同时它的证书是由底层的 CA签发的u在CA的机构中，要维护这棵树在每个节点CA上，需要保存两种cert (1) Forward Certificates: 其他CA发给它的certs
13、(2) Reverse Certificates: 它发给其他CA的certs层次结构CA中证书的验证u假设个体A看到B的一个证书uB的证书中含有签发该证书的CA的信息u沿着层次树往上找，可以构成一条证书链，直到 根证书u验证过程：沿相反的方向，从根证书开始，依次往下验证每一个 证书中的签名。其中，根证书是自签名的，用它自己 的公钥进行验证一直到验证B的证书中的签名如果所有的签名验证都通过，则A可以确定所有的证 书都是正确的，如果他信任根CA，则他可以相信B的 证书和公钥u问题：证书链如何获得？证书链的验证示例交叉认证u两个不同的CA层次结构之间可以建立信任关系单向交叉认证一个CA可以承认另一
14、个CA在一定名字空间范围内的所有被 授权签发的证书双向交叉认证u交叉认证可以分为域内交叉认证(同一个层次结构内部)域间交叉认证(不同的层次结构之间)u交叉认证的约束名字约束路径长度约束策略约束以用户为中心的信任模型u对于每一个用户而言，应该建立各种信任关系， 这种信任关系可以被扩展u例子：用户的浏览器配置以用户为中心的信任模型示例：PGP与PKI有关的标准情况uCertificates X.509 v.3u交叉认证 PKIX group in IETF(RFC 2459)u智能卡/硬件插件 PKCS #11uPKCS系列u目录服务LDAPPKCS系列标准uPKCS #1RSA Encrypti
15、on StandarduPKCS #3Diffie-Hellman Key-Agreement StandarduPKCS # 5Password-Based Encryption StandarduPKCS #6Extended-Certificate Syntax StandarduPKCS #7Cryptographic Message Syntax StandarduPKCS #8Private-Key Information Syntax StandardPKCS系列标准(续)uPKCS #9Selected Attribute TypesuPKCS #10Certification Request Syntax StandarduPKCS #11Cryptograph
