【问题标题】:Security Guarantees, Pitfalls of Proposed Method安全保证,所提出方法的缺陷
【发布时间】:2019-02-25 21:27:48
【问题描述】:

我想通过类似于 UDP 的传输方法从 Alice 向 Bob 发送消息,因此未连接。我假设窃听者 Eve 可以获得所发送内容的副本,并且攻击者 Mallory 可以做 Eve 可以做的所有事情并将其发送给 Bob。我还假设马洛里不能中间人,即不能阻止从爱丽丝到鲍勃的消息到达鲍勃,但马洛里可以改变数据并且只能重播截获的消息。我的带宽是有限的,所以我不希望在“用户数据”中添加太多数据来实现数据保护。

我想实现数据机密性(加密)加上防篡改(完整性)和真实性保证,基本上是将 Mallory 的能力降低到零。我建议:

Alice 和 Bob 共享一个密钥,用于加密(例如 AES)。

Alice 和 Bob 共享一个密钥,用于签名/验证(例如 HMAC+SHA256)。

加密密钥和签名密钥可以相同也可以不同。

Alice 发送给 Bob 的消息中应包含 nonce。 UUID 可以用作随机数,给我一个 16 字节的随机数。提前时间也可以作为随机数。

对于明文数据 P,Alice 对其进行加密以产生 C,然后附加一个随机数 N 以产生 C+N。然后她签署 C+N,得到 S,并将 S 附加到 C+N,产生 C+N+S。这就是发送给 Bob 的内容。 Eve/Mallory 无法推导出 P,Mallory 也无法更改消息、重播消息或编写新消息。

Bob 必须管理他见过的所有 nonce 的“nonce store”。或者也许使用时间作为随机数(将存储减少到单个值),但是 Alice 有责任产生单调递增的值。

鉴于大多数加密协议(例如 TLS)在连接模型上工作,例如TCP,我还没有找到任何现成的(接受!) 方法,因此提出了这个建议。

任何帮助表示赞赏,尤其是“您不想那样做,因为它会遭受安全漏洞 X、Y、Z”的多样性。我知道整个“加密然后签名”的辩论,我真的不想把它带入其中。

更新:作为对建议 DTLS 和随机数使用时间的回复的回应,我将不得不详细说明我希望在最初的帖子中不相关但显然是相关的非连接模型的各个方面。在我的模型中,Alice 实际上并不直接发送给 Bob。消息由中介持有,将其视为邮件服务器。从 Alice 发布消息的那一刻起,Bob 可能会在数小时甚至数天内查看他的“收件箱”。此外,Bob 和 Alice 的时钟不同步,因此拥有一个“到期时间”x 并非易事

【问题讨论】:

  • 为什么不使用 DTLS?
  • 地穴设计问题在这里是题外话。

标签: encryption cryptography signature


【解决方案1】:

您提出的方法已经很合理了。不过,我会建议:

  • 不要使用与 MAC 相同的密钥进行加密。 AES 和 HMAC 之间没有任何已知的基于理论的交互,但实际原因(密钥泄漏等)意味着拥有两个不同的密钥可能更好。

  • 您说您不想参与其中,但很少有理由不加密然后-mac。如果可能的话,你应该更喜欢这个。

  • 永久存储所有随机数是相当乏味的。使用基于时间的签名到期方法:

    • Alice 加密C = E(M) 并附加当前时间T,然后签名生成S。她将 C + T + S 发送给 Bob。
    • Bob 检查 T 是否在当前时间的x 秒内。如果不是,Bob 会忽略该消息。
    • Bob 检查他是否识别出S。如果他这样做了,Bob 会忽略该消息。
    • Bob 将 S 临时存储 x 秒,之后他就忘记了。
    • Bob 解密 M = D(C) 并处理 M

这里x的值理论上可以是你喜欢的任何值,但我建议在5-10秒左右的范围内。

【讨论】:

  • 我不理解你关于 Bob 识别 S 和存储 S 的观点。S 不只是为了保证(Alice)的完整性和身份吗?您是否建议在唯一性断言中使用 S?你能详细说明一下吗?
  • x 秒内的重复消息将被处理,除非我们有某种识别方式。如果是重复消息(重放攻击),那么签名也是一样的。因此,如果我们跟踪签名x 秒,我们可以识别出重放攻击或意外重复的消息并安全地忽略它们。在x 秒之外,由于时差,消息无论如何都会被忽略,并且不需要记住签名。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2023-04-07
  • 2016-12-12
  • 2016-10-30
  • 1970-01-01
  • 1970-01-01
  • 2015-02-17
  • 1970-01-01
相关资源
最近更新 更多