资源预览内容
第1页 / 共138页
第2页 / 共138页
第3页 / 共138页
第4页 / 共138页
第5页 / 共138页
第6页 / 共138页
第7页 / 共138页
第8页 / 共138页
第9页 / 共138页
第10页 / 共138页
亲,该文档总共138页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
PKI技术,第十六讲 属性证书与PMI,2,回顾,PKI中,提供服务的最基本方式就是: Certificate 数字证书、证书 根据X.509 The binding of a public-key to an entity is provided by an authority through a digitally signed data structure called a public-key certificate. 证书就是 权威的、数字签名保护的 绑定了公钥和某个实体,3,PKI提供的重要服务之一,鉴别Authentication 身份鉴别: 提供了关于某个实体的身份的保证。也就是: 当某个实体声称具有一个特定的身份时(例如,声称“我就是拉登”),鉴别服务将提供某种方法来证实这一声称是正确或者错误。 PKI的鉴别服务通过如下方式实现 如下图,4,PKI的鉴别服务,验证 证书是否有效? 是否具有证书所对应的私钥? 声称者的身份就是证书Subject,Bob证书,随机数R,随机数R,随机数R,签名结果8714968,利用公钥验证签名,我是Bob,我是Bob,我是Bob,签名结果8714968,签名结果8714968,是否正确?,5,信息安全的另一方面授权,授权Authorization 赋予某个实体(用户、进程等)对客体(数据、文件等)的一定程度的支配权力 授权是在鉴别的基础上进行的,只有确定了实体的身份之后,才能对其授权 否则,就可能盲目地将权限赋予攻击者,6,授权的几种方法,基于身份的授权策略 直接对每个访问实体进行授权,说明其能够执行的权限 基于角色的授权策略Role-Base 给每个访问实体分配角色(可以属于多个角色) 对角色进行授权 一般,更多地使用基于角色的授权策略 Role Base Access Control, RBAC 如下图,7,基于身份/角色的授权策略,如下图 Role: 浏览者/修改者 Identity: Alice/Bob Alice: 浏览者 Bob: 浏览者/修改者,8,授权的几种分类,自主访问策略 Discretional Access Control 允许主体针对访问资源的用户设置访问控制权限 某个主体可以修改其他主体对于客体的权限 强制访问策略 Mandatory Access Control 不允许主体干涉的访问控制类型 主体对客体的权限是由系统统一控制的,访问主体不能修改权限 例如,将主体和客体分为几个安全等级,根据“上读下写”原则判断权限,9,授权的需求,授权必须是在鉴别的基础上进行的 一般对于信息系统而言,授权是在鉴别后立即需要进行的 鉴别:来访者是谁? 授权:该来访者能够做什么? 鉴别是授权的基础,10,问题,利用PKI完成了鉴别(强度更高、更安全),是否也可利用PKI来进行授权? 或者使用类似于PKI的方法? 或者由PKI来辅助进行授权? 或者利用PKI,将鉴别和授权一并完成?,11,用PKI直接解决授权,在证书扩展subjectDirectoryAttributes中 给出用户的角色,或者, 给出用户的安全级别(用于强制访问控制) 对于Role-Base、强制访问控制,在鉴别的过程中,同时得到: 用户的角色RBAC 用户的安全级别(BLP模型的级别) 然后,应用系统就进行授权操作、权限判断,12,存在问题,但直接用PKI证书来解决授权存在问题 周期问题,变化频繁 权限信息来源不统一,缺少权威机构 角色多变,1个实体具有多个角色 下面详细说明,13,存在的问题1 (to be contd),周期 相比于角色的变化,身份信息的变化是比较缓慢的。例如: 证书Subject包括了国籍、出生地(省、市、地址)、姓名,几乎不可能变动 角色信息很轻易变化:“只读用户”“Root用户”“操作者”等等 证书有效期设定得很短、或频繁地撤销证书 给其他方面(例如机密性)的使用带来不便,14,存在的问题2 (to be contd),权限信息从哪里得到,如下图 用户申请证书时,需要与信息系统进行确认 或者CA可以决定该用户的角色(一般不成立) 增加证书申请时的通信复杂性和CA复杂性,15,存在的问题3,在不同的信息系统中 用户角色一般是不同的 在证书中难以全面地设定,16,因为存在以上问题,X.509标准中,提出PMI和Attribute证书,以及各种概念 属性证书 因为在X.500目录中,有关Entry的各种所有信息,都称为Attribute属性 但是,目前而言,Attribute Certificate主要是为了解决授权/访问控制问题 AA,Attribute Authority SOA,Source of Authority,17,本节课程,讲述PMI以及属性证书的基本内容 同时,与PKI进行适当的比较,18,提纲,PMI的基本概念 PMI权限管理的4种应用模式 属性证书的基本结构 属性证书的扩展 与属性证书相关的X.500 Schema,19,PMI和属性证书,PMI Privilege Management Infrastructure 专门用于权限管理的基础设施 也利用了公钥密码学 PMI提供服务的最基本方式是: Attribute Certificate 以证书的方式,给出了用户的各种与权限相关的属性 属性证书 为了避免混淆,用“公钥证书PKC”和“属性证书AC”分别来区分PKI和PMI中的证书,20,属性证书,根据X.509 The binding of a privilege to an entity is provided by an authority through a digitally signed data structure called an attribute certificate. 属性证书AC 权威的、数字签名保护的 绑定了权限和某个实体 公钥证书,简称Public Key Certificate, PKC,21,属性证书中的属性,在X.500目录的概念中,各种信息都可以称为Attribute 但是在属性证书,一般只是包含了“与权限管理有关”的属性 The binding of a privilege to an entity 并不是要将各种无关紧要的属性都放入证书 下文中的“属性”,如无特别说明,仅指“与权限管理有关”的属性 所以,称为PMI,Privilege Management Infrastructure 而不是Attribute Management Infrastructure,22,PMI中的基本概念,属性证书Attribute Certificate 由AA签发、绑定了End Entity和若干属性 AA,Attribute Authority 属性证书的签发者 SOA,Source of Authority 权限管理的起点 SOA也是AA End Entity,简称EE 拥有属性证书(拥有一定权限)的实体,不能再将权限传播给其他实体 后面的讲述会进一步说明这些概念,23,与PKI比较,各种概念的比较 AACA SOARoot CA End EntityPKI Subscriber/End Entity Attribute CertificatePublic-Key Certificate Attribute Certificate VerifierPKI User/PKI Relying Party,24,属性证书的最简单示意,属性证书的最简单示意,包括如下内容: Holder:CN,CAS,GUCAS,LOIS,LINJQ 属性: Users组 可以读写http:/www.lois.cn 有效期:2006-4-272006-5-27 签名结果:AA用自己的私钥的签名结果,25,属性证书的验证PKI,注意: 验证属性证书的正确性 要找到签发者AA的公钥证书,验证签名有效性 就要先验证AA的公钥证书(根CA证书、CRL等等) 也就是说,必须先有PKI,才能建设PMI “有PKI、没有PMI”是可能的 “有PMI、没有PKI”是不可能的 同时,属性证书也有有效期、签发者、Subject等等,26,PMI的基本模型,专门的AA(Attribute Authority)签发属性证书 在属性证书中,包括了权限、角色信息等 同时,属性证书经常会与某个公钥证书相关 如下图,27,AA,AA给其他实体签发属性证书 如下图 AA必须具有“给其他人授权”的权限 图中,AA有2个属性证书 对于第1个属性证书而言,AA仅仅是普通的End Entity,28,AA与End Entity的区别,在PMI中, AA与End Entity的区别: AA可以将权限传播给别人 EE不可以 在PKI中, CA与End Entity的区别: CA可以给其他人签发证书,可以传播信任 EE不可以 信任的传播,需要起点 权限的传播呢?是否需要起点?,29,权限来自哪里?,PMI之所以能够代替应用系统进行授权 因为PMI得到了应用系统的委托 也就是,应用系统承认某个根AA对于其权限的代管 然后,再由根AA传播给其他AA、再到End Entity 在PMI中,将根AA称为SOA Source of Authority 权限从SOA开始传播 应用系统要安装自己委托的SOA的属性证书(后面会提到,称为Attribute descriptor证书),30,SOA,相当于PKI中的根CA、信任锚 SOA使用自己的私钥,给自己签发属性证书,列出了“自己可以分配给别人的权限” SOA的Attribute descriptor证书(相当于根CA的自签名证书) 如果应用系统相信该SOA,就将SOA的属性证书安装到系统中 方法应该是与根CA证书传递的方法相似,带外传输 相当于是:将“Attribute descriptor证书”中列出的各种权限,委托给SOA管理,31,从SOA到AA,到End Entity,AA是签发属性证书的权威机构 也就是,AA能够给实体分配权限 那么,为什么AA能够给实体分配权限呢? 来自上一级AA的授权 AA也有自己的属性证书,说明了自己“可以分配给别人的权限” 逐级授权、然后将权限分配给End Entity 同时,AA、SOA的公钥都是由PKI来确定的,32,SOAAA,SOA可以直接给End Entity签发属性证书 说明了该实体所拥有的权限、属性 SOA可以先给其他的AA签发属性证书,再由AA给End Entity签发属性证书 与PKI中的层次结构一致 SOA一定是个AA、AA不一定就是SOA 类比于 根CA一定是CA、CA不一定就是根CA,33,权限验证方法1,如下过程 先进行身份鉴别 通信得到实体的属性证书,与公钥证书比较Subject 用SOA的公钥证书验证实体的属性证书 查看SOA的属性证书,是否在信任列表中 即:是否来自可信的SOA;是否能够管理该权限,34,权限验证方法2,层次的PMI 逐级地验证权限证书,以其公钥证书,35,AASOACAEE,应用系统信任CA CA鉴别了SOA/AA/EE,所以应用系统有能力鉴别SOA/AA/EE 应用系统信任SOA SOA授权给AA/EE,所以应用系统有能力确定AA/EE的权限,36,提纲,PMI的基本概念 PMI权限管理的4种应用模式 属性证书的基本结构 属性证书的扩展 与属性证书相关的X.500 Schema,37,PMI工作模式,即在应用系统中,如何使用PMI来进行访问控制权限的判断、 判断某个entity是否可以进行某种访问动作 是关于如何“使用PMI”,而不是关于如何“构建PMI” X.509标准说明的方式,共有4种 注意,实际中是4种结合使用的 4种Model从不同的方面,说明了PMI的特点,38,4种模式,国际标准X.509给出PMI的4种工作模式 General Model Control Model Delegation Model
收藏 下载该资源
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号