Шифрование файла базы данных SQLite в iPhone OS

Ответ 1

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

Поместите строку в базу данных, говоря "пожалуйста, не обманывайте".

Ответ 2

Здесь есть как минимум два простых подхода (оба бесплатных), которые позволяют избежать шифрования значений или баз данных в памяти:

# 1 - обнаружение трещины ipa

Избегайте технических (и юридических) хлопот шифрования базы данных и/или содержимого и просто определяйте, является ли приложение пиратским и отключает аспекты сети/оценки/ранжирования игры. Подробнее см. Ниже:

http://thwart-ipa-cracks.blogspot.com/2008/11/detection.html

# 2 - проверка целостности данных

Альтернативно хранить HMAC/соленый хеш важных столбцов в каждой строке при сохранении ваших данных (и в вашем начальном sqlite db). При загрузке каждой строки проверяйте данные по HMAC/хешу, и если проверка не срабатывает соответствующим образом.

Ни один из подходов не заставит вас заполнить формы экспорта шифрования, требуемые правительством Apple/США.

Подача баллов

Не забывайте, что вам нужно будет сделать что-то похожее для фактических заявок, чтобы защитить от ценностей, поступающих из чего-то другого, кроме вашего приложения. Вы можете увидеть реализацию этого в структурах cocos2d-iphone и cocoslive в http://code.google.com/p/cocos2d-iphone/ и http://code.google.com/p/cocoslive/

Ответ на комментарии

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

Существует множество книг по разработке многопользовательских игр, в которых обсуждаются эти проблемы.

Наличие хэша с известным секретом в коде, вероятно, является разумным подходом (по крайней мере, при рассмотрении типа приложений, которые обычно существуют в App Store).

Ответ 3

Как сказал Кендалл, включая ключ на устройстве, в основном просят взломать. Однако есть люди, у которых есть причины для обфускации данных с помощью ключа на устройстве. Если вы решите это сделать, вы можете использовать SQLCipher для своей реализации. Это сборка SQLite, обеспечивающая прозрачное шифрование на уровне страницы всей БД. Там учебник на Mobile Orchard для использования в приложениях для iPhone.

Ответ 4

Насколько вы думаете, насколько ваш обычный пользователь будет делать это? Я предполагаю, что вы проходите через магазин приложений, а это значит, что все подписывается/зашифровывается, прежде чем перейти к пользовательскому устройству. Им нужно будет сделать джейлбрейк своего устройства, чтобы получить доступ к вашей базе данных.

Какие данные вы храните для шифрования? Если он содержит пароли, введенные пользователем, тогда вам не нужно их шифровать; пользователю не нужно будет узнать свой пароль. Если это общие данные BLOB, которые вы только хотите, чтобы пользователь мог получить доступ через приложение, это могло быть так же просто, как хранить зашифрованный blob с помощью API безопасности.

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

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

Изменить

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

Ответ 5

SQLCipher:

Основываясь на моем опыте, SQLCipher - лучший вариант для шифрования базы данных.

Как только ключ ( "PRAGMA key" ) установлен, SQLCipher будет автоматически шифровать все данные в базе данных! Обратите внимание: если вы не установите ключ, SQLCipher будет работать идентично стандартной базе данных SQLite.

Вызов sqlite3_key или "PRAGMA key" должен выполняться как первая операция после открытия базы данных. В большинстве случаев SQLCipher использует PBKDF2, функцию соленой и итерированной функции вывода ключей, чтобы получить ключ шифрования. В качестве альтернативы приложение может указать SQLCipher использовать определенный двоичный ключ в нотации blob (обратите внимание, что SQLCipher требует ровно 256 бит ключевого материала), т.е.

Ссылка:

http://sqlcipher.net/ios-tutorial

Я надеюсь, что кто-то сэкономит время на изучение этого

Ответ 6

Игнорируя проблемы философии и экспорта, я бы предположил, что вам лучше будет шифровать данные в таблице напрямую.

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

Для алгоритма я бы использовал надежную реализацию AES для любого языка, который вы используете. Возможно, это для С#:

http://msdn.microsoft.com/en-us/magazine/cc164055.aspx

Наконец, вам нужно знать ограничения этого подхода. А именно, ключ дешифрования является слабым звеном, он будет доступен в памяти во время выполнения в ясном тексте. (Как минимум) Это должно быть так, чтобы вы могли его использовать. Реализация вашей схемы шифрования - еще одна слабость - любые недостатки есть и недостатки в вашем коде. Как еще несколько человек указали, что ваши сообщения клиент-сервер также подозреваются.

Вы должны помнить, что ваш исполняемый файл может быть рассмотрен в шестнадцатеричном редакторе, в котором строки с открытым текстом выпрыгнут из случайного мусора, который является вашим скомпилированным кодом. И что многие языки (например, С#, например) могут быть скомпилированы с обратной записью, и все, что будет отсутствовать, это комментарии.

Все, что сказал, зашифровав ваши данные, поднимет планку для обмана. Сколько зависит от того, насколько вы внимательны? но даже так решительный противник все равно сломает ваше шифрование и обман. Кроме того, они, вероятно, напишут инструмент, который упростит вашу популярность; в этот момент вам будет предложен сценарий гонки вооружений.

Что касается значения контрольной суммы, вы можете вычислить контрольную сумму на основе суммы значений в строке, предполагая, что для этой цели вам достаточно числовых значений в вашей базе данных. Или, для кучи логических значений, вы можете сохранить их в поле varbinary и использовать побитовый эксклюзивный оператор ^ для их сравнения - вы должны получить 0s.

Например,

для числовых столбцов,

2 | 3 | 5 | 7 | с колонкой контрольной суммы | 17 |

для булевых,

0 | 1 | 0 | 1 | с колонкой контрольной суммы | 0101 |

Если вы сделаете это, вы можете даже добавить итоговую строку в конце, которая суммирует ваши контрольные суммы. Хотя это может быть проблематично, если вы постоянно добавляете новые записи. Вы также можете преобразовать строки в свои компоненты ANSI/UNICODE и суммировать их тоже.

Затем, когда вы хотите проверить контрольную сумму, просто сделайте выбор следующим образом:

Select * 
FROM OrigTable 
right outer join 
(select pk, (col1 + col2 + col3) as OnTheFlyChecksum, PreComputedChecksum from OrigTable) OT on OrigTable.pk = OT.pk
where OT.OnTheFlyChecksum = OT.PreComputedChecksum

Ответ 7

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

Если пользователь A фальсифицирует результат, если его игра с пользователем B, этот результат будет распространяться до тех пор, пока B не увидит его с предупреждением о том, что данные не совпадают с его телефоном. Затем он может пойти и избить объяснить A, что его поведение неверно, так оно и есть в реальной жизни, если кто-то обманывает.

Когда вы вычисляете итоговые результаты турнира, показываете предупреждение, имена и выкидываете все игры с противоречивыми результатами. Это отнимает стимул для обмана.

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

Ответ 8

Тем не менее, если на платформе Windows вы также можете выбрать SQLiteEncrypt, чтобы удовлетворить ваши потребности. SQLiteEncrypt расширяет поддержку шифрования sqlite, но вы можете лечить это как оригинальная библиотека sqlite3 c.