К сожалению пользователь системы может сделать chroot с флешки. Порты не закрыть.

Ok.

Передавай Сергею привет из солнечного Берлина.

Ладушки. =) Сделаю. =)

А вот Садовникову (aka Flex_Ferrum), к сожалению, уже не смогу. Сильный был «плюсовик». Слышали? =(

Я во ч0 подумал. Ты хочешь на машинах других людей выполнять код и максимально его скрыть о них. Ты очень подходящий форум выбрал))

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

Звучит интересно. Но задача подразумевает статично собранный бинарник (ELF) с некой магией внутри.

рантайм SBCL и есть канонический пример такой статически собранной магии. Другой вопрос насколько наличие лиспа будет мешать. Есть для развлечения компиляторы С и python-а которые реализованы поверх common lisp. то есть подтянуть сторонние исходники на этот рантайм не проблема.

Оуууу... Eah! =)

Как я погляжу, дошли до Lisp & Oberon… Ждём erlang для полного набора. И будет как обычно… =)))

И всё-таки вопрос. Вы хотите генерировать бинарник из С на лету (по запросу «пользователя») и отдавать его «пользователям» или бинарник можно скомпилить на машине «пользователя» опять же по его запросу и запустить после компиляции у него на машине, так?

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

Ну и исходник должен быть по максимуму обфусцирован ещё до кучи. Так?

1. на компьютер пользователя устанавливается некий софт согласно договору. Пользователь - юрлицо/ип
2. на компьютер пользователя заливаются некие шифрованные данные
3. ключ спрятан в бинарнике. алгоритм расшифровки молодец
4. беда в том что данные после расшифровки в памяти и пользователь этим может воспользоваться. Потеря приватности данных = финансовые потери. Не расшифровывать их нельзя - т.к. нужно по ним производить поиск (процесс работы с данными).
5. в процессе нормальной работы пользователь работает с этими данными

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

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

Понимаете...

Во всей этой задаче меня настораживает несколько вещей.

Первая и самая важная. «Первый звоночек». Судя по всему, у Вас там 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, это не принципиально, просто как правило, люди не думают о том, что можно и такие «чаты» использовать и мало кто заметит информационный обмен вообще. =)))

на компьютер пользователя устанавливается некий софт

А поставить рядом с компом пользователя сервер? Защищенный от влезания и тем более загрузки с флэшки. Ну по аналогии с аппаратными криптографическими токенами.

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

К сожалению очень дорого. 4000 серверов… хотя мысль правильная. Полностью закрытая On chip система - возможно самый дешёвый и быстрый путь.

К сожалению очень дорого. 4000 серверов

В микрокомп на ARM алгоритм/данные влезут? С аналогом Intel ME, чтобы ничего левого на нем не запустили.

Попробуй поглядеть в сторону гомоморфного шифрования, тогда есть шанс что для поиска не потребуется расшифровывать данные.

вполне.

4000 серверов… К сожалению очень дорого

В РФ около 1000 городов. К каждому из серверов прилагается минимум один сотрудник (ну от кого-то же защищаемся). Контора, обладающая такой большой сетью филиалов не может позволить капитальные затраты в районе десятков тысяч за точку? Странная какая-то история.

Не совсем.

Бизнес абсолютно легальный, никто не сидит через тор.

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

Поиск и подбор ключа к базе будет стоить +- как сама база.

Реверс алгоритма шифрации. Если используется AES-NI, которые есть в практически любом уважающем себя процессоре, то задача сводится только к поиску ключа. А это чуть быстрее-чуть дольше, не важно уже.

Вопрос именно в том чтобы защитить данные в памяти.

Нет. Это не так, к сожалению. Задача RAM encryption это… довольно сложно, гиморно, долго и ненадёжно.

AMD вот с этим уже просто задолбались, Intel тоже с аналогами, но со своими.

И то не особо дело ладится. На ARM (поставить 4000 «серверов» на базе Raspberry Pi 2/3/4?) в принципе можно эту задачу при помощи TEE порешать, но…

Но проблема в том, что кроме памяти в виде RAM есть ещё такая память как кеш и регистры процессора. Это, кстати да, тоже память, при чём самая быстрая. И для каких-либо преобразований данных мне придётся их дешифровать и какое-то время держать в кеше и регистрах процессора. Оттуда я их точно так же могу сдёрнуть.

в GNU/Linux необходимо написать программу на C/C++, которая может на лету генерировать исполняемый код и его запускать.

Генерировать из чего?

Например, можно генерировать байткод LLVM, его транслировать в машинный код x86-64 и записать в mmap()-нутый кусок, потом через mprotect() сделать этот сегмент памяти исполняемым и недоступным для записи, и потом вызывать оттуда что-то.

Тогда уж FPGA...

Полностью закрытая On chip система - возможно самый дешёвый и быстрый путь.

MEAS. Вот рабы Божии делали на Zynq XC7Z020. Тогда данные укладываются в электронную схему (нужен-не нужен апдейт данных?), осуществляется запрос на вход схемы, там производится обсчёт и возвращается результат.

Тогда объединяем данные + алгоритмы в единой железке. Ну и защищаем её по максимуму. Это уже не просто «криптопроцессор», это уже несколько иная тема.

И самой простой задачей здесь будет написание модуля ядра для поддержки работы этого девайса. Генератор запросов-анализатор откликов это уже семечки.

Ну и защищаем её по максимуму

Залить эпоксидкой))

Как ещё можно?

Ну не улыбается мне идея отдавать всю базу клиенту. Не у-лы-ба-ет-ся. Вовсе. =))) Это вообще до первого встречного, кто умеет пользоваться отладчиком. Извините.

У клиентов реально по маленьким городам плохие каналы связи.

Хммм… Но e-mail у них есть? Тогда надо просто минимизировать объём передаваемых данных. В обе стороны.

Можно попробовать создать стык СУБД-e-mail сервер и на сервер слать запросы по e-mail. Ответы, содержащие конкретные данные, так же получать назад по e-mail. В пределах одного «сеанса» может быть несколько запросов и ответов на них, соответственно будет по числу запросов. А уж как там прилетят запросы-будут получены на них ответы, дело десятое, если on line не канает. Да хоть с вечерней кобылой. Хоть, согласно [RFC 1149] (https://datatracker.ietf.org/doc/html/rfc1149) – A Standard for the Transmission of IP Datagrams on Avian Carriers (голубиной почтой).

Сгорит на хрен.

Залить эпоксидкой))

Как вариант да, но у FPGA потребление энергии сравнительно высокое, следовательно и нагрев (рассеяние мощности через тепловую энергию). Тут тоже не всё так просто. Но как версия, да. =)))

стык СУБД-e-mail

Что-то мне подсказывает, что система на запрос должна отвечать быстрее. В условиях было указано автономность три дня.

Да отвечать можно хоть сразу...

Как только получили запрос, сразу ответили. Вопрос когда прокашляется клиент и когда он получит данные.

А запросы на e-mail слать, я даже не вставая со стула могу либу показать (ибо сам пользуюсь иногда и для аналогичных случаев) – прямо в своём коде, нагло и решительно используем libesmtp. Для pop3/imap4 либы, я думаю, найти не сложно? Чтобы организовать получение откликов.

Ответ базы можно даже упаковать, если надо. Получили-распаковали-показали юзеру. E-mail это допускает.

Ну можно и свой аналог сгородить, конечно, для сеансового обмена, но… зачем?

но у FPGA потребление энергии сравнительно высокое, следовательно и нагрев (рассеяние мощности через тепловую энергию). Тут тоже не всё так просто

У эпоксидки теплопроводность не маленькая (как). Можно обойтись теплораспределителем между микросхемкой и наполнителем. Можно применить компаунд с высокой теплопроводностью.

Да отвечать можно хоть сразу…

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

Можно.

Денег только это стоит… Да и программировать FPGA ещё то «развлечение». В принципе-то дело знакомое, но схему паять… Да ещё и 4000, т.е. «серийное производство», ну не особо это весело и прикольно. Да ещё где заказывать (опять же вопрос бюджета). У дядюшки Ляо можно, конечно и не дорого, но тут уже вопрос на что нарвёшься, а то не опять как в «прошлый раз» – фен в лапки и rock’nd’roll. И заказчика потом пришлось на бабло ставить, т.к. он ногами сучил чтобы именно у конкретного дядюшки Ляо заказали.

А он и будет работать.

С теми данными, которые у него уже есть.

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

Мы же раньше-то ему данные уже отдали. То, что отдали, то уже… Как говорится, «что с возу упало, того топором уже не вырубишь…».

Нужны новые данные – цепляется к сети и получает ответы на ранее заданные вопросы. И опять на трое суток пусть выпадает.

Но ведь это JIT, которое тебе не подходит, лол.

Плюс, сюда же.

Мы должны отдавать только те данные, которые клиент запросил, фильтруя запросы на их избыточность. Т.е., например, у нас есть таблица «Города и веси Японии». Запрос всех данных из талицы должен быть отброшен как невалидный, а вот запросы типа «каково население Йоко-сука» или «какова площадь Сима-сука» это вполне валидные запросы. Конкретные. Просто возвращаем результат, сохраняя общую массу данных в тайне от пользователя.

У клиента в локальной базе порядка 15 миллионов уникальных записей За день в произвольный момент времени требуется порядка 100 000 уникальных записей. Досылать данные - у нас есть канал для этого. Качать данные с сервера (даже часть) в момент когда они нужны - нет такой возможности. Канал по опыту поднимается на 15 минут, потом падает. т.е. серверная реализация работать не будет на 100 % в силу плохой связи.

Вариант с одноплатником, подключаемым по USB и выносом туда вычислений - норм (так работает фискальный модуль от налоговой). Вариант с виртуалкой - почти норм.

Можно как-то так: в БД ключи хранятся зашифрованные односторонним алгоритмом типа RSA.

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

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

Идеально - иметь некую виртуалку внутри бинарника, которая исходя из своих наборов инструкций - будет выдавать данные (уже расшифрованные). Но внутри будет хранить тайну всего массива данных.

Что помешает также взломать виртуалку? Это же всего лишь область памяти.

Мммдддааа...

Качать данные с сервера (даже часть) в момент когда они нужны - нет такой возможности. Канал по опыту поднимается на 15 минут, потом падает. т.е. серверная реализация работать не будет на 100 % в силу плохой связи.

Если где и есть «жопа мира», то это прямо самый эпицентр, можно сказать ея дырдочка… =)))

Ладно. Судя по всему, тогда одноплатник это Ваш вариант. Вам придётся всячески сокращать поверхность атаки. Тогда только делать заказную платку, на которой сразу распаивать микро-SD под загрузку системы и саму по себе систему, а так же оставлять всего два USB. Делать два демона – один для расчётов, другой для того, чтобы можно было заапдейтить базу с флеш. Т.е., демон увидит что в USB есть флешка с файлом update_db.tar.xz, скачает его, распакует и проапдейтит базу, на всё остальное он реагировать не должен.

Саму базу держать только на распаяном внутри схемы флеш-накопителе (тоже USB, но внутренний). Из скриптов загрузки (init) долой всё, кроме этих двух демонов. «Расчётного», который отрабатывает запросы пользователя и «апдейтного», который отвечает за апдейты.

В такой системе не должно быть ни ssh, ни чего, что обеспечивало бы более-менее полноценный доступ к ФС самой системы. JTAG тоже быть не должно, кстати. Да и сама «система» тут крайне условна. Кастомное ядро, buzybox, статическая линковка с musl (такой классический embedded вариант). Т.е., после загрузки данный одноплатник может выполнить только две функции – принять запрос с USB, обработать его, вернуть ответ. И обновить БД если есть строго определённый файл на том USB-накопителе, в который вставили USB-разъём. Всё, в принципе. Больше на плате ничего не должно быть (ни HDMI, ни дополнительных разъёмов), ничего. Рутовый пароль длинный и пользователям не передаётся. Пользователей в системе только один, который отвечает за оба этих демона. Возможность логина сразу отключена для обоих пользователей. Ни su, ни sudo, ни даже текстового редактора в системе быть не должно.

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

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

Остальные методы защиты… ну так себе идея. Тут можно особо не упираться, т.к.:

Досылать данные - у нас есть канал для этого.

Т.е., к данным доступ со стороны третьих лиц уже есть, можно сказать. И есть доступ к самому по себе устройству, т.е., его можно разобрать при желании и отреверсить по полной.

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

Разве что ещё «закрепить» комплекс применением OP-TEE как тут выше советовал уважаемый AlexVR (Генерация и запуск кода на лету (комментарий)). Ну вот типа такой механизм должен быть в обоих приложениях (пример для OP-TEE). Но тогда часть реализации должна быть убрана в TEE и там должна работать своя ОС, которая будет работать на том же процессоре, что и основная (non trusted система или ещё её называют REE) и обеспечивать ответы со стороны non trusted OS. Пример такой trusted OS. По сути, здесь что-то типа слоя виртуалки добавляется, причём, в «виртуалку» попадает REE и её оба демона.

Иных альтернатив не вижу, к сожалению.

Спасибо. Всё грамотно расписали. Надеюсь когда-нибудь получится вместе поработать

Гут.

Я в курсе что такое OP-TEE (ну и остальное), т.к. это относится напрямую к тому, что я довольно регулярно делаю. Но вот задач примерно в течении месяца будет примерно как у хреновой сучки блох. «Мало нас, но мы в тель… в ушанках». =))) И отдуваться приходится малым числом и за себя и за того парня, точнее, тех парней. Где-то через месяц выйду на связь.

Перловика пока не выловил, но выловлю, он сам на связь выйдет. По моему поводу ему лучше вопросов не задавать. Знакомство шапочное, что называется и он не в курсе чем я, как раб Божий, занимаюсь. Ну знает что есть такой чувак (при чём под другим именем, а не по интернет-нику). В общем и всё. =) Большего и не нужно. В принципе, учитывая то, что он из Каспера, мы с ним стояли… малость по разные стороны «баррикады». =)))

Сюда бы secure boot ещё. Есть информация, во сколько это обойдется для мелкосерийки?

Есть.

Сюда бы secure boot ещё.

Есть и secure boot и boot guard и (даже!) UEFI есть в т.ч. и для ARM. Завезли уже, да.

Есть информация, во сколько это обойдется для мелкосерийки?

Зависит от условий. Можно вообще бесплатно сделать в обмен на долю от сбыта продаваемых устройств. Всё зависит от условий заказа.

Передал.

Передавай Сергею привет из солнечного Берлина.

Привет передал. Правда, он спросил от кого, но я сказал что «из солнечного Берлина» и его поотпустило. =)

Он сейчас нашёл себя в архитектуре. Архитектором стал. Ну, в общем, Бог в помощь. =)))

P.S. Жаль что здесь нет аналога личных/приватных сообщений, но при том числе долб… «неадекватов», что здесь есть, решение не делать их понятно.

Здравствуйте ещё раз. У меня вакансия открылас. Программиста с++. Если интересует - @ A2154242153085202020 в телеграмм

Здравствуйте.

Плюсы не мой основной язык, к сожалению. А точно С++ или всё таки, С?

Да, с++ это основной язык в нашем проекте.

Тогда я к сожалению пас.

Пока, во всяком случае. Я не то чтобы не умею на плюсах, просто не особо люблю этот язык. И сейчас вот готовлюсь к новому проекту.

Зайдите в XMPP, пожалуйста.