身份验证令牌已加密但未签名 - 弱点?

时间:2009-07-06 17:13:42

标签: security authentication encryption token digital-signature

多年来,我不止一次地遇到过这种情况。您有一堆与用户相关的数据要从一个应用程序发送到另一个应用程序。第二个应用程序应该“信任”这个“令牌”并使用其中的数据。令牌中包含时间戳以防止盗窃/重复使用攻击。无论出于何种原因(我们在此不用担心),我们选择了自定义解决方案,而不是像SAML这样的行业标准。

对我而言,数字签名数据似乎就是您想要的。如果数据需要保密,那么您也可以对其进行加密。

但我看到很多是开发人员将使用对称加密,例如AES。他们假设除了使数据“保密”外,加密还提供1)消息完整性和2)信任(源的认证)。

我是否正确怀疑这里存在固有的弱点?如果正确管理对称密钥,那么它看起来似乎有效。缺少这个密钥,我当然不知道如何修改加密的令牌,或在拦截几个令牌后启动某种加密攻击。但是,一个更复杂的攻击者能够在这里利用某些东西吗?

3 个答案:

答案 0 :(得分:6)

部分取决于加密模式。如果您使用ECB( shame on you!),我可以交换块,改变消息。 Stackoverflow got hit by this very bug

威胁较小 - 没有任何完整性检查,我可以执行中间人攻击,并交换各种各样的位,你会收到它并尝试解密它。你当然失败了,但这种尝试可能是有启发性的。 “伯恩斯坦(利用缓存和微体系结构特征的组合)和Osvik,Shamir和Tromer(利用缓存冲突)依赖于基于大量随机测试获得统计数据的侧通道攻击。” 1脚注文章是由比我更重要的密码学家提出的,他建议用MAC减少攻击面:

  

如果你能确定攻击者   谁无法访问您的MAC   钥匙不能把邪恶的输入送到一个   但是,代码块,你   大大降低了他的机会   将能够利用任何错误

答案 1 :(得分:2)

烨。仅加密不提供身份验证。如果您需要身份验证,那么您应该使用消息身份验证代码,如HMAC或数字签名(根据您的要求)。

如果邮件只是加密但未经过身份验证,则可能会发生大量攻击。这是一个非常简单的例子。假设使用CBC加密消息。此模式使用IV来随机化密文,以便两次加密相同的消息不会产生相同的密文。现在看一下,如果攻击者只修改了IV但是保留了密文的其余部分,那么在解密期间会发生什么。只有解密消息的第一个块才会改变。此外,消息中的IV更改确切地改变了这些位。因此,攻击者确切知道接收器解密消息时会发生什么变化。如果是第一块 例如,攻击者知道原始消息何时被发送的时间戳,然后他可以轻松地将时间戳固定到任何其他时间,只需翻转正确的位即可。

也可以操纵消息的其他块,尽管这有点棘手。另请注意,这不仅仅是CBC的弱点。其他模式如OFB,CFB也有类似的缺点。因此,期望仅加密提供身份验证只是一个非常危险的假设

答案 2 :(得分:-5)

对称加密方法与密钥一样安全。如果两个系统都可以获得密钥并牢固地按住密钥,那么这很好。公钥加密当然更合适。