Chebuya 415 Опубликовано: 5 мая, 2021 (изменено) Сидя уже 5 час над этой задачей, адекватных решений не пришло в голову. Вопрос таков: каким образом можно обезопасить окружение на уровне компонента EEPROM, например, если нам нужно удостоверится, что текущий component.eeprom не был подменен как и его код? Не думаю, что это может помочь, если злоумышленник достаточно заинтересован во взломе. Какие практики первыми приходят в голову? Обфускация кода/держать EEPROM под подушкой? В irc-канале #oc не нашел ничего интересного по этому поводу, поэтому, предлагаю обсудить здесь. Изменено 5 мая, 2021 пользователем BrightYC Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Mihis 14 Опубликовано: 6 мая, 2021 (изменено) Думаю можно постоянно чекать чексум EEPROM. Если изменилась - значит EEPROM был подменен. getChecksum():string https://ocdoc.cil.li/component:eeprom Изменено 6 мая, 2021 пользователем Mihis Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 4 минуты назад, Mihis сказал: Думаю можно постоянно чекать чексум EEPROM. Этого недостаточно. Все обращения к периферии могут быть перехвачены злоумышленником. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 31 минуту назад, Mihis сказал: Думаю можно постоянно чекать чексум EEPROM. Если изменилась - значит EEPROM был подменен. getChecksum():string https://ocdoc.cil.li/component:eeprom а что если сам component.eeprom был подменен физически? нечему проверять checksum. Нужно как-то "секретно" индицировать, что это наш eeprom, а не EEPROM злоумышленника. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 1 минуту назад, BrightYC сказал: Нужно как-то "секретно" индицировать, что это наш eeprom, а не EEPROM злоумышленника Если злоумышленник перехватил все вызовы к периферии, уже ничто не будет секретным. Поэтому секретность уходит на второй план. А на первый выходит определение факта взлома. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 Я когда-то давно пытался исследовать этот вопрос, но абсолютно непробиваемой и при этом удобной защиты у меня не получилось. Есть неудобный, но надёжный параноидальный вариант: не хранить ничего ценного в постоянной памяти робота, а любого перезагруженного робота считать скомпрометированным. Скомпрометированных роботов следует выводить на нейтральную территорию и проверять содержимое EEPROM аппаратным способом. А при обнаружении опасных изменений следует поменять открытые порты во всей системе, а сетевые карты как робота, так и общавшегося с ним планшета разобрать на запчасти. Определить же факт модификации EEPROM не всегда возможно. Возможно, я не прав, но мне кажется, полностью публичное существование такой системы невозможно. Да, на начальном этапе можно и нужно вести публичное обсуждение. Но в конечном итоге каждая система должна будет заиметь свои уникальные секретные особенности, неожиданные для взломщика. Мотивированный взломщик может обойти каждый конкретный известный ему вариант, но вряд ли сможет написать универсальный анализатор кода. Предлагаю сыграть в игру. Накидывайте возможные варианты защиты, а я скажу как им противодействовать. А можно и наоборот. Главное, сохранить состязательность. Это позволит по-новому взглянуть на старые идеи. Итак, идея: запрашивать по сети не контрольную сумму EEPROM, а полное содержимое. Чем ответит взломщик? 2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ProgramCrafter 545 Опубликовано: 6 мая, 2021 11 час назад, BrightYC сказал: текущий component.eeprom не был подменен Немного не в теме: имеется в виду программная подмена компонента или вставка нового EEPROM? И кто должен убедиться в неизменности EEPROM: сам робот/дрон/кто-то там или компьютер, общающийся с ним по сети? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 Только что, ProgramCrafter сказал: Немного не в теме: имеется в виду программная подмена компонента или вставка нового EEPROM? И кто должен убедиться в неизменности EEPROM: сам робот/дрон/кто-то там или компьютер, общающийся с ним по сети? Fingercomp в IRC уже написал мне об неправильно поставленном вопросе. В общем: убедится в неизменности EEPROM должен сам игрок при включении компьютера, на счет подмены: имеется в виду либо вставка нового компонента, либо подмена окружения, либо изменение самого кода eeprom напрямую (впрочем, eeprom можно установить в readonly, но едва ли это поможет, если подменили физический компонент) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 @BrightYC После вмешательства злоумышленника компьютер не может достоверно диагностировать сам себя. Для этого нужен какой-то эталон. Но эталон, хранящийся внутри компьютера также может быть сломан, поэтому самодиагностика бессмысленна. Да и сама процедура диагностики может быть сломана. Можно лишь что-то выявить с помощью другого, гарантированно защищённого компьютера, опрашивая по сети проверяемый компьютер. Но т.к. взломанный компьютер может подделывать ответы, задача сводится к выявлению лжи и составлению таких вопросов, на которые взломанный компьютер будет вынужден ответить честно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 30 минут назад, eu_tomat сказал: Итак, идея: запрашивать по сети не контрольную сумму EEPROM, а полное содержимое. Чем ответит взломщик? Но кто будет запрашивать? Если запрашивать будет сервер, вроде схемы загрузки по сети (потенциально небезопасная EEPROM -> содержимое -> сервер) тогда это не имеет смысла, т.к взломщик может просто отправить оригинальный код. 33 минуты назад, eu_tomat сказал: Предлагаю сыграть в игру. Накидывайте возможные варианты защиты, а я скажу как им противодействовать. А можно и наоборот. Главное, сохранить состязательность. Это позволит по-новому взглянуть на старые идеи. Первое, что мне пришло в голову - это в целом не давать компьютерам биос, и вставлять еепрому только на этап загрузки системы. Как сказал fingercomp в IRC - просто поставить eeprom в readonly режим, и физически при старте системы просто сверять адреса компонентов. Остальные варианты представить сложно, потому что в основном защита будет строится на обфускации и спагетти-коде. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 6 минут назад, BrightYC сказал: не давать компьютерам биос, и вставлять еепрому только на этап загрузки системы Но как провернуть этот трюк с роботами или дронами? Они больше всех уязвимы, т.к. часто работают на общедоступной территории. 2 минуты назад, BrightYC сказал: это не имеет смысла, т.к взломщик может просто отправить оригинальный код Чтобы отправить оригинальный код, его надо где-то хранить. Все известные мне способы хранения можно либо выявить, либо противодействовать им. А где предлагаешь хранить оригинальный код ты? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 (изменено) 2 минуты назад, eu_tomat сказал: Чтобы отправить оригинальный код, его надо где-то хранить. Все известные мне способы хранения можно либо выявить, либо противодействовать им. А где предлагаешь хранить оригинальный код ты? На зашифрованном сервере, который предварительно мы загрузили безопасно с трюком выше. Изменено 6 мая, 2021 пользователем BrightYC Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 1 минуту назад, BrightYC сказал: На зашифрованном сервере, который предварительно мы загрузили безопасно с трюком выше. Тут я не понял. Ты сейчас за какую сторону выступаешь? Я предложил запрашивать у робота текущий код EEPROM, чтобы сравнить его с эталонным. Да, он хранится на нашем сервере. Ты парировал тем, что взломщик может отправить наш оригинальный код. Я спрашиваю, где взломщик хранит наш оригинальный код, чтобы отправить его на запрос нашего сервера. Или взломщик также хранит наш оригинальный код уже на своём сервере? Я правильно понял? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 (изменено) 6 минут назад, eu_tomat сказал: Я спрашиваю, где взломщик хранит наш оригинальный код, чтобы отправить его на запрос нашего сервера. Мне показалось, что защищающаяся сторона должна хранить где-то код. Но даже так взломщик может тоже хранить оригинальный код у себя на сервере. Проблема вот в чем: злоумышленник может просто взять оригинальный код еепромы, сделать что-то вроде: data = maliciousChunk .. eeprom.get() и потом если проверяющая сторона запрашивает код, мы просто делаем что-то вроде этого: modem.send(serverAddress, eeprom.get():sub(maliciousChunk, #eeprom.get()) P.S Или даже проще, банально разделив полезную нагрузку и потом вычленив gsub'ом modem.send(.., eeprom.get:gsub("|(.+)")) Изменено 6 мая, 2021 пользователем BrightYC Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 Так... я обнаружил новую дыру в защите, но до неё мы еще не дошли. Поэтому продолжаем. Может, ещё что-то интересное обнаружится. 7 часов назад, BrightYC сказал: data = maliciousChunk .. eeprom.get() Чтобы этот трюк стал невозможным, достаточно забить всю свободную часть EEPROM трудносжимаемым комментарием. Такая сигнатура будет даже лучше контрольной суммы. Поэтому EEPROM для хранения оригинального кода не годится. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 (изменено) 22 минуты назад, eu_tomat сказал: Чтобы этот трюк стал невозможным, достаточно забить всю свободную часть EEPROM трудносжимаемым комментарием. Такая сигнатура будет даже лучше контрольной суммы. Поэтому EEPROM для хранения оригинального кода не годится. насколько трудносжимаемым? если злоумышленник достаточно заинтересован, он может переписать оригинальную нагрузку в более оптимальный вид, чтобы осталось место под его код. Изменено 6 мая, 2021 пользователем BrightYC Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 10 минут назад, BrightYC сказал: насколько трудносжимаемым? Например: $ (dd if=/dev/urandom bs=4096 count=1 | gzip | dd > /dev/zero ) 2>&1 | grep bytes 4096 bytes (4,1 kB, 4,0 KiB) copied, 5,6993e-05 s, 71,9 MB/s 4119 bytes (4,1 kB, 4,0 KiB) copied, 4,2526e-05 s, 96,9 MB/s Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 1 минуту назад, eu_tomat сказал: Например: $ (dd if=/dev/urandom bs=4096 count=1 | gzip | dd > /dev/zero ) 2>&1 | grep bytes 4096 bytes (4,1 kB, 4,0 KiB) copied, 5,6993e-05 s, 71,9 MB/s 4119 bytes (4,1 kB, 4,0 KiB) copied, 4,2526e-05 s, 96,9 MB/s хорошо, я не вижу подвоха здесь пока что, но как поступать, если злоумышленник будет хранить данные в tmpfs? она не чистится, если был soft reboot. или в конце концов интернет-карта или беспроводная карта. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat 2 155 Опубликовано: 6 мая, 2021 2 минуты назад, BrightYC сказал: как поступать, если злоумышленник будет хранить данные в tmpfs? Во! Отличный вопрос. Про хранение в tmpfs я раньше не думал, но решение простое. Так как объём tmpfs ограничен, то даём допрашиваемому роботу задачу записать в tmpfs файл максимально возможного размера с псевдослучайными данными, генерируемыми по заданному алгоритму и стартовыми значениями, а затем прочитать байты в псевдослучайном порядке, посчитать контрольную сумму и сообщить результат серверу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya Автор темы 415 Опубликовано: 6 мая, 2021 1 минуту назад, eu_tomat сказал: Во! Отличный вопрос. Про хранение в tmpfs я раньше не думал, но решение простое. Так как объём tmpfs ограничен, то даём допрашиваемому роботу задачу записать в tmpfs файл максимально возможного размера с псевдослучайными данными, генерируемыми по заданному алгоритму и стартовыми значениями, а затем прочитать байты в псевдослучайном порядке, посчитать контрольную сумму и сообщить результат серверу. хорошо, но какой в этом смысл, если мы можем проксировать tmpfs и хранить файл который запросил сервер в озу, а настоящую еепрому хранить в tmpfs? и не допускать доступа к реальной tmpfs. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах