История изменений
Исправление
Moisha_Liberman,
(текущая версия)
:
Во всей этой задаче меня настораживает несколько вещей.
Первая и самая важная. «Первый звоночек». Судя по всему, у Вас там 4Gb данных (Генерация и запуск кода на лету (комментарий)). Примерно. Плюс-минус. Но у Вас критически важны не столько алгоритмы их обработки, сколько сами данные, которые хотелось бы скрыть от пользователя.
Второй и более… «нестандартный звоночек» здесь то, что потребитель якобы не в состоянии организовать высокоскоростной доступ (Генерация и запуск кода на лету (комментарий)):
Связь в лучшем случае раз в пол часа по модему через EDGE
Так делают либо в случае, если пользователь работает с действительно мобильным устройством (ищет что-либо на телефоне), либо просто пытается скрыть свою принадлежность к какой-либо организации. Ну не верю я что NTT DoCoMo (или кто там провайдер) не может дать высокоскоростной канал связи. Правда, если провайдер подаст этот канал, то сразу IP, всё выпаливается… Очевидно этого и пытаются избежать?
Можно ли всё таки предложить реализацию в виде запросов к некой СУБД, которая находится под Вашим полным контролем и в которой осуществляется вся обработка данных, генерируя только ответ для удалённого пользователя?
Если пользователь боится выпалить свою контору, то тогда можно воспользоваться сетью Тор, развернув в ней свой «сервер СУБД» как hidden service и обеспечив доступ с клиента, который тоже использует сеть Тор как транспортную сеть. Ну будет по временам скорость «плавать» (каналы-то разные), но да и Бог бы с ним. Работа будет строиться по принципу «запрос-отклик».
Меня больше всего напрягает передача данных в руки заказчика, которые мы ни как не контролируем. Ну да, есть в той же Berkeley DB (ныне Oracle Embedded) возможность создавать и использовать encrypted databases, но даже там абсолютно правильно сказано что:
The encryption support provided with Berkeley DB will not protect applications from attackers able to read system memory on the system where Berkeley DB is running.
Если по большому счёту, то вся эта Ваша encryption будет стоять пока я не пойму алгоритм шифрации и не найду (не подберу) ключ, которым шифровали. Дальше уже всё очевидно.
Думаю, передачу данных как наиболее критичного компонента системы всё таки стоит избежать, сведя задачу к простому удалённому доступу со стороны заказчика в виде «запрос-ответ».
Сам по себе софт не стоек, да и железо тоже. Если не городить отдельный криптопроцессор. Даже если его сгородить, то ни что не мешает пользователю сгенерировать локально массу запросов к БД и выдернуть оттуда все данные, т.е., «выпотрошить БД» под чистую. Гнерации софта on the fly тоже особо доверия нет, т.к. узким местом всё равно останется база, которая уже у пользователя.
Вещи типа «противодействие отладке» тоже не работают, да и смысла нет, если я могу просто запросами вытянуть все данные из базы, даже не лазя особо в отладку (ну ключ и алгоритм понять надо будет, конечно, но это разовое действие).
Какие-то вот такие вот соображения, возможно я и не прав, конечно.
P.S. Да, вот именно про это я и говорю:
беда в том что данные после расшифровки в памяти и пользователь этим может воспользоваться. Потеря приватности данных = финансовые потери. Не расшифровывать их нельзя - т.к. нужно по ним производить поиск (процесс работы с данными).
P.P.S. Если напрягает даже использование tor, то можно в принципе организовать передачу запросов-откликов хоть через бота в телеграмме. То, что я им не пользуюсь сам, не означает того, что я не использую ботов для каких-либо целей. Точно так же можно хоть через IRC/Jabber, да хоть чат в World of Warcraft, это не принципиально, просто как правило, люди не думают о том, что можно и такие «чаты» использовать и мало кто заметит информационный обмен вообще. =)))
Исправление
Moisha_Liberman,
:
Во всей этой задаче меня настораживает несколько вещей.
Первая и самая важная. «Первый звоночек». Судя по всему, у Вас там 4Gb данных (Генерация и запуск кода на лету (комментарий)). Примерно. Плюс-минус. Но у Вас критически важны не столько алгоритмы их обработки, сколько сами данные, которые хотелось бы скрыть от пользователя.
Второй и более… «нестандартный звоночек» здесь то, что потребитель якобы не в состоянии организовать высокоскоростной доступ (Генерация и запуск кода на лету (комментарий)):
Связь в лучшем случае раз в пол часа по модему через EDGE
Так делают либо в случае, если пользователь работает с действительно мобильным устройством (ищет что-либо на телефоне), либо просто пытается скрыть свою принадлежность к какой-либо организации. Ну не верю я что NTT DoCoMo (или кто там провайдер) не может дать высокоскоростной канал связи. Правда, если провайдер подаст этот канал, то сразу IP, всё выпаливается… Очевидно этого и пытаются избежать?
Можно ли всё таки предложить реализацию в виде запросов к некой СУБД, которая находится под Вашим полным контролем и в которой осуществляется вся обработка данных, генерируя только ответ для удалённого пользователя?
Если пользователь боится выпалить свою контору, то тогда можно воспользоваться сетью Тор, развернув в ней свой «сервер СУБД» как hidden service и обеспечив доступ с клиента, который тоже использует сеть Тор как транспортную сеть. Ну будет по временам скорость «плавать» (каналы-то разные), но да и Бог бы с ним. Работа будет строиться по принципу «запрос-отклик».
Меня больше всего напрягает передача данных в руки заказчика, которые мы ни как не контролируем. Ну да, есть в той же Berkeley DB (ныне Oracle Embedded) возможность создавать и использовать encrypted databases, но даже там абсолютно правильно сказано что:
The encryption support provided with Berkeley DB will not protect applications from attackers able to read system memory on the system where Berkeley DB is running.
Если по большому счёту, то вся эта Ваша encryption будет стоять пока я не пойму алгоритм шифрации и не найду (не подберу) ключ, которым шифровали. Дальше уже всё очевидно.
Думаю, передачу данных как наиболее критичного компонента системы всё таки стоит избежать, сведя задачу к простому удалённому доступу со стороны заказчика в виде «запрос-ответ».
Сам по себе софт не стоек, да и железо тоже. Если не городить отдельный криптопроцессор. Даже если его сгородить, то ни что не мешает пользователю сгенерировать локально массу запросов к БД и выдернуть оттуда все данные, т.е., «выпотрошить БД» под чистую. Гнерации софта on the fly тоже особо доверия нет, т.к. узким местом всё равно останется база, которая уже у пользователя.
Вещи типа «противодействие отладке» тоже не работают, да и смысла нет, если я могу просто запросами вытянуть все данные из базы, даже не лазя особо в отладку (ну ключ и алгоритм понять надо будет, конечно, но это разовое действие).
Какие-то вот такие вот соображения, возможно я и не прав, конечно.
P.S. Да, вот именно про это я и говорю:
беда в том что данные после расшифровки в памяти и пользователь этим может воспользоваться. Потеря приватности данных = финансовые потери. Не расшифровывать их нельзя - т.к. нужно по ним производить поиск (процесс работы с данными).
Исходная версия
Moisha_Liberman,
:
Понимаете...
Во всей этой задаче меня настораживает несколько вещей.
Первая и самая важная. «Первый звоночек». Судя по всему, у Вас там 4Gb данных (Генерация и запуск кода на лету (комментарий)). Примерно. Плюс-минус. Но у Вас критически важны не столько алгоритмы их обработки, сколько сами данные, которые хотелось бы скрыть от пользователя.
Второй и более… «нестандартный звоночек» здесь то, что потребитель якобы не в состоянии организовать высокоскоростной доступ (Генерация и запуск кода на лету (комментарий)):
Связь в лучшем случае раз в пол часа по модему через EDGE
Так делают либо в случае, если пользователь работает с действительно мобильным устройством (ищет что-либо на телефоне), либо просто пытается скрыть свою принадлежность к какой-либо организации. Ну не верю я что NTT DoCoMo (или кто там провайдер) не может дать высокоскоростной канал связи. Правда, если провайдер подаст этот канал, то сразу IP, всё выпаливается… Очевидно этого и пытаются избежать?
Можно ли всё таки предложить реализацию в виде запросов к некой СУБД, которая находится под Вашим полным контролем и в которой осуществляется вся обработка данных, генерируя только ответ для удалённого пользователя?
Если пользователь боится выпалить свою контору, то тогда можно воспользоваться сетью Тор, развернув в ней свой «сервер СУБД» как hidden service и обеспечив доступ с клиента, который тоже использует сеть Тор как транспортную сеть. Ну будет по временам скорость «плавать» (каналы-то разные), но да и Бог бы с ним. Работа будет строиться по принципу «запрос-отклик».
Меня больше всего напрягает передача данных в руки заказчика, которые мы ни как не контролируем. Ну да, есть в той же Berkeley DB (ныне Oracle Embedded) возможность создавать и использовать encrypted databases, но даже там абсолютно правильно сказано что:
The encryption support provided with Berkeley DB will not protect applications from attackers able to read system memory on the system where Berkeley DB is running.
Если по большому счёту, то вся эта Ваша encryption будет стоять пока я не пойму алгоритм шифрации и не найду (не подберу) ключ, которым шифровали. Дальше уже всё очевидно.
Думаю, передачу данных как наиболее критичного компонента системы всё таки стоит избежать, сведя задачу к простому удалённому доступу со стороны заказчика в виде «запрос-ответ».
Сам по себе софт не стоек, да и железо тоже. Если не городить отдельный криптопроцессор. Даже если его сгородить, то ни что не мешает пользователю сгенерировать локально массу запросов к БД и выдернуть оттуда все данные, т.е., «выпотрошить БД» под чистую. Гнерации софта on the fly тоже особо доверия нет, т.к. узким местом всё равно останется база, которая уже у пользователя.
Вещи типа «противодействие отладке» тоже не работают, да и смысла нет, если я могу просто запросами вытянуть все данные из базы, даже не лазя особо в отладку (ну ключ и алгоритм понять надо будет, конечно, но это разовое действие).
Какие-то вот такие вот соображения, возможно я и не прав, конечно.