嗨我有一些关于在Android,Blackberry和J2ME上实现加密存储(加密文件系统类型)的问题(请阅读Doubts部分).密码学硕士,我需要你的建议.
我知道这个问题有点长,可能太冗长了,但是请尝试阅读它直到最后(我有很多相关的问题,我不能在几个帖子中将它们分开).如果您能就我的至少一个问题(怀疑部分)给我一些反馈,我将非常感激.
谢谢,
目的
我目前正在为多平台存储系统设计API,该系统将提供与以下支持的移动Java平台相同的接口和功能:
- J2ME.最低配置/配置文件CLDC 1.1/MIDP 2.0,支持一些必要的JSR(用于文件存储的JSR-75).
- Android.尚未确定最低平台版本,但很可能是API级别7.
- 黑莓.它将使用相同的J2ME基础源,但利用该平台的一些先进功能.尚未确定最低配置(可能为4.6,因为4.5上的RMS限制为64 KB).
基本上API会运行三种商店:
- 档案.这些将允许标准目录/文件操作(通过流,create,mkdir等读/写).
- 偏好.它是一个特殊的商店,处理通过键访问的属性(类似于普通的旧java属性文件,但支持一些改进,如不同的值数据类型,如Android平台上的SharedPreferences)
- 本地消息队列.该商店将提供基本的消息队列功能.
注意事项
受JSR-75启发,所有类型的商店都将通过符合RFC 1738惯例的URL以统一的方式访问,但具有自定义前缀(即"file://"表示文件,"prefs://"表示对于消息队列,首选项或"queue://").该地址将指的是每个移动平台实现将映射到物理存储对象的虚拟位置.只有文件才允许分层存储(文件夹)和访问外部存储卡(通过单元名称,与JSR-75相同,但不管底层平台如何都不会改变).其他类型只支持平面存储.
系统还应支持所有基本类型的安全版本.用户通过在URL上加"s"前缀来表示它(即"sfile://"而不是"file://").API 只需要一个PIN(仅引入一次)来访问任何类型的安全对象类型.
实施问题
为了实现明文和加密存储,我将使用底层平台上可用的功能:
- 档案.这些可在所有平台上使用(J2ME仅适用于JSR-75,但它对我们的需求是强制性的).除了解决问题之外,抽象文件到实际文件映射是直接的.
- RMS.在J2ME(和Blackberry)平台上可用的这种类型的存储对于Preferences和Message Queues来说很方便(虽然取决于性能或大小要求,这些可以通过普通文件实现).
- SharedPreferences.此类存储仅在Android上可用,将与首选项需求相匹配.
- SQLite数据库.这可以用于Android(也许是Blackberry)上的消息队列.
在加密方面,应满足一些要求:
- 为了简化实现,它将基于流(用于文件),RMS记录,SharedPreferences键值对,SQLite数据库列在读/写操作的基础上执行.每个底层存储对象都应使用相同的加密密钥.
- 加密商店的处理应与未加密的商店相同.访问加密存储的唯一区别(从用户的角度来看)是寻址.
- 用户PIN提供对任何安全存储对象的访问,但是更改它不需要解密/重新加密所有加密数据.
- 应尽可能使用底层平台的加密功能,因此我们将使用:
- J2ME:SATSA-CRYPTO(如果可用)(非强制)或轻量级的BoncyCastle加密框架(适用于J2ME).
- Blackberry:RIM Cryptographic API或BouncyCastle
- Android:JCE与集成加密提供程序(BouncyCastle？)
我怀疑.求助于此
达到这一点后,考虑到平台的局限性,我对于哪种解决方案更方便感到震惊.这些是我的一些疑问:
- 数据加密算法.AES-128能够坚固且足够快吗？您会建议使用哪种替代方案？
- 加密模式.我已经读过ECB加密与CBC的弱点,但在这种情况下,第一个将具有随机访问块的优势,这对于文件的搜索功能很有意义.您会选择什么类型的加密模式？流加密适合这种情况吗？
- 密钥生成.可以为每个存储对象(文件,RMS RecordStore等)生成一个密钥,或者只为同一类型的所有对象使用一个密钥.第一个似乎"更安全",虽然它需要一些额外的设备空间.在您看来,每个人的权衡取舍是什么？
- 密钥存储.对于这种情况,使用标准JKS(或PKCS#12)KeyStore文件可能适合存储加密密钥,但我也可以定义一个较小的结构(加密转换/密钥数据/校验和),可以附加到每个存储库(即使用具有相同名称和特殊扩展名的附加文件用于普通文件或嵌入其他类型的对象(如RMS记录存储)中.你更喜欢什么方法？当使用具有多密钥生成的标准KeyStore时(假设这是您的偏好),使用每个存储对象的记录存储或仅保留所有密钥的全局KeyStore(即使用URL标识符)会更好吗？抽象存储对象作为别名)？
- 万能钥匙.使用主密钥似乎很明显.此密钥应受用户PIN(仅引入一次)的保护,并允许访问其余的加密密钥(它们将通过此主密钥加密).更改PIN只需要重新加密此密钥而不是所有加密数据.您会在哪里考虑到如果丢失了所有数据将无法进一步访问？我应该考虑哪些进一步的考虑因素？
- 平台加密支持 …