认证性 不可否认性_一次性密码不提供不可否认性

认证性 不可否认性

标题很明显，它可能是推文，而不是博客文章。 但让我扩展。

OTP或一次性密码曾经是在线银行的主流。 您将获得一个专用的设备，该设备会生成一个6位数的代码，您将该代码输入到网上银行中以登录或确认交易。 该设备（令牌）是有气隙的（没有互联网连接），并且具有一个预先安装的密钥，该密钥不会泄漏。 此密钥是对称密钥，用于（取决于所使用的算法）对当前时间进行加密，剥离大部分密文并将其余密文转换为6位数字。 服务器拥有相同的密钥，执行相同的操作，并将得到的6位数字与提供的数字进行比较。 如果要更精确地描述（T）OTP， 请检查Wikipedia 。 当然，有SMS OTP，但是它们不鼓励使用并且不安全，因此我不再讨论它们。

在这种情况下，不可否认性是加密方案的属性，这意味着消息的作者不能拒绝作者。 在银行业务场景中，这意味着您不能怀疑确实是您输入了这6位数字（因为据称，只有您拥有密钥，因为只有您拥有令牌）。

硬件令牌已过时，并且已被易于使用且仍代表硬件设备的移动应用程序所取代。 不过，有一个主要区别–手机已连接到互联网，这带来了额外的安全风险。 但是，如果我们尝试忽略它们，那么可以在智能手机上拥有密钥，特别是如果它支持安全的按应用存储，则第三方应用程序无法访问，甚至不支持加密的硬件安全模块（尤其是最新的加密软件）做。

软件“令牌”（移动应用程序）通常也依赖OTP，即使它们不向用户显示代码。 这没有什么意义，因为OTP短是因为人们需要输入OTP。 如果您通过RESTful API发送OTP，为什么不发送整个密文呢？ 或者更好–在服务器提供的挑战中进行数字签名。

但这不是OTP的最大问题。 它们不会给银行（或决定使用它们作为确认交易的手段的人）不可抵赖性。 因为OTP依赖于共享机密。 这意味着银行和任何（好奇的）管理员都知道共享机密。 正如我在某些情况下看到的那样，尤其是如果共享机密是根据一些与事务相关的数据动态生成的。 银行数据泄露或恶意内部人员可以使用您的安全令牌（专用硬件或移动设备）轻松生成与您相​​同的6位数字。

当然，也有例外。 显然存在ITU-T X.1156 –一种用于OTP的不可否认性框架。 但是，它涉及受信任的第三方，这在银行中不太可能发生。 还有一些HSM（服务器端硬件安全模块）可以存储秘密密钥，而无需任何选择将其泄露给本机支持TOTP的外界。 因此，设备会生成接下来的6位数字。 有权访问HSM的人仍然可以生成这样的序列，但是希望审计跟踪会表明发生了这种情况，这不仅仅是数据库违规，而不仅仅是一个问题。 显然（甚至希望？）机密即使不在HSM中也不会以明文形式存储，但是有可能它们被HSM中的主密钥包裹了。 这意味着某人可以批量解密并泄漏它们。

这个“罐头”非常重要。 无论是多么不可能，由于内部安全策略等原因，OTP都没有加密不可否认性。 客户可以轻松地拒绝输入代码以确认交易。 是否将其提上法庭是一个复杂的法律问题，可以对银行的流程进行审计，以查看是否可能发生违规行为，是否有任何管理员有动机滥用特权等等，是否存在违规记录。可以根据来自互联网运营商的网络日志链接到其设备的用户活动，等等。 因此，您可以通过适当的过程来实现一定程度的不可否认性。 但这与使用密码授权交易没有什么不同（希望它至少不是共享的秘密）。

但是，如果您有一个具有互联网连接的移动应用程序，那么为什么还要为此烦恼呢？ 您只需在独特的每次交易挑战中创建数字签名，即可获得适当的不可否认性。 手机可以在注册时生成私钥，并将其公钥发送到服务器，该服务器以后可以用来验证签名。 您没有人脑的带宽限制（导致需要6位数字），因此签名长度可以任意长（甚至GPRS都可以处理数字签名）。

使用正确的工具完成工作不仅具有技术意义，还具有法律和业务意义。 如果您可以使用标准的公共密钥加密技术实现不可否认性，如果您的客户的手机带有安全的硬件模块，并且您仍在进行基于移动应用程序的在线身份验证和授权，则只需丢弃OTP。

翻译自: https://www.javacodegeeks.com/2020/01/one-time-passwords-do-not-provide-non-repudiation.html

认证性 不可否认性