多平台加密java移动存储系统的思路

您好，我有一些关于在 Android、Blackberry 和 J2ME 上实现加密存储（一种加密文件系统）的问题（请阅读“疑问”部分）。我密码学大师们需要您的建议.

我知道这个问题有点长，可能太冗长，但请尝试读到最后（我有很多相关的问题，我无法将它们分成几篇文章）。如果您能就我的至少一个问题提供一些反馈，我将不胜感激（疑惑部分).

Thanks,

客观的

我目前正在为多平台存储系统设计 API，该系统将在以下受支持的移动 Java 平台上提供相同的接口和功能：

• J2ME。最低配置/配置文件 CLDC 1.1/MIDP 2.0，支持一些必要的 JSR（用于文件存储的 JSR-75）。
• Android。最低平台版本尚未确定，但很可能是 API 级别 7。
• 黑莓。它将使用与 J2ME 相同的基础源，但利用该平台的一些高级功能。尚未确定最低配置（可能是 4.6，因为 4.5 上 RMS 的 64 KB 限制）。

基本上，API 将支持三种类型的商店：

• Files。这些将允许标准目录/文件操作（通过流读/写、创建、mkdir 等）。
• 优先。它是一个特殊的存储，处理通过键访问的属性（类似于普通的旧java属性文件，但支持一些改进，例如不同的值数据类型，例如Android平台上的SharedPreferences）
• 本地消息队列。该商店将提供基本的消息队列功能。

注意事项

受 JSR-75 的启发，所有类型的商店都可以通过以下 URL 以统一的方式访问RFC 1738 http://www.faqs.org/rfcs/rfc1738.html约定，但具有自定义定义的前缀（即“file://”用于文件，“prefs://”用于首选项或“queue://”用于消息队列）。该地址指的是由每个移动平台实现映射到物理存储对象的虚拟位置。只有文件才允许分层存储（文件夹）和访问外部存储卡（通过单元名称，与 JSR-75 中的方式相同，但无论底层平台如何，都不会改变）。其他类型仅支持平面存储。

该系统还应该支持所有基本类型的安全版本。用户可以通过在 URL 中添加前缀“s”来表明这一点（即“sfile://”而不是“file://”）。该 API 将只需要一个 PIN 码（仅介绍一次）访问任何类型的安全对象类型。

实施问题

对于明文和加密存储的实现，我将使用底层平台上可用的功能：

• Files。这些在所有平台上都可用（J2ME 仅适用于 JSR-75，但对于我们的需求来说这是强制性的）。除了解决问题之外，抽象文件到实际文件的映射是直接的。
• RMS。 J2ME（和 Blackberry）平台上提供的这种类型的存储对于首选项和消息队列来说很方便（尽管根据性能或大小要求，这些可以通过普通文件来实现）。
• 共享首选项。这种类型的存储仅在 Android 上可用，可以满足首选项需求。
• SQLite 数据库。这可用于 Android（也可能是 Blackberry）上的消息队列。

当涉及到加密时，应满足一些要求：

• 为了简化实施，它将在流（文件）、RMS 记录、SharedPreferences 键值对、SQLite 数据库列的基础上执行读/写操作。每个底层存储对象都应使用相同的加密密钥。
• 加密存储的处理应与未加密对应的处理相同。访问加密存储的唯一区别（从用户的角度来看）是寻址。
• 用户 PIN 提供对任何安全存储对象的访问，但对其进行更改不需要解密/重新加密所有加密数据。
• Cryptographic capabilities of underlying platform should be used whenever it is possible, so we would use:
  • J2ME：SATSA-CRYPTO（如果可用）（非强制）或 J2ME 的轻量级 BoncyCastle 加密框架。
  • 黑莓：RIM 加密 API 或 BouncyCastle
  • Android：带有集成加密提供程序的 JCE（BouncyCastle？）

我的疑问。这里需要帮助

到达这一点后，考虑到平台的限制，我对哪种解决方案更方便感到怀疑。这些是其中一些我的疑问:

• 数据加密算法。 AES-128 是否足够强大且足够快？对于这种情况，您会建议什么替代方案？
• 加密方式。我已经了解了 ECB 加密与 CBC 相比的弱点，但在这种情况下，第一个加密具有随机访问块的优势，这对于文件的查找功能很有趣。您会选择哪种类型的加密模式？流加密适合这种情况吗？
• 密钥生成。可以为每个存储对象（文件、RMS RecordStore 等）生成一个密钥，或者仅对同一类型的所有对象使用一个密钥。第一个似乎“更安全”，尽管它需要设备上有一些额外的空间。您认为两者之间的权衡是什么？
• 密钥存储。对于这种情况，使用标准 JKS（或 PKCS#12）KeyStore 文件可能适合存储加密密钥，但我也可以定义一个较小的结构（加密转换/密钥数据/校验和），该结构可以附加到每个存储存储（即使用与普通文件相同名称和特殊扩展名的附加文件或嵌入其他类型的对象（例如 RMS 记录存储）中。您更喜欢哪种方法？当涉及到使用具有多个密钥生成功能的标准 KeyStore 时（假设这是您的偏好），最好是为每个存储对象使用一个记录存储，还是仅使用一个保留所有密钥的全局 KeyStore（即使用 URL 标识符）抽象存储对象作为别名）？
• 主密钥。主密钥的使用似乎是显而易见的。该密钥应受用户 PIN 码（仅引入一次）保护，并允许访问其余加密密钥（它们将通过该主密钥进行加密）。更改 PIN 仅需要重新加密该密钥，而不需要重新加密所有加密数据。考虑到如果丢失了所有数据将无法进一步访问，您会将其保存在哪里？我还应该考虑哪些进一步的考虑因素？
• 平台加密支持。支持 SATSA-CRYPTO 的 J2ME 手机是否真的利用了某些专用硬件加速（或我未预见到的其他优势），并且这种方法是否比 BouncyCastle 实施更受青睐（只要可能）？出于同样的原因，RIM 加密 API 是否值得比 BouncyCastle 更值得支付许可费用？

欢迎任何评论、批评、进一步的考虑或不同的方法。

我的第一个想法：

数据加密算法：AES 是一种非常快的算法，但如果您想确保它足够强大，可以采用 AES-256。虽然我认为如果你真的想要的话，有更简单的方法可以破解这个系统（例如内存中的密钥？读取 PIN 码？）

主密钥：如果用户丢失了主密钥，则无能为力。这就是重点！如果存在后门，就会被黑客发现并利用。

与所有安全问题一样，您希望付出多少努力来阻止黑客入侵。这主要与该程序的流行和广泛使用有关。