需要在脱机系统中进行身份验证

Question

我需要设计一个方案，其中访问离线系统是基于某种信息/知识的证明，由一个独立的系统，支持系统提供。

我可以在这两个系统上提供任何信息。

完美世界的场景是这样的

1. 脱机系统的用户(S)希望访问受保护的资源。
2. S向用户提供一些挑战字符串。
3. 用户在Prover (P)中重新键入挑战(它有自己的功能来检查用户是否有权这样做)
4. Prover计算并显示对用户的响应。
5. 用户重新键入对系统的响应。
6. 系统验证响应并授予访问权限。

上面的场景是时间限制的:系统将允许在执行1、6.之间的时间不超过2-5分钟。

额外的要求是防止对脱机系统的重放攻击。

另外，我还想避免在离线系统上保守静态共享秘密(所以TOTP/HOTP对我来说是不允许的)。

对我来说，最大的挑战是用户必须在3和6中重新键入字符串的大小。它应该适合大约20个字符，或者假设Base64编码在128位左右。

我会选择安装在系统上的Prover公钥，3中的随机字符串，6中的Prover签名，但据我所见，签名的大小令人望而却步，是DSA、ElGamal或Schnorr的“密钥大小”的3-4倍，相当于安全密钥的大约400-2k位。

我还尝试使用质疑字符串(使用Prover的公钥加密了一些随机消息)和作为消息哈希的证明；这在6.中产生了小的响应，在3中留下了大消息(最坏的情况是，我可以在3.中使用QR代码，扫描而不是重新键入4.)以及需要额外保护系统中的原始随机消息。

我对密码不太感兴趣，所以我可能遗漏了一些其他有用的方案，比如3路协议或其他东西。

Answer 1

在你想要的高度安全的情况下，你所要求的是不可能的，不过如果你放松一下长度限制，那就不算太糟了。S生成一个挑战(应该至少为128位)，P在挑战中附加一些元数据(用户名、时间戳、权限等)，然后使用基于256位椭圆曲线的算法(我推荐的Ed25519)对其进行签名，并返回签名加上S需要从P获得的任何元数据(可能只是时间戳)。这将大于256位，但可能不是很多。S重新构造签名字符串，验证签名和时间戳是最近的，并让用户进入。你甚至可以避免时间戳长度的开销，方法是使用带桶的时间戳(例如，时间戳总是在一分钟内)，然后S只检查最后N分钟(其中N小于5)，以确定其中是否有有效的时间戳。

有些签名方案只允许线性熵损失的签名截断，但我不确定这是否适用于任何椭圆曲线。如果是这样的话，您可以交换少于128位的安全性，以获得少于256位的签名来中继(尽管元数据长度是固定的)。HMACs确实具有此属性，但需要对称密钥(这意味着S必须存储秘密，而不仅仅是公钥)。

有比键入一堆base64更容易传递信息的方法。使用字典词会大大增加击键的总数(因为每个字符的击键数都少于64‘S的6位熵)，但对于一个经验丰富的打字员来说，困难的因素是记住和验证字符串，而不是实际的打字，在这方面，单词要容易得多。如果S有一台相机，你可以使用一个应用程序或打印出来显示QR代码(或其他二维条形码；有许多选项)。你可以使用一种硬件设备--一种专用的硬件，比如智能卡，或者通用的USB闪存--它除了向一个方向传达挑战和在另一个方向上的响应之外，什么也不做。如果S有麦克风，甚至只有麦克风杰克，你可以使用手机应用程序的音频。

如果你不需要P来集中，你可以使用智能卡，这是一个小小的硬件安全模块，有一点可编程的能力。智能卡可以很容易地要求用户认证(通过密码或类似的方式)，用户输入S(插入卡后)，然后使用用户的私钥(存储在卡上，不可导出)进行质询响应签名。这意味着，用户访问管理需要对S自己进行，因为没有一个P对每个用户都有了解，但在维护良好安全的同时，它更简单、更方便用户(从安全性上讲，您损失的主要事情是审计日志将驻留在S而不是P上，因此只能由也在或连接到成都的系统来监视，另外，如果您想尽快撤销用户的访问权限，并且需要逐个更新每个用户，这可能会为攻击创建一个窗口)。

Answer 2

如果您想要避免预先共享的秘密并使用PKI，那么至少在一个方向上，您必须传输相对较多的要输入的数据。

你可以跟着做。脱机应用程序可以对验证程序的数据进行加密，并将其表示为QR代码。用户应该扫描它，应用程序应该将数据传输到验证程序。然后，验证器对用户进行身份验证，并在肯定的情况下告诉短号码，例如6位数字或8位数字。用户输入此号码。

Answer 3

深入挖掘@CBHacking的观点，我发现了什么非对称方案在安全的同时提供最短的签名？问题的答案非常有用。我的选择：

• BLS (例如，scheme中使用的BLS 12-381)产生长度为2*n的签名，具有n位安全性，与@CBHacking中提到的HMAC相同，但使用更适合我的公钥方案(注意：评论发现BLS 12-381可以具有117到120位的安全性，而不是128位)。
• 论文https://eprint.iacr.org/2016/911描述了如何生成具有80位安全性的110位签名(但有一些功能缺陷)；对我来说并不是很实用，但是很想知道其局限性。