История изменений

Качать данные с сервера (даже часть) в момент когда они нужны - нет такой возможности. Канал по опыту поднимается на 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 и её оба демона.

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

Качать данные с сервера (даже часть) в момент когда они нужны - нет такой возможности. Канал по опыту поднимается на 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.

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