(转)WSE3.0安全性方面整理

对称密码学、非对称密码学&＃xff08;Symmetric Algorithm, Asymmetric Algorithm&＃xff09;
    对称密码只有一个密匙&＃xff0c;加密和解密都使用这个相同的密匙。非对称密码有两个密匙&＃xff0c;一个作为公匙可以告诉其他人&＃xff0c;一个作为私匙只有自己知道&＃xff0c;用公匙加密的数据只能用私匙解密&＃xff0c;用私匙加密的数据只能用公匙解密。
    使用对称密码&＃xff0c;通讯双方都需要知道密匙&＃xff0c;为了验证身份&＃xff0c;发送方可能需要把密匙传递给接收方&＃xff0c;这种方式可能带来一些潜在的安全性问题。非对称密码中&＃xff0c;A用自己的私匙加密数据然后发送出去&＃xff0c;其他人如果能够用A的公匙解密数据&＃xff0c;那就能知道这个数据一定来自A&＃xff0d;&＃xff0d;不可抵赖性&＃xff0c;一般用户数字签名中&＃xff1b;如果其他人需要向A发送数据&＃xff0c;可以使用A的公匙加密数据&＃xff0c;这样加密后的数据只有A才能解密&＃xff0d;&＃xff0d;保密性&＃xff0c;这个用于确保通讯的机密性。使用非对称密码通讯的双方各自拥有自己的一对公匙和私匙&＃xff0c;向对方发送数据时&＃xff0c;使用对方的公匙加密&＃xff0c;让对方用私匙进行解密。
    对称密码学的算法简便高效&＃xff0c;密匙短&＃xff0c;但很难破译&＃xff0c;加密解密速度快。非对称密码一般较弱一些&＃xff0c;为了防止被破译&＃xff0c;使用的密匙长度会比较长&＃xff0c;例如128位、512位等&＃xff0c;加密解密运算所需时间会比较长。为了改善通讯过程中安全性应用带来的性能问题&＃xff0c;一般的做法是发送方先使用一个对称密匙对消息加密&＃xff0c;然后使用接收方的公匙加密这个对称密匙&＃xff0c;一起发送给接收方。接收方先用自己的私匙解密出对称密匙&＃xff0c;然后再用对称密匙解密消息数据。这样在传输的信息比较大时&＃xff0c;带来的改善是明显的。在X.509一节中可以看到这一运用。

    数字签名
    数字签名是公共密匙体制的另一种应用。A需要向B发送一段报文&＃xff0c;首先A使用特定的Hash算法对要发送的报文取得一个一定长度&＃xff08;例如128位等&＃xff09;的 Hash值&＃xff0c;这个Hash值称为数字摘要&＃xff08;Digital Digest&＃xff09;。Hash算法尽量保证不同的报文产生的摘要不相同&＃xff0c;即如果发送的报文在中途被攻击者修改了&＃xff0c;新的摘要跟原来的摘要就不相同。然后A使用自己的私匙对摘要进行加密&＃xff0c;加密后的值称为数字指纹、数字签名&＃xff08;Digital Signature&＃xff09;&＃xff0c;A把这个数字签名和要发送的报文一起发送给B。B接收到内容后&＃xff0c;取出数字签名和报文&＃xff0c;使用A的公匙对签名解密&＃xff0c;就得到原文的数字摘要&＃xff0c;然后B使用相同的Hash算法对报文获取摘要值&＃xff0c;比较这两个摘要值是否一致。如果验证成功&＃xff0c;B能够确定两件事情&＃xff1a;1. 数据的确是A发送的&＃xff1b;2. 数据在发送过程中没有被修改过。

    常见窃取、攻击场景简单描述
    应用系统最普通的方式是使用用户名、密码认证&＃xff0c;如果使用明文方式向服务器发送认证信息&＃xff0c;窃取者在路由上很容易截取到用户名、密码。
    为了防止攻击者截获到明文的密码&＃xff0c;最简单的方式是将密码加密后传送。但这样攻击者截获到加密过的密码&＃xff0c;他虽然不知道密码的原文&＃xff0c;但如果使用加密过的密码字符串&＃xff0c;仍然可以通过服务器的验证&＃xff0c;这也是重放攻击&＃xff08;Replay Attack&＃xff09;的一种形式。解决方法是客户端每次使用一个随机序列跟密码一起加密&＃xff0c;这样每一次加密后的结果都不一样&＃xff1b;客户端同时把这个随机序列和加密后的值发送给服务器&＃xff0c;服务器用同样的方法用原密码和随机序列进行加密&＃xff0c;比较加密的结果和客户端发来的加密结果是否一致。
    这样做还没有解决问题&＃xff0c;因为攻击者仍然可以截获消息中的加密结果和随机序列&＃xff0c;用以通过服务器验证&＃xff0c;还需要添加另外一个处理&＃xff1a;过期策略。除了随机序列之外&＃xff0c;客户端在添加一个创建时间&＃xff0c;把密码&＃xff08;Password&＃xff09;、随机序列&＃xff08;Nonce&＃xff09;、创建时间&＃xff08;CreatedTime&＃xff09;这三个因素一起加密&＃xff0c;例如加密值&＃61;Base64(SHA-1(Password&＃43;CreatedTime&＃43;Password))&＃xff0c;同样&＃xff0c;客户端把加密值、随机序列Nonce、创建时间CreatedTime一起传给服务器。在服务器上验证机制有所改变。首先&＃xff0c;客户端每一次请求的Nonce都使用一个唯一标识&＃xff0c;不会重复。服务器维护一个已经被处理过的Nonce缓存&＃xff0c;每次接收到消息先检查这个Nonce是否在缓存中存在&＃xff0c;如果已经存在&＃xff0c;说明这个消息已经被处理过了&＃xff0c;决绝这一次请求服务&＃xff1b;如果不存在&＃xff0c;则把这个Nonce添加到缓存&＃xff0c;然后处理请求。为了避免缓存的Nonce值越来越多&＃xff0c;因此使用一个CreatedTime&＃xff0c;并确定一个过期时间&＃xff0c;例如5分钟之后过期&＃xff0c;这样&＃xff0c;服务器只需要保存5分钟之内、还没有过期的Nonce值。在重放攻击中&＃xff0c;对于那些已经过期的消息中的认证信息&＃xff0c;服务器会拒绝处理。如果通过上面两项检查&＃xff0c;则服务器使用相同的算法Base64(SHA-1(Password&＃43;CreatedTime&＃43;Password)) 来验证认证信息。通过这样的处理&＃xff0c;确保认证信息每一次加密的结果都不一样&＃xff0c;并且只能被有效的使用一次。

    X.509
    详细的规范可以从http://www.rfc.net/&＃xff0c;查询X.509。
    不清楚WSE 3.0中具体是如何使用X.509&＃xff0c;但大致的数字签名步骤如下&＃xff0c;应当相差不多&＃xff1a;
    1. A准备好要传送的信息&＃xff08;明文&＃xff09;。
    2. A对数字信息进行Hash运算&＃xff0c;得到一个数字摘要&＃xff08;Digital Digest&＃xff09;。
    3. A用自己的私钥对数字摘要进行加密&＃xff0c;得到数字签名&＃xff08;Digital Signature&＃xff09;&＃xff0c;并将其附在信息上。
    4. A随机产生一个加密密钥&＃xff08;DES密钥&＃xff09;&＃xff0c;并用此密钥对要发送的信息进行加密&＃xff0c;形成密文。
    5. A用B的公钥对刚才随机产生的加密密钥进行加密&＃xff0c;将加密后的DES密钥连同密文一起传送给B。
    6. B收到A传送过来的密文和加过密的DES密钥&＃xff0c;先用自己的私钥对加密的DES密钥进行解密&＃xff0c;得到DES密钥。
    7. B用DES密钥对收到的密文进行解密&＃xff0c;得到明文的信息。
    8. B用A的公钥对A的数字签名进行解密&＃xff0c;得到数字摘要。
    9. B用同样的Hash算法对收到的明文进行Hash运算&＃xff0c;得到一个新的数字摘要。
    10. B将解密的数字摘要和自己运算的数字摘要进行验证是否一致。
    对称密码学使用相同的密匙加密和解密消息&＃xff0c;因此客户端和服务器端都存在密码保存问题&＃xff0c;验证过程中存在密码信息直接或间接的传送&＃xff0c;给这种机制带来一些不安全因素。正由于这样的因素&＃xff0c;非对称密码学&＃xff0c;尤其是X.509&＃xff0c;目前被普遍运用在Internet的电子商务中。

    Kerberos
    RFC标准中Kerberos工作步骤如下&＃xff1a;

    1. Kerberos authentication service request (KRB_AS_REQ)
    用户输入用户名、用户口令登录工作站机器&＃xff0c;工作站向KDC&＃xff08;Key Distribution Center&＃xff09;的AS&＃xff08;Authentication Service认证服务&＃xff09;发送认证信息。认证信息只包含用户帐号&＃xff0c;不包含用户口令。
    2. Kerberos authentication service response (KRB_AS_REP)
    AS为后面工作站与TGS&＃xff08;Ticket Granting Service票据授权服务&＃xff09;之间的通讯创建Session Key&＃xff08;会话口令&＃xff09;SK1&＃xff0c;将客户端信息、TGS服务信息、SK1、时间戳、有效期等信息使用TGS的口令加密&＃xff0c;生成TGT&＃xff08;Ticket Granting Ticket票据授权票&＃xff09;。同时KDC在用户帐号数据库中查询用户口令&＃xff0c;将TGS服务信息、SK1使用用户口令加密打包。最后AS把加密包和TGT发送给工作站。
    工作站接收到返回信息之后&＃xff0c;使用用户登录时输入的用户口令对加密包解密&＃xff0c;如果能成功解密&＃xff0c;则表示通过了KDC的身份认证&＃xff0c;并得到TGS服务信息和SK1&＃xff0c;并且拥有了TGT。
    第一点&＃xff0c;用户口令只有用户与KDC知道&＃xff0c;工作站向KDC认证的过程中并不将用户口令发送给KDC的AS&＃xff0c;而是通过让工作站自己解密的方式来证明自己。如果工作站无法解密&＃xff0c;它将无法与TGS通讯&＃xff0c;从而无法使用其它应用服务和资源等。
    第二点&＃xff0c;AS给工作站颁发TGT&＃xff0c;后面工作站将使用TGT向TGS请求其它应用服务&＃xff0c;而无需再进行用户名、用户口令的验证&＃xff0c;实现SSO。
    第三点&＃xff0c;TGS拥有自己的口令&＃xff0c;这个口令只有TGS和AS知道&＃xff0c;因此工作站虽然拿到TGT&＃xff0c;因为是使用TGS的口令加密&＃xff0c;其他人包括工作站并不能解密和篡改TGT中内容&＃xff0c;它只需要在向TGS申请其它应用服务时发送这个TGT。
    第四点&＃xff0c;AS为工作站后面与TGS的通讯生成一个Session Key SK1&＃xff0c;这个SK1在工作站与TGS之间共享&＃xff0c;使得后面TGS与工作站通讯时&＃xff0c;TGS能够对工作站这个客户端进行认证。上面已经看到工作站如何得到SK1&＃xff0c;而AS并没有直接告诉TGS这个SK1&＃xff0c;下面的步骤中你可以看到TGS如何得到SK1。
    3. Kerberos ticket-granting service request (KRB_TGS_REQ)
    工作站上的用户请求其它应用系统服务&＃xff0c;例如邮件服务时&＃xff0c;邮件客户端首先查询工作站上是否已经拥有邮件服务的Service Ticket&＃xff08;服务票据&＃xff09;&＃xff0c;如果没有则向TGS申请这个Service Ticket。
    申请Service Ticket过程如下。工作站将客户端信息、要申请的服务信息&＃xff08;邮件服务&＃xff09;使用SK1加密生成一个验证器&＃xff0c;与TGT一起发送给TGS。
    TGS接收到工作站的请求后&＃xff0c;使用TGS的口令对TGT解密&＃xff0c;得到TGT中的内容。首先根据时间戳、有效期信息检查是否过期&＃xff0c;如果没有过期&＃xff0c;则使用SK1解密验证器&＃xff0c;比较验证器中的客户端信息与TGT中的客户端信息是否一致。如果一致则表示这个请求通过了TGS的认证。
    4. Kerberos ticket-granting service response (KRB_TGS_REP)
    从验证器的解密内容中&＃xff0c;TGS知道工作站是在申请邮件服务的Service Ticket。同样&＃xff0c;TGS为工作站与邮件服务之间的通讯创建一个Session Key SK2&＃xff0c;将客户端信息、邮件服务信息、SK2、时间戳、有效期等信息使用邮件服务的口令加密&＃xff0c;生成邮件服务的Service Ticket。TGS将SK2使用SK1加密&＃xff0c;把这个加密包和Service Ticket一起发送给工作站。
    第一点&＃xff0c;从上面3、4步骤中可以看出&＃xff0c;TGS如何获得AS为它和工作站之间建立的会话口令SK1&＃xff0c;并使用这个SK1对工作站的请求进行验证。同样的方式&＃xff0c;TGS为工作站与邮件服务之间的通讯也创建一个会话口令SK2。
    第二点&＃xff0c;邮件服务拥有自己的口令&＃xff0c;只有TGS与邮件服务自己知道。邮件服务的Service Ticket使用邮件服务口令加密&＃xff0c;其他人包括工作站无法解密&＃xff0c;只有邮件服务自己可以解开。
    5. Kerberos application server request (KRB_AP_REQ)
    接下来工作站得到TGS的响应消息&＃xff0c;它得到了邮件服务的Service Ticket和一个加密包。工作站是使用SK1解开加密包&＃xff0c;得到它与邮件服务器之间通讯的会话口令SK2。
    然后工作站将客户端信息使用SK2加密&＃xff0c;生成验证器&＃xff0c;将验证器和邮件服务的Service Ticket一起发送给邮件服务器&＃xff0c;请求邮件服务。
    邮件服务接收到工作站的请求后&＃xff0c;使用邮件服务口令解密Service Ticket&＃xff0c;得到里面的内容。首先查看Service Ticket中的邮件服务信息&＃xff0c;确认是否是在向自己请求服务。然后根据时间戳、有效期检查是否过期。如果没有过期&＃xff0c;则使用SK2解密验证器&＃xff0c;比较验证器中的客户端信息与Service Ticket中的客户端信息是否一致。如果上面的验证全部通过&＃xff0c;则这个请求通过了邮件服务器的认证。
    6. Kerberos application server response (optional) (KRB_AP_REP)
    在RFC标准中&＃xff0c;这一个步骤是可选的。应用服务处理完请求之后&＃xff0c;如果需要向工作站发送信息&＃xff0c;则将这些信息发送回工作站。

    最后需要说明的是&＃xff0c;在Kerberos V5中&＃xff0c;为防止Replay Attack&＃xff08;重放攻击&＃xff09;&＃xff0c;上面对验证器的处理说得并不详细。首先采用一些处理使得每次验证器不一样。验证器本身有一个有效期&＃xff0c;大概5分钟的样子。服务器上将建立一个验证器缓存&＃xff0c;确保一个验证器在有效期之内只能被使用一次。
    另外&＃xff0c;RFC标准中KDC的AS和TGS可以是在一起&＃xff0c;也可以是分开在不同的Server上。
    通过上面的过程可以看出&＃xff0c;Kerberos使用对称密码&＃xff0c;而对称密码算法高效&＃xff0c;密匙短但难以被破译&＃xff0c;如果再采取一些其它措施&＃xff0c;例如Strong Password&＃xff08;强密码&＃xff09;、密码有效期控制等&＃xff0c;不考虑被集成的应用等其它因素&＃xff0c;这种机制本身非常严密&＃xff0c;机密性比较高。针对Kerberos机制的一些攻防场景&＃xff0c;参考设计一个认证系统&＃xff0c;这里有中文版本&＃xff0c;不少地方翻译的不够准确。微软基于域环境实现Kerberos&＃xff0c;详细的资料可以参考微软官方网站&＃xff0c;例如&＃xff0c;Kerberos Authentication Explained&＃xff1b;How the Kerberos Version 5 Authentication Protocol Works。
    由于实现Kerberos的机制、被集成的应用等各种原因&＃xff0c;使得目前Kerberos只能在一个内网中使用&＃xff0c;例如微软的域环境下。