多平台加密java移动存储系统的构想

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

我知道这个问题有点长，可能太冗长了，但请试着读到最后（我有太多相关的问题，我不能把它们分成几个帖子）。如果您能就我的至少一个问题（疑问部分）给我一些反馈，我将不胜感激

谢谢

客观的

---

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

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

基本上，API将运动三种类型的商店：

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

考虑

---

受JSR-75启发，所有类型的存储都将通过URL以统一的方式访问，并遵循惯例，但使用自定义的前缀（即，文件为“file://”，首选项为“prefs://”，消息队列为“queue://”）。地址是指每个移动平台实现将映射到物理存储对象的虚拟位置。只有文件才允许分级存储（文件夹）和访问外部Extrage存储卡（通过单元名称，与JSR-75中的方式相同，但无论底层平台如何，都不会改变）。其他类型仅支持平面存储

系统还应支持所有基本类型的安全版本。用户可以在URL前面加上前缀“s”（即“sfile://”，而不是“file://”）。API只需要一个PIN（只引入一次）就可以访问任何类型的安全对象类型

执行问题

---

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

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

在加密方面，应满足以下要求：

• 为了简化实现，它将在流（文件）、RMS记录、SharedReferences键值对、SQLite数据库列的读/写操作基础上执行。每个底层存储对象都应该使用相同的加密密钥
• 加密存储的处理应与未加密存储的处理相同。从用户的角度来看，访问加密存储的唯一区别是寻址
• 用户PIN提供对任何安全存储对象的访问，但更改PIN不需要解密/重新加密所有加密数据
• 应尽可能使用底层平台的加密功能，因此我们将使用：
  • J2ME:SATSA-CRYPTO（如果可用）（不是强制性的）或用于J2ME的轻量级BoncyCastle加密框架
  • 黑莓：RIM加密API或BouncyCastle
  • Android:JCE与集成加密提供程序（BouncyCastle？）

我的怀疑。这里需要帮助

---

考虑到平台形式的局限性，达到这一点后，我对什么样的解决方案更方便产生了一些疑问。以下是我的一些疑问：

• 数据加密算法。AES-128是否足够强大和快速？对于这种情况，您会建议哪些替代方案
• 加密模式。我已经读过ECB加密相对于CBC的弱点，但在本例中，第一种加密具有随机访问块的优势，这对于文件上的seek功能很有意思。您会选择哪种类型的加密模式？流加密适合这种情况吗
• 密钥生成。可以为每个存储对象（文件、RMS RecordStore等）生成一个密钥，也可以仅为相同类型的所有对象使用一个密钥。第一种似乎“更安全”，尽管它需要设备上的一些额外空间。在你看来，每种方法的取舍是什么
• 密钥存储。在这种情况下，使用标准JKS（或PKCS#12）密钥库文件可能适合存储加密密钥，但我也可以定义一个较小的结构（加密转换）