Зашифруйте и сожмите html-коды в комплекте приложений iPhone, распакуйте при первом запуске - PullRequest
2 голосов
/ 05 марта 2009

Мой клиент хочет зашифровать / сжать html-код для своих медицинских книг в комплекте iPhone, чтобы защитить свой IP.

Что является хорошим способом подготовить этот файл для пакета приложения, и какие дополнительные библиотеки (C, Obj-C) я должен использовать для расшифровки и распаковки при первом запуске приложения?

Копирование файла в ~ / Documents, а затем работа над ним кажется лучшим решением. Мысли? * * 1005

Ответы [ 6 ]

2 голосов
/ 05 марта 2009

Вот несколько мыслей.

Если текст книги представляет собой буквенно-цифровые данные, не сохраняйте данные как ASCII - сохраняйте их в своем собственном двоичном кодированном формате (например, используйте 5 бит вместо 8 и упаковывайте их в слова). Это дает вам небольшую компрессию, небольшое запутывание и очень дешевую (в тактах) декомпрессию. У вас был бы формат данных, к которому можно быстро получить доступ на лету, и вы не допустите случайного любопытного хакера в текст. Циклы часов были бы моей главной заботой и вторым по безопасности.

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

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

Приветствия

2 голосов
/ 05 марта 2009

Это довольно сложно ... почти невозможно сделать его действительно нерушимым. Любой разумно мотивированный человек сможет пробить его. Вы только сделаете это немного сложнее. В любом случае, вы не можете хранить какой-либо секретный ключ в самом комплекте. Вам нужно было бы безопасно получить ключ дешифрования по защищенному каналу от сервера и использовать его по мере необходимости. Даже тогда кто-то, кто делает джейлбрейк, вероятно, сможет запустить GDB поверх вашей работающей программы и извлечь секретный ключ в ОЗУ + секретный ключ будет доступен всем пользователям вашего приложения ... По сути, вы пытаетесь реализовать схему DRM , который изначально имеет недостатки в дизайне ... Если вам не нужен автономный доступ, вы можете извлекать данные по мере необходимости из защищенной ошибки ... по крайней мере, вы "могли бы" предотвратить утечку информации ...

1 голос
/ 07 ноября 2009

Для сжатия я могу порекомендовать QuickLZ (самый быстрый двигатель, который я видел, отличная степень сжатия).

1 голос
/ 12 марта 2009

Из Службы безопасности Mac OS X и iPhone OS :

Вы можете использовать Keychain Services для шифровать и хранить небольшое количество данные (см. Справочник по связке ключей и Программирование сервисов ключей Руководство ). Если вы хотите зашифровать или расшифровывать большие объемы данных в Mac OS X, вы можете использовать общую безопасность Диспетчер служб (CSSM) Криптография Менеджер сервисов. Этот менеджер также имеет функции для создания и проверки цифровые подписи, генерировать криптографические ключи и создать криптографические хеши. В iPhone OS, Сертификат, Ключ и Доверие Сервис API предоставляет функции для генерация ключей шифрования, создание и проверка цифровых подписей, и шифрование блоков данных; увидеть Сертификат, Ключ и Услуги Доверия Ссылка .

Это всегда выбор между производительностью (шифрование просто не предоставляется бесплатно) и безопасностью (безопасность и все остальное, на самом деле). Но что еще нового? Если вы сохраняете отдельные файлы достаточно маленькими, возможно, расшифровка не сильно вас затормозит. В качестве альтернативы, вы можете рассмотреть возможность прогнозирующего дешифрования, когда у вас есть определенные файлы, которые расшифровываются в фоновом режиме, скажем, те, которые связаны с просматриваемым в данный момент файлом, и т. Д. Однако я понимаю, что параллелизм на iPhone может быть довольно нестабильным (я не знаю поскольку я не уронил наличные деньги за лицензию). Вы также можете добиться увеличения производительности, только зашифровав те файлы, которые действительно в этом нуждаются; действительно ли нужно шифровать индекс / оглавление или другой часто используемый файл? Это считается как IP, о котором беспокоится ваш клиент?

1 голос
/ 05 марта 2009

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

1 голос
/ 05 марта 2009

Я бы держал документы в зашифрованном виде на вашем месте и просто расшифровывал их по мере необходимости. Можно легко получить доступ к расшифрованным документам на взломанном устройстве.

См. Документ "Обзор безопасности" и пример кода CryptoExercise для методов шифрования

...