Привет У меня есть несколько вопросов (прочитайте часть Сомнений) относительно реализации зашифрованного хранилища (разновидности зашифрованной файловой системы) на Android, Blackberry и J2ME.Мне нужен ваш совет, вы, мастера криптографии .
Я знаю, что этот вопрос немного длинен, возможно, слишком многословен, но, пожалуйста, попробуйте прочитать его до конца (у меня так много связанных вопросовчто я не смог разделить их на несколько постов).Я был бы очень признателен, если бы вы могли дать мне хотя бы один ответ на один из моих вопросов ( Сомнения часть ).
Спасибо,
Цель
В настоящее время я разрабатываю API для многоплатформенной системы хранения, которая будет предлагать такой же интерфейс и возможности для следующих поддерживаемых мобильных платформ Java:
- * J2ME 1022 *.Минимальная конфигурация / профиль CLDC 1.1 / MIDP 2.0 с поддержкой некоторых необходимых JSR (JSR-75 для хранения файлов).
- Android .Минимальная версия платформы еще не определена, но скорее всего это может быть API уровня 7.
- Blackberry .Он будет использовать тот же базовый источник J2ME, но с использованием некоторых расширенных возможностей платформы.Минимальная конфигурация еще не определена (возможно, 4,6 из-за ограничения 64 КБ для RMS на 4.5).
В основном API будет содержать три вида магазинов:
- файлы .Они позволят стандартное управление каталогом / файлом (чтение / запись через потоки, создание, mkdir и т. Д.).
- Предпочтения .Это специальное хранилище, которое обрабатывает свойства, доступ к которым осуществляется через ключи (аналогично обычному старому файлу свойств Java, но поддерживает некоторые улучшения, такие как различные типы данных значений, такие как SharedPreferences на платформе Android)
- Local Message Queues .Это хранилище будет предлагать базовую функциональность очереди сообщений.
Соображения
Вдохновленные на JSR-75, все типы хранилищ будут доступны единообразно с помощью URLследующие RFC 1738 соглашения, но с пользовательскими префиксами (например, «file: //» для файлов, «prefs: //» для предпочтений или «queue: //» для очередей сообщений).Адрес будет относиться к виртуальному местоположению, которое будет отображаться в физическом объекте хранения каждой реализацией мобильной платформы.Только файлы разрешают иерархическое хранение (папки) и доступ к внешним картам памяти extorage (посредством имени устройства, так же, как в JSR-75, но это не изменится независимо от базовой платформы).Другие типы будут поддерживать только плоское хранилище.
Система также должна поддерживать защищенную версию всех основных типов .Пользователь может указать это путем добавления префикса «s» к URL-адресу (то есть «sfile: //» вместо «file: //»).API потребует только один PIN (введенный только один раз) для доступа к любому типу защищенных объектов.
Проблемы реализации
Для реализации обоих открытых текстови зашифрованные хранилища, я бы использовал функциональность, доступную на базовых платформах:
- Файлы .Они доступны на всех платформах (J2ME только с JSR-75, но это обязательно для наших нужд).Отображение абстрактного файла в фактический файл является прямым, за исключением решения проблем.
- RMS .Этот тип хранилища, доступный на платформах J2ME (и Blackberry), удобен для предпочтений и, возможно, очередей сообщений (хотя в зависимости от требований к производительности или размеру они могут быть реализованы с помощью обычных файлов).
- SharedPreferences .Этот тип хранилища, доступный только на Android, будет соответствовать потребностям предпочтений.
- Базы данных SQLite .Это может быть использовано для очередей сообщений на Android (и, возможно, Blackberry).
Когда дело доходит до шифрования, должны выполняться некоторые требования:
- Чтобы упростить реализацию, она будет выполняться на основе операций чтения / записи для потоков (для файлов), RMS-записей, пар ключ-значение SharedPreferences, столбцов базы данных SQLite. Каждый базовый объект хранения должен использовать один и тот же ключ шифрования.
- Обработка зашифрованных хранилищ должна быть такой же, как и у незашифрованного аналога. Единственная разница (с точки зрения пользователя) в доступе к зашифрованному хранилищу - это адресация.
- ПИН-код пользователя обеспечивает доступ к любому защищенному объекту хранения, но для его изменения не потребуется расшифровывать / повторно шифровать все зашифрованные данные.
- Криптографические возможности базовой платформы должны использоваться, когда это возможно, поэтому мы будем использовать:
- J2ME: SATSA-CRYPTO, если он доступен (не обязательно), или облегченная криптографическая структура BoncyCastle для J2ME.
- Blackberry: RIM Cryptographic API или BouncyCastle
- Android: JCE с интегрированным провайдером криптографии (BouncyCastle?)
Мои сомнения. Требуется помощь здесь
Достигнув этой точки, я был поражен некоторыми сомнениями относительно того, какое решение было бы более удобным, принимая во внимание ограничение платформ. Вот некоторые из моих сомнений :
- Алгоритм шифрования данных . Будет ли AES-128 достаточно сильным и быстрым? Какие альтернативы для такого сценария вы бы предложили?
- Режим шифрования . Я читал о слабости шифрования ECB по сравнению с CBC, но в этом случае первое будет иметь преимущество произвольного доступа к блокам, что интересно для функциональности поиска по файлам. Какой тип режима шифрования вы бы выбрали вместо этого? Подходит ли потоковое шифрование для этого случая?
- Генерация ключей . Может быть один ключ, сгенерированный для каждого объекта хранилища (файл, RMS RecordStore и т. Д.), Или просто использовать его для всех объектов одного типа. Первый кажется «более безопасным», хотя для этого потребуется дополнительное место на устройстве. По вашему мнению, что компромиссы каждого?
- Хранение ключей . Для этого случая можно использовать стандартный файл ключей JKS (или PKCS # 12) для хранения ключей шифрования, но я также мог бы определить меньшую структуру (преобразование шифрования / данные ключа / контрольную сумму), которую можно прикрепить к каждому хранилищу хранилища ( т.е. использование файлов дополнений с тем же именем и специальным расширением для простых файлов или встроенных в другие типы объектов, такие как хранилища записей RMS). Какой подход вы бы предпочли? И когда дело доходит до использования стандартного хранилища ключей с генерацией нескольких ключей (учитывая, что это ваши предпочтения), было бы лучше использовать хранилище записей для каждого объекта хранения или просто глобальное хранилище ключей, сохраняющее все ключи (т.е. используя идентификатор URL-адреса абстрактный объект хранения как псевдоним)?
- Мастер-ключ . Использование мастер-ключа кажется очевидным. Этот ключ должен быть защищен ПИН-кодом пользователя (вводится только один раз) и позволит получить доступ к остальным ключам шифрования (они будут зашифрованы с помощью этого мастер-ключа). Изменение ПИН-кода потребует только повторного шифрования этого ключа, а не всех зашифрованных данных. Где бы вы хранили его, принимая во внимание, что в случае его утери все данные больше не будут доступны? Какие дальнейшие соображения я должен принять во внимание?
- Поддержка криптографии платформы . Используют ли телефоны J2ME с поддержкой SATSA-CRYPTO действительно какое-то выделенное аппаратное ускорение (или другое преимущество, которое я не предвидел), и будет ли этот подход предпочтительным (когда это возможно) по сравнению только с реализацией BouncyCastle? По той же причине стоит ли криптографический API RIM стоимость лицензии по сравнению с BouncyCastle?
Любые комментарии, критика, дальнейшие соображения или другие подходы приветствуются.