问题标签 [key-management]

我需要在内核中存储一些加密密钥，其中每个密钥都与磁盘上的路径相关。一组受限制的用户可以在这样的路径上创建文件，但加密密钥由所有此类用户共享。我正在考虑为我的项目使用 linux 内核密钥管理工具。我有一个管理密钥和内核模块的用户模式应用程序。但是我不清楚 add_key 接口。如何创建所有人都可以访问的全局密钥环？add_key 的手册页对 add_key 有这样的说法

key_serial_t add_key(const char *type, const char *description, const void *payload, size_t plen, key_serial_t keyring);

描述

add_key() 要求内核创建或更新给定类型和描述的密钥，使用长度为 plen 的有效负载对其进行实例化，并将其附加到指定的密钥环并返回其序列号。

目标密钥环序列号可能是调用者具有写入权限的有效密钥环序列号，也可能是特殊密钥环 ID：

KEY_SPEC_THREAD_KEYRING 这指定调用者的线程特定密钥环。

KEY_SPEC_PROCESS_KEYRING 这指定调用者的进程特定的密钥环。

KEY_SPEC_SESSION_KEYRING 这指定调用者的会话特定密钥环。

KEY_SPEC_USER_KEYRING 这指定调用者的 UID 特定的密钥环。

KEY_SPEC_USER_SESSION_KEYRING 这指定调用者的 UID 会话密钥环。

我知道我可能需要使用内核中的 register_key_type API 在内核中注册我自己的“类型”。但是我不明白应该将什么值传递给 keyring 参数。另外，所有者在分配权限时是什么意思？

我们正在尝试使用 always on 功能创建 HA 组。

我们的数据库使用 EKM（外部加密提供商 - HSM）通过 TDE 加密。

尝试通过向导构建可用性组时，您无法选择具有

加密密钥，我找到了一个使用 T-SQL 脚本绕过此问题的链接，但它使用

主密钥而不是外部密钥（非对称）

https://www.simple-talk.com/sql/database-administration/encrypting-your-sql-server-2012-alwayson-availability-databases/

有没有办法使用 EKM 进行设置？

我想根据时间限制对特定资源的访问（可配置）。因此，假设用户 A 从他那里配置了时间 t。他每 t 个时间单位只能访问一次资源。t 的值可以来自一个固定的集合，但不是一个非常小的集合。我正在考虑使用多个哈希链来加密数据，但我正在寻找更具可扩展性的东西。

有什么建议么？

我的任务如下：

• 从我创建的密钥库中检索我的公钥和私钥。
• 使用这些密钥使用我的 RSA 2048 位公钥加密段落。
• 使用 DSA-SHA-1 签名算法对结果进行数字签名。
• 将数字签名输出保存在名为output.dat.

下面的程序抛出错误：“java.security.InvalidKeyException：没有安装的提供程序支持此密钥：sun.security.provider.DSAPublicKeyImpl”。

我有一个设计问题。我有一个使用 .NET 加密 API 来加密/解密数据的 Web 应用程序。（应用程序使用旧的加密算法，如 MD5 和 SHA-1）。此外，应用程序对生产代码中的加密密钥进行硬编码。

我想; 1 ) 将现有的旧算法（MD5 和 SHA-1）更新为新算法。2 ) 将加密密钥从源代码移动到安全共享。3 ) 可以轻松定期更改加密密钥

我的设计;

算法更新 对于算法更新，我们使用加密算法的特定 .NET 实现。我们使用像 MD5CryptoProvider 或 RijndaelManaged 这样的类。这些都是硬编码的。我将删除特定的算法依赖并使其更敏捷；

HashAlgorithm 算法 = HashAlgorithm.Create(MyPreferredHash.ToString()); 算法.ComputeHash(...);

MyPreferredHash 值将从配置文件中加载，以便我们可以在需要时更改它。

问题：升级代码很容易做到这一点。但是，您是否看到更改加密算法的任何潜在问题？我们不会在任何地方存储任何加密或散列数据，并且 Web 应用程序是无状态的。所有的哈希值都被生成并附加到 url 字符串并从其他页面解密。因此，不存储任何数据。除了饼干。当我们加密cookie并将其发送回用户时，我们会在服务器接收到它时对其进行解密。在这种情况下，我想销毁 cookie 并向客户端发送一个新的。这合理吗？你想到的还有其他问题吗？

密钥管理

设计的第二部分是从源代码中删除硬编码密钥以安全共享。在此之后，我需要能够推出新的加密密钥。每个加密密钥都将与过期日期相关联。当我们推出新的加密密钥时，新密钥将用于加密和解密。如果它无法解密，那么我们可以尝试旧密钥。旧密钥将用于解密或验证，直到其到期日期为止。当他们超过到期日时，他们应该退休。

用于存储；我正在考虑将加密密钥存储在本地计算机的配置文件中，由将驻留在安全共享中的主密钥“加密”。因此，无权访问此安全共享的任何人都无法看到主密钥。当机器重新启动时，主密钥将从安全共享加载到机器注册表。本地机器中的加密密钥将从配置文件（本地）加载并由注册表中的主密钥解密。

这种存储选择将使我们仅将一个主密钥存储在安全共享中，以及加密密钥的历史更改，因为我们将它们存储在版本控制系统中。

具有挑战性的部分是关键更改/更新。

对于分布式 Web 应用程序，这里推荐的密钥更改算法是什么？如果我们在发布后进行部分部署，则并非所有机器都具有相同的配置文件内容（例如，添加了新的加密密钥）。所有站点部署可能需要 1-2 周。这也是另一个问题，如果我们应该等待所有部署完成，以便之后这些密钥将处于活动状态。

还有别的反馈吗？

我一直在尝试在 Jenkins 上开始一项工作，以通过 SSH 密钥克隆存储库，但即使在我设置了凭据之后，我仍然不断收到密码错误。

葡萄牙版画对不起。

我错过了一些设置配置？

谢谢。

解决方法 我删除了公钥的密码并且有效。但仍然需要加密密码的解决方案。

我正在邀请一名临时工为 iPhone 编写我的应用程序的一部分。大部分数据都是使用 mcrypt 加密的。数据在 Android 或 iPhone 上生成并在 php 中解密，反之亦然。

临时工有什么办法可以在不知道加密密钥和盐的情况下完成他的任务？

我有一个付费插件的程序，它会经常更新。用户必须购买订阅才能使用某些插件（即每月免费支付）。

我为插件选择基于订阅的模式的主要原因很简单，更新确实是卖点，因为插件必须经常更新。长话短说，这些插件在没有更新的情况下基本上是无用的，因为它所使用的软件也会经常更新，并且会出现问题。

现在到文件下载。我基本上只想允许付费用户使用这些插件。

通常使用中央服务器和数据库，这是相当微不足道的，但当您不能拥有带有数据库的中央服务器时，情况并非如此。（我对此没有影响。）

这是我想出的最有效的解决方案：

• 用户获得一个随机的 AES256 密钥。
• 我们使用随机的 AES256 密钥加密付费插件。
• 然后我们用用户密钥加密插件的密钥。
• 冲洗并对所有用户和插件重复上述操作，并创建一个整体密钥文件。
• 将加密的插件文件和整体密钥文件上传到文件共享服务。

上述解决方案具有以下特点：

• 能够在后续版本中撤销密钥。（很重要）
• 默默无闻没有安全感。任何人都可以下载插件或密钥文件，但除非他们有自己的密钥，否则对他们没有用处，因为暴力破解 AES256 在计算上是不可行的。

这个解决方案没问题，但是当用户和插件数量增加时就会出现问题。

例子：

• 我们有 10,000 个用户和 100 个插件。
• 10,000 个用户 * 100 个插件 = 1,000,000 个密钥
• 1,000,000 个密钥 * 每个密钥 300 字节** = 300MB

** 密钥 (64) + 初始化向量 (32) + 每个密钥的文件格式开销，以便软件可以找到正确的密钥进行解密。

即使在最好的情况下（不可能），它也是一个 96 MB 的密钥文件。

这个（未知）已知问题还有其他解决方案吗？它们叫什么，它们在哪里使用？

如何将 .p12 证书从类路径导入 java 密钥库？首先，我使用了 InstallCert https://code.google.com/p/java-use-examples/source/browse/trunk/src/com/aw/ad/util/InstallCert.java并做了一些更改，因此服务器证书将被导入到 java 安装目录中的密钥库中。这工作正常，但现在我想从我的类路径加载证书。

编辑：我只使用 .cer 证书，请参阅下一个答案

我的 Java 应用程序服务器即将与 RESTful Web 服务集成，并将轮询它以获取内容 (JSON) 以显示给我的用户。

我的用户使用他们的用户名/密码登录，然后我必须对其进行哈希 + salt，然后在每次调用时转发到 Web 服务。Web 服务获取散列/加盐登录信息并对其进行身份验证（同样，每次调用）。

假设我无法在 Web 服务端更改任何内容，并且 Web 服务需要散列/盐渍登录凭据作为输入参数（以及 API 端点、HTTP 正文等），我可以采取哪些安全措施客户端以确保用户提供的用户名/密码安全。

我可能做的最糟糕的事情就是把它们留在记忆中。我还有哪些其他选择？