问为脱机应用程序生成安全的短激活代码

EN

让我们研究一下问题中的命题：

• 我想使用ISO 7064 Mod 97,10公式，该公式不提供密码保护来抵御确定的对手。ISO/IEC 7064仅仅指定了一组检查字符系统，这些系统能够保护字符串不受在复制或键入数据时发生的错误的影响。
• 我可以使用上述公式生成代码，并使用带有数字证书的RSA。但是，输出会太长，对吗？是。RSA签名至少有公共模数的宽度，即用于现代安全2048位或$2048\log2 2/\log2 10\\约617$十进制字符。这太过分了，不能输入。
• 此外，这意味着中央当局必须有权访问所有硬件系统的公钥。不是的。对RSA签名的验证需要有权出示该签名的当局的公钥。忽略大小问题，将需要一个单独的公钥/私钥对，其中签名当局持有的私钥和所有设备中的相同公钥。设备可以识别签名数据中的序列号。

虽然有比RSA更紧凑的签名系统，但所有签名都至少比目标"7-8位数“高出10倍。因此，我们不能使用公钥密码学。

标准选项将是对称加密，每个设备中都有一个密钥。标准做法是，设备密钥来自发证机构已知的主密钥，而设备序列号则由某种密钥派生功能(智能卡行业自1980年代以来以多样化的名称实现)。必须保留一个主密钥，但是提取设备的密钥不会损害其他密钥。HMAC-SHA-256是一种合适的衍生方法.$\mathsf{DeviceKey}=\operatorname{HMAC}(\mathsf{MasterKey}，\mathsf{SerialNumber})$就行了。

解锁代码可以是某种消息身份验证代码，其索引在每次重新加载时递增，并被设备(和权威机构的发射系统)保存在永久内存中，并被截断。这可能是$\mathsf{UnlockCode}=\operatorname{HMAC}(\mathsf{DeviceKey}，\mathsf{Index}\bmod10^8$的十进制表达式。

正常操作是，授权机构获得付款，在其数据库中为$\mathsf{SerialNumber}$查找$\mathsf{索引}$，计算$\mathsf{DeviceKey}$然后$\mathsf{UnlockCode}$，在数据库中为该设备增加$\mathsf{索引}$。设备根据$\mathsf{UnlockCode}$检查输入内容，如果有匹配，则激活并在永久内存中增加$\mathsf{Index}$。

有些问题需要解决：

• $\mathsf{MasterKey}$和$\mathsf{DeviceKey}$s是敏感目标，在权限和制造站点可能容易受到攻击。HSM或智能卡可能会有所帮助。特别是，对有限数量的$\mathsf{UnlockCode}$s有利的智能卡可能是当局职员真正使用的东西。
• $\mathsf{SerialNumber}$或任何标识设备的设备都应该存在显著的冗余，以避免权威机构出现文书错误；
• 攻击者可能会随机尝试代码来解锁设备，可能是自动的。对策是条目之间的延迟，在多次连续错误之后可能会增加。也有可能有两个代码，一个限制为3次尝试的短代码(6位将很好)和一个长代码(比如12位数字)作为备份(类似于移动电话SIM中的PIN，并以PUK作为备份)。
• 对于各种威胁，设备应该有适当的缓解:未经授权使用而绕过付款，$\mathsf{DeviceKey}$提取，将$\mathsf{DeviceKey}$设置为已知值，将$\mathsf{索引}$设置为较早的值，允许重用早期代码，通过电池移除或其他烦扰，侧通道重置上述条目之间的延迟。一个经典的傻瓜是将输入的代码与使用$\mathsf{UnlockCode}$的strcmp或类似的库/语言特性进行比较，后者通过计时泄漏第一次失配的位置，而不需要打开框就可以观察到，例如，由于使用了LED或键盘扫描EMI，可以在大约40次(而不是5000万次)内找到8位数的代码。安全工程可不容易！
• 用户将丢失或暂时错误的代码，而不是麻烦要求一个副本，将支付一个新的。因此，该设备应能接受前面的几个代码。然后接受一些无序代码是可取的；这使算法变得复杂，特别是对于短代码(因为可接受窗口中的所有代码都必须是不同的)。如果必须接受一个$w$代码窗口，一个简单的选项是$w$ w)$。
• 更一般地，可以在代码中编码辅助信息(例如，重新加载数量)。当我们做到这一点时，代码的长度可以是可变的，对于高值代码，为了更高的安全性，它的长度可能会增加一到两个额外的数字。

注意:我认为格式保持加密在这里并没有真正的帮助，即使在有辅助信息要传达的时候也是如此，因为它的机密性似乎是一种麻烦而不是一种有用的特性。