Перейти к содержимому
Chebuya

Аппаратная безопасность в OC

Рекомендуемые сообщения

Сидя уже 5 час над этой задачей, адекватных решений не пришло в голову.
Вопрос таков: каким образом можно обезопасить окружение на уровне компонента EEPROM, например, если нам нужно удостоверится, что текущий component.eeprom не был подменен как и его код? Не думаю, что это может помочь, если злоумышленник достаточно заинтересован во взломе.

Какие практики первыми приходят в голову? Обфускация кода/держать EEPROM под подушкой? В irc-канале #oc не нашел ничего интересного по этому поводу, поэтому, предлагаю обсудить здесь.

Изменено пользователем BrightYC

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю можно постоянно чекать чексум EEPROM. Если изменилась - значит EEPROM был подменен.

 

getChecksum():string

https://ocdoc.cil.li/component:eeprom

Изменено пользователем Mihis

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, Mihis сказал:

Думаю можно постоянно чекать чексум EEPROM.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
31 минуту назад, Mihis сказал:

Думаю можно постоянно чекать чексум EEPROM. Если изменилась - значит EEPROM был подменен.

 

getChecksum():string

https://ocdoc.cil.li/component:eeprom

а что если сам component.eeprom был подменен физически? нечему проверять checksum. Нужно как-то "секретно" индицировать, что это наш eeprom, а не EEPROM злоумышленника.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, BrightYC сказал:

Нужно как-то "секретно" индицировать, что это наш eeprom, а не EEPROM злоумышленника

Если злоумышленник перехватил все вызовы к периферии, уже ничто не будет секретным. Поэтому секретность уходит на второй план. А на первый выходит определение факта взлома.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Есть неудобный, но надёжный параноидальный вариант: не хранить ничего ценного в постоянной памяти робота, а любого перезагруженного робота считать скомпрометированным. Скомпрометированных роботов следует выводить на нейтральную территорию и проверять содержимое EEPROM аппаратным способом. А при обнаружении  опасных изменений следует поменять открытые порты во всей системе, а сетевые карты как робота, так и общавшегося с ним планшета разобрать на запчасти.

 

Определить же факт модификации EEPROM не всегда возможно. Возможно, я не прав, но мне кажется, полностью публичное существование такой системы невозможно. Да, на начальном этапе можно и нужно вести публичное обсуждение. Но в конечном итоге каждая система должна будет заиметь свои уникальные секретные особенности, неожиданные для взломщика. Мотивированный взломщик может обойти каждый конкретный известный ему вариант, но вряд ли сможет написать универсальный анализатор кода.

 

Предлагаю сыграть в игру. Накидывайте возможные варианты защиты, а я скажу как им противодействовать. А можно и наоборот. Главное, сохранить состязательность. Это позволит по-новому взглянуть на старые идеи.

 

Итак, идея: запрашивать по сети не контрольную сумму EEPROM, а полное содержимое. Чем ответит взломщик?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
11 час назад, BrightYC сказал:

текущий component.eeprom не был подменен

Немного не в теме: имеется в виду программная подмена компонента или вставка нового EEPROM?

И кто должен убедиться в неизменности EEPROM: сам робот/дрон/кто-то там или компьютер, общающийся с ним по сети?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Только что, ProgramCrafter сказал:

Немного не в теме: имеется в виду программная подмена компонента или вставка нового EEPROM?

И кто должен убедиться в неизменности EEPROM: сам робот/дрон/кто-то там или компьютер, общающийся с ним по сети?

Fingercomp в IRC уже написал мне об неправильно поставленном вопросе.

В общем: убедится в неизменности EEPROM должен сам игрок при включении компьютера, на счет подмены: имеется в виду либо вставка нового компонента, либо подмена окружения, либо изменение самого кода eeprom напрямую (впрочем, eeprom можно установить в readonly, но едва ли это поможет, если подменили физический компонент)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@BrightYC После вмешательства злоумышленника компьютер не может достоверно диагностировать сам себя. Для этого нужен какой-то эталон. Но эталон, хранящийся внутри компьютера также может быть сломан, поэтому самодиагностика бессмысленна. Да и сама процедура диагностики может быть сломана.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
30 минут назад, eu_tomat сказал:

Итак, идея: запрашивать по сети не контрольную сумму EEPROM, а полное содержимое. Чем ответит взломщик?

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

 

33 минуты назад, eu_tomat сказал:

Предлагаю сыграть в игру. Накидывайте возможные варианты защиты, а я скажу как им противодействовать. А можно и наоборот. Главное, сохранить состязательность. Это позволит по-новому взглянуть на старые идеи.

Первое, что мне пришло в голову - это в целом не давать компьютерам биос, и вставлять еепрому только на этап загрузки системы. Как сказал fingercomp в IRC - просто поставить eeprom в readonly режим, и физически при старте системы просто сверять адреса компонентов. Остальные варианты представить сложно, потому что в основном защита будет строится на обфускации и спагетти-коде.   

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
6 минут назад, BrightYC сказал:

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

Но как провернуть этот трюк с роботами или дронами? Они больше всех уязвимы, т.к. часто работают на общедоступной территории.

 

2 минуты назад, BrightYC сказал:

это не имеет смысла, т.к взломщик может просто отправить оригинальный код

Чтобы отправить оригинальный код, его надо где-то хранить. Все известные мне способы хранения можно либо выявить, либо противодействовать им. А где предлагаешь хранить оригинальный код ты?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, eu_tomat сказал:

Чтобы отправить оригинальный код, его надо где-то хранить. Все известные мне способы хранения можно либо выявить, либо противодействовать им. А где предлагаешь хранить оригинальный код ты?

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

Изменено пользователем BrightYC

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, BrightYC сказал:

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

Тут я не понял. Ты сейчас за какую сторону выступаешь?

 

Я предложил запрашивать у робота текущий код EEPROM, чтобы сравнить его с эталонным. Да, он хранится на нашем сервере.

Ты парировал тем, что взломщик может отправить наш оригинальный код.

Я спрашиваю, где взломщик хранит наш оригинальный код, чтобы отправить его на запрос нашего сервера.

 

Или взломщик также хранит наш оригинальный код уже на своём сервере? Я правильно понял?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
6 минут назад, eu_tomat сказал:

Я спрашиваю, где взломщик хранит наш оригинальный код, чтобы отправить его на запрос нашего сервера.

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

data = maliciousChunk .. eeprom.get()
и потом если проверяющая сторона запрашивает код, мы просто делаем что-то вроде этого:

modem.send(serverAddress, eeprom.get():sub(maliciousChunk, #eeprom.get())

P.S Или даже проще, банально разделив полезную нагрузку и потом вычленив gsub'ом

modem.send(.., eeprom.get:gsub("|(.+)"))

Изменено пользователем BrightYC

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так... я обнаружил новую дыру в защите, но до неё мы еще не дошли. Поэтому продолжаем. Может, ещё что-то интересное обнаружится.

 

7 часов назад, BrightYC сказал:

data = maliciousChunk .. eeprom.get()

Чтобы этот трюк стал невозможным, достаточно забить всю свободную часть EEPROM трудносжимаемым комментарием. Такая сигнатура будет даже лучше контрольной суммы. Поэтому EEPROM для хранения оригинального кода не годится.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
22 минуты назад, eu_tomat сказал:

Чтобы этот трюк стал невозможным, достаточно забить всю свободную часть EEPROM трудносжимаемым комментарием. Такая сигнатура будет даже лучше контрольной суммы. Поэтому EEPROM для хранения оригинального кода не годится.

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

Изменено пользователем BrightYC

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
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. или в конце концов интернет-карта или беспроводная карта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, BrightYC сказал:

как поступать, если злоумышленник будет хранить данные в tmpfs?

Во! Отличный вопрос. Про хранение в tmpfs я раньше не думал, но решение простое. Так как объём tmpfs ограничен, то даём допрашиваемому роботу задачу записать в tmpfs файл максимально возможного размера с псевдослучайными данными, генерируемыми по заданному алгоритму и стартовыми значениями, а затем прочитать байты в псевдослучайном порядке, посчитать контрольную сумму и сообщить результат серверу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, eu_tomat сказал:

Во! Отличный вопрос. Про хранение в tmpfs я раньше не думал, но решение простое. Так как объём tmpfs ограничен, то даём допрашиваемому роботу задачу записать в tmpfs файл максимально возможного размера с псевдослучайными данными, генерируемыми по заданному алгоритму и стартовыми значениями, а затем прочитать байты в псевдослучайном порядке, посчитать контрольную сумму и сообщить результат серверу.

хорошо, но какой в этом смысл, если мы можем проксировать tmpfs и хранить файл который запросил сервер в озу, а настоящую еепрому хранить в tmpfs? и не допускать доступа к реальной tmpfs.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...