认证中心
我们已经讨论过对密码系统的“传统”攻击，比如通过破解算法来确定私钥，或是经由物理手段接触密钥，比如获取一台能够使用密钥或能探测到秘密数值的装置等。然而，公钥系统还需要能对付模仿攻击的基础设施。假设用户A能使他的公钥看起来就像属于B的一样，此时其他用户可能会用A的公钥为B的对称密钥加密。但是最终A将会得到被这些对称密钥所保护的机密信息，B却得不到。此外，A还能够用他的私钥签署信息，而他的这些签名也将被别人当作是B的签名。利用认证中心以及建立公钥基础设施（PKI）的目的就是为了防止这类模仿攻击。
认证中心（CA）的主要作用是提供数字签名的“证书”，它把实体的身份与其公钥值绑在一起。为了使CA的证书也能被核查，CA自己的公钥必须广为人知并被广泛认可。在这个背景下，证书乃是一种带签名的信息，它包含了实体的身份、其公钥值，也许还有些附加信息，如终止日期等。这些证书可以看作是由广受尊敬的发证机构（即CA）签发的“介绍信”。
假定CERTA是由CA颁发的一份证书，其中包含了A的身份和A的公钥，所以CERTA将A的身份及其公钥值绑在了一起。任何人只要有真实的CA公钥的副本就能验证CERTA中的签名的正确性，从而确认他们知道A的公钥。于是，确保A的公钥可靠性的问题就被替换成保证CA公钥的可靠性的问题，同时还要确信对A身份的验证正确无误。注意，如有人能在认证过程中假冒A，那他就可以得到将他的公钥与A的身份绑在一起的证书。这使他们能在那份证书的整个有效期内假冒A。这个例子说明身份盗窃的隐患将来可能会愈发严重。
值得注意的是，任何人都能够编造出一个特定用户的证书，使得用户A的数字证书的所有权不能用来识别A。这个证书只是将A的身份与一个公钥值绑在一起。此时，身份证明可以使用质询–应答协议来达成，该协议能证明A的私钥是否已使用。这可能涉及到收到质询的A需要给出签名。A用他的签名作答，校验器利用A的证的公钥值来证实签名是真实的。在这里，正是与A的证的公钥相对应的私钥的使用，才确认了A的身份。
现在假定有两个用户A和B，他们持有由不同的CA颁发的证书。若A需要确认B的公钥的可靠性，那么A就需要一份B的CA颁发的公钥的副本。这可以通过交叉验证的方式完成，此时每个CA都要给另一个颁发一份证书；也可以引入认证阶层的办法，即有一个“根CA”，它位于那两个CA之上并给每一方都颁发证书。
我们可以用图来解释这两种过程。图（a）和（b）中的X和Y都是CA，X→A意指X给A颁发证书。图（b）中的Z是根CA。例如，当B需要确认E的公钥时，那么在（a）中，B需要核实由X颁发给Y的证书以及由Y颁发给E的证书。而在（b）中，B需要核实由Z颁发给Y的证书和由Y颁发给E的证书。因此，无论是在哪种情形中，B都需要检验由两个证书组成的一个链。在更复杂的系统中，会遇到包括很多交叉验证和多层次认证的组合，此时需要检验的链也会更长。
交叉验证
认证阶层
很多人认为数字签名是电子商务的核心问题，许多国家都在制定法律，以使数字签名与手写签名具有同等的法律地位。若有读者想对当前的数字签名机制有一个全面的了解，并对公钥基础设施相关课题的讨论感兴趣，我们建议其参阅由派珀、布莱克–威尔逊（Blake-Wilson）和米切尔（Mitchell）所著的《数字签名》一书。当然其中有一些问题十分重要，需要在这里加以讨论。与证书的使用有关的一个主要问题是撤销的问题。例如，某公司发给一名雇员一份证书，但后来该雇员离开了。第二个例子是关于密钥持有者的，他了解到他的私钥已受到侵害。在这两种情形中，都需要CA能够撤销那份证书。由于这些证书可能已经广为散布，直接去通知每个人该证书已被撤销是不太现实的。一种常用的解决办法是由CA发布一份“证书撤销表”（CRL），然而，这是一笔重要的管理费用，而且还有很多与此相关的问题。
第二个显而易见的问题与责任有关。很多用户怀着信任的心理使用这种证书。假定一份证书出了差错，使得列在表中的公钥值不属于列表中的主人，在这种情况下，可能会搞不清楚谁该负责：是公钥的所有者，是用户，还是CA。
