[转载]两种网络安全系统的缺陷分析
文章作者：benjurry信息来源：ChinAsp <[url]http://www.chinaasp.com/>[/url]
一、网络安全系统的产生背景
随着网络应用的迅猛发展，与网络安全相关的问题：如对主机的攻击，网络上传输的信息
被截取，篡改等对网络应用进一步推广构成巨大威胁。Kerberos和公钥加密系统就是在
这种背景下应运而生的。
为了提供运用于安全网络传输的用户认证系统，八十年代中期，MIT的Athena计划推出了
基于可信赖第三方的用户认证系统Kerberos。目前第四版V4已有了许多应用系统。最新
的V5版是Kerberos的Internet标准。其协议文本为RFC1510。
公钥加密安全系统具有易于管理，不需要过多依赖一个可信的第三方因而更安全的特点。
秘密增强邮件(Privacy Enhanced Mail)中首先建议在lnterent网上使用公钥加密系
统。一个安全的域名系统正被建议用作全球的公钥分发和管理设施。在公钥分发问题解
决后，公钥加密安全系统可望成为Internet上的主导安全系统。
二、kerberos的原理及缺陷
1Kerberos的原理
Kerberos采用可信赖第三方服务器进行密钥分发和身份确认，包括：
① 对用户认证
② 对应用服务的提供者进行认证。
此外，还可根据用户要求提供客户/服务器间的数据加密与完整性服务。
RFC1510协议文件对V5作了如下说明：
Kerberos提供了在开放型网络中进行身份认证的方法，认证实体可以是用户或用户服
务。这种认证不依赖宿主机的操作系统或主机的IP地址，不需要保证网络上所有主机
的物理安全性，并且假定数据包在传输中可被随机窃取篡改。
2Kerberos的主要概念及一个工作模型
DES：对信息加密的算法。V4只支持这一DES(数据加密标准)算法，V5采用独立的加密
模块，可用其它加密算法替换。
主体Principal:用户或服务，具体格式为〈登录名Primary name，实体名lnstance,
域名realm〉
许可证Ticket:向Kerberos server认证的凭证。
格式〈Primary name,会话密钥Sessionkey，时间戳Timestamp〉
会话密钥Session key:两个主体通信的临时密钥。
KDC(密钥发送中心)：包括认证服务器AS(Authenticatin server)
用于用户的初始认证服务。
和TGS(Ticket Granting server)许可证认证服务器。
AS和TGS同驻于一台主机上。
认证符Authenticator.用户创建的令牌。发送给服务器用于证明用户身份
格式〈primary name ,timestamp>
一个Kerberos服务器也称为密钥分发中心KDC，维护着一个数据库.里面保存着所辖域内
的用户及服务器的DES密钥。DES密钥基于用户口令而生。用户首次注册时，系统根据用
户口令生成密钥。应用服务器向KDC注册也生成密钥，这个密钥既存放在KDC上，也存于
该服务器的主机上。
现在假定一用户需要某应用服务器提供服务，工作模型如下：
(电子版中略）
从此例可以看出，基于Needham-schroeder密钥协议的Kerberos系统保障了网络传输和
通信的安全。
但用户的负担十分繁重：用户的目的是得到应用服务器S的服务，却不得不积极地申请
许可证!
在KerberosV4版里，为防止“重放”攻击，nonce由时间戳实现，这就带来了时间同步
问题。即使利用网络时间协议(Network Time Protocol)或国际标准时间(Coordinated
universal time)能在一定程度上解决时间同步问题，用户需要承担的责任也令人忍受。
Kerberos V5 版允许nonce可以是一个数字序列，但要求它唯一。由于服务器无法保证
不同用户的nonce不冲突，偶然的冲突可能将合法用户的服务器申请当作重放攻击而拒
之门外。
简言之，从没有网络安全知识的用户角度来看，Kerberos以加大用户参与安全保证的
力度（而他们并不具备这方面的知识更没有耐心）来保障通信的安全，这种做法并不
可行。
三、公钥加密安全系统的缺陷分析
1简介
公钥加密非常适合于全球安全网络的某些部分，它不需传送私有密钥，需要的设施开
销也小，易于管理。但它要过分依赖于最终用户的安全意识。表面上看公钥安全系统
不需要可信的密钥管理机构，事实上密钥管理的负担落到了用户身上。用户必须积极
地验证他所使用的每一个公钥的有效性(Validation)而且得不珍藏自己的私有密钥。
这些任务远非一般用户所能胜任的。
另外，非对称密钥管理无法由计算机全部自动地完成，一些安全细节如Root-key 的
有效性检查、通行字(Passphrase)的选择及用户端的物理安全性等都需要用户的介
入。即使系统可以自动完成证书作废表(Certificate Rovacation List)的查询，
但如果用户或开发商跳过了这些步骤(这很可能发生，因为CRL将始终是个瓶领)，系
统无法检测出这些疏忽也不可能审计其后果。当用户没能使他的私有密钥处于安全状
态时或没有尽心检验通话对方的公钥的有效性时，系统的认证作用就会大为削弱，并
且与该用户有关的每个人的安全度也会降低。
这并不是说公钥系统一无是处，而是说公钥系统不适合客户端的应用。只有高级用户
如系统管理员才有能力履行公钥系统要求用户完成的职责。因此公钥加密系统最适合
用在服务器间的通信上。
2公钥系统所需设施总览
证书认证机构(Certificate Authority)：确定用户的公钥
目录(Directory)：存放有效证书的公共访问数据库
证书作废表(Certificate Revocation List)：存放作废证书的公共访问数据库
在广域网中，具有层次结构的服务器提供了这些服务。举例来说，所有CA以层次结构存
在，每个CA都有自己的公钥，这个公钥用该CA的证书签名后存放于更高一级CA所在服务
器。但是由于“Root CA”位于最顶端，没有上一级结点，故不受此限。)
本节的剩余部分将总结公钥安全系统的管理特征，重点放在密钥分发上。在用户的公钥
证书有效生命期内，以下时刻需要密钥管理：
① 创建密钥对：
· 用户创建了新的密钥对
· 用户通过非电子手段向CA证明身份
· CA签发证书，命名该用户为新公钥的拥有者
· 用户收到了Root CA的公钥
· 用户选择秘密的通行字(Passphrase)，用来加密私有密钥
② 登录(Single-sign-on)
· 登录时，用户敲入通行字，以便解开私有密钥
· 用户凭他的私有密钥加入公钥协议。
③ 认证他人
· 为了安全地与其他用户和服务商通信，用户查阅对方的公钥证书
· 用户要么直接与其他用户交换证书，要么从目录服务中得到证书
· 在使用一个证书前，用户必须查阅CRL表，确保该证书尚未作废
· 检查CA签名的有效性
④ 改变密钥
·用户应定期改变用于加密私有密钥的通行字
⑤ 宣布密钥作废
· 证书都有一个有效时间，经过一定时期后作废
· 如果用户的通行字或私有密钥泄露，他必须通知CRL管理员，后者将立即公布消息声
明相关的公钥证书无效
· 用户在每次使用一个证书前都必须核对CRL表，因为CRL表可能会随时更新
从以上可以看出，一个公钥系统用户必须频繁地检查对称或非对称密钥的有效性。而公
钥系统无法提供这方面的帮助，也不能强制用户履行他的责任。
3缺陷
上述密钥对生命周期中的五个重要时刻依次暴露了公钥系统的以下缺陷；
① 认证用户：在发布最初的证书时，CA如何认证一个相距遥远的用户?
分发或有效性检查符合安全性标准
② 证书作废表：定期宣布证书作废带来性能和伸缩性(Scalability)方面的问题，其
结果是只有舍弃证书作废表的核对工作。
④ 私有密钥的管理：用户必须将私有密钥牢牢地存放在计算机中。
⑤ 通行字的选取质量：通行字的选取完全由用户决定，且不受系统的制约，通行字的
质量难以保证。
其中与证书创建及作废有关的缺陷,原则上可用增加集中式设施来补救。但是另外三个
缺陷要有用户的合作才能解决。而且，增加额外的设施将使系统伸缩性变得困难，这
种情况下，要保持系统原有的性能，只能以降低安全性为代价。
下面对上述5个缺陷作详细分析。
3.1 认证用户方面的缺陷
与传统的密钥分发服务相比，证书授权机构可以支持更多的用户使用。这是公钥的加
密钥系统的优势这一。的确，由于用户每月或每年才拿到一次证书，所以用户访问CA
的频率只是访问KDC(Key DistributeCenter )的百分之一或千分之一。即使考虑到
CA需要更大的加解密开销，理论上CA也能服务上百万甚至更多的用户。不幸的是，事
情并非如此简单。
问题在于CA不仅仅是计算一个数字签名，还要去发布证书。公钥证书是关于拥有私有
密钥的用户身份的保证。正如用户不能依赖于以电子手段传送Roog-key，CA也不能依
赖于电子手段来传送用户身份。
这两种情况都要求非电子手段的通络。理想情况下，CA系统管理员应约见新用户并当
面验证他的身份材料如身份证，驾照，护照，确认无误后再授权该用户拥有一对公开、
私有密钥。但是与上百万相距遥远的用户进行面对面的确认并不现实。而且面对面的
确认会大大增加证书的成本，从而吓跑大量潜在用户。如果允许用户通过电子手段提
供身份信息，则公钥系统的安全度将大为降低。
总之，CA并不能如理论上的设想可以大规模扩允用户，因为创建新帐户更多的依赖于
社会环境，这并非是技术问题所能解决的。
3.2 认证CA方面的缺陷
到目前为止，每个有关电子商务协议的论述都避而不谈RoogCA的公钥验证。常见的
托辞是“超出本论述的范围”。
而且公钥证书的签名都存放在其上一级机构所在的服务器，在使用一个公钥证书前，
用户不得不一级一级核对有关的数字签名。由于用户不能检查Root CA的公钥，因
而不能确认RootCA是否被冒名顶替。
3.3 证书作废表(CRL)方面的缺陷
在使用一个公钥前，用户除需要检验CA的签名外，还得核对CRL表，以确保该公钥
没有作废。CRL是公钥系统中帐户管理子系统的一部分。即使CRL非常安全且高度可
用，也难以满足百万用户的频繁访问。这样，CRL很容易成为瓶颈。另外，这种烦
琐的过程促使用户避免查询CRL表而冒险使用一个公钥，从而给公钥加密系统的安
全性造成损害。
3.4 私钥管理方面的缺陷
为了在发送和接收消息时使用公钥，用户要么需要把私有密钥保存在内存中，要么
每次输入一个通行字。但明显，用户不愿使用一个整日里要他一再输入口令的软件，
所以在实际应用中，用户倾向于把口令存放在内存里。注意到用户不仅在签名或打
开电子邮件时使用他的私有密钥。这暴露出很大的安全漏洞：很容易把生命周期很
长的私有密钥泄露给黑客或窃。例如，如果用户在计算机处于开机状态时离开一会
儿，或他的笔记本电脑被窃了，那么他们的私有密钥就可能被泄露出去。类似地，
病毒和特洛伊木马程序也能偷取用户的私有密钥。这样，私有密钥仅有与用户的计
算机一样的安全度。
相比之下，对称密钥系统通常使用生命周期短的会话密钥。这会最大限度降低被攻
击的风险。而非对称密钥对不可能采用短周期的策略(如果也用短周期的策略，证
书作废表CRL每天都会以惊人速度扩大其记录，最终将导致整个公钥安全系统痪)。
要使用户存放在计算机里的私有密钥安全，最关键的是就是保证计算机的物理安
全，并且拒绝所有远程的访问请求。显然，并不能指望用户会严格遵守这么多的条
条框框。
3.5 通行字选取质量方面的缺陷
由于用户不与任何安全服务系统共享他的通行字，所以公钥系统无法保证用户会选
取高质量的通行字，也不能强制使用户的通行字作废。
如果采用对称密钥加密方法，密钥分发中心(KDC)与用户共享口令，从而能实施口
令质量控制。Kerberos系统已经溶合了德州大学的npasswd技术，作废口令的监管
等提高口令质量的措施。
如果把口令选择权完全交给用户，那么用户会偏爱选取易于记忆，但同时也易于被
攻破的口令。可见，若没有有效的口令质量控制措施，用户口令很容易被脱机猜测
攻击所攻破，而公钥系统对此无能为力。
总之，实施高质量口令保证机制是网络数据安全的第一道防线，对于商业网络来说
更是至关重要。由于公钥系统中用户私有密钥的生命周期很长，价值高，一旦泄露
将给用户带来难以估量的损失。然而公钥安全系统在用户选取口令或通行字这一重
要问题上缺乏有效措施，给整个系统的安全度蒙上了阴影。
表1列出了公钥安全系统和对称密钥系统的记录
5个主要方面 公钥系统 对称密钥系统
新增用户 可伸缩性差 可伸缩性差
证书作废 难管理 易管理
窃贼得到了口令 由于用户口令生命周期长， 口令生存期很短，损失有限
价值非常高，造成的破坏或损失大
口令质量保证 非强制的 强制实施
网络的瓶颈 CRL服务 KDC
密钥管理的责任 落在用户身上 落在系统管理员身上
4公钥系统在转嫁管理负担方面的缺陷
与对称密钥系统相比，公钥系统的集中管理负担要小得多。
另外公钥系统中CA，证书目录和作废证书表所在服务器不必每次都介入安全通信，
这不仅提高了网络性能而且更可靠，易管理。
但是这些优势是以转嫁管理负担给用户为前提的。第一个转嫁的负担是要求用户
进行大量的的本地计算。用户尽量避免了许多网络上传输的延迟，但在这些时间
里用户也不能闲着：运行大数运算的执行程序!
第二个转嫁的负担就是本文所涉及的：用户必须全力负责本地计算机的物理安全，
高质量口令的选取和存放，积极检查每个证书的有效性。用户是否严格履行这些
职责将决定公钥安全系统是否能有效运转。
网络安全的实现是为了使广大用户受益。但是不应以加重用户的负担为前提，不
能是安全上受益，行动上受制。
将对称加密系统与公钥的加密系统结合起来，是既保证网络安全又不加重普通用
户负担的可行之策。前者应用于用户平台上，后者用于服务器间的安全通信。
KDC负责用户的口令的选取质量，发布短周期密钥、检查服务器公钥的有效性，
以及管理作废证书表。基于对称密钥的签名系统为本地对称密钥的用户与远程非
对称公钥的用户间的通信提供服务
页:
[1]