Зашифрованный, Сжимаемый, Кроссплатформенный, Файловая система в файле - PullRequest
2 голосов
/ 30 июня 2010

Мы хотим создать настольное приложение, которое ищет локально упакованную текстовую базу данных размером несколько ГБ.Мы думаем об использовании lucene.

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

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

Один из способов, как мы думали, это сделать, если индекс lucene можно было бы сохранить в зашифрованной файловой системе в файле (что-то вродеTrueCrypt).Поэтому настольное приложение «монтирует» файл, содержащий индексы lucene.

И это должно быть кроссплатформенным (Linux, Windows) ... Мы бы использовали Qt или Java для написания настольного приложения.

Есть ли более простой / лучший способ сделать это?

[Это для клиента.Да, да, концептуально это плохо :-) но так они этого хотят.По сути, дело в том, что только настольное приложение должно иметь доступ к индексу lucene, и никому другому.Кто-то указал, что это по сути DRM.Да, это похоже на DRM]

Ответы [ 6 ]

5 голосов
/ 30 июня 2010

Как мы шифруем базу данных Люсена так что только клиентское приложение может получить доступ к индексу Люсена и любопытству пользователь не может получить полный текстовый дамп индекс?

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

3 голосов
/ 30 июня 2010

Проблема здесь в том, что вы пытаетесь одновременно предоставить пользователю данные и отказать им в em.Это в основном проблема DRM под другим именем - злоумышленник (пользователь) полностью контролирует среду приложения (аппаратное обеспечение и ОС).В такой ситуации безопасность невозможна, только запутывание и иллюзия безопасности.

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

Обратите внимание, что создание недоуменной иллюзии безопасности может быть достаточным с юридической точки зрения (например, положения DMCA об обходе защиты от обхода)) - но это выходит за рамки SO.

2 голосов
/ 30 июня 2010

Технически, вы мало что можете сделать.Lucene написан на Java, и код Java всегда можно декомпилировать или запустить в отладчике, чтобы получить ключ, который вам нужно где-то хранить (вероятно, в лицензионном ключе, который вы продаете пользователю).

Единственный вариант -закон (или договор с пользователем).Текстовые данные защищены авторским правом, поэтому вы можете подать в суд на пользователя, если он его использует каким-либо образом, выходящим за рамки лицензионного соглашения.

Или вы можете написать собственную систему индексации текста.

Или купите коммерческий, который соответствует вашим потребностям.

[РЕДАКТИРОВАТЬ] Если вы хотите использовать зашифрованный индекс, просто создайте свой собственный FSDirectory.Проверьте источник для SimpleFSDirectory для примера.

1 голос
/ 01 августа 2011

Однонаправленная хеш-функция .

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

Готовы ли вы использовать ложные срабатывания, чтобы сэкономить место?Фильтр Блума.

1 голос
/ 01 июля 2010

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

Нет, это не совсем безопасно, но должно работать достаточно хорошо.

1 голос
/ 30 июня 2010

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

...