使用硬件加密设备（例如 USB 加密狗/密钥库）而不是使用软件库是否有正当理由？
如果您的应用程序需要加密/解密数据（出于各种原因），您是否有任何理由使用硬件设备（例如 USB 加密设备 - 如 Marx CryptoBox）而不是使用软件加密库（如 .net Cryptography）或者自己编写）并将密钥保存在安全的密钥库中？
我正在寻找对此事的一些客观看法。
缩小提出的问题范围：如果使用 USB 加密狗的系统位于物理安全的服务器库中并且仅存在一个系统（即它不是一个软件），您会有何看法在许多桌面上分发和运行的产品）？ 简而言之，上述系统的目的是验证（解密和比较）传入的加密数据。
到目前为止，感谢您的精彩回答！
If your application needs to encrypt/decrypt data (for various reasons), are there any reasons why you would use a hardware device (e.g. a USB encryption device - like a Marx CryptoBox) instead of using a software encryption library (like .net Cryptography or writing your own) and keep your keys in a safe key store?
I am looking for some objective views on this matter.
To narrow down the question posed: what would your opinion be if the system that used the usb encrpytion dongle was housed in a physically secure server vault and there was only one system in existence (i.e. its not a software product that is distributed and run on many desktops) ? In very simplistic terms, the purpose of the above system is to validate (decrypt and compare) a piece of incoming encrypted data.
Thanks so far for your great answers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这并不是什么更安全的问题，因为没有什么是 100% 防弹的。 这是一个关于“如何使其尽可能困难”的问题，
您可以从这一点看出：如果您将密钥存储在计算机上，那么它们 24/7 都在那里。 如果我的一对密钥位于外部设备上，则只有在连接到设备时才能访问这些密钥。 ==> 您可以减少其他人复制您的密钥的时间。 如果不需要物理访问，则访问某些内容会容易得多。
想想网上银行：许多银行都添加了“外部”身份验证方式，例如 Tan / Tac /tanSMS/ 令牌生成器等。这些本身都不安全：我可以窃取您的登录密码，我可以窃取您的手机，我可以窃取你的 Tac/Tan 列表等等。 但我一次性窃取所有必要元素的可能性非常低=> 难题的所有部分共同创造了一个非常安全的解决方案。
还要考虑这些因素：
It's not about what's more secure because nothing is 100% bullet proof. It's a question on "how to make it as difficult as possible"
You could see it from this point: If you store keys on the computer, they're there 24/7. If my pair of keys is on an external device, the keys are only accessible while attached to the device. ==> You reduce the timeframe in which somebody else can copy your keys. It's much easier to access something if physical access is not needed.
Think of online banking: Many banks have added "external" ways of authentifcation such as Tan / Tac /tanSMS/ tokengenerators etc. etc. Neither of those is secure for itself: I can steal your login password, I can steal your mobile phone, I can steal your Tac/Tan list and so on. But chaces are very low that I can steal all necessary elements at once => All pieces of the puzzle together create a quite secure solution.
Also think of these factors:
硬件密钥允许将软件的使用限制在插入密钥的机器上。
通过软件加密，可以更轻松地将软件复制到多台机器并并行运行多次。
A hardware key allows use to constrain usage of the software to a machine where the key is plugged in.
With software encryption it would be easier to copy the software to many machines and run it many times in parallel.
是的，有。
一方面，这允许您通过安全通道物理传输私钥，而不是信任网络。
另一方面，如果您必须在许多不一定全部联网的系统之间移动，那么 USB 密钥会更方便。 这就是为什么军队使用非常类似的系统（EKMS）。 他们不使用 USB，但使用看起来像大塑料钥匙的小加密狗。 想法是一样的，但是在 90 年代初他们开发 USB 时还不存在。
（注意：维基百科文章的完整程度有点可怕。当我当时正在从事 KP 工作，有人告诉我，我们可以在简历上使用 FIREFLY 等缩写词，但我们不被允许告诉任何人他们的意思。）
Yes, there are.
For one thing, this allows you to transmit the private keys physically through secure channels, rather than trusting a network.
For another, if you have to move around between a lot of systems that aren't nessecarily all networked, the USB key is just way more convienent. That's why the military uses a system very much like that (EKMS). They don't use USB, but they use little dongles that look like big plastic keys. The idea is the same, but USB didn't exist back in the early 90's when they were developing this.
(note: Its kinda scary how complete that Wikipedia article is. When I was working on the KP I was told we were allowed to put acronyms like FIREFLY on our resumes, but we weren't allowed to tell anybody what they meant.)
我认为这取决于您的应用程序的目的/用途。 如果您正在开发满足高安全需求的产品（例如银行或政府），那么在解决方案中添加硬件可能是完全合适的。 您必须考虑硬件解决方案会给项目增加的额外成本。 不仅在最初的开发中，而且在开发完成后所需的持续硬件维护成本。 从我的角度来看，在过去的银行业工作中，我们认为硬件解决方案值得付出额外成本的解决方案非常非常少。
I think it depends on the purpose/usage of your application. If you're developing a product for a high security need, such as banking or government, a hardware addition to your solution could be entirely appropriate. You have to consider the additional costs that a hardware solution would add to the project. Not just in the initial development, but the ongoing hardware maintenance costs that would be required after development is complete. From my perspective, having worked banking in the past, there were very, very few solutions where we felt that a hardware solution was worth the additional costs it would entail.