Chebuya

Справедливости ради, модуль chacha20 и pbkdf2 писал не я ¯\_(ツ)_/¯ 

2 часа назад, hohserg сказал:

А какие системные требования? Скоко памяти жрет? Какой максимальный размер файла поддерживается?

хз, есть поддержка монохромных мониторов, но на запуск проги надо оперативную память 1.5 уровня. максимальный размер файла неизвестен, но на потребление озу влияет только запись перед файлом, то есть: открываем файл в режиме append, и выполняем seek, допустим, на 0. Тогда весь файл будет записан в озу, что поделать ¯\_(ツ)_/¯

1 минуту назад, hohserg сказал:

Правильно ли я понимаю, что эта программа имеет смысл, когда могут украсть диск с ценными файлами?

Только в таком случае и имеет. От админов смысла прятаться нет. К тому же, программа не защищает от физической подмены загрузочного кода: можно украсть пароль.

Представляю вам программу для (тавтология) полнодискового шифрования. Позволяет зашифровывать данные "на лету", в прозрачном режиме.

Установка:

Для OpenOS:

wget -f https://raw.githubusercontent.com/BrightYC/Catch/main/catch.lua /bin/catch.lua

Для MineOS же есть приложение в местном AppMarket, под названием Catch.

Код обитает здесь: https://github.com/BrightYC/Catch/

Использование:

В OpenOS, вы можете зашифровать любые диски, например, чтобы они были портативными

Примеры:

• catch --encrypt --drive=XXX (Диск XXX будет зашифрован)
• catch --encrypt (Будет зашифрован относительный путь: например, если мы находимся в директории /mnt/xxx, диск xxx будет зашифрован, если мы находимся в главной директории - загрузочный диск будет зашифрован)
• catch --decrypt --drive=XXX (Диск XXX будет расшифрован)

В MineOS, вы можете только зашифровать загрузочный диск, если же вы попытаетесь открыть программу на другому диске, программа запросит пароль для диска и смонтирует его по пути /Mounts/Catch-XXX. Если же запустить программу на другом диске с аргументом rootfs, будет запущена программа для шифрования, как обычно.
 

Количество итераций:

Количество итераций определяет сложность вычисления ключа, чем выше количество - тем сложнее взломать ключ. Если количество итераций слишком высокое - расшифровка диска будет выполняться очень медленно, цифра в 1-2 минуты вполне реальна. Стандартное значение - 5000. Количество итераций можно указать только в OpenOS.

Пример: catch --encrypt --iter-time=3000

Программа в MineOS:



Видеодемонстрация:

В 29.05.2021 в 20:24, Asior сказал:

Перезалью если его востановят.

восстановили.

В 12.11.2015 в 07:16, Doob сказал:

Кстати, это меня натолкнуло на мысль - сделать подобие VeraCrypt для OpenOS

Неделю назад доделал одну вещь, что-то вроде VeraCrypt. Что стоит отметить: OC слишком тормознутый, чтобы какие-либо KDF работали достаточно быстро (100 тысяч итераций выполнится за полторы минуты, но 1000 итераций выполняется достаточно шустро). Потребление озу в той же MineOS легко доходит до 90%, если, например, открыть какой-нибудь жирный файл.
 

44 минуты назад, chapo сказал:

как отсортировать таблицу:

local table = {
    {'b', 'd', 'z', 'c', 'a'},
}

по алфавиту?

table.sort(table, function(a, b) return a < b end)

в обратном порядке:

table.sort(table, function(a, b) return a > b end)

со стороны взломщиков появилась идея. Хранить код для пробуждения на сервере, а для самого модема выставить сигнал на пробуждение. Перед выполнением любого кода отсылать на сервер, что робот выполняет код - и начинает в цикле while true do end посылать сигнал на wakeup.

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

но каким образом это поможет если, сам этот код обвернут в pcall?

local chunkFromServer = [[
while true do
  pcall(function()
    for i=1,1e15 do end
  end)
end
]]

local chunk = load(chunkFromServer)

if chunk then
	pcall(chunk)
end

 

проверил, оказывается, даже если код обвернут в pcall, tlwy вылетает сразу, провоцируя выключение компьютера.

4 часа назад, eu_tomat сказал:

Что-то лагерь взломщиков долго молчит.

 

Поясню свой предыдущий ответ:

Код может выглядеть, например, так:

while true do
  pcall(function()
    for i=1,1e15 do end
  end)
end

Это код должен спровоцировать ошибку TLWY и отключение робота.

но каким образом это поможет если, сам этот код обвернут в pcall?

local chunkFromServer = [[
while true do
  pcall(function()
    for i=1,1e15 do end
  end)
end
]]

local chunk = load(chunkFromServer)

if chunk then
	pcall(chunk)
end

https://github.com/Shuudoushi/SecureOS

из мода OC давно удалена (по крайней мере на 1.12)

5 минут назад, Taruu сказал:

Можно тогда в дискету засунуть uuid робота и если его пересобрали то дискета просто скажет фи... Ибо uuid поменяется 

Нельзя. Программа на уровне EEPROM может подменить вызовы и к component.invoke. В том числе и к очереди сигналов и прокси компонентов.

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

Ты имеешь в виду тот случай когда у нас стырили робота и потом вернули?

собственно, вся тема об этом, а не о том, как сохранить данные. Всякие secure boot бесполезны, если самый главный загрузчик скомпрометирован.

3 минуты назад, Taruu сказал:

А можно ли сделать защиту при помощи внешнего ключа?
Те зашифровать все данные в роботе, а для его запуска юзать дискету с ключом и автораном.
На ходу юзать Дата карту 2-3 уровня (можно даже карту достать) что бы запустить весь код, и после можно вынуть дискету.
И если у нас сперли робота то результату будет ноль. Ведь для его запуска нужно засунуть дискету.

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

какой смысл, если EEPROM могли подменить? Ну засунешь дискету - а какой смысл, если код был запущен еепромой, которая пожет подменить *все*.

Кстати, немного оффтопа, но дата-карта не обязательна. Она медленнее, чем software решения.

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

Новый ход лагеря злоумышленников:

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

После создания соединения он посылает запрос на авторизацию у сервера "хороших", все сетевые пакеты передаёт в эмулятор.

Как контрить этот вариант? Задержка ответа будет весьма незначительной.

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

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

Соглсен. На computer.shutdown полагаться нельзя. Останов по TLWY будет понадёжнее.

каким образом? код обвернут в pcall, а полагаться на то, что упадет сам робот из-за лагов сервера - несколько странно.

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

Логично. Но сервер может специально проверить, способен ли робот пробуждаться по сообщению, специально остановив его.

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

1 час назад, eu_tomat сказал:

Но вернусь к теме.

Исходя из новейших данных, WakeMessage сетевой платы должен быть заполнен трудносжимаемыми данными размером 8 KiB. Можно было бы использовать и больший размер, но как тогда будить уснувших роботов? В этом решении я вижу уязвимость, но она, возможно, не единственная, поэтому я подожду ответного хода лагеря взломщиков.

Если использовать сетевую плату, то я не уверен, что сервер может просчитать задержку в 1 пакет до сервера злоумышленника, откуда мы просто можем скачать оригинальные данные. Т.к EEPROM весит всего 4 килобайта, по сравнению с интернет-картой, где на открытие сокета тратится 3-4 секунды, сообщение придет практически мгновенно, и это можно списать на лаги сервера.

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

Но как поступать, если в дрона/робота вставили интернет-карту?

впрочем, у интернет карты ограниченная скорость ( 40 киб/с), думаю, это можно обыграть.

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

Устанавливаем в робота диск максимально возможного объёма и полностью забиваем его процедурно сгенерированными данными.

Но как поступать, если в дрона/робота вставили интернет-карту? в таком случае можно забивать робота мусорными компонентами для увеличения сложности? (как можно определить уровень процессора внутри окружения? мне кажется, это возможно)

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

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

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

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

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

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

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. или в конце концов интернет-карта или беспроводная карта.

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

Чтобы этот трюк стал невозможным, достаточно забить всю свободную часть EEPROM трудносжимаемым комментарием. Такая сигнатура будет даже лучше контрольной суммы. Поэтому 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("|(.+)"))