Pki guide v1.0a_aka

  • 2,842 views
Uploaded on

PKI Guide 2001

PKI Guide 2001

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,842
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 各位朋友们,你们好: 《 PKI 漫谈》是我早就想写的一系列文稿。有一段时间,经常给一些同事介绍 PKI ,几次后手头就有了一个简要的大纲。在和几个朋友有了一些简单的交流后,我将经过第一次修改后的大纲拿给了一些专业人员看了看,有一些朋友提出了很好的意见,如金辉 (Arthur Jin) 提出了应加入 RC 系列密码算法的介绍,李延昭 (Chorus Li) 提出了应对国内的 PKI 厂商与产品进行一些介绍,……。最后,更为重要的是, Yongtian Zhang 提出一些很好的意见。基于这些意见,我对大纲做了第二次的修改 ( 我会附在下面 ) 。这些事情都发生在 2000 年 11 月份以前,在接下来的这一年时间里,一直没抽出比较整块的时间来写这份东西,此次,借 AKA 安全沙龙召开活动的契机,我用 Powerpoint 的形式整编了一些资料,希望能对大家学习、了解 PKI 有一些帮助。 王曙 (Kevin Wang) 2001.11.11 附: From: Kevin Wang Date: Fri Nov 15, 2000 11:51am Subject: the second revision for the outline of <<PKI Guide>> Hi, all: The following is the second revision for the outline of <<PKI Guide>>. Thanks Arthur for reminding me to add RC2/RC4, thanks Chorous for reminding me to add something about domestic PKI vendors, and some of important ideas come from a friend - Zhang.Yongtian, he spent time to review the outline and give me his important comments. I hope you can review the new coming one and give me your ideas about it. kevin 11/15/2000 =========================================================== PKI 漫 谈 Chapter 0 绪论 0.1 什么是 PKI 0.2 PKI 的理论基础 0.3 PKI 的由来 / 来源 ( 为什么需要 PKI , PKI 能解决什么问题 ) 0.4 PKI 的进展 0.5 本漫谈的内容介绍 Chapter 1 密码学 1.1 概述 1.2 公钥密码学 1.2.1 概述 1.2.2 RSA 1.2.3 DH/DSA 1.2.4 Elgemal 1.2.5 Others 1.3 传统密码学 1.3.1 概述 1.3.2 DES 1.3.3 IDEA 1.3.4 RC2 与 RC4 1.3.5 AES 与 Rijndeal 1.3.6 Others 1.4 散列算法 1.4.1 概述 1.4.2 MD5,MD4 1.4.3 SHA 1.4.4 RIPEMD 1.4.5 HMAC 1.4.6 Others 1.5 不同算法的特点 Chapter 2 X.500 目录体系与数字证书 2.1 概述 2.2 X.500 目录体系 2.3 X.509 数字证书 2.4 LDAP 协议 Chapter 3 PKI 及其构件 3.1 综述 3.2 CA 、 RA 与 EE 3.3 PKI 运作与 CPS 3.4 PMI 与 TSA 在本章中,先介绍 PKI 的构件组成,再谈一谈 PKI 中各构件的关系,最后谈一谈 PKI 运作与 CPS 。 Chapter 4 PKI 实施中的问题 ( 一 ) – 技术问题 4.1 数字证书 RSA 证书, DH/DSA 证书的实现; 4.2 证书验证与证书生命周期 4.3 交叉认证 4.4 标准化 本章主要介绍 PKI 实施中涉及到的一些实际问题。 如各 CA 间的互操作性,验证证书时的协议实现 (CRL or OCSP) - 客户端应用与 CA 之间的配合,这涉及到各个 PKI 厂商的专用实现。 Chapter 5 PKI 实施中的问题 ( 二 ) – 非技术问题 5.1 证书政策与证书政策声明 (CP and CPS) 5.2 运作安全 5.3 PKI 涉及到的法律问题 Chapter 6 PKI 应用 6.1 SSL/TLS 6.2 S/MIME 6.3 IPSec 6.4 SET 6.5 Time Stamping 6.6 Data Certification Chapter 7 著名的 PKI 厂商与实现 7.1 著名的 PKI 厂商及其产品 7.1.1 VeriSign 7.1.2 Entrust 7.1.3 Baltimore 7.1.4 RSA Security 7.1.5 Others 7.2 著名的 PKI 实现 7.2.1 OpenCA 工程 7.2.2 OSCAR PKI 工程 7.2.3 JonahPKI 工程 7.2.4 pyCA 工程 7.2.5 Mozilla NSS/PSM 7.2.6 MISPC 参考实现 Chapter 8 标准化进展 8.1 概述 8.2 X 系列标准 (X.208,X.209,X.500 & X.509) 8.3 IETF PKIX 工作组 8.4 SET 8.5 PKCS 8.6 OpenPGP 8.4 其它 Appendix A 信任模型 Web of Trust, Trust Hierarchy, Others Appendix B 现有 PKI 的不足 指明现有 PKI 的不足之处,如 Trust Model , Privacy 以及应用标准化等方面存在的问题,并说明下一步可能的 进展。主要内容基于 http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html 和其它方面的一些文章和报道。 Appendix C Terminology( 术语表 ) Appendix D References( 参考文献 ) Appendix E 国内的 PKI 工程与厂商 1. CTCA ( 即中国电信 CA ,由创原世纪完成 ) 2. 外经贸部 CA - 国富安 ( http://www.cacenter.com.cn/ ) 3. CFCA (即中国金融认证中心, http://www.cfca.com.cn/ ) 4. CPCA (即国家邮政总局 CA ,在建项目) 5. 信安世纪 ( http://www.infosec.com.cn/ ) 6. 诺方信业 ( http://www.netfront.com.cn/ ) 7. 德达创新 ( http://www.datatrust.com.cn/ ) 8. 吉大正元 ( http://www.jit.com.cn/ )
  • 引出并简要定义 PKI
  • 1. PKI 是一个用公钥概念和技术来实施和提供安全服务的具有普适性的安全基础设施。 2. PKI 是安全管理基础设施中使用基于公钥安全服务、专注于密钥和证书管理的部分。这包括共同为用户和应用提供安全服务的策略、规程、设备和个人。 PKI 产生等同于手工过程的“信任链”。 A PKI is that portion of the security management infrastructure dedicated to the management of keys and certificates used by public key-based security services. This includes the policy, procedures, equipment, and personnel that collectively provide security services to users and applications. A PKI produces a "chain of trust" equivalent to manual processes. URL : http://www.computermagic.com/PKI/pki-components.htm 3. Public Key Infrastructure (PKI): 提供公钥证书的生成、制造、分发、控制、计帐和破坏的框架和服务。 The framework and services that provide for the generation, production, distribution, control, accounting and destruction of public key certificates URL : http://www.wcecrc.org/Definitions.html Definitions for Department of Defense (DoD) Public Key Infrastructure (PKI) 4. PKI 公钥基础设施的缩写,是用于验证和鉴别在互联网交易中涉及到各方的有效性的关于数字证书、证书授权机构和其它登记机构的系统。 PKI 正在演进,当前没有单独的 PKI 和为建立 PKI 公认的标准。然而,几乎所有人都同意可靠的 PKI 是电子商务获得广泛应用必需的。 PKI 也被称为信任层次结构。 Short for public key infrastructure, a system of digital certificates, Certificate Authorities, and other registration authorities that verify and authenticate the validity of each party involved in an Internet transaction. PKIs are   currently evolving and there is no single PKI nor even a single agreed-upon standard for setting up a PKI. However, nearly everyone agrees that reliable PKIs are necessary before electronic commerce can become widespread. A PKI is also called a trust hierarchy URL : http://webopedia.internet.com/TERM/P/PKI.html 5. What is a PKI? PKI 由支持公钥密码学应用的协议、服务和标准组成。术语 PKI ,出现时间并不长,定义也变化多端。有时 PKI 只简单的指基于公钥证书的信任层次,而在其它场合却意味着提供给最终用户应用的加密和数字签名服务。较中立的观点是 PKI 包括管理公钥的服务和协议,通常是通过 CA 和 RA 构件,但执行密码运算不是必需的。 A public-key infrastructure (PKI) consists of protocols, services, and standards supporting applications of public-key cryptography. The term PKI, which is relatively recent, is defined variously in current literature. PKI sometimes refers simply to a trust hierarchy based on public-key certificates [1], and in other contexts embraces encryption and digital signature services provided to end-user applications as well [OG99]. A middle view is that a PKI includes services and protocols for managing public keys, often through the use of Certification Authority (CA) and   Registration Authority (RA) components, but not necessarily for performing cryptographic operations with the keys. 在 PKI 中可见到的服务有: 密钥注册:发布公钥的证书; 证书吊销:取消先前发布的证书; 密钥选择:得到一方的公钥; 信任评估:确定一证书是否有效以及它授权了什么操作; 也建议密钥恢复是 PKI 的一部分; Among the services likely to be found in a PKI are the following: Key registration: issuing a new certificate for a public key. Certificate revocation: canceling a previously issued certificate. Key selection: obtaining a party's public key. Trust evaluation: determining whether a certificate is valid and what operations it authorizes. Key recovery has also been suggested as a possible aspect of a PKI. 今天还没有一个单一普适的公钥基础设施,尽管定义 PKI 的努力通常假定最会只有一个,或者多个独立的 PKI 会日益演进成不同程度共存和互操作性的基础设施。从这个意义上讲,今天的 PKI 可被视作 20 世纪 80 年代,未广泛连接形成互联网前的局域网和广域网。从往全球性的 PKI 发展这个观点来看,证书格式和信任机制以开放和可伸缩的方式定义,但可根据特定客户和应用环境的信任和政策需求制定相应的使用框架 (Usage Profile) 。例如,通常可以接受在全球性的 PKI 中有多个“根”或“顶级”证书授权中心,而非只是一个“根”,尽管在本地 ( 局部 )PKI 中只能有一个根。相应的,协议可被定义为按规定为给定应用或用户提定根。 There is no single pervasive public-key infrastructure today, though efforts to define a PKI generally presume there will eventually be one, or, increasingly, that multiple independent PKIs will evolve with varying degrees of   coexistence and interoperability. In this sense, the PKI today can be viewed akin to local and wide-area networks in the 1980's, before there was widespread connectivity via the Internet. As a result of this view toward a global PKI, certificate formats and trust mechanisms are defined in an open and scaleable manner, but with usage profiles corresponding to trust and policy requirements of particular customer and application environments. For instance, it is usually accepted that there will be multiple ``root'' or ``top-level'' certificate authorities in a global PKI, not just one ``root,'' although in a local PKI there may be only one root. Accordingly, protocols are defined with provision for specifying which roots are trusted by a given application or user. 今天定义 PKI 的努力在几个政府和标准化组织中进行。美国财政部和 NIST 都有 PKI 项目,在加拿大和英国也一样。 NIST 发布了 PKI 构件互操作性的描述;它指定了证书授权机构需支持的算法和证书格式。另外一些有 PKI 工作项目的标准化团体包括 IETF 中的 PKIX 和 SPKI 工作组和 TOG(The Open Group) 。 Efforts to define a PKI today are underway in several governments as well as standards organizations. The U.S. Department of the Treasury and NIST both have PKI programs [2,3], as do Canada [4] and the United Kingdom [5]. NIST has published an interoperability profile for PKI components [BDN97]; it specifies algorithms and certificate formats that certification authorities should support. Some standards bodies which have worked on PKI aspects   have included the IETF's PKIX and SPKI working groups [6,7] and The Open Group [8]. Most PKI definitions are based on X.509 certificates, with the notable exception of the IETF's SPKI. URL : http://www.rsasecurity.com/rsalabs/faq/4-1-3-1.html
  • 为什么需要数字证书与第三方认证 2. 对 PGP 来说公匙本来就要公开,就没有防监听的问题。但公匙的发布中仍然存在安全性问题,例如公匙的被篡改 (Public Key Tampering) ,这可能是公匙密码体系中最大的漏洞,因为大多数新手不能很快发现这一点。你必须确信你拿到的公匙属于它看上去属于的那个人。为了把这个问题说清楚,我举个例子,然后再说如何正确地用 PGP 堵住这个漏洞。   以你和 Alice 的通信为例,假设你想给 Alice 发封信,那你必须有 Alice 的公匙,你从 BBS 上下载了 Alice 的公匙,并用它加密了信件用 BBS 的 Email 功能发给了 Alice 。不幸地,你和 Alice 都不知道,另一个用户叫 Charlie 的用户潜入 BBS ,把他自己用 Alice 的名字生成的密匙对中的公匙替换了 Alice 的公匙。那你用来发信的公匙就不是 Alice 的而是 Charlie 的,一切看来都很正常,因为你拿到的公匙的用户名是“ Alice” 。于是 Charlie 就可以用他手中的私匙来解密你给 Alice 的信,甚至他还可以用 Alice 真正的公匙来转发你给 Alice 的信,这样谁都不会起疑心,他如果想改动你给 Alice 的信也没问题。更有甚者,他还可以伪造 Alice 的签名给你或其他人发信,因为你们手中的公匙是伪造的,你们会以为真是 Alice 的来信。   防止这种情况出现的最好办法是避免让任何其他人有机会篡改公匙,比如直接从 Alice 手中得到她的公匙,然而当她在千里之外或无法见到时,这是很困难的。 PGP 发展了一种公匙介绍机制来解决这个问题。举例来说:如果你和 Alice 有一个共同的朋友 David ,而 David 知道他手中的 Alice 的公匙是正确的(关于如何认证公匙, PGP 还有一种方法,后面会谈到,这里假设 David 已经和 Alice 认证过她的公匙)。这样 David 可以用他自己的私匙在 Alice 的公匙上签名(就是用上面讲的签名方法),表示他担保这个公匙属于 Alice 。当然你需要用 David 的公匙来校验他给你的 Alice 的公匙,同样 David 也可以向 Alice 认证你的公匙,这样 David 就成为你和 Alice 之间的“介绍人”。这样 Alice 或 David 就可以放心地把 David 签过字的 Alice 的公匙上载到 BBS 上让你去拿,没人可能去篡改它而不被你发现,即使是 BBS 的管理员。这就是从公共渠道传递公匙的安全手段。   有人会问:那你怎么安全地得到 David 的公匙呢,这不是个先有鸡还是先有蛋的问题吗?确实有可能你拿到的 David 的公匙也是假的,但这就要求这个捣蛋者参与这整个过程,他必须对你们三人都很熟悉,还要策划很久,这一般不可能。当然, PGP 对这种可能也有预防的建议,那就是由一个大家普遍信任的人或机构担当这个角色。他被称为“密匙侍者”或“认证权威”,每个由他签字的公匙都被认为是真的,这样大家只要有一份他的公匙就行了,认证这个人的公匙是方便的,因为他广泛提供这个服务,假冒他的公匙是很极困难的,因为他的公匙流传广泛。这样的“权威”适合由非个人控制组织或政府机构充当,现在已经有等级认证制度的机构存在。   对于那些非常分散的人们, PGP 更赞成使用私人方式的密匙转介方式,因为这样有机的非官方更能反映出人们自然的社会交往,而且人们也能自由地选择信任的人来介绍。总之和不认识的人们见面一样。每个公匙有至少一个“用户名” (User ID) ,请尽量用自己的全名,最好再加上本人的 Email 地址,以免混淆。   注意!你所必须遵循的一条规则是:在你使用任何一个公匙之前,一定要首先认证它!!!无论你受到什么诱惑,当然会有这种诱惑,你都不要,绝对不要,直接信任一个从公共渠道(由其是那些看起来保密的)得来的公匙,记得要用熟人介绍的公匙,或者自己与对方亲自认证。同样你也不要随便为别人签字认证他们的公匙,就和你在现实生活中一样,家里的房门钥匙你是只会交给信任的人的。
  • 密码学和信息安全的关系,以及密码学可解决信息安全的什么问题; 要讲清楚对称密码和公钥密码体制如何一致工作以解决信息安全的各种问题;
  • PKI 的本质是表示和管理信任关系的工具,是数字化、电子化社会的基础之一,
  • On the Internet, nobody know you’re a dog. 互联网困境 – 为什么安全如此重要?
  • 昆士兰这个地方的昆虫很多,已经开始危害到庄稼的生长。   有不少专家就开始建议, " 咱们是不是引进一些癞蛤蟆,癞蛤蟆可以吃虫子,也不会象农药那样破坏环境 " , " 这是一个好主意 ...!", ......, 虽然也有一些反对意见,但最终人们认为还是应该引进癞蛤蟆, " 癞蛤蟆好,癞蛤蟆好! ".   于是,昆士兰政府就开始引进了一批癞蛤蟆,并希望以后会有好收成。   但过了一阵子后,人们发现了不少新的问题:癞蛤蟆越来越多,虫子却并不减少。这可是个大问题了,因为癞蛤蟆引入了一些新的问题 ...... 。   又有一批专家开始调查,并且发现了原因:癞蛤蟆是在晚上活动的,而昆虫是在白天活动,一到晚上昆虫就开始休息了,而癞蛤蟆只能看到移动的物体,所以它们根本发现不了昆虫,也就无法解决昆虫害。   这是一个同事给我讲的故事,很有意思。有些朋友就用它来形容电子商务与 PKI 的关系:大家都说电子商务的安全有问题,怎么办呢?那就引入 PKI 吧, PKI 多好啊,可以解决许多问题 ......! 但真正引入 PKI 后,才发现, PKI 也就是 Queensland‘s Toad! -- 并未解决问题! 对 PKI 的认识并不统一,这里只是举出一个例子。
  • 本漫谈是以 PKI 为中心展开的,因此,对密码学的介绍要简单一些。
  • 参阅海南出版社《密码故事》,朱小篷、林金钟译 2. 密码学与隐写术 - 信息保密的两种途径  密码学 (Cryptography)  - 不是隐藏信息本身,而是要隐藏它的意思  隐写术 (Staganography)  - 通过把信息隐藏起来的秘密通信。 3. 分组密码 (block cipher) 与流密码 (stream cipher). 4. 文献记载最早使用的加密术是在公元前 1900 年的埃及:一个书记员在一幅题字中使用了非标准的象形文字; 公元前 1500 年的美索不达米亚文字匾中含有一个制造陶瓷釉的秘方; 公元前 500 - 600 年的希伯来人的 ATBASH 密码; 公元前 486 年希腊人的 skytale ,以及 Julius Caesar 的简单的置换密码等; 摘自 吴世忠、马芳译的《网络信息安全的真相》 ( 原书为《 Secrets and Lies: Digital Security in a Networked World 》,作者为 Bruce Schneier)
  • 1. 直到 20 世纪 70 年代中期,人们使用的仍然全是传统密码学 - 对称密码学 .
  • 1.1973 年 5 月 15 日, NBS( 国家标准局,后来的 NIST) 在 Federal Register 上,发布了公开征集标准密码算法的请求,他们确定了一系列的设计准则: * 算法必须提供较高的安全性; * 算法必须完全确定且易于理解; * 算法的安全性必须依赖于密钥,而不应依赖于算法; * 算法必须对所有用户都用效; * 算法必须适用于各种应用; * 用以实现算法的电子器件必须很经济; * 算法必须能有效使用; * 算法必须能验证; * 算法必须能出口; 2. 1976 年 11 月 23 日 DES 被采纳为联邦标准,并授权在非密级的政府通信中使用。 FIPS PUB 46 - DES 的正式文本,于 1977 年 1 月 15 日公布,并在 6 个月后生效; FIPS PUB 81 - DES 工作方式 ( 模式 ) ,于 1980 年公布; FIPS PUB 74 – 实现和使用 DES 的指南,于 1981 年公布; 此外, FIPS PUB 112 指定 DES 用作口令加密, FIPS PUB 113 指定 DES 用作计算机数据鉴别 3. DES Challenge http://www.eff.org/descracker.html
  • 1. Xuejia Lai 和 James Massey 于 1990 年公布了 IDEA 密码算法第一版,它被称做 PES (Proposed Encryption Standard, 推荐加密标准 ) 。在 Biham 和 Shamir 演示了差分密码分析之后,第二年设计者为对抗此攻击,增加了密码算法的强度,他们把新算法称之为 IPES (Improved Proposed Encryption Standard ,改进型推荐加密标准 ) 。 IPES 在 1992 年又改名为 IDEA (International Data Encryption Algorithm ,国际数据加密标准 ) 。
  • 1. RC2 是 Ron Rivest 为 RSA 公司设计的变长密钥加密算法,其分组长度为 64bit ,虽然“ RC” 正式的说法是“ Rivest Cipher” ,但实际上,它示” Ron’s Code“ 。 2. RC3 在开发过程中在 RSADSI 被攻破了; RC1 除了在 Rivest 的记事本上外,从未公开过; 3. RC4 是 Ron Rivest 在 1987 年为 RSA 数据安全公司开发的变长密钥的序列密码,在开始的 7 年中它有专利,算法的细节仅在签署一个保密协议后才能得到; 1994 年 9 月,有人把它的源代码匿名贴到 Cyberpunk 邮件列表中,该代码迅速被传到 Usenet 新闻组 sci.crypt 中,并且通过互联网传到了全球的许多的 ftp 站 . 美国政府已允许 RC2 、 RC4 产品出口,但密钥限制为 <=40bit 。 5. RC5 是由 RSA 公司的 Rivest 于 1994 年设计的一种新型的分组密码算法。它是一种分组长、密钥长和迭代轮数都可变的分组迭代密码算法,一个特定的 RC5 表示为 RC5-w/r/b ,其中 w 是以比特表示的字 (word) 的尺寸 (w=16, 32, 64) , r 是轮数 (0<=r<=255) , b 是密钥的字节 (byte) 长度 (0<=b<=255) 。 RC5 有两个字长 (2w) 的输入和输出。 6. RSA Laboratories Secret-Key Challenge – Status and Prizes The current status each of the contests in the RSA Security Secret-Key Challenge is as follows: contest prize start end DES $10,000 28 January 1997, 9 am 17 June 1997, 10:40 pm PST RC5-32/12/5 $1,000 28 January 1997, 9 am 28 January 1997, 12:30 pm PST RC5-32/12/6 $5,000 28 January 1997, 9 am 10 February 1997, 10:00 am PST RC5-32/12/7 $10,000 28 January 1997, 9 am 20 October 1997,11:18 am PST RC5-32/12/8 $10,000 28 January 1997, 9 am RC5-32/12/9 $10,000 28 January 1997, 9 am RC5-32/12/10 $10,000 28 January 1997, 9 am RC5-32/12/11 $10,000 28 January 1997, 9 am RC5-32/12/12 $10,000 28 January 1997, 9 am RC5-32/12/13 $10,000 28 January 1997, 9 am RC5-32/12/14 $10,000 28 January 1997, 9 am RC5-32/12/15 $10,000 28 January 1997, 9 am RC5-32/12/16
  • 1. 1997 年 1 月 2 日, NIST 发起 AES 开发活动,并于 9 月 12 日形成了正式的征集活动 - AES (Advanced Encryption Standard) ,并专门成立了 AES 工作组,目的是为了确定一非保密的、公开披露的、全球免费使用的分组密码算法,用于保护下一代政府的敏感信息,也希望能够成为秘密的和公开部门的数据加密标准 (DES) 。 1997 年 9 月 12 日在 Federal Register 公布了征集 AES 候选算法的通告。 AES 的基本要求比三重 DES 快而且至少和三重 DES 一样安全,分组长度为 128 bit ,密钥长度为 128/192/256 bit 。 1998 年 8 月 20 日 NIST 召开了第一次 AES 候选会议,并公布了 15 个 AES 候选算法。 1999 年 3 月 22 日举行第二次 AES 候选会议,公开 15 个候选算法的讨论结果。关于算法的讨论于 1999 年 4 月 15 日结束,从 15 个中选出 5 个。 NIST 从这 5 个算法选取一个做为 AES 。 2000 年 4 月 13 、 14 日在 New York 举行了 AES 第三次候选大会, NIST 听取来自全球的 200 多个密码研究团体的建议。 2000 年 10 月 2 日, NIST 宣布选定 Rijndael 做为 AES 的建议标准。 2. 5 个最后的候选算法分别是: MARS, submitted by International Business Machines Corporation (U.S.) ; RC6, submitted by RSA Laboratories (U.S.) ; Rijndael, submitted by Joan Daemen and Vincent Rijmen (Belgium) ; Serpent, submitted by Ross Anderson (U.K.), Eli Biham (Israel), and Lars Knudsen (Norway) ; Twofish, submitted by Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall and Niels Ferguson (U.S.) ; 3. The Home Page is: http://csrc.nist.gov/encryption/aes/ 4. Rijndael 算法的原型是 Square 算法,其设计策略是宽轨迹策略 (Wide Trail Strategy) 。这种策略是针对差分分析和线性分析提出的。 Rijndael 是一个迭代分组密码,其分组长度和密钥长度都是可变的,但是为了满足 AES 的要求,分组长度为 128bit ,密码长度为 128/192/256bit ,相应的轮数 r 为 10/12/14 。
  • 在英国政府的政府通信总部工作的 Ellis(1970), Cocks(1973) 和 Williamson(1974,1975) 也独立地完成的 PKC 的发明。 公钥密码学使用了一对密钥 – 加密密钥和解密密钥,且从解密密钥推出加密密钥是不可行的; 2. 公钥密码学解决了密钥分发问题; 3. Bob 给 Alice 发信 Alice 对外发放许多带锁的空盒子 ( 只有 Alice 一个人拥有此锁的钥匙 ) , Bob 找到这样一个盒子,将信息放进去,然后将锁锁上,并将上锁后的盒子寄给 Alice ,由于只能 Alice 有相应的钥匙,所以只有 Alice 才可以打开盒子读取里面的信息。 4. 一个误解是公开密钥加密在防范密码分析上比常规加密更安全。事实上,任何加密方案的安全程度都依赖于密钥的长度和破译密码所包含的计算工作量。从抗击密码分析的角度讲,无论常规还是公开密钥原则上都没有比对方优越的地方。 5. 另一个误解是公开密钥是一个使得常规加密已经过时的通用技术。相反,由于当前公开密钥加密在计算上的巨大开销,在可以预见的将来常规加密并不会被抛弃。 Diffie 曾说过:大家几乎普遍接受的观点是公开密钥编码学的使用只限于密钥管理和数字签名等应用。 6. 最后,有一个感觉是与使用常规加密涉及密钥分配中心的相当繁琐的握手过程相比,使用公开密钥加密后密钥分配就变得非常简单。事实上,仍然需要某种形式的协议,一般这会涉及到一个中心代理,而且整个过程比常规加密中的过程既不更简单也不更有效。
  • 1. RSA155 (512bit) 已于 1999 年 8 月 22 日被一个密码研究团体分解,用了 5.2 个月 (Mar 17 – Aug 22) 时间,如果加上多项式选择时间,共用了 7.4 个月。 2. RSA140 于 1999 年 2 月 2 日被分解,其用去了 9 周时间;
  • 1. 杂凑 (Hash) 函数是将任意长的数字串 M 映射成一个较短的定长输出数字串 H 的函数,以 h 表示,即 h(M) 。 h(M) 易于计算,称 H=h(M) 为 M 的杂凑值,也称杂凑码。杂凑函数有时也称为哈希函数。 2. 若杂凑函数 h 为单向函数,则称其为单向杂凑函数。 在密码学中,我们关心的通常是单向杂凑函数。 3. 若单向杂凑函数 h ,在任意给定 M 的杂凑值 H=h(M) 下,找一 M’ 使得 h(M’)=H 在计算上不可行,则称 h 为弱单向杂凑函数。 对单向杂凑函数 h ,若要找任意一对输入 M1, M2, M1 ≠ M2 ,使 h(M1)=h(M2) 在计算上不可行,则称 h 为强单向杂凑函数 . 上述两个定义给出了杂凑函数的无碰撞 (collision-free) 性概念。弱单向杂凑,是在给定 M 下,考察与特定 M 的无碰撞性;而强单向函数在考察输入集中任意两个元素的无碰撞性 4. 单向迭代杂凑函数的设计理论 怎样的函数能够满足安全性要求,这是一个困难的理论问题,还不能给出一个充分条件,但迄今为止已得到不少有意义的必要条件,从理论上讲最重要的有两点:一个函数的单向性;二是函数映射的随机性;另外,还需要有抗差分分析能力,以及非线性性 5. 关于生日攻击
  • 1. Ron Rivest 于 1990 年提出 MD4 杂凑算法 [Rivest 1990, 1992, 1995; RFC1320, RFC1321] ,特别适合于软、硬件快速实现。 MD5 是 MD4 的改进形式,两者都产生 128bit 的输出。 MD2 是 Ron Rivest 于 1988 年设计的另一个单向杂凑函数,其安全性依赖于字节间的随机转换,它和 MD5 一起用于 PEM 协议,其输出也是 128bit ,结构类似于 MD4 和 MD5 ,但其速度更慢,安全性也较差,已被 Rogier 等攻破 [RFC1319, Rogier 等 1995] 。 MD3 有些缺点,并未付诸实用。 2. Rivest 概括了 MD4 算法的设计目标: * 安全性。找到两个杂凑值相同的报文在计算上是不可行的,没有比蛮力攻击更有效的攻击方法; * 直接安全性。 MD4 的安全性不建筑在如因子分解的难度等任何假设上; * 速度。 MD4 适合于高速的软件实现,它基于对 32bit 操作数的一些简单的位操作; * 简单性。 MD4 尽可能简单,没有大的数据结构或复杂的程序; * 偏爱 Little-Endian 体系结构。 MD4 为微处理器体系结构 ( 尤其是 Intel 微处理器 ) 作了优化,更大和更快的计算机作必需的转换 ) 算法提出后, B.Boer 和 A.Bosseleass 成功地破译了算法的三轮中的两轮, R.merkle 成功地攻击了前二轮, E.Biham 对 2/3 的 MD4 讨论了可能的差分分析,虽然这些攻击未能扩展到整个算法,但 Rivest 巩固了算法了,产生了 MD5. MD5 的压缩函数 G 有一个碰撞,虽然这并不是说 MD5 是不安全的,但这与 MD5 的基本设计准则之一即设计一个无碰撞的压缩函数相违背,这不得不引起使用者的担心。 3. 关于
  • 1. NIST 和 NSA 一道设计了与 DSS 一起使用的安全 Hash 算法 (SHA) ,该标准是 SHS 。当然,该算法不仅仅可应用于数字签名中,它也可以应用到任何需要 Hash 算法的地方。 2. SHS 于 1992 年 1 月 31 日在 Federal Register 中公布, 1993 年 5 月 11 日起采纳为标准。 1994 年 7 月 11 日作了一个小的修改, 1995 年 4 月 17 日公布了修改了的版本。新的版本被称为 SHA-1
  • 1. RIPE-MD 算法是由欧共体 RIPE 计划 [RACE1992] 开发的杂凑算法,为 MD4 的变型,是针对已知的密码攻击设计的,杂凑值为 128bit 。 2. RIPE-MD 的改进型为 RIPEMD-160[Dobbertin 等 1996]. 3. RIPE - RACE Integrity Primitives Evaluation, 1988-1992 RACE - Research and development in Advanced Communications technologies in Europe
  • 1. RFC2104 列出了如下的 HMAC 设计目标: * 无需修改地使用现有的散列函数。特别地,散列函数的软件实现执行很快,且程序代码是公开的和容易获得的; * 当出现或获得更快的或更安全的散列函数时,对算法中嵌入的散列函数要能轻易地进行替换; * 保持散列函数的原有性能不会导致算法性能的降低; * 使用和处理函数的方式很简单; * 基于对嵌入散列函数合理的假设,对鉴别机制的强度有一个易懂的密码编码分析。 前两个目标对 HMAC 的普及很重要。 HMAC 将散列看作是一个“黑盒”。这有两个益处:第一,一个已有的散列函数实现可以作为 HMAC 实现中的一个块。在这种方式下,大量的 HMAC 程序代码能够预先打包,无需修改就可使用。第二,如果想在一个 HMAC 实现中替换一个给定的散列函数,所要做的工作就是移走现有的散列函数模块并加入新的散列函数。列为重要的是,如果嵌入散列函数已不够安全,可简单地用更安全的散列函数来替换嵌入的散列函数 ( 如用 RIPEMD-160 替换 MD5) ,使 HMAC 保持原有的安全性。 最后一个设计目标实际上是 HMAC 与其他提出基于散列方案相比的主要优点。 HMAC 能够证明嵌入散列函数提供的安全性有某些合理的密码分析强度。 2.
  • 证书和证书吊销列表的存储 ( 主要针对 X.509 格式来说 ) 是 X.500 和目录服务标准的主题
  • [X.500] ITU-T Recommendation X.500. The Directory – Overview of Concepts and Models. International Telecommunication Union. Geneva, Switzereland. 1997 (equivalent to ISO/IEC 9594-1; see also related parts 9594-2 through 9594-10) [X.509] ITU-T Recommendation X.509. Information Technology – Open System Interconnection – The Directory: Authentication Framework. 1997-6 (equivalent to ISO/IEC 9594-8, 1997) ISO/ITU-T 中有关目录的标准族通常称为 X.500 规范系列 , X.509 文档最初便是从其中产生的。 X.500 目录服务是一个高度复杂的信息存储机制,包括客户机 - 目录服务器访问协议、服务器 - 服务器通信协议、完全或部分的目录数据复制、服务器链对查询的响应、复杂搜寻的过滤功能等。意识到对目录访问控制的需要,包括某些环境中强认证的要求,是导致对 X.509 中证书和证吊销列表格式以及其它的 PKI 概念做详细规定的原因。 X.500 对 PKI 有着特别重要的作用,它定义了方案。即在实体的目录服务器访问入口处使用标准化方法来完成证书和证书吊销列表数据结构的存储访问。于是,无论支持 X.500 标准的目录服务是由哪一个产品商提供的, PKI 实施机构都能在它需要时正确地收回证书和证书吊销列表。虽然目录服务并没有像开发者期望的那样得到世界范围内的应用,但标准化的方案使它成为了很多 PKI 配置的重要组成部分。而且,由于将目录服务器链接起来在技术上很容易实现,所以当有必要在独立社区之间进行安全通信时,将这些独立分布的 PKI 连接在一起是可行的。
  • [X.509] ITU-T Recommendation X.509. Information Technology – Open System Interconnection – The Directory: Authentication Framework. 1997-6 (equivalent to ISO/IEC 9594-8, 1997) X.509 是 ISO 和 CCITT/ITU-T 的 X.500 标准系列的一部分,在 PKI 概念由小的、封闭式网络的试验环境变到大的、开放式分布环境的过程中,在很多方面 X.509 标准起了无可比拟的作用。 当实体在很大程度上相互不了解的情况下,证书使公钥技术变得可行。于是,将 PKI 应用于跨国公司或上百万的 Internet 用户时,必须要有一个可用的证书格式。为在多种工具和应用软件中实现互操作,证书的格式应加以标准化并被广为接受。 X.509 规范定义并标准化了一个通用的、灵活的证书格式。它被广泛采用的事实也证明了其技术适用于多种环境,作为国际标准的有效性是表现在被众多的生产商实现产品时采用了它。 X.509 的实用性来源于它为证书版本 3 和版本 2 中证书吊销列表所定义的的强有力的扩展机制。无论怎样定义及放置于证书或证书吊销列表中的扩展,这一机制都是很通用的。此外,一个重要的标志是指示了认证者是否必须了解并在认证过程中校验这些扩展。于是,证书和证书吊销列表内容可按照意愿被裁减来适用于特定的环境,或在其它特定的环境中不限制它的可用性。
  • LDAP 最早被看作是 X.500 目录访问协议 (DAP) 中的那些易描述、易执行的功能子集。随着时间的推移,这个用处颇大的功能“子集”被加以扩展以应用很多不同环境的需要。这些环境往往采用 LDAP 作为存储器 (X.500 相容的目录服务或其它 ) 访问协议。这使人们对 LDAP 中的” L” 还是否适用产生了疑问,正如 IETF 的一些“ Simple” 协议之中的” S” 有时会让人感 到奇怪一样。 生产商们在世界范围内发布 LDAP 版本 2[RFC1777] 和版本 3[RFC2251] 。此协议的扩展机制可以随时间发展用标准化的方法在其中加入新的功能。 IETF 已经成立了 LDAPext 工作来定义和标准化 LDAP 版本 3 的某些特殊而有用的扩展,比如访问控制机制。 与 X.500 一样,一个方案 (Schma)[RFC2587] 详细说明了适用于 LDAP 相兼容的信息存储,以此为 PKI 实体的证书和证书吊销列表信息存储提供基于标准化方法的存储。 当前, IETF 有三个工作组工作于 LDAP ,分别是 : l dapbis LDAP (v3) Revision l dapext LDAP Extension l dup LDAP Duplication/Replication/Update Protocols
  • 在本章中,先介绍一下 PKI 的构件组成,再谈一谈 PKI 中各构件的关系, PKI 运作与 CPS 的关系,最后谈一谈 PMI 与 TSA. 1. Functions of a PKI This section describes the major functions of a PKI. In some cases, PKIs may provide extra functions. 1.1 Registration This is the process whereby a subject first makes itself known to a CA (directly, or through an RA), prior to that CA issuing a PKC or PKCs for that subject. Registration involves the subject providing its name (e.g., common name, fully-qualified domain name, IP address), and other attributes to be put in the PKC, followed by the CA (possibly with help from the RA) verifying in accordance with its Certification Practice Statement (CPS) that the name and other attributes are correct. 1.2 Initialization Initialization is when the subject (e.g., the user or client system) gets the values needed to begin communicating with the PKI. For example, initialization can involve providing the client system with the public key or PKC of a CA, or generating the client system's own public-private key pair. 1.3 Certification This is the process in which a CA issues a PKC for a subject's public key, and returns that PKC to the subject or posts that PKC in a repository. 1.4 Key Pair Recovery In some implementations, key exchange or encryption keys will be required by local policy to be "backed up," or recoverable in case the key is lost and access to previously-encrypted information is needed. Such implementations can include those where the private key exchange key is stored on a hardware token which can be lost or broken, or when a private key file is protected by a password which can be forgotten. Often, a company is concerned about being able to read mail encrypted by or for a particular employee when that employee is no longer available because she is ill or no longer works for the company. In these cases, the user's private key can be backed up by a CA or by a separate key backup system. If a user or her employer needs to recover these backed up key materials, the PKI must provide a system that permits the recovery without providing an unacceptable risk of compromise of the private key. 1.5 Key Generation Depending on the CA's policy, the private-public key pair can either be generated by the user in his local environment, or generated by the CA. In the latter case, the key material may be distributed to the user in an encrypted file or on a physical token (e.g., a smart card or PCMCIA card). 1.6 Key Update All key pairs need to be updated regularly (i.e., replaced with a new key pair) and new PKCs issued. This will happen in two cases: normally, when a key has passed its maximum usable lifetime; and exceptionally, when a key has been compromised and must be replaced. 1.6.1 Key Expiry In the normal case, a PKI needs to provide a facility to gracefully transition from a PKC with an existing key to a new PKC with a new key. This is particularly true when the key to be updated is that of a CA. Users will know in advance that the key will expire on a certain date; the PKI, working together with PKC-using applications, should allow for appropriate keys to work before and after the transition. There are a number of ways to do this; see [CMP] for an example of one. 1.6.2 Key Compromise In the case of a key compromise, the transition will not be "graceful" in that there will be an unplanned switch of PKCs and keys; users will not have known in advance what was about to happen. Still, the PKI must support the ability to declare that the previous PKC is now invalid and shall not be used, and to announce the validity and availability of the new PKC. Note: compromise of a private key associated with a Root CA is catastrophic for users relying on that Root CA. If a Root CA's private key is compromised, that CA's PKC must be revoked and all PKCs subordinate to it must also be revoked. Until such time as the Root CA has been issued a new PKC and the Root CA issues PKCs to users relying upon it, users relying on that Root CA are cut off from the rest of the system, as there is no way to develop a valid certification path back to a trusted node. Further, users will likely have to be notified by out-of-band mechanisms about the change in CA keys. If the old key is compromised, any "update" message telling subordinates to switch to a new key could have come from an attacker in possession of the old key, and could point to a new public key for which the attacker already has the private key. It is possible to have anticipated this event, and "pre-placed" replacement Root CA keys with all relying parties, but some secure, out-of-band mechanism will have to be used to tell users to make the switch, and this will only help if the replacement key has not been compromised. Additionally, once the Root CA is brought back up with a new key, it will likely be necessary to re-issue PKCs, signed with the new key, to all subordinate users, since their current PKC would be signed with a now-revoked key. 1.7 Cross-certification A cross-certificate is a PKC issued by one CA to another CA which contains a public CA key associated with the private CA signature key used for issuing PKCs. Typically, a cross-certificate is used to allow client systems orend entities in one administrative domain to communicate securely with client systems or end users in another administrative domain. Use of a cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob, which was issued by CA_2. Cross-certificates can also be issued from one CA to another CA in the same administrative domain, if required. Cross-certificates can be issued in only one direction, or in both directions, between two CA's. That is, just because CA_1 issues a cross-certificate for CA_2, CA_2 does not have to issue a cross-certificate for CA_1. 1.8 Revocation When a PKC is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a PKC to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the PKC. X.509 defines one method of PKC revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time stamped list identifying revoked PKCs which is signed by a CA and made freely available in a public repository. Each revoked PKC is identified in a CRL by its PKC serial number. When a certificate-using system uses a PKC, that system not only checks the PKC signature and validity but also acquires a suitably-recent CRL and checks that the PKC serial number is not on that CRL. The meaning of "suitably-recent" may vary with local policy, but it usually means the most recently-issued CRL. A CA issues a new CRL on a regular periodic basis (e.g., hourly, daily, or weekly). CA's may also issue CRLs aperiodically. For example, if an important key is deemed compromised, the CA may issue a new CRL to expedite notification of that fact, even if the next CRL does not have to be issued for some time. (A problem of aperiodic CRL issuance is that end-entities may not know that a new CRL has been issued, and thus may not retrieve it from a repository.) An entry is added to the CRL as part of the next update following notification of revocation. An entry may be removed from the CRL after appearing on one regularly scheduled CRL issued beyond the revoked PKC's validity period. Leaving the revoked PKC on the CRL for this extra period allows for PKCs that are revoked prior to issuing a new CRL and whose invalidity date falls before the CRL issuing time to be accounted for. If the revoked PKC is not retained on the CRL for this extra period then the possibility arises that a revoked PKC may never appear on a CRL. An advantage of the CRL revocation method is that CRLs may be distributed by exactly the same means as PKCs themselves, namely, via untrusted communications and server systems. One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until the next CRL is issued - this may be up to one hour, one day, or one week depending on the frequency that the CA issues CRLs. As with the X.509 v3 PKC format, in order to facilitate interoperable implementations from multiple vendors, the X.509 v2 CRL format needed to be profiled for Internet use. This was done as part of [FORMAT]. However, PKIX does not require CAs to issue CRLs. On-line methods of revocation notification may be applicable in some environments as an alternative to the X.509 CRL. PKIX defines a protocol known as OCSP to facilitate on-line checking of the status of PKCs [OCSP]. On-line revocation checking may significantly reduce the latency between a revocation report and the distribution of the information to relying parties. Once the CA accepts the report as authentic and valid, any query to the on-line service will correctly reflect the PKC validation impacts of the revocation. However, these methods impose new security requirements; the PKC validator must trust the on-line validation service while the repository does not need to be trusted. 1.9 Certificate and Revocation Notice Distribution and Publication As alluded to in sections 3.1 and 3.5.8 above, the PKI is responsible for the distribution of PKCs and PKC revocation notices (whether in CRL form or in some other form) in the system. "Distribution" of PKCs includes transmission of the PKC to its owner, and may also include publication of the PKC in a repository. "Distribution" of revocation notices may involve posting CRLs in a repository, transmitting them to end-entities, or forwarding them to on-line responders.
  • 1. Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Certificate - Can refer to either an AC or a public key certificate. Where there is no distinction made the context should be assumed to apply to both an AC and a public key certificate. 2. PKI 的安全策略
  • 1. 介绍一个三者的定义,以及它们的逻辑关系 2. CA is a trusted authority that is responsible for creating, distributing and revoking digital certificate. RAs are used to enroll new users into a PKI. 3. 术语 Certification Authority (CA) - An authority trusted by one or more users to create and assign public key certificates. Optionally the CA may create the user's keys. It is important to note that the CA is responsible for the public key certificates during their whole lifetime, not just for issuing them. Certificate Policy (CP) - A named set of rules that indicates the applicability of a public key certificate to a particular community or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of public key certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. End-entity - A subject of a certificate who is not a CA in the PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the PMI.) 终端实体 -- 证书的主题 ( 此证书既非 PKIC 中的 CA ,也非 PMI 中的 AA 的证书 ) Public Key Certificate (PKC) - A data structure containing the public key of an end-entity and some other information, which is digitally signed with the private key of the CA which issued it. Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Registration Authority (RA) - An optional entity given responsibility for performing some of the administrative tasks necessary in the registration of subjects, such as: confirming the subject's identity; validating that the subject is entitled to have the values requested in a PKC; and verifying that the subject has possession of the private key associated with the public key requested for a PKC. Relying party - A user or agent (e.g., a client or server) who relies on the data in a certificate in making decisions. 依赖方 / 依托方 -- 依赖证书中的数据做决策的用户或代理。 Root CA - A CA that is directly trusted by an EE; that is, securely acquiring the value of a Root CA public key requires some out-of-band step(s). This term is not meant to imply that a Root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. Subordinate CA - A "subordinate CA" is one that is not a Root CA for the EE in question. Often, a subordinate CA will not be a Root CA for any entity but this is not mandatory. Subject - A subject is the entity (AA, CA, or EE) named in a certificate. Subjects can be human users, computers (as represented by Domain Name Service (DNS) names or Internet Protocol (IP) addresses), or even software agents. 主题 -- 主题是指在证书命名的实体 (AA, CA 或 EE) 。主题可以是人,计算机 ( 由 DNS 或 IP 地址表示 ) ,甚至是软件代理。 Top CA - A CA that is at the top of a PKI hierarchy. Note: This is often also called a "Root CA," since in data structures terms and in graph theory, the node at the top of a tree is the "root." However, to minimize confusion in this document, we elect to call this node a "Top CA," and reserve "Root CA" for the CA directly trusted by the EE. Readers new to PKIX should be aware that these terms are not used consistently throughout the PKIX documents, as [FORMAT] uses "Root CA" to refer to what this and other documents call a "Top CA," and "most-trusted CA" to refer to what this and other documents call a "Root CA.“ 4. PKI Entities: +---+ | C | +------------+ | e | <-------------------->| End entity | | r | Operational +------------+ | t | transactions ^ | | and management | Management | / | transactions | transactions | | | PKI users | C | v | R | -----------------+------+------------+---------------- | L | ^ ^ | | | | PKI management | | v | entities | R | +------+ | | e | <---------------------| RA |  --+ | | p | Publish +------+ | | | o | certificate | | | s | | | | I | v v | t | +------------+ | o | <---------------------------------| CA | | r | Publish certificate +------------+ | y | Publish CRL ^ | | | +---+ Management | transactions | v +------+ | CA | +------+
  • A PKI consists of five types of components [MISPC]: - Certification Authorities (CAs) that issue and revoke PKCs; - Organizational Registration Authorities (ORAs) that vouch for the binding between public keys and certificate holder identities and other attributes; - Certificate holders that are issued certificates and can sign digital documents and encrypt documents; - Clients that validate digital signatures and their certification paths from a known public key of a trusted CA; - Repositories that store and make available certificates and Certificate Revocation Lists (CRLs).
  • 1. Certification Practice Statement (CPS) - A statement of the practices which a CA employs in issuing public key certificates. CPS ,是 CA 在发行公钥证书时使用的实践 ( 惯例 ) 的声明。 2. VeriSign CPS V1.2 中文版目录 1 : 前言 2 : VeriSign 認證基礎建設 3 : 憑證制度運作之基礎 4 : 憑證申請程序 5 : 憑證申請書之確認 6 : 憑證之簽發 7 : 用戶同意接受憑證 8 : 憑證之使用 9 : 憑證之中止與廢止 10 : 憑證期效 11 : 簽發管理中心與 VERISIGN 之義務,以及該義務之限制 12 : 雜項條款 13 : 附錄
  • VeriSign 、 VeriSign 之簽發管理中心及其它經授權加入 VeriSign 公共憑證服務之 非 VeriSign 憑證簽發管理中心 ,從事簽發與管理 憑證 及維持以憑證為基礎之 公開金鑰基礎建設 之實務都列在 VeriSign CPS 中 VeriSign CPS 詳列 認證 程序並加以管理,涵蓋建立簽發管理中心,開始經營, 檔案庫 操作與 用戶 註冊等。公共憑證服務規定簽發、管理、使用、中止、廢止與更新憑證等事項。 VeriSign CPS 旨在提供法律之約束力,提出正式 通知 予所有依公共憑證服務之規範製作,使用及 批準憑證者 之各方 。 VeriSign CPS 在管理公共憑證服務中扮演舉足輕重的角色,如圖一所示 VeriSign CPS 只管理 VeriSign 所提供服務之一部分。 VeriSign 提供之其它服務可能不需要也不採用簽發管理中心體系。未來公共憑證服務必定會因應市場需求,逐漸發展並涵蓋其它結構。 VeriSign CPS 定期更新,提供最新的服務並改善公共憑證服務的基礎建設。 VeriSign CPS 敘述之認證過程,有如一個生命週期。首先成立簽發管理中心並開始運作,並涵蓋簽發管理中心一般的作業與 註冊 ;及憑證之使用、中止、廢止與期滿。此種方式之優點,在於以時間先後之次序排列,且與目前公私立機構所採行之實作準則相容。
  • 1. Privilege Management Infrastructure (PMI) - A collection of ACs, with their issuing AA's, subjects, relying parties, and repositories, is referred to as a Privilege Management Infrastructure. The TSA is a TTP that creates time stamp tokens in order to indicate that a datum existed at a particular point in time 2.Many systems use the PKC to perform identity based access control decisions (i.e., the identity may be used to support identity-based access control decisions after the client proves that it has access to the private key that corresponds to the public key contained in the PKC). For many systems this is sufficient, but increasingly systems are beginning to find that rule-based, role-based, and rank-based access control is required. These forms of access control decisions require additional information that is normally not included in a PKC, because the lifetime of the information is much shorter than the lifetime of the public-private key pair. To support binding this information to a PKC the Attribute Certificate (AC) was defined in ANSI and later incorporated into ITU-T Recommendation X.509. The AC format allows any additional information to be bound to a PKC by including, in a digitally signed data structure, a reference back to one specific PKC or to multiple PKCs, useful when the subject has the same identity in multiple PKCs. Additionally, the AC can be constructed in such a way that it is only useful at one or more particular targets (e.g., web server, mail host). Users of a PMI must be confident that the identity purporting to posess an attribute has the right to possess that attribute. This confidence may be obtained through the use of PKCs or it may be configured in the AC-using system. If PKCs are used the party making the access control decision can determine "if the AC issuer is trusted to issue ACs containing this attribute."
  • 1. 同时采用多种机制协作的方案也是可行的,一种机制用于 PMI 的某些方面,另一种机制用于其他方面。 2. 由于授权必须与认证 (Authentication) 联系在一起,所以这三种机制都可以与 PKI 的认证服务协同工作。
  • 本章主要介绍 PKI 实施中涉及到的一些实际问题。如各 CA 间的互操作性,验证证书时的协议实现 (CRL or OCSP) - 客户端应用与 CA 之间的配合,这涉及到各个 PKI 厂商的专用实现。
  • 这里是指广义的数字证书, X.509 只是其一个特例 1 RSA 证书, DH/DSA 证书的实现; 2. Public Key Certificate (PKC) - A data structure containing the public key of an end-entity and some other information, which is digitally signed with the private key of the CA which issued it. A certificate is a document, issued by a trusted agent, stating that the public key of the person named in the document has a certain value. 3. Different Digital Certificate Formats: X.509 , the identity certificate from the X.500 effort, with an attribute certificate added recently (perhaps borrowed from X9) PGP , an identity certificate format, the first to gain widespread usage and the form supporting the well known Web of Trust X9.59 (also known as AADS) is a mechanism that uses ACLs only, instead of certificates.  Specifically, the ACL is a bank's account database that has had a public-key field added, so that the bank can look up the account-holder's public key.  This makes the X9.59 ACL an authorization instrument, in SPKI terms, similar to the ACL implemented by SSH's file: .ssh/authorized_keys.  For more information on X9.59, see: http://www.garlic.com/~lynn Others , such as: Blaze, Feigenbaum and Lacy trust management forms (computing authorization with certified code) PolicyMaker KeyNote 4. In general, the certificate provides a statement by a trusted third party (eg. Issuer Authority or Certificate Authority or a person) that the signed key is authentic and truly belongs to the entity who claims it. The term certificate was proposed for the first time in 1978 by Loren M. Kohnfelder in his bachelor thesis at MIT. Since then, the concept of certificate has evolved to act as a token of trust to participate the process of authentication, authorisation, and authority delegation. A certificate contains a range of information, which varies between the different trust models: information about an entity (or non-entity): email address, public key and/or permission/credential. information about a certificate issuer: issuer-signature (created using the issuer's private key), issuer-public-key. information about the certificate itself: date and time of certificate issue, certificate-serial-number, validity-period, certificate-fingerprint. extra information: version certificate, Certificate Revocation List (CRL) version, class and type of the certificate and comments.
  • 版本号 : 标示证书的版本 (v1, v2, 或是 v3); 序列号 : 由证书颁发者分配的本证书的唯一标识符 ; 签名算法 : 签名算法标识符 ( 对 OID 加上相关参数组成 ), 用于说明本证书所用的数字签名算法 . 例如 , SHA-1 和 RSA 的标识符就用来说明数字签名是利用 RSA 对 SHA-1 杂凑加密 ; 颁发者 : 证书颁发者的可识别名 (DN), 这是必须说明的 ; 有效期 : 证书有效的时间段 . 本字段由” Not Valid Before” 和” Not Valid After” 两项组成 , 它们分别由 UTC 时间或一般的时间表示 ( 在 RFC2459 中有详细的时间表示规则 ) 主体 : 证书拥有者的可识别名 – 此字段必须是非空的 , 除非使用了其它的名字形式 ; 主体公钥信息 : 主体的公钥 ( 以及算法标识符 ) – 这是必须说明的 ; 颁发者唯一标识符 : 证书颁发者的唯一标识符 , 仅在版本 2 和版本 3 中要求 , 属于可选项 ; 该字段在实际使用中很少使用 , 并且不被 RFC2459 推荐使用 ; 主体唯一标识符 : 证书拥有者的唯一标识符 , 仅在版本 2 和版本 3 中要求 , 属于可选项 ; 该字段在实际使用中很少使用 , 并且不被 RFC2459 推荐使用 ; 扩展 : 可选的标准和专用扩展 ( 仅在版本 3 中使用 ), 包括: …… VERISIGN 憑證擴充欄 名稱 / 憑證 擴充欄 目的及描述 附屬英語 ( 或其他人類可閱讀之 ) 文字 憑證管理中心及次層級 憑證管理中心之一般 擴充欄 :     基本限制 請見 CPS § 2.4.6 不具重要性       cA=TRUE keyUsage 請見 CPS Section 2.4.7 不具重要性       keyCertSign (Bit 5 Set)       cRLSign (Bit 6 Set) 一般用戶之一般擴充欄 :     基本限制 See CPS § 2.4.6 不具重要性       cA=FALSE 憑證政策 See CPS § 2.4.8 不具重要性      See CPS § 2.4.9.3 「本合併引憑證及其使用方法,須嚴守 VeriSign VeriSign 標準 包含由 VeriSign 檔案庫(及 CPS 之規定,該 CPS 可由 VeriSign 檔案庫取得, 修飾語- 本 CPS 未來版本;特定之 網站為 : https://www.verisign.com; 電子郵件 Practices 非 VeriSign 檔案庫)所引用 地址為: CPS-requests@verisign.com; 地址 Reference 之文件,其中包含 VeriSign 為: VeriSign, Inc., 2593 Coast Ave., CPS 、憑證廢止清冊與其 Mountain View CA 94043 USA Copyright (c) 它資訊。 1997 VeriSign, Inc. 版權所有,否認特定保 證,責任有限。」 ( 自 5/15/97 起 , ,如欲取得此 CPS ,請來函: VeriSign, Inc., 1390 Shorebird Way, Mountain View, CA 94043 USA) VeriSign 標準 修飾語- 單一之 URL ,標示本 CPS 來 " https://www.verisign.com/repository/CPS " cpsURLs 源。 或類似之 URL 所引述之已註冊字串 ,其 內容顯示與憑證使用相關 已註冊字串 " 警告:此憑證之使用須嚴守憑證實作 VeriSign 標準 之警告、保證之否認、責 準則。憑證簽發管理中心 否認任何暗示或明示 修飾語- 任限制等事項。此 OBJECT 之保證,包括對特定目的之商業或配合之保證, NoticeID IDENTIFIER 會隨憑證顯示 且對於必然或因處罰所衍生之損害、或其它特定 於使用者媒介 ( 如 電腦或終 之損害,不負賠償責任。請見 VeriSign CPS 之內 端機 ) 的憑證瀏覽功能(並 容。 " 非包含於任何憑證中)。 OBJECT IDENTIFIER 所引 VeriSign 标准 述之已註冊字串,其內容 已註冊字串 " VeriSign 已註冊之未經證實的客體屬 修饰语- 說明簽發管理中心不擔保 性修飾語擴充值,不應視為簽發管理中心已確認 NSINotice 憑證中部份資料之正確 之資訊。 " 度。
  • 1. 在考虑证书的有效性或者可用性时除了简单的完整性检查还需要其它的机制。 证书验证包括确定以下内容: * 一个可信的 CA 已经在证书上签名 ( 即 CA 的数字签名被验证是正确的 ) 。注意这可能包括证书路径处理; * 证书有良好的完整性;即证书上的数字签名与签名者的公钥和单独计算出来的证书杂凑值一致; * 证书处在有效期内 ( 由证书中的 Not Valid Before 和 Not Valid After 两个参数来限定有效期 ) ; * 证书没有被吊销; * 证书的使用方式与任何声明的策略和 / 或使用限制相一致 ( 这由特殊的扩展来限定 ) 2. 关于综合密钥 / 证书生命周期管理的基本假设如下: * 密钥和证书生命周期的终端实体管理是不实际的; * 密钥 / 证书生命周期管理必须尽可能自动完成; * 密钥 / 证书生命周期管理必须尽可能对终端实体是不显眼的。 * 综合密钥 / 证书生命周期管理要求安全的运作和可信实体如: RA 、 CA 以及必要时这些部件相互作用的客户端软件等的合作。
  • VeriSign CPS 敘述之認證過程,有如一個生命週期。首先成立簽發管理中心並開始運作,並涵蓋簽發管理中心一般的作業與 註冊 ;及憑證之使用、中止、廢止與期滿。此種方式之優點,在於以時間先後之次序排列,且與目前公私立機構所採行之實作準則相容。 CA certification authority ,憑證管理中心 CK common key ,一般金鑰 CPS VeriSign Certification Practice Statement 憑證實作準則 CRL certificate revocation list 憑證廢止清冊 CSR certificate signing request 憑證簽章要求 DAM draft amendment (to an ISO standard) 擬稿修正條文 ( 符合國際標準組織 ISO 的標準 ) FIPS Federal Information Processing Standard 聯邦資料處理標準 FTP File Transfer Protocol 檔案傳輸協定 GMT Greenwich Mean Time 格林威治標準時間 HTTP Hypertext Transfer Protocol 超文字傳輸協定 HTTPS Hypertext Transfer Protocol with SSL 採用 SSL 的超文字傳輸協定 IA issuing authority 簽發管理中心 LRA local registration authority 地方註冊管理中心 LRAA local registration authority administrator 地方註冊管理中心主管 NSI nonverified subscriber information 未經證實之用戶資料 PCA VeriSign public primary certification authority 主要憑證管理中心 PCS VeriSign‘s public certification services VeriSign 公共憑證服務 PIN personal identification number 個人識別密碼 PKCS Public Key Cryptography 公開金鑰密碼法 標準 PKI public key infrastructure 公開金鑰基礎建設 RDN Relative Distinguished Name 易於辨識之名稱 RSA 一種 cryptographic system 密碼系統 ( 請見 定義 ) SET Secure Electronic Transaction 安全電子交易 S/MIME Secure Multipurpose Internet Mail Extensions 安全多用途網際信件延伸格式 SSL Secure Sockets Layer URL uniform resource locator 單一資源位址 VDPE VeriSign Distinguished Panel of Experts VeriSign 傑出的專家小組 VR VeriSign root VeriSign 根節點 VSP VeriSign Security Procedures VeriSign 保全程序 WWW or Web World Wide Web 全球資訊網 X.509 the ITU-T standard for certificates and their corresponding authentication framework 一種由 ITU-T ( International Telecommunication Union-T ;國際電訊聯盟)所發佈之憑證標準 以及對應的鑑別架構
  • 1. 关于交叉认证的所用到的信任模型,可以参阅 RSA Labs 的 John Linn 于 2000 年 11 月写的论文《 Trust Models and Management in Public-Key Infrastructures 》, .pdf 文档在 ftp://ftp.rsasecurity.com/pub/pdfs/PKIPaper.pdf 。
  • 1. Profiles A profile of the X.509 v3 PKC specification is a description of the contents of the PKC and which extensions must be supported, which extensions may be supported, and which extensions may not be supported. Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 2459) 2. Operational Protocols Operational protocols are required to deliver certificates and CRLs (or other certificate status information) to certificate using systems. Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP (RFC 2585) Internet X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP (RFC 2560) Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 (RFC 2559) Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3, <draft-ietf-pkix-ldap-v3-0x.txt> Limited AttributeCertificate Acquisition Protocol, <draft-ietf-pkix-laap-0x.txt> Diffie-Hellman Proof-of-Possession Algorithms, <draft-ietf-pkix-dhpop-0x.txt> 3. Management Protocols Management protocols are required to support on-line interactions between PKI user and management entities. There are two parts to a "management protocol." The first is the format of the messages that will be sent, and the second is the actual protocol that governs the transmission of those messages. Internet X.509 Certificate Request Message Format (RFC 2511) Internet X.509 Public Key Infrastructure Certificate Management Protocols (RFC 2510) Certificate Management Messages over CMS (RFC 2797) Using HTTP as a Transport Protocol for CMP, <draft-ietf-pkix-cmp-http-0x.txt> Using TCP as a Transport Protocol for CMP, <draft-ietf-pkix-cmp-tcp-0x.txt 4. Policy Outline As mentioned before, profiling certificates and specifying operational and management protocols only addresses a part of the problem of actually developing and implementing a secure PKI. What is also needed is the development of a certificate policy (CP) and certification practice statement (CPS), and then following those documents. The CP and CPS should address physical and personnel security, subject identification requirements, revocation policy, and a number of other topics. [POLPROC] provides a framework for certification practice statements. Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 2527) 5. Time-Stamp, Data Verification, and Data Certification Services Time stamping is a service in which a trusted third party - a Time Stamp Authority, or TSA - signs a message, in order to provide evidence that it existed prior to a given time. TSP also defines the role of a Temporal Data Authority, or TDA. A TDA is a Trusted Third Party (TTP) that creates a temporal data token. This temporal data token associates a message with a particular event and provides supplementary evidence for the time included in the time stamp token. A DVCS is a Trusted Third Party that verifies the correctness of specific data submitted to it. It also allows the delegation of trustworthy servers and allows for chaining of verifications. Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) (RFC 3161) Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (RFC 3029)
  • 1. MISPC, Minimum Interoperability Specifications for PKI Components  NIST developed the Minimum Interoperability Specifications for PKI Components (MISPC), Version 1 with the assistance of ten CRADA partners: AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola, Nortel (Entrust), Spyrus, and Verisign. The specification includes a certificate and CRL profile, message formats and basic transactions for a PKI issuing signature certificates. The specification includes support for multiple signature algorithms and transactions to support a broad range of security policies. This document has been formally published as a NIST Special Publication 800-15; it is available electronically in Microsoft Word (284K) or PostScript (954K) .   NIST has developed an updated specification with the help of CRADA partners to enhance the specification to support development of conforming PKI components. MISPC Version 2 is available for review and comment. The associated reference implementation is currently undergoing an upgrade and will be available second quarter of fiscal year 2001. 2. The PKI Forum is an international, not-for-profit, multi-vendor and end-user alliance whose purpose is to accelerate the adoption and use of Public-Key Infrastructure (PKI) products and services. The PKI Forum advocates industry cooperation and market awareness to enable organizations to understand and exploit the value of PKI in their e-business applications. Key objectives of the PKI Forum are to: * Accelerate the adoption and use of PKI as a critical enabler of e-business * Advocate industry cooperation in a vendor-neutral atmosphere * Enhance the value of PKI for customers and business partners * Increase confidence in deployment of PKI by customers and independent software vendors (ISVs)
  • 1.CP , Certificate Policy ; CPS , Certification Practice Statement ; 2.CPS A certification practice statement (CPS) is a legal document, created and published by a CA, that explains the CA’s certificate issuance and revocation policies. People and organizations use the CA’s CPS to determine the level of trust they can place in a CA 3.Certificate Policy A certificate policy (CP) explains the conditions and limitations of use for a digital certificate. In other words, a CP defines the level of trust a user can place in someone else’s digital certificate. A CP can be embedded in or referenced in a digital certificate.
  • 美国联邦政府的“证书策略建模” (MCS) 证书策略要比 CPS 处在更高的级别上,证书策略要考虑的是支持什么,而不是如何支持。 CPS 却是一个相当详细全面的技术和程序化的文档,它考虑的是支持基础设施的具体操作。 证书策略和 CPS 的角色 CPS – 认证惯例综述 1. CPS A certification practice statement (CPS) is a legal document, created and published by a CA, that explains the CA’s certificate issuance revcation policies. People and organizations use the CA’s CPS to determine the level of trust they can place in a CA. 2. Certificate Policy A certificate policy (CP) explains the conditions and limitions of use for a digital certificate. In other words, a CP defines the level of trust a use can place in someone else’s digital certificate. A CP can be embeded in or referenced in a digital certificate. 4. Liability and Other Legal Considerations Organizations should determine who assumes responsibility for losses if a PKI entity engages in or fails victim to fraud. For example, does the CA bear full responsibility for all losses? Or do members of the PKI share responsibility? After determining an organization’s legal rights and obligations, policies can be put in place to ensure that these responsibilities will be met.
  • PKI 的运作考虑包括 为使 PKI 发挥功能所必需的那些规程、组成和设施 ( 并不包括 PKI 操作本身 ). 1. 客户端软件 安全基础设施必须存在于应用之外,这些应用程序包括客户端应用程序、协议引擎、库、操作系统等。客户端的 PKI 构件必须是一个独立的库 ( 模块、工具包、 Java 小程序或其他任何形式 ) 。 在特殊的环境中,如 PDA ,设备没有能力在本地执行一些功能,可以将这些功能外置。但并非所有人都认为 PKI 的功能外置式是一种好的结构策略。 在设计一个公司的跨平台、多设备的 PKI 实施结构时,管理者必须要意识到这一点,认真考虑这种结构模型。 2. 离线运作 3. 物理安全 最敏感的 PKI 部件必须在高度安全的环境中被物理保护。 另外,必须意识到一点,在系统安全性和系统易用性之间总是有一些折中。 4. 硬件部件 为避免由于纯软件实现的 PKI 带来的风险,可以有选择的使用硬件部件。 5. 用户密钥的泄露 6. 灾难预防和恢复
  • 1. 数字签名的法律状况 世界各国对数字签名的立法情况,中国尚未对数字签名进行立法。 2. PKI 的法律框架:许可权,角色与责任,私有 PKI( 企业 PKI) 许可权 (License) : PKI 运营商是否需要先行取得运营牌照。 角色与责任:在 PKI 中的各方,如 CA 运营商、用户 (Subscriber) 、依托方 (Relying Party) ,软件开发商在法律事务中,各自不同的角色与责任 私用 PKI :在企业 / 组织内运作的 PKI ,相应的法律问题如何解决。 3. 密码管理政策与法规 ( 不同的密码管理政策 ) 世界各国不同的密码管理政策。
  • SSL 被设计成使用 TCP 来提供一种端到端的安全服务。 1. SSL Record Protocol SSL 记录协议为 SSL 连接提供两种服务: * 机密性:握手协议定义了共享的、可以用于对 SSL 有效载荷进行常规加密的密钥。 * 报文完整性:握手协议还定义了共享的、可以用来形成报文的鉴别码 (MAC) 的密钥。 2. SSL Change Cipher Protocol 3. SSL Alert Protocol 4. SSL Handshake Protocol 客户与服务器之间建立逻辑连接的 4 个阶段: * 建立安全能力:包括协议版本、会话 ID 、密文组、压缩方法和初始随机数; * 服务器鉴别和密钥交换:,服务器可以发送证书、密钥交换和证书请求。服务器发出结束 Hello 报文阶段的信号; * 客户鉴别和密钥交换,如果请求的话,客户发送证书,客户发送密钥交换,客户可以发送证书验证报文; * 结束,修改密文族并结束握手协议。
  • PGP 1. PGP 的成功,主要由于 Phil Zimmerman 的贡献。 PGP 提供了一种机密性和鉴别的服务,可以用于电子邮件和文件存储的应用。 2. PGP 的实际操作由 5 种服务组成:鉴别、机密性、压缩、电子邮件的兼容性和分段 / 重组。 3. 加密密钥和密钥环 PGP 使用了 4 种类型的密钥:一次性会话的常规密钥、公开密钥、私有密钥和基于口令短语 (Passphrase) 的常规密钥。 4. 公开密钥管理 S/MIME 1. RFC822 – MIME – S/MIME 2. S/MIME 的功能:加密的数据、签名的数据、 Clear-signed Data 和签名并且加密的数据。 3. S/MIME 证书的处理 (RFC2632) : 4. S/MIME 增强的安全服务 (RFC2634) : Signed Receipt 、 Security Label 和 Security mailing list 。
  • 1. IP 层的安全包括了 3 个功能域:鉴别、机密性和密钥管理。 2. IPSec 的使用,将使现有的许多系统安全手段 ( 如报文分析 ) 不再可行,因此, IPv6 、 IPSec 的采用将使互联网安全经历一个大的变化,一方面, IPSec 使增进了网络安全;另一方面, IPSec 使一些现有的安全手段无法使用。 3. 术语: AH – Authentication Header ESP – Encapsulating Security Payload Transport Mode Tunnel Mode SA – Security Association ISAKMP – Internet Security Association and Key Management Protocol
  • 2. IPSec 文档分类 体系结构:覆盖了定义 IPSec 技术的一般性概念、安全需求、定义和机制。 ESP( 封装安全有效负载 ) :覆盖了使用 ESP 进行分组加密和可选的鉴别有关分组的格式和一般问题。 AH( 鉴别首部 ) :覆盖了使用 AH 进行分组鉴别的分组的格式和一般问题。 加密算法:一组文档描述了怎样将不同的加密算法用于 ESP 。 鉴别算法:一组文档描述了怎样将不同的鉴别算法用于 AH 和 ESP 可选的鉴别选项。 密钥管理:描述密钥管理机制的文档。 解释域 (DOI) :包含了其他文档需要的为了彼此间相互联系的一些值。这些值包括经过检验的加密和鉴别算法的标识以及操作参数,例如密钥的生存期。
  • 1. SET 是开放的、设计用来保护 Internet 上信用卡交易的加密和安全规范。 IBM, Microsoft, Netscape, RSA, Terisa 和 VeriSign 都参加了规范的开发。 2. SET 本身不是一个支付系统。事实上,它是一个安全协议和格式的集合,使得用户可以以一种安全的方式,将已经存在的信用卡支付基础设施配置在开放网络,如 Internet 上。 3. 从本质上, SET 提供了三种服务: * 在交易涉及的各方之间提供安全的通信信道。 * 通过使用 X.509 v3 数字证书来提供信任。 * 保证机密性,因为信息只是在必要的时候、必要的地方才对交易各方可用。
  • 1. Time stamping is a service in which a trusted third party - a Time Stamp Authority, or TSA - signs a message, in order to provide evidence that it existed prior to a given time. 2. TSP also defines the role of a Temporal Data Authority, or TDA. A TDA is a Trusted Third Party (TTP) that creates a temporal data token. This temporal data token associates a message with a particular event and provides supplementary evidence for the time included in the time stamp token. Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) (RFC 3161)
  • DVCS – Data Validation and Certification Service A DVCS is a Trusted Third Party that verifies the correctness of specific data submitted to it. It also allows the delegation of trustworthy servers and allows for chaining of verifications. Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (RFC 3029)
  • 1. VeriSign – 专业 PKI 公司,提供证书服务,并有 OnSite 产品,全球最大的安全公司之一,最初是从 RSA DSI 分离出来的。现在中国已有合资公司出现。 2. Entrust – 最著名的 PKI 公司之一,其 PKI 产品在北美市场居有绝对优势。中国的 CFCA( 即金融认证中心 ) 的非 SET 证书 CA 部分即基于 Entrust 的产品与技术。 3. Baltimore – 最著名的 PKI 公司之一,总部位于爱尔兰, 20 世纪 90 年代后期转型做 PKI ,在欧洲 PKI 市场有相当大的影响力。其主打产品 Unicert V3.5 技术也相当先进。 4. RSA Security – 最著名的密码安全公司,拥有 RSA 算法的专利 ( 已于 2000 年放弃 ) ,最初只提供密码算法实现的 Toolkit ,近几年来开始提供 PKI 产品,其旗舰级产品 Keon 在技术上相当领先。另外, RSA Security 从今年开始展开了一系列的并购,其产品线已相当完整。 5. Others – 在这里,没有涉及到一些最著名的加密算法与密码卡厂商。
  • From: Kevin Wang Date: Tue Aug 8, 2000 10:29am Subject: Differences between Enterprise CA And Trade CA Hi, all: The following is someone told to me the differences between Enterprise CA and Trade CA , I think it is helpful. Enterprise CA is a model that your company hold everything of PKI including CA, RA, Directory Server etc. The best vendor on this is Entrust and Baltimore. RSA Security Inc. can provide this product too. In China, InfoSec, JIT, Koal and NetFront can provide Enterprise CA products. The Trade CA is another model that a trusted third party (offten are PKI vendors) will manage every thing for you, but maybe you can control the user enrollment process. The dominant vendor is Verisign. In China, CFCA (China Financial CA), CTCA (China Telecom CA) belong to Trade CA. The selection between them will base on a lot things, such as trust relationship, the control you have on the end users etc. You can surf these vendors' website and get more informaiton. http://www.infosec.com.cn/ http://www.jit.com.cn/ http://www.koal.com/ http://www.netfront.com.cn/ http://www.netfront.com/ http://www.rsasecurity.com/ http://www.verisign.com/ http://www.entrust.com/ http://www.baltimore.com/ http://www.openca.org/
  • 1. OpenCA Project (http://www.openca.org/) The OpenCA Project is a collaborative effort to develop a robust, full-featured and Open Source out-of-the-box Certification Authority implementing the most used protocols with full-strength cryptography world-wide. OpenCA is based on many Open-Source Projects. Among the supported software is OpenLDAP, OpenSSL, Apache Project, Apache mod_ssl. The project development is divided in two main tasks: studying and refining the security scheme that guarantees the best model to be used in a CA and developing software to easily setup and manage a Certification Authority. FAQs: What is the OpenCA PKI development ? TheOpenCA PKI development is a project aimed to the deveoping of a full PKI Toolkit anyone can use to setup their own CAs. All software used together with the one we directly code is under OS licenses so you have not the need to pay to manage your PKI. Obviously if you want to contribute to our project or to any of the project related with ours you can! What is the difference between the former OpenCA Project and the OpenCA PKI development ? None. The renaming of the project is due to the OpenCA LABS acting as a framework where PKI related projects (R&D) are grouped together. The OpenCA PKI development Project will countinue its work releasing ever more complete version of the OpenCA packages 2. OSCAR PKI Project (http://oscar.dstc.qut.edu.au/) What is Oscar? Oscar is a project aimed at designing and constructing a public key certification system from the ground up. The system will include all necessary components including, a Certificate Authority, Certificate repository and client interface. This will provide the infrastructure required to manage and administer a public key environment. The Oscar project aims to conform to existing and emerging standards such as the IETF PKIX, OSI X.509, and RSA PKCS standards. Oscar stands for O pen S ecure C ertificate AR chitechture. Note:Oscar is no longer undergoing active development. Instead you might want to take a look at µPKI [C] or JCSI [Java] 3. Jonah PKIX (http://www.mit.edu/pfl/) a freeware PKIX (see below) reference implementation (IBM). 4. pyCA (http://www.pyca.de/) The usage of cryptographic techniques promises secure usage of Internet services concerning authentication of clients and servers and authorized access to sensitive data. During the last two years it turned out that X.509 certificates, SSL and S/MIME are the relevant, widely adopted cryptographic standards for securing various Internet services like WWW, Mail, etc. However these standards require setting up a working X.509-based PKI (pulic key infrastructure). Although there is a quite lot of documentation and some example software for setting up a primitive PKI with an own certificate authority with the free package OpenSSL it seems that this task is not easy for most people. There is a lot of discussion on various mailing-lists, e.g. how to generate self-signed CA certificates, generate certificate requests with the famous WWW browsers and how to provide client certificates / certificate revocation lists for download, etc. Additionally if the certification business of an organization gets only a little bit more serious one has to take care about critical security issues. pyCA tries to make it easier for people to set up and run a organizational certificate authority which fulfills the need for a fairly secure certification processing. The package also tries to reduce administrative tasks and user's frustration by providing a comfortable web interface to users contacting the certificate authority. 5. Mozilla Open Source PKI Project (http://www.mozilla.org/projects/security/pki/) Open source PKI projects include: Network Security Services (NSS) . Libraries designed to support cross-platform development of security-enabled server applications. Applications built with NSS can support SSL v2 and v3 , TLS , PKCS #5 , PKCS #7 , PKCS #11 , PKCS #12 , S/MIME , X.509 v3 certificates, and other security standards. The Sun-Netscape Alliance uses NSS to support these standards in a wide range of products, including iPlanet Certificate Management System, iPlanet Web Server, iPlanet Directory Server, and iPlanet Messaging Server. NSS also provides the security foundation for Netscape Communicator. Network Security Services for Java (JSS) . A Java interface to NSS that supports most of the security standards and encryption technologies supported by NSS. JSS also provides a pure Java interface for ASN.1 types and BER/DER encoding. Personal Security Manager (PSM) . Libraries and a daemon designed to support cross-platform development of security-enabled client applications. Built on top of NSS, these libraries are currently being used by the Sun-Netscape Alliance for ongoing development of a security module for use with Netscape Communicator 4.7 and Seamonkey. PKCS #11 Conformance Testing . Test suites designed to test PKCS #11 implementations. Open Source PKI Goals Improve the quality, scalability, and feature set of security code used to create PKI products. Encourage the development and deployment of PKI-enabled applications and services throughout the industry, including support for PKI features in more open source applications. Improve confidence in security software by encouraging open review of source code. Accelerate the growth of a standards-based security foundation for ecommerce and the Internet. 6. MISPC Reference Implementation ( http://csrc.nist.gov/pki/mispc/welcome.html ) MISPC, Minimum Interoperability Specifications for PKI Components  NIST developed the Minimum Interoperability Specifications for PKI Components (MISPC), Version 1 with the assistance of ten CRADA partners: AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola, Nortel (Entrust), Spyrus, and Verisign. The specification includes a certificate and CRL profile, message formats and basic transactions for a PKI issuing signature certificates. The specification includes support for multiple signature algorithms and transactions to support a broad range of security policies. This document has been formally published as a NIST Special Publication 800-15; it is available electronically in Microsoft Word (284K) or PostScript (954K) .   NIST has developed an updated specification with the help of CRADA partners to enhance the specification to support development of conforming PKI components. MISPC Version 2 is available for review and comment. The associated reference implementation is currently undergoing an upgrade and will be available second quarter of fiscal year 2001. NIST developed the Minimum Interoperability Specifications for PKI Components (MISPC), Version 1 with the assistance of ten partners: AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola, Nortel (Entrust), Spyrus, and Verisign. The specification includes a certificate and CRL profile, message formats and basic transactions for a PKI issuing signature certificates. Also, it includes support for multiple signature algorithms and transactions to support a broad range of security policies. This document is available at the MISPC WWW page. Along with the specification, there is a reference implementation that is available only by ordering a CDROM from NIST. The CDROM does not contain cryptographic support.
  • OpenSSL Project 源于 SSLeay, 由 Eric Young 发起。 Open Source 的实现, Apache-style license. 2. CDSA – Common Data Security Architecture Intel 开发,由 TOG 标准化,其参考实现支持 Windows 及 Linux ,类 BSD License. 3. RSA BSAFE 商用软件包,需要付费
  • 1. ITU-T Recommendations X.208, X.209, X.500, X.509 X.509 v4 draft 2. IETF PKIX, SPKI, TLS, OpenPGP, ……Workgroup. http://www.ietf.org/ 3. SET 4. PKCS http://www.rsasecurity.com/rsalabs/pkcs/index.html 5. 其它 互操作性
  • 指明现有 PKI 的不足之处,如 Trust Model , Privacy 以及应用标准化等方面存在的问题,并说明下一步可能的进展。主要内容基于 1. Conventional Public Key Infrastructure: An Artefact Ill-Fitted to the Needs of the Information Society ( http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html ) 2. Ten Risks in PKI, (http://www.counterpane.com/pki-risks.html), By Carl Ellison, Bruce Schneier 3. PKI POLICY PITFALLS (http://www.infosecuritymag.com/articles/july01/features_pki.shtml), By MIKE BOBBITT 和其它方面的一些文章和报道。
  • 1. WPKI (Wireless PKI) – PKI 在无线领域的发展 http://www.wapforum.org/ 2. LPKI (Lightweight PKI) – 针对传统 PKI 过于复杂、庞大的情况,如何将 PKI“ 瘦”下来,已成为不少人们的思考。 Thin PKI (http://www.mobilephones-tng.com/v100/pkidawn.html) 3. Traditional PKI ,即 Classical PKI
  • 1. PEM (Hierarchy), PGP (Web of Trust), ICE-TEL (Web of Hierarchy), The Solar Trust Model, SDSI/SPKI 2. 王曙,曾晓涛,伍思仪,“ PKI 中的常见信任模型 ”, 2001 年 7 月 (http://www.whizlabs.net/topic/topics.html)
  • 这一部分,尚未认真整理,下面只是 copy&paste 过来的一些内容。 asymmetric cryptography : defined originally by Diffie and Hellman, a cryptographic system using different keys for encipherment and decipherment such that one of the keys (private key) can not be derived efficiently from the other (public key). certificate : a digitally signed data record communicating some information from the signer (issuer) of the certificate to the verifier of the certificate.  A certificate differs from a general signed message usually in that: the data structure is well defined so that a computer can interpret the structure, and the certificate's ``message'' is of the form ``to whom it may concern'', rather than addressed to a specific party Certificate Authority : in the X.509 world, a special certificate issuing entity, usually part of a hierarchy, responsible for issuing all certificates to end entity keyholders. digital signature : a computation with a private key and typically the hash of a document or data record such that any entity in possession of the matching public key can verify computationally that the computation was performed by the associated private key and that the signed document has not changed since the signature was computed. hash : a cryptographic computation over a message yielding a fixed length quantity (the hash value) such that it is computationally difficult to find any two different input messages yielding the same hash value.  The ``strength of a hash'' is a reference to the difficulty of finding such message pairs. keyholder : the holder of the private key. non-repudiation : the notion that the keyholder is legally liable for any statement digitally signed by that keyholder's signature key. PGP : Pretty Good Privacy -- an early public key application, defining the first public key infrastructure to be widely deployed. PKI : Public Key Infrastructure -- a mechanism to permit the distributed use of public keys, involving certificates that bind information of interest to public keys private key : a key in an asymmetric cryptosystem that is kept secret and held by one entity, called the keyholder. public key :  a key in an asymmetric cryptosystem that need not be kept secret and is often SDSI : Simple Distributed Security Infrastructure secret key : a key in a symmetric cryptosystem. speaks for : the notion that a private digital signature key speaks digitally signed statements in cyberspace on behalf of the keyholder SPKI : Simple Public Key Infrastructure symmetric cryptography : the original kind of cryptography, in which the same key is used for both encipherment and decipherment. Web of Trust: a mechanism for fault tolerance of certificate signature , associated with PGP. X.509 : a data structure defined as part of the X.500 global directory effort, designed to bind an X.500 distinguished name to a public key.  The presumption in X.509 is that the named entity is the keyholder of the associated public key.  In some cases, it is assumed that the public key speaks for the named entity. Attribute Authority (AA) - An authority trusted by one or more users to create and sign attribute certificates. It is important to note that the AA is responsible for the attribute certificates during their whole lifetime, not just for issuing them.   属性认证中心 -- 一或多个用户信任的生成并签发属性证书的认证中心。重要的需要指出的是, AA 在属性证书的整个生命周期中都要负责任,而非仅仅签发它们。 Attribute Certificate (AC) - A data structure containing a set of attributes for an end-entity and some other information, which is digitally signed with the private key of the AA which issued it. 属性证书 -- 包含终端实体的一系列属性或其它信息的数据结构,使用签发它的 AA 的私钥进行数字签名得到。 Certificate - Can refer to either an AC or a public key certificate. Where there is no distinction made the context should be assumed to apply to both an AC and a public key certificate. Certification Authority (CA) - An authority trusted by one or more users to create and assign public key certificates. Optionally the CA may create the user's keys. It is important to note that the CA is responsible for the public key certificates during their whole lifetime, not just for issuing them. Certificate Policy (CP) - A named set of rules that indicates the applicability of a public key certificate to a particular community or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of public key certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. Certification Practice Statement (CPS) - A statement of the practices which a CA employs in issuing public key certificates. End-entity - A subject of a certificate who is not a CA in the PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the PMI.) 终端实体 -- 证书的主题 ( 此证书既非 PKIC 中的 CA ,也非 PMI 中的 AA 的证书 ) Public Key Certificate (PKC) - A data structure containing the public key of an end-entity and some other information, which is digitally signed with the private key of the CA which issued it. Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Privilege Management Infrastructure (PMI) - A collection of ACs, with their issuing AA's, subjects, relying parties, and repositories, is referred to as a Privilege Management Infrastructure. Registration Authority (RA) - An optional entity given responsibility for performing some of the administrative tasks necessary in the registration of subjects, such as: confirming the subject's identity; validating that the subject is entitled to have the values requested in a PKC; and verifying that the subject has possession of the private key associated with the public key requested for a PKC. Relying party - A user or agent (e.g., a client or server) who relies on the data in a certificate in making decisions. 依赖方 / 依托方 -- 依赖证书中的数据做决策的用户或代理。 Root CA - A CA that is directly trusted by an EE; that is, securely acquiring the value of a Root CA public key requires some out-of-band step(s). This term is not meant to imply that a Root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. Subordinate CA - A "subordinate CA" is one that is not a Root CA for the EE in question. Often, a subordinate CA will not be a Root CA for any entity but this is not mandatory. Subject - A subject is the entity (AA, CA, or EE) named in a certificate. Subjects can be human users, computers (as represented by Domain Name Service (DNS) names or Internet Protocol (IP) addresses), or even software agents. 主题 -- 主题是指在证书命名的实体 (AA, CA 或 EE) 。主题可以是人,计算机 ( 由 DNS 或 IP 地址表示 ) ,甚至是软件代理。 Top CA - A CA that is at the top of a PKI hierarchy. Note: This is often also called a "Root CA," since in data structures terms and in graph theory, the node at the top of a tree is the "root." However, to minimize confusion in this document, we elect to call this node a "Top CA," and reserve "Root CA" for the CA directly trusted by the EE. Readers new to PKIX should be aware that these terms are not used consistently throughout the PKIX documents, as [FORMAT] uses "Root CA" to refer to what this and other documents call a "Top CA," and "most-trusted CA" to refer to what this and other documents call a "Root CA."
  • 以下面这些进行分类: 1. 标准 2. 论文 3. 书籍 4. 邮件列表 , Newsletter 5. 其它
  • 主要的运营商和软件厂商 ( 这只是我一下子想到并列出来的,当然还有很多相关的 PKI 厂商与产品 ) 1. CTCA ( 即中国电信 CA ,由创原世纪等完成 ) 2. 外经贸部 CA - 国富安 (http://www.cacenter.com.cn/) 3. CFCA (即中国金融认证中心, http://www.cfca.com.cn/ ) 4. CPCA (即国家邮政总局 CA ) 5. 协卡体系 ( 即上海证书管理中心, http://www.sheca.com/) 6. 北京 CA(http://www.bjca.com/) 7. 信安世纪 (http://www.infosec.com.cn/) 8. 诺方信业 (http://www.netfront.com.cn/) 9. 德达创新 (http://www.datatrust.com.cn/) 10. 吉大正元 (http://www.jit.com.cn/) 11. 北京安软 (http://www.anyware.comcn/)
  • If you have an questions or comments, please mailto me.

Transcript

  • 1. AKA安全沙龙:PKI漫谈 PKI 漫谈 Kevin Wang
  • 2. 第 0 章 绪论
  • 3. §0.1 What’s PKI? PKI , Short for Public Key Infrastructure. PKI 正在快速地演进中,从不同的角度出发, 有不同的定义 . PKI 是一个用公钥概念和技术来实施和提供安 全服务的具有普适性的安全基础设施 .
  • 4. PKI 的组成
  • 5. §0.2 PKI 基础 公钥密钥学 (Public Key Cryptography) 公钥密码学解决的核心问题是密钥分发 . 目录服务 (Directory Services) 目录服务的目的是建立全局 / 局部统一的命令 方案 . 数字证书 (Digital Certificate)
  • 6. 密码学与信息安全 信息的私密性 (Privacy) 对称加密 信息的完整性 (Integrity) 数字签名 信息的源发鉴别 (Authentication) 数字签名 信息的防抵赖性 (Non-Reputation) 数字签名 + 时间戳
  • 7. §0.3 PKI 的由来 信任管理 从根本上讲, PKI 是表示和管理信任关系的工 具; 数字化、电子化社会的基础之一 在数字化社会中,实体间建立信任关系的关键 是能彼此确定对方的身份;
  • 8. 互联网困境
  • 9. §0.4 PKI 进展 标准化进展 IETF PKIX 、 SPKI Workgroup ; NIST , DOT (Department of the Treasury) ; TOG (The Open Group) ; and others (include WAPForum, etc) 产品与工程 From Pilot Projects to Practices, Various Vendors and Products PKI 应用 MS Outlook/Netscape Messanger (S/MIME), IE/Navigator (SSL/TLS), PGP
  • 10. PKI – Queensland’s Toad?
  • 11. 第 1 章 密码学
  • 12. §1.1 密码学的历史与发展 密码学的演进 单表代替- > 多表代替- > 机械密 ( 恩格玛 ) - > 现代密码学 ( 对称与非对称密码体制 ) - > 量子密码学 密码编码学和密码分析学 应用领域 军事,外交,商业,个人通信,古文化研究等
  • 13. §1.2 传统密码学 历史悠久,最古老与最现代的密码学 基本特点:加密和解密采用同一个密钥 let C = Cipher text, P = Plain text, k is key, E()/D() is the encryption/decryption function, then C=E(P, k), P=D(C, k) 基本技术 替换 / 置换和移位
  • 14. DES DES 是第一个得到广泛应用的密码算法; DES 是一种分组加密算法,输入的明文为 64 位,密钥为 56 位,生成的密文为 64 位; DES 是一种对称密码算法,源于 Lucifer 算法 ,其中采用了 Feistel 网络 (Feistel Network) , 即 Li = Ri −1 Ri = Li −1 ⊕ f ( Ri −1 , K i ) DES 已经过时,基本上认为不再安全; http://dir.yahoo.com/Computers_and_Internet/Security_and_E
  • 15. IDEA Xuejia Lai 和 James Massey 提出; IDEA 是对称、分组密码算法,输入明文为 64 位,密钥为 128 位,生成的密文为 64 位; IDEA 是一种相对较新的算法,虽有坚实的理 论基础,但仍应谨慎使用 ( 尽管该算法已被证 明可对抗差分分析和线性分析 ) ; IDEA 是一种专利算法 ( 在欧洲和美国 ) ,专利 由 Ascom-Tech AG 拥有 ; PGP 中已实现了 IDEA ;
  • 16. RC 系列 RC 系列是 Ron Rivest 为 RSA 公司设计的一系 列密码 :  RC1 从未被公开,以致于许多人们称其只出现在 Rivest 的记事本上;  RC2 是变长密钥加密密法; (RC3 在设计过程中在 RSADSI 内被攻破 );  RC4 是 Rivest 在 1987 年设计的变长密钥的序列密码;  RC5 是 Rivest 在 1994 年设计的分组长、密钥长的迭代 轮数都可变的分组迭代密码算法; DES(56),RC5-32/12/5, RC5-32/12/6,RC-32/12/7 已 分别在 1997 年被破译;
  • 17. AES Candidate 和 Rijndeal AES 评选过程 最后的 5 个候选算法: Mars, RC6, Rijndael, Serpent, and Twofish Rijndael 算法的原型是 Square 算法,其设计策 略是宽轨迹策略 (Wide Trail Strategy) ,以针对 差分分析和线性分析; Rijndael 是迭代分组密码,其分组长度和密钥 长度都是可变的;为了满足 AES 的要求,分组 长度为 128bit ,密码长度为 128/192/256bit ,相 应的轮数 r 为 10/12/14 。
  • 18. Summary DES 是应用最广泛的对称密码算法 ( 由于计算 能力的快速进展, DES 已不在被认为是安全的 ); IDEA 在欧洲应用较多; RC 系列密码算法的使用也较广 ( 已随着 SSL 传遍全球 ); AES 将是未来最主要,最常用的对称密码算法 ;
  • 19. §1.3 公钥密码学 Whitefield Diffie , Martin Hellman ,《 New Directions in Cryptography 》 ,1976 公钥密码学的出现使大规模的安全通信得以实 现 – 解决了密钥分发问题; 公钥密码学还可用于另外一些应用:数字签名 、防抵赖等; 公钥密码体制的基本原理 – 陷门单向函数 (troopdoor one-way function)
  • 20. RSA Ron Rivest, Adi Shamir 和 Len Adleman 于 1977 年研制并于 1978 年首次发表; RSA 是一种分组密码,其理论基础是一种特殊 的可逆模幂运算,其安全性基于分解大整数的 困难性; RSA 既可用于加密,又可用于数字签名,已得 到广泛采用; RSA 已被许多标准化组织 ( 如 ISO 、 ITU 、 IETF 和 SWIFT 等 ) 接纳; RSA-155(512 bit), RSA-140 于 1999 年分别被分
  • 21. RSA (cont.) 设 n 是两个不同奇素数之积,即 n = pq , 计算其欧拉函数值 Φ(n)=(p-1)(q-1). 随机选一整数 e,1≤e<Φ(n), (Φ(n),e)=1. 因而在模 Φ(n) 下 ,e 有逆元 d = e −1 mod(n) 取公钥为 n,e, 秘密钥为 d.(p,q 不再需要,应该被舍弃,但绝不可泄露 ) Ek ( x) = x e mod n, x ∈ Z n 定义加密变换为 解密变换为 y ) = y d mod n, y ∈ Z n Dk (
  • 22. DH/DSA Diffie-Hellman(DH) 是第一个公钥算法,其安全 性基于在有限域中计算离散对数的难度; DH 可用于密钥分发,但不能用于加 / 解密报文 ; DH 算法已得到广泛应用,并为许多标准化组 织 (IETF 等 ) 接纳; DSA 是 NIST 于 1991 年提出的数字签名标准 (DSS), 该标准于 1994 年 5 月 19 日被颁布; DSA 是 Schnorr 和 Elgemal 签名算法的变 型 ,DSA 只能用于数字签名不能用于加密;
  • 23. Elgemal Elgemal 于 1985 年基于离散对数问题提出了一 个既可用于数字签名又可用于加密的密码体制 ; ( 此数字签名方案的一个修改被 NIST 采纳为 数字签名标准 DSS) Elgemal,Schnorr 和 DSA 签名算法都非常类似。 事实上,它们仅仅是基于离散对数问题的一般 数字签名的三个例子。
  • 24. Summary RSA 是最易于实现的; Elgemal 算法更适合于加密; DSA 对数字签名是极好的,并且 DSA 无专利 费,可以随意获取; Diffie-Hellman 是最容易的密钥交换算法;
  • 25. §1.4 单向杂凑 (Hash) 函数 杂凑 (Hash) 函数是将任意长的数字串 M 映射 成一个较短的定长输出数字串 H 的函数,我们 关心的通常是单向杂凑函数; 强单向杂凑与弱单向杂凑 – ( 无碰撞性 collision-free) ; 单向杂凑函数的设计理论 杂凑函数除了可用于数字签名方案之外,还可 用于其它方面,诸如消息的完整性检测、消息 的起源认证检测等 常见的攻击方法
  • 26. MD 系列 Ron Rivest 设计的系列杂凑函数系列 :  MD4[Rivest 1990, 1992, 1995; RFC1320]  MD5 是 MD4 的改进型 [RFC1321]  MD2[RFC1319], 已被 Rogier 等于 1995 年攻破 较早被标准化组织 IETF 接纳,并已获得广泛 应用 安全性介绍
  • 27. SHA 和 SHA-1 NIST 和 NSA 为配合 DSS 的使用,设计了安全 杂凑标准 (SHS) ,其算法为 SHA[FIPS PUB 180] ,修改的版本被称为 SHA-1[FIPS PUB 180-1] SHA/SHA-1 采用了与 MD4 相似的设计准则, 其结构也类似于 MD4 ,但其输出为 160bit 目前还没有针对 SHA 有效的攻击
  • 28. RIPE-MD 欧共体的 RIPE[RACE 1992] 计划下开发的杂凑 算法,为 MD4 的变型,是针对已知的密码攻 击而设计的,杂凑值为 128bit; RIPE-MD 的改进型为 RIPEMD-160 ;
  • 29. HMAC HMAC 是利用散列函数计算报文鉴别码 值 HMAC 能够证明嵌入散列函数提供的安 全性有某些合理的密码分析强度
  • 30. SHA 与 MD4 和 MD5 的比较 MD4 SHA MD5Hash 值 128bit 160bit 128bit分组处理长 512bit 512bit 512bit基本字长 32bit 32bit 32bit步数 48(3*16) 80(4*20) 64(4*16)消息长 ≤2^64bit 2^64bit 不限基本逻辑函 3 3( 第 2,4 轮相 4数常数个数 3 同) 4 64速度 约为 MD4 的 约为 MD4 的 3/4 1/7
  • 31. §1.5 各种算法的特点 对称密码算法 加 / 解密速度快,但密钥分发问题严重 非对称密码算法 加 / 解密速度较慢,但无密钥分发问题 杂凑函数 计算速度快,结果长度统一
  • 32. §1.6 进一步的读物 Bruce Schneier, 《 Applied Cryptography: Protocols, algorithms and source code in C 》 ,1996 Simon Singh, 《 The Code Book 》 ,1999 冯登国,裴定一 , 《密码学导引》 , 科学出版社 , 1999 王育民,刘建伟 , 《通信网的安全 -- 理论与技术》 , 西安电子科技大学出版社 , 1999 梁晋,施仁,王育民等 , 《电子商务核心技术 – 安 全电子易协议的理论与设计》 ,2000 William Stallings 著,杨明,胥光辉,齐望东等译 , 《 密码编码学与网络安全:原理与实践 ( 第二版 ) 》 , 电 子工业出版社, 2001
  • 33. 第 2 章 X.500 目录服务和数字证书
  • 34. §2.1 概述 证书和证书吊销列表 (CRL) 的存储 ( 主要针 对 X.509 格式来说 ) 是 X.500 和目录服务标 准的主题
  • 35. §2.2 X.500 目录服务 X.500, ITU-T Recommendation: The Directory – Overview of Concepts and Models. X.500 目录服务是一个高度复杂的信息存储机 制,包括客户机 - 目录服务器访问协议、服务 器 - 服务器通信协议、完全或部分的目录数据 复制、服务器链对查询的响应、复杂搜寻的过 滤功能等 . X.500 对 PKI 的重要性 .
  • 36. §2.3 X.509 数字证书 X.509, ITU-T Recommendation: Information Technology – Open System Interconnection – The Directory: Authentication Framework X.509 是 X.500 标准系列的一部分,在 PKI 的发 展中, X.509 起到了无可比拟的作用 . X.509 定义并标准化了一个通用的、灵活的证 书格式 . X.509 的实用性来源于它为 X.509 v3 和 X.509 v2 CRL 定义的强有力的扩展机制 .
  • 37. §2.4 LDAP 协议 LDAP, Lightweight Directory Access Protocol. LDAP 的发展 LDAP v1, v2, v3, ldapbis, ldapext, ldup
  • 38. 第 3 章 PKI 及其构件
  • 39. §3.1 综述 PKI 是生成、管理、存储、分发和吊销基于公 钥密码学的公钥证书所需要的硬件、软件、人 员、策略和规程的总和。 PKI 的构件, PKI 的安全策略
  • 40. §3.2 PKI 构件 A PKI includes the following components: CA, RA, Directory, EE, PKI-enabled Applications, Certificate Status Checking PKI 构件及证书生命周期 ( 接下页 )
  • 41. PKI 构件与证书生命周期 ( 接上页 )
  • 42. PKI 实体
  • 43. 常见的信任模型
  • 44. VeriSign PKI 层次图
  • 45. §3.3 PKI 运作与 CPS CPS 是 CA 在发行公钥证书时使用的实践 (practice, 惯例 ) 的声明,统率 PKI 的整体运作 RFC2527 - Certificate Policy and Certification Practices Framework VeriSign, Entrust, DoD PKI, SHECA, CFCA etc.
  • 46. VeriSign CPS 处于中心角色
  • 47. §3.4 PMI 与 TSA PMI, 即 Privilege Management Infrastructure, 在 ANSI, ITU X.509 和 IETF PKIX 中都有定义 特权管理服务 (PKI Based) 依赖于策略,所谓策 略就是将实体、组和角色与相应的特权进行映 射 ( 如 列出实体名称或角色被允许还是禁止的 权限 ). TSA, 即 Time Stamp Authority[RFC3162, Time- Stamp Protocol] TSA 是一个产生时间戳记号的可信第三方,该 时间戳记号用以显示数据在特定时间前已存在
  • 48. 特权管理基础设施机制 实现特权管理基础设施 (PMI) 有很多机制 ,大致可以分为三类: 基于 Kerberos 基于策略服务器 基于属性证书 原理 对称密码技术 有一个中心服务器 , 创建 AC , PKI 、维护和验证身份、组和 优点 性能诱人 角色 控制高度集中,单点管理 完全分布处理, 具有失败拒绝的 缺点 不便于密钥管理 容易成为通信的瓶颈 优点 性能不高 ( 原因是 ,单点失败 基于公钥的操作 ) 适用环境 有大量的实时事 是地理上在一起的实体环 是需要支持不可 务处理环境中的 境的最好选择,有很强的 否认服务的授权 授权 中心管理控制功能 的最佳选择 其它 RFC1510, 实现有 DCE, SESAME
  • 49. 第 4 章 PKI 实践 – 技术 问题
  • 50. §4.1 数字证书 证书与数字证书 Loren M. Kohnfelder, 1978 (bachelor thesis) 数字证书的用途 Authentication, Authorization and Authority Delegation 常见的数字证书格式 X.509, PGP, SDSI/SPKI, X9.59(AADS), AC, Others
  • 51. X.509 数字证书 (VeriSign)
  • 52. §4.2 证书验证与证书生命周期 证书有效性或可用性验证 密钥 / 证书生命周期 初始化阶段:终端实体注册 -> 密钥对产生 -> 证书创建和密钥 / 证书分发,证书分发,密钥 备份 颁发阶段:证书检索,证书验证,密钥恢复, 密钥更新 取消阶段:证书过期,证书恢复,证书吊销, 密钥历史,密钥档案
  • 53. Cert Lifecycle in VeriSign CPS
  • 54. §4.3 交叉认证 交叉认证是把以前无关的 CA 连接在一起的机 制 交叉认证可以是单向的,也可以是双向的 不同的交叉认证信任模型 Subordinated Hierarchy , Cross-certified Mesh , Hybrid , Bridge CA , Trust Lists etc. 域内交叉认证,域外交叉认证 约束 名字约束,策略约束,路径长度约束
  • 55. §4.4 标准化 (PKIX 文档概况 ) 概貌 (Profiles) – RFC2459 运作协议 – RFC2559, RFC2560, RFC2585, etc. 管理协议 – RFC2510, RFC2511, RFC2797, etc. 策略概要 (Policy Outline) – RFC2527 时间戳、数据验证和数据认证服务 – RFC3029, RFC3161 Time-Stamp, Data Verification, and Data Certification Services
  • 56. §4.5 互操作 MISPC, Minimum Interoperability Specifications for PKI Components http://csrc.nist.gov/pki/mispc/welcome.html PKI Forum http://www.pkiforum.org/
  • 57. 第 5 章 PKI 实践 – 非技术问 题
  • 58. §5.1 CP 与 CPS CP, Certificate Policy 定义了一个用户对其它用户数字证书信任的程 度 CPS, Certification Practice Statement 人们与组织根据 CA 的 CPS 来确定他们对该 CA 的信任程度 RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
  • 59. PKI 的安全策略 Certification Practice Statement 证书政策 责任与其它法律考虑
  • 60. §5.2 运作考虑 客户端软件 在线需求与离线运作 物理安全 硬件部件 用户密钥的威胁 灾难恢复
  • 61. §5.3 PKI 涉及到的法律问题 数字签名的法律状况 PKI 的法律框架 许可权,角色与责任,私有 PKI( 企业 PKI) 密码管理政策与法规 ( 不同的密码管理政策 )
  • 62. 第 6 章 PKI 应用
  • 63. §6.1 SSL/TLS 由 Netscape , IETF TLS 工作组开发 SSL/TLS 在源和目的实体间建立了一条安全通道 ( 在传 输层之上 ) ,提供基于证书的认证、信息完整性和数 据保密性 SSL 体系结构: SSL 协议栈 SSL 握手 SSL 修改 SSL 告警 HTTP 协议 密文协议 协议 协议 SSL 记录协议 TCP IP
  • 64. §6.2 S/MIME & PGP PGP, Phil Zimmerman, 1991  PGP 的操作描述、加密密钥和密钥环、公开密钥管理  RFC2440 , S/MIME  RFC822 -> MIME -> S/MIME v2, v3  S/MIME 的功能  S/MIME 证书的处理  S/MIME 增强的安全服务 Signed receipt , Security Label 和 Security mailing list.
  • 65. §6.3 IPSec IP 层的安全包括了 3 个功能域:鉴别、机密性 和密钥管理 IPSec 的重要概念 鉴别报头 (AH), 封装安全有效负载 (ESP), 传输 模式 , 隧道模式 , 安全关连 (SA), 安全关连组 (SA Bundle), ISAKMP. IPSec , IPv6 将使互联网 ( 尤其是网络安全 ) 发 生巨大变化
  • 66. IPSec(Cont.) IPSec 安全服务 AH ESP( 只加密 ) ESP( 加密并鉴别 ) 访问控制 * * * 无连接完整性 * * 数据源的鉴别 * * 拒绝重放的分组 * * * 机密性 * * 有限的通信量的机密性 * * IPSec 密钥管理 人工,自动, ISAKMP/Oakley
  • 67. IPSec 文档结构概况 体系结构ESP 协议 AH 协议 加密算法 鉴别算法 DOI 密钥管理
  • 68. §6.4 SET 1996 年 2 月, IBM, Microsoft, Netscape, RSA, Terisa 和 VeriSign 开发了 SET v1( 针对 MasterCard 和 Visa 安全标准的需要而出现的 SET 是开放的、设计用来保护 Internet 上信用 卡交易的加密和安全规范 从本质上, SET 提供了三种服务:  在交易涉及的各方之间提供安全的通信信道  通过使用 X.509 v3 数字证书来提供信任。  保证机密性,因为信息只是在必要的时候、必要的地方 才对交易各方可用 交易过程:购买请求、支付认可和支付获取
  • 69. §6.5 时间戳服务 RFC3161 (TSP, Time Stamp Protocol) 时间戳也是一种安全服务 - 可信第三方时间 戳权威 (TSA, Time Stamp Authority) 签名某信息 ,为此信息在特定时间前存在提供证据 数字签名 + 时间戳 可提供不可否认服务 TDA(Temporal Data Authority)
  • 70. §6.6 DVCS RFC3029, Data Validation and Certification Service DVCS 是验证提交给它的特定数据的正确性的 可信第三方
  • 71. 第 7 章 PKI 厂商、产品及 实现
  • 72. §7.1 著名的 PKI 厂商 VeriSign (http://www.verisign.com/) Entrust (http://www.entrust.com/) Baltimore (http://www.baltimore.com/) RSA Security (http://www.rsasecurity.com/)
  • 73. Differences between Enterprise CA And Trade CA  Enterprise CA is a model that your company hold everything of PKI including CA, RA, Directory Server etc. Entrust , Baltimore , RSA Security, InfoSec, JIT, Koal and NetFront etc.  Trade CA is another model that a trusted third party (often are PKI vendors) will manage every thing for you, but maybe you can control the user enrollment process. Verisign, CFCA, CTCA  The selection between them will base on a lot things, such as trust relationship, the control you have on the end users etc
  • 74. §7.2 著名的 PKI 实现 (opensource) OpenCA Project (http://www.openca.org/) OSCAR PKI Project (http://oscar.dstc.qut.edu.au/) Jonah PKIX (http://web.mit.edu/pfl/) pyCA (http://www.pyca.de/) Mozilla Open Source PKI Project http://www.mozilla.org/projects/security/pki/
  • 75. §7.2 著名的密码算法 Toolkit OpenSSL Project (Open Source) http://www.openssl.org/ CDSA (Open Source) http://developer.intel.com/ial/security/ RSA BSAFE (Commercial Version) http://www.rsasecurity.com/products/bsafe/index.html
  • 76. 第 8 章 标准化进展
  • 77. §8.1 概述 ITU 系列标准 IETF PKIX, SPKI etc. SET PKCS 其它
  • 78. 第 9 章 传统 PKI 的不足
  • 79. 第 10 章 PKI 的新进展
  • 80. 附录 1 信任模型
  • 81. 附录 2 术语表
  • 82. 附录 3 参考文献
  • 83. 附录 4 国内的 PKI 发展情况
  • 84. 致谢 ! Arthur Jin (who remind me to add RC2/RC4) Chorus Li (who remind me to add something about domestic PKI vendors) Yongtian Zhang (who spent time to review the outline and give me his important comments) Frank Lau, Richard Wei, WHIZ Labs, & AKA etc.
  • 85. Any Questions or Comments?