多平台加密java移动存储系统的想法 [英] Ideas for multiplatform encrypted java mobile storage system
问题描述
我知道这个问题有点长，也许太冗长了，但请尝试阅读直到最后（我有这么多相关的问题，我不能分开在几个帖子）。我真的很感激，如果你能给我一些关于至少一个问题的反馈（疑问部分）。
谢谢，
目标
我目前正在为多平台存储系统设计API，在支持的移动Java平台之后提供相同的界面和功能： p>
- 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平台上的SharedPreferences）
- 本地邮件队列。
注意事项
受JSR-75的启发，所有类型的商店将以统一的方式通过 RFC 1738 约定，但使用自定义的前缀（即file：//用于文件，prefs：//用于首选项或queue：//表示消息队列）。该地址将指的是由每个移动平台实现映射到物理存储对象的虚拟位置。只有文件才允许分层存储（文件夹）和访问外部存储卡（通过单元名称，与JSR-75中相同的方式，但不管底层平台如何，都不会改变）。其他类型只能支持平面存储。
系统还应支持所有基本类型的安全版本。用户将通过在URL（即sfile：//而不是file：//）前缀s来指示它。 API将只需要一个PIN （仅引入一次）来访问任何类型的安全对象类型。
实现问题
为了实现明文和加密存储，我将使用底层平台上提供的功能：
- 文件。这些可用于所有平台（J2ME仅适用于JSR-75，但对我们的需求是强制性的）。抽象文件到实际的文件映射是直接的，除了解决问题。
- RMS 。 J2ME（和Blackberry）平台上的这种类型的商店对于首选项和可能的消息队列（尽管取决于性能或大小要求，可以通过普通文件来实现）。
- 的 SharedPreferences 即可。这种类型的存储（仅在Android上可用）将匹配首选项需求。
- SQLite数据库。这可以用于Android（也可能是黑莓）上的消息队列。
在加密时应满足一些要求： / p>
- 为了简化实现，将以流（文件），RMS记录，SharedPreferences键值的读/写操作为基础进行对，SQLite数据库列。每个底层存储对象应使用相同的加密密钥。
- 加密存储的处理应与未加密对应的处理相同。访问加密存储的唯一区别（从用户的角度来看）将是寻址。
- 用户PIN提供对任何安全存储对象的访问，但是它的更改不需要解密/重新加密所有加密的数据。
- 应用层次平台的加密功能，只要有可能，我们将使用：
- J2ME：SATSA-CRYPTO如果可用（不是强制性的）或J2ME的轻量级BoncyCastle加密框架。</ li>
- 黑莓：RIM加密API或BouncyCastle
- Android：具有集成加密提供商的JCE（BouncyCastle？）
- J2ME：SATSA-CRYPTO如果可用（不是强制性的）或J2ME的轻量级BoncyCastle加密框架。</ li>
我的怀疑帮助希望在这里
达到这一点后，我对某些解决方案会更方便，考虑到平台的局限性。这些是一些我的怀疑：
- 数据加密算法。 AES-128能够强大和足够快吗？您会建议哪种替代方案？
- 加密模式。我已经阅读了关于ECB加密与CBC的弱点，但在这种情况下，第一个将具有随机访问块的优点，这对于文件上的查找功能很有意思。你会选择什么类型的加密模式？流加密适用于这种情况吗？
- 密钥生成。可以为每个存储对象（文件，RMS RecordStore等）生成一个密钥，或只对所有相同类型的对象使用一个密钥。第一个似乎是更安全，虽然它将需要一些额外的空间在设备上。在你看来，每个的权衡是什么？
- 密钥存储。对于这种情况，使用标准的JKS（或PKCS＃12）KeyStore文件可能适合存储加密密钥，但是我也可以定义可以附加到每个存储存储的较小结构（加密转换/密钥数据/校验和）即使用相同名称的附加文件和普通文件的特殊扩展或嵌入其他类型的对象（如RMS记录存储））。你会喜欢什么方法？而当涉及使用具有多密钥生成的标准密钥存储（给定这是您的首选项）时，最好是使用每个存储对象的记录存储或仅保留所有密钥的全局密钥存储（即使用抽象存储对象作为别名）？
- 主密钥。使用主键似乎很明显。该密钥应由用户PIN（仅引入一次）保护，并允许访问其余的加密密钥（它们将通过该主密钥进行加密）。更改PIN只需要重新加密该密钥，而不是所有的加密数据。考虑到如果丢失了所有的数据，那么你会在哪里保留它呢？我应该考虑什么进一步的考虑？
- 平台加密支持。启用SATSA-CRYPTO的J2ME手机真的可以利用一些专用的硬件加速（或者我没有预见到的其他优势），而且只要BouncyCastle实现，这种方法会被优先考虑（尽可能的）同样的原因是RIM加密API价值超过BouncyCastle的许可证成本？
任何评论，评论，进一步的考虑或不同
我的第一个想法：
<数据加密算法：AES是一个非常快的算法，但如果要确保它足够强大，可以使用AES-256。虽然我想，如果你真的想要（如密码在内存中阅读PIN码）有更简单的方式来破解这个系统。
主密钥：如果用户丢失了主密钥，你什么都不做。这就是整点！如果有一个后门，它将被黑客找到并使用。
与所有安全问题一样，你想要做多少努力来保持黑客的远离。这主要是关于该程序如何受欢迎和广泛使用。
Hi I have some questions (read Doubts part) regarding implementing encrypted storage (kind of encrypted filesystem) on Android, Blackberry and J2ME. I need your advice, you cryptography masters.
I know this question is a bit long a maybe too verbose, but please try to read it till the end (I have so many related questions that I couldn't split them up in several posts). I would really appreciate if you can give me some feedback on at least one of my questions (Doubts part).
Thanks,
Objective
I am currently designing the API for a multiplatform storage system that would offer same interface and capabilities accross following supported mobile Java Platforms:
- J2ME. Minimum configuration/profile CLDC 1.1/MIDP 2.0 with support for some necessary JSRs (JSR-75 for file storage).
- Android. No minimum platform version decided yet, but rather likely could be API level 7.
- Blackberry. It would use the same base source of J2ME but taking advantage of some advaced capabilities of the platform. No minimum configuration decided yet (maybe 4.6 because of 64 KB limitation for RMS on 4.5).
Basically the API would sport three kind of stores:
- Files. These would allow standard directory/file manipulation (read/write through streams, create, mkdir, etc.).
- Preferences. It is a special store that handles properties accessed through keys (Similar to plain old java properties file but supporting some improvements such as different value data types such as SharedPreferences on Android platform)
- Local Message Queues. This store would offer basic message queue functionality.
Considerations
Inspired on JSR-75, all types of stores would be accessed in an uniform way by means of an URL following RFC 1738 conventions, but with custom defined prefixes (i.e. "file://" for files, "prefs://" for preferences or "queue://" for message queues). The address would refer to a virtual location that would be mapped to a physical storage object by each mobile platform implementation. Only files would allow hierarchical storage (folders) and access to external extorage memory cards (by means of a unit name, the same way as in JSR-75, but that would not change regardless of underlying platform). The other types would only support flat storage.
The system should also support a secure version of all basic types. The user would indicate it by prefixing "s" to the URL (i.e. "sfile://" instead of "file://"). The API would only require one PIN (introduced only once) to access any kind of secure object types.
Implementation issues
For the implementation of both plaintext and encrypted stores, I would use the functionality available on the underlying platforms:
- Files. These are available on all platforms (J2ME only with JSR-75, but it is mandatory for our needs). The abstract File to actual File mapping is straight except for addressing issues.
- RMS. This type of store available on J2ME (and Blackberry) platforms is convenient for Preferences and maybe Message Queues (though depending on performance or size requirements these could be implemented by means of normal files).
- SharedPreferences. This type of storage, only available on Android, would match Preferences needs.
- SQLite databases. This could be used for message queues on Android (and maybe Blackberry).
When it comes to encryption some requirements should be met:
- To ease the implementation it will be carried out on read/write operations basis on streams (for files), RMS Records, SharedPreferences key-value pairs, SQLite database columns. Every underlying storage object should use the same encryption key.
- Handling of encrypted stores should be the same as the unencrypted counterpart. The only difference (from the user point of view) accessing an encrypted store would be the addressing.
- The user PIN provides access to any secure storage object, but the change of it would not require to decrypt/re-encrypt all the encrypted data.
- Cryptographic capabilities of underlying platform should be used whenever it is possible, so we would use:
- J2ME: SATSA-CRYPTO if it is available (not mandatory) or lightweight BoncyCastle cryptographic framework for J2ME.
- Blackberry: RIM Cryptographic API or BouncyCastle
- Android: JCE with integraced cryptographic provider (BouncyCastle?)
My Doubts. Help Wanted Here
Having reached this point I was struck by some doubts about what solution would be more convenient, taking into account the limitation of the plataforms. These are some of my doubts:
- Encryption Algorithm for data. Would AES-128 be strong and fast enough? What alternatives for such scenario would you suggest?
- Encryption Mode. I have read about the weakness of ECB encryption versus CBC, but in this case the first would have the advantage of random access to blocks, which is interesting for seek functionality on files. What type of encryption mode would you choose instead? Is stream encryption suitable for this case?
- Key generation. There could be one key generated for each storage object (file, RMS RecordStore, etc.) or just use one for all the objects of the same type. The first seems "safer", though it would require some extra space on device. In your opinion what would the trade-offs of each?
- Key storage. For this case using a standard JKS (or PKCS#12) KeyStore file could be suited to store encryption keys, but I could also define a smaller structure (encryption-transformation / key data / checksum) that could be attached to each storage store (i.e. using addition files with the same name and special extension for plain files or embedded inside other types of objects such as RMS Record Stores). What approach would you prefer? And when it comes to using a standard KeyStore with multiple-key generation (given this is your preference), would it be better to use a record-store per storage object or just a global KeyStore keeping all keys (i.e. using the URL identifier of abstract storage object as alias)?
- Master key. The use of a master key seems obvious. This key should be protected by user PIN (introduced only once) and would allow access to the rest of encryption keys (they would be encrypted by means of this master key). Changing the PIN would only require to reencrypt this key and not all the encrypted data. Where would you keep it taking into account that if this got lost all data would be no further accesible? What further considerations should I take into account?
- Platform cryptography support. Do SATSA-CRYPTO-enabled J2ME phones really take advantage of some dedicated hardware acceleration (or other advantage I have not foreseen) and would this approach be prefered (whenever possible) over just BouncyCastle implementation? For the same reason is RIM Cryptographic API worth the license cost over BouncyCastle?
Any comments, critics, further considerations or different approaches are welcome.
My first thoughts:
Encryption Algorithm for data: AES is a pretty fast algorithm, but you can take AES-256 if you want to make sure that it is strong enough. Although I think there are easier ways to hack this system if you really want to (e.g. keys in memory? reading of PIN code?)
Master key: If the user loses the master key, you can do nothing. That is the whole point! If there is a backdoor, it will be found and used by hackers.
As with all security issues, how much effort do you want to do to keep hackers away. This has mainly to do with how popular and widely used the program becomes.
这篇关于多平台加密java移动存储系统的想法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
