现代密码学(22)课件

1、第九章 网络加密与认证 2022/10/131第九章 网络加密与认证 2022/10/111网络加密方式基本方式链路加密每个易受攻击的链路两端都使用加密设备进行加密缺点是每次到达通信节点时都需要解密以确定路由,在节点处容易受到攻击端端加密仅在通信线路的两端进行加密，可防止对网络上链路和节点设备的攻击可以提供一定程度的认证缺点是只能对数据报中的用户数据部分加密，容易受到业务流量分析攻击2022/10/132网络加密方式基本方式2022/10/112网络加密方式结合方式主机之间使用端端加密每个链路之间使用链路加密PSNPSNPSNPSNPSN分组交换节点链路加密设备端端加密设备2022/10/13

2、3网络加密方式结合方式PSNPSNPSNPSNPSN分组交换节端端加密的逻辑位置指加密功能部署在OSI参考模型的哪一层不同的层次有不同的协议异构的网络之间只在应用层可能有端到端加密2022/10/134端端加密的逻辑位置指加密功能部署在OSI参考模型的哪一层20存储转发通信的加密范围互联网互联网2022/10/135存储转发通信的加密范围互联网互联网2022/10/115各层加密的数据数据链路层报头网络层报头IP报头TCP报头数据数据链路层报头数据链路层报头网络层报头IP报头TCP报头数据数据链路层报头数据链路层报头网络层报头IP报头TCP报头数据数据链路层报头TCP层加密应用层加密数据链路层

3、加密2022/10/136各层加密的数据数据链路层报头网络层报头IP报头TCP报头数据Kerberos认证系统2022/10/137Kerberos认证系统2022/10/117Kerberos雅典娜计划的一部分 (MIT)。可信的第三方认证方案。假定主机是不可信的要求每个client (对每次业务请求 ) 证明其身份.不要求用户每次业务请求都输入密码!密码设计基于NeedhamSchroeder协议2022/10/138Kerberos雅典娜计划的一部分 (MIT)。2022/1Kerberos 设计用户必须在工作站会话开始的时候验证自己 (登录会话).密码永远不在网络中明文传输 (或在存储

4、器中存储)2022/10/139Kerberos 设计用户必须在工作站会话开始的时候验证自己Kerberos设计 (续)每个用户有一个口令.每个业务有一个口令.知道所有口令的唯一实体是认证 服务器.2022/10/1310Kerberos设计 (续)每个用户有一个口令.2022/1ServerServerServerServerKerberosDatabaseTicket Granting ServerAuthentication ServerWorkstationKerberos 密钥分配服务2022/10/1311ServerServerServerServerKerber票据（Ticke

5、ts）每个业务请求需要一个 ticket.一个 只能用于单个用户访问单个服务器.Tickets 由 “Ticket Granting Server” (TGS)分发,TGS有所有的加密密钥.Tickets 对clients是无意义的, clients只是用他们接入服务器.2022/10/1312票据（Tickets）每个业务请求需要一个 ticket.2票据（Tickets） (续) TGS 用服务器的加密密钥密每个ticket加密的tickets可在网上安全传输，只有服务器可以解密.每一 ticket有有限的生存期 (几个小时).2022/10/1313票据（Tickets） (续) TGS

6、 用服务器的加密密钥密Ticket 内容Client名 (用户登陆名)Server 名Client 主机网络地址Client/Server会话密钥，用于加密client和server间的请求和响应Ticket 生存期产生时戳2022/10/1314Ticket 内容Client名 (用户登陆名)2022/1认证符（Authenticators）认证符证明client身份.包括Client 用户名.Client 网络地址.时戳.认证符以 session key加密.2022/10/1315认证符（Authenticators）认证符证明client问题每次client要访问要申请新的ticket

7、.为了从 TGS获得ticket, client 必须已经有 TG ticket和一个会话密钥与TGS通信! 2022/10/1316问题每次client要访问要申请新的ticket.2022/认证服务器(AS)Client向AS 发送明文请求以获得一个 ticket用于和TGS通信。请求:登录名TGS 名称由于这个请求只包括公开的名字，不需要加密.2022/10/1317认证服务器(AS)Client向AS 发送明文请求以获得一个认证服务器(AS)AS 找到与登陆名和TGS 名对应的密钥 . AS 生成一个ticket:login nameTGS nameClient网络地址TGS 会话密钥

8、 AS 以TGS 秘密密钥加密此ticket.2022/10/1318认证服务器(AS)AS 找到与登陆名和TGS 名对应的密钥 AS响应AS 同时产生一个随机会话密钥供client 和TGS 使用.会话密钥和加密的ticket 以用户的秘密密钥加密.TGS session keyTicket:login nameTGS namenet addressTGS session key以用户密钥加密以TGS密钥加密2022/10/1319AS响应AS 同时产生一个随机会话密钥供client 和TG访问 TGSClient以用户口令作为秘密密钥解密消息.Client这时获得了会话密钥和与 TGS 通

9、信的ticket.Client看不到ticket内部的内容,因为client 不知道TGS 的秘密密钥.2022/10/1320访问 TGSClient以用户口令作为秘密密钥解密消息.20当client想开始使用服务,client必须首先获得一个 ticket.Client构造一个请求发送给TGS:访问服务器TGS Ticket认证符Server Name以TGS密钥加密以会话密钥加密2022/10/1321当client想开始使用服务,client必须首先获得一个 TGS 响应 TGS 用其秘密密钥解密ticket获得TGS会话密钥. TGS 用会话密钥解密信任状. TGS 检查验证登陆名，

10、client地址和 TGS server名都正确.TGS 验证信任状是最新的.2022/10/1322TGS 响应 TGS 用其秘密密钥解密ticket获得TGSTGS 响应一旦所有验证通过，TGS:产生一个ticket使client用于请求的server. Ticket用server密钥加密.产生一个会话密钥以TGS会话密钥加密整个消息发回给client. 2022/10/1323TGS 响应一旦所有验证通过，TGS:2022/10/112用户访问服务器Client以TGS会话密钥解密TGS响应 .Client现在获得了与服务器通信的会话密钥和ticket.client 用与和访问TGS一样

11、格式的数据访问服务器。2022/10/1324用户访问服务器Client以TGS会话密钥解密TGS响应 .Kerberos 总结每业务请求需要一个 ticket.Tickets 来源于TGS (除了访问TGS的ticket).工作站不能解密用服务器密钥加密的tickets.每个 ticket有个相应的session key.Tickets 不能重用.2022/10/1325Kerberos 总结每业务请求需要一个 ticket.20Kerberos 总结（续）Tickets有有限的生命期.信任状只能使用一次.信任状失效的更快 !服务器维护一个信任状列表2022/10/1326Kerberos

12、总结（续）Tickets有有限的生命期.2Kerberos区域和多区域的KerberosASTGSASTGS服务器Client区域AKerberosKerberos12435672022/10/1327Kerberos区域和多区域的KerberosASTGSASX.509和PKIPublic Key Infrastructure2022/10/1328X.509和PKIPublic Key InfrastrucPKI的用途机密性只有指定的接收者才能访问信息。数据完整性交易中的信息不可篡改。技术上的不可抵赖性交易中一方事后不能抵赖。 认证 通信中一方可以确定和谁在通信。2022/10/1329P

13、KI的用途机密性数据完整性技术上的不可抵赖性认证2022/PKI 还可用于 .授权用户可以有效的访问拥有权限的受控资源。访问控制 用户可以方便的控制需要进行控制的资源2022/10/1330PKI 还可用于 .授权访问控制 2022/10/113PKI包含什么?一个PKI是一系列安全业务的集合，采用公钥密码和 X.509 数字证书，应用于分布式计算系统。2022/10/1331PKI包含什么?一个PKI是一系列安全业务的集合，采用公钥密PKI包含什么?密钥对: 公开和秘密密钥X.509数字证书CA（Certificate Authority）RA（Register Authority）公共目录

14、服务 (PKI)相关CA间的信任关系一组PKI政策: 注销，维护,更新等等.PKI 应用集成PKI的目录服务 (企业)2022/10/1332PKI包含什么?密钥对: 公开和秘密密钥2022/10/11专用还是通用PKI目前许多消息和群组产品提供自己的PKI，专用PKI支持专门应用。也需要通用PKI支持多种应用，管理多个应用产生的密钥 集中管理证书政策，与企业目录更紧密的集成，降低管理的复杂性。2022/10/1333专用还是通用PKI目前许多消息和群组产品提供自己的PKI，专密钥对交换问题:1. 接收者如何确定的知道发送者的公开密钥 (用于验证数字签名)2. 发送者如何确定的知道接收者的公开

15、密钥（用于加密消息）2022/10/1334密钥对交换问题:2022/10/1134解决方案: 数字证书.数字证书将一个人或其他实体的身份和公开密钥绑定，以确保密钥确实属于该用户或实体。数字证书2022/10/1335解决方案: 数字证书.数字证书2022/10/1135数字证书包含下列信息的数据结构: 所有者公钥用户或实体的身份发布者身份由第三方信任机构签名 (Certificate Authority)有限的有效期.X.509 定义该结构 (ITU, IETF PKIX standards). 现在为 v3.2022/10/1336数字证书包含下列信息的数据结构: 2022/10/1136

16、数字证书version (v3)serial numbersignature algorithm idissuer namevalidity periodsubject namesubject public key infoissuer unique identifierextensionssignatureX.509v3 证书:2022/10/1337数字证书version (v3)X.509v3 证书:202数字证书证书分类: ID/认证分级证书重要性是不一样的PKI通常支持不同类型的证书，可以 (1)用于不同的功能 (2)建立不同级别的 身份认证机制.证书分类没有标准2022/10/13

17、38数字证书证书分类: ID/认证分级证书重要性是不一样的证书数字证书1.最低级确保用户名和e-mail地址.，无第三方认证 用途：Web浏览2.基础级由第三方(RA)验证姓名，地址和其他注册的个人信息。可能应用: 小额 EDI, 在线支付。2022/10/1339数字证书1.最低级2.基础级2022/10/1139数字证书3. 中级 注册过程需要个人当面认定，高强度的密码模块和访问控制 典型应用: 敏感的公司间邮件或 EDI 4. 高级 需要个人当面以及详细调查 最强的计算安全控制2022/10/1340数字证书3. 中级4. 高级2022/10/1Certificate Authority

18、 (CA) 对给定的安全域产生和发布证书。控制政策，相对其他用户具有绝对的权威. 数字证书2022/10/1341Certificate Authority (CA) 对给定Principal/ ApplicantRegistration AuthorityCertificate AuthorityRepositoryApplicationor other entity1. Users apply for certification2. RA verifies identity3. RA requests cert for userCert and CRL Repository (LDAP D

19、irectory)4. CA issues cert5. CA publishes certs and CRLs5a. CA pushes CRL info to client based on policy6. Apps and other systems use certs. 数字证书2022/10/1342Principal/ Registration CertifCertificate AuthorityLocal Area NetworkWide Area NetworkLocal Area NetworkLocal Area NetworkRegistration Authorit

20、yPrincipal/ ApplicantRepository数字证书2022/10/1343Certificate AuthorityLocal AreCA 信任模型任何支持超出单个安全域的PKI必须考虑 : 如何建立对 CA本身的信任?问: 谁是CA的可信第三方？ 谁签发它的数字证书？ (分层)它和谁共享信任? (交叉证书)2022/10/1344CA 信任模型任何支持超出单个安全域的PKI必须考虑 : 如CA 信任模型三种主要的 CA信任模型:1.交叉认证2.证书链3. hub/桥 CA2022/10/1345CA 信任模型三种主要的 CA信任模型:2022/10/11CA 信任模型1.

21、 交叉认证:A. 证书信任列表CTLs 是信任的证书或 CA的列表.Web 浏览器可以在client端存储 CTLs ，或在中心目录或信任server上存储。管理员可指定信任CA的集合.在验证证书有效性的同时,client检查发布证书的CA是否在证书列表中。2022/10/1346CA 信任模型1. 交叉认证:CTLs 是信任的证书或 CCA 信任模型1. 交叉认证:B.双侧交叉认证CAs 通过公证彼此的公钥彼此交叉认证。CA1CA2CA3Cross-certifiedCross-certifiedTrust relationshipTrust relationshipOptional imp

22、licit third-party trust2022/10/1347CA 信任模型1. 交叉认证:CA1CA2CA3Cross2. 证书链:user Auser BCACACACA(“root”)CATrustsTrustsTrustsTrustsTrustsTrustsOptional cross-cert.CA 信任模型2022/10/13482. 证书链:user Auser BCACACACACA3. Hub/桥 CAHubCACACACACACACACACACA 信任模型2022/10/13493. Hub/桥 CAHubCACACACACACACAC3. Hub/桥CAHub/桥

23、 CA 为成员提供中心化的信任管理/和政策映射.建立确信级别和维护政策.Hub CA 会检查成员CA 的政策以保证一致性和完整性。处理交叉认证任务和维护目录仓库.CA 信任模型2022/10/13503. Hub/桥CAHub/桥 CA 为成员提供中心化的信HybridHubCACACACACommunity of InterestCABi-lateral cross-certification with trading partnerCACACACross-certificationinto a public hierarchyCA 信任模型2022/10/1351HybridHubCACACACommunity ofCABPKI 政策“证书政策”:“A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.”- RFC 2527