Защита объектов Coredata

Question

Я работаю над приложением, в котором есть некоторая конфиденциальная информация. Я знаю, что непрофессионалу будет трудно взломать iphone, чтобы получить информацию. Если я использую SQLite напрямую, у меня есть что-то под названием SQLite Cipher для шифрования / кодирования базы данных.

В любом случае, где я могу использовать такой же способ шифрования coredata, чтобы хакерам было трудно получить доступ к данным.

Может кто-нибудь пролить свет на это?

Заранее спасибо

Answer 1

Базовые данные теперь шифруются по умолчанию (аппаратное шифрование) на iPhone 3GS и более поздних устройствах, включая iPad. Это означает, что данные автоматически шифруются с помощью аппаратного ключа. В iOS 4 или более поздней версии, с помощью , следуя указаниям в более подробной записи в блоге Ника Харриса , можно включить второй уровень шифрования (называемый «защита данных»), который также использует пароль пользователя для шифрования оборудования. ключ.

Все это зависит от пользователей, устанавливающих безопасный пароль и включающих защиту данных в iOS 4 . Если вы являетесь зарегистрированным разработчиком Apple, вы также можете посмотреть видео WWDC 2010 "Защита данных приложений" в iTunes по этой ссылке и , посмотреть PDF слайдов здесь после введите идентификатор разработчика и пароль, чтобы получить более подробную информацию о шифровании файлов.

Чтобы включить защиту данных, при вызове - (NSPersistentStoreCoordinator *)persistentStoreCoordinator просто измените атрибуты файла .sqlite, используя ключ и значение ниже. См. Блог Ника Харриса для более детального кода, включая как проверить, активна ли iOS 4 или выше.

NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:@"MyAppName.sqlite"];
NSString *storePath = [storeURL path];
NSDictionary *fileAttributes = [NSDictionary dictionaryWithObject:NSFileProtectionComplete forKey:NSFileProtectionKey];
[[NSFileManager defaultManager] setAttributes:fileAttributes ofItemAtPath:storePath error:&error]

Answer 2

В Руководстве по программированию базовых данных четко сказано, что тип хранилища SQL немного более безопасен, чем XML или двоичный файл, но не является безопасным по своей природе - он рекомендует зашифрованный образ диска. К сожалению, это немного сложно управлять на iPhone.

Если вы действительно заинтересованы в этом, вы можете подумать о создании собственного постоянного типа хранилища - в Руководстве есть раздел , посвященный созданию собственного атомарного хранилища, и отсылает вас к Темы программирования для атомарного магазина документ. Создайте хранилище, которое берет ключ из приглашения пользователя при запуске, а затем инициализирует этот ключ для целей шифрования и дешифрования. (Обратите внимание, что если вы выберете этот маршрут, ссылка на класс NSPersistentStore говорит о том, что подкласс NSPersistentStore напрямую не поддерживается в Базовых данных - вместо этого вы должны создать подкласс NSAtomicStore.)

Answer 3

Вы можете добавить категорию для сущности, которая переопределяет чтение и запись значений в постоянное хранилище. Затем вы можете подключиться к подпрограммам CommonCrypto для шифрования закрытых и открытых ключей и дешифрования этих значений, когда они сохраняются и извлекаются вашим приложением.

Answer 4

Если кто-то использует сломанный в тюрьме iphone, вы абсолютно ничего не можете сделать. Функции, которые вы используете для шифрования и дешифрования, могут быть подключены для получения используемого ключа / iv. Вы также можете делать неприятные вещи, такие как делать полный дамп флэш-памяти, буфер клавиатуры и другую «отладочную» информацию.

Чтобы усложнить задачу, вы можете ограничить время хранения секрета на устройстве. Храните секреты в удаленной системе и передавайте их через ssl, удаляйте их, когда они вам не нужны. Это защищает от кражи iphone, взлома, а также сброса базы данных. Я не уверен, что это атака, которая угрожает вашему конкретному приложению.

С точки зрения "мирянина" (людей, которые не умеют читать? :) Тогда вам не о чем беспокоиться. Apple имеет защиту, чтобы предотвратить чтение / запись установленных приложений на ресурсы друг друга.