思路多平台的Java加密移动存储系统 [英] Ideas for multiplatform encrypted java mobile storage system
问题描述
您好我有一些问题（读疑虑部分）关于执行加密存储（一种加密文件系统）在Android，黑莓和J2ME。 我需要你的意见，你加密大师
我知道这个问题有点长一个也许太详细，但请尽量读它，直到最后（我有很多相关的问题，我不能在几个职位分裂他们）。我真的AP preciate，如果你能给我一些反馈的至少一个我的问题（惑一部分）。
谢谢
＆NBSP;
＆NBSP;
目标
我目前正在设计用于多平台的存储系统，将提供相同的接口和功能翻过的API以下支持Java手机平台：
- J2ME 。最低配置/ profile文件CLDC 1.1 / MIDP 2.0将一些必要的JSR（JSR-75用于文件存储）的支持。
- 机器人。没有最低平台版本尚未决定，而是可能会是API 7级。
- 黑莓。它会使用J2ME的相同的基础源的平台，一些advaced功能，但利用。 （中可能4.6，因为64 KB的限制，对4.5 RMS）。没有最低配置决定呢
基本上，API将运动型三类店：
- 的文件的。这将允许标准目录/文件操作（读/写过流，创造，MKDIR，等等）。
- 的 preferences 的。这是处理通过键访问属性的特殊商店（类似普通的旧Java属性文件，但支持了一些改进，例如不同的值数据类型，如Android平台的共享preferences）
- 的本地消息队列的。这家商店将提供基本的消息队列功能。
注意事项
灵感的JSR-75，所有类型的商店将是一个统一的方式通过URL之后的 RFC 1738 公约，但与自定义prefixes（即文件：//的文件，preFS：//为preferences或队列：// 消息队列）。地址将提及，将被映射到一个物理存储目的是通过每个移动平台执行的虚拟位置。只有文件将使分层存储（文件夹），并获得外部extorage存储器卡（由一个单位名称，相同的方式在JSR 75的装置，但无论底层平台的，不会改变）。其他类型将只支持平面仓库。
该系统还应该支持所有的基本类型的安全版的。用户将表明它由prefixingS的网址（即：不是文件：//sfile //）。该API将的只需要一个密码的（只介绍一次）来访问任何类型的安全对象类型。
实施问题
对于这两个明文和加密存储的实现，我会用底层的平台上可用的功能：
- 文件。这些都可以在所有平台（J2ME只能与支持JSR-75，但它是必须满足我们的需要）。摘要文件，以实际文件的映射是直的，除了解决问题。
- RMS 。这种类型的商店可以在J2ME（和黑莓）平台，便于preferences，也许消息队列（尽管这取决于使用性能和尺寸要求，这些可以通过正常的文件来实现）。
- 共享preferences 。这种类型的存储，只可在Android，将匹配preferences需求。
- SQLite数据库。这可用于信息队列在Android（也许黑莓）。
当它涉及到加密一些要求应满足：
- 要减轻它的实施将进行读/写操作的基础上，流（的文件），RMS记录，共享preferences键值对，SQLite数据库列。每个基本存储对象应使用相同的加密密钥。
- 处理的加密存储的应该是一样的未加密的对应。唯一的区别（从用户的角度来看）访问加密存储将是寻址方式。
- 在用户密码可以访问任何安全存储的对象，但它的变化不会要求解密/重新加密所有的加密数据。
- 底层平台的加密功能应该使用只要可能，因此，我们可以使用：
- J2ME：SATSA-CRYPTO（如果可用）（非强制）或轻BoncyCastle加密框架为J2ME
- 黑莓手机：RIM加密API或BouncyCastle的
- 安卓JCE与integraced加密提供商（？BouncyCastle的）
我的疑惑。虚位以待这里
在到达这一点我感到震惊的有些疑惑什么解决方案，那就更方便了，考虑到plataforms的限制。这些都是一些我的疑惑
- 加密算法用于数据。将AES-128是强而快的还不够吗？你会建议什么选择了这样的场景？
- 加密模式。我已阅读有关的ECB加密与CBC的弱点，但在这种情况下，第一将具有随机存取块，这是有趣的寻求上的文件的功能的优点。你会选择什么类型的加密模式，而不是？是流加密适用于这种情况？
- 密钥生成。有可能是对每个存储的对象（文件，有效值的RecordStore等）或只使用一个用于同一类型的所有对象生成的一个密钥。第一个似乎更安全，但它需要在设备上一些额外的空间。您认为会是什么权衡每一个？
- 键存储。对于使用标准JKS（或PKCS＃12）密钥存储的文件可以适合于存储密钥，但我也可以定义一个更小的结构（加密变换/关键数据/校验），可以连接到每个存储存储（这种情况下，即采用另外的文件具有相同的名称和专用扩展纯文本文件或嵌入到其它类型的对象，如RMS记录存储）的。你会$什么方法p $ PFER？当涉及到使用多个密钥生成一个标准的密钥库（鉴于这是你的preference），会是更好的使用记录存储每个存储对象或只是一个全球性的密钥库保存所有密钥（即使用抽象的存储对象为化名）？ 的URL标识
- 主键。使用万能钥匙的似乎是显而易见的。该键应该由用户PIN来保护（引入仅一次），并将允许访问加密密钥的剩余部分（它们将通过此主密钥的装置进行加密）。改变的PIN将仅需要重新加密该密钥，而不是所有的加密的数据。你会在哪里把它考虑到，如果这个走失的所有数据将不再入店？我应该采取什么进一步的因素考虑在内？
- 平台加密支持。不要SATSA启用-加密J2ME手机真正利用一些专用硬件加速（或其他好处我还没有预见到），希望这种做法是prefered（尽可能）经过短短BouncyCastle的实施？出于同样的原因是RIM加密API价值超过BouncyCastle的许可费用是多少？
的任何意见，批评，进一步的考虑和不同的做法是值得欢迎的。
我的第一个想法：
加密算法用于数据的：AES是pretty的快速算法，但你可以采取AES-256，如果你想确保它是足够强大。虽然我觉得有更简单的方法来破解这个系统，如果你真的想要（如钥匙在读PIN code内存？）
主键的：如果用户丢失了主密钥，你可以什么也不做。这是整点！如果有一个后门程序，它会被发现和使用的黑客的攻击。</ P>
与所有安全问题，付出多少努力，你想要做的，让黑客侵入。这主要有做有多大流行和广泛使用的程序就越大。
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屋！
