Previous Entry Share Next Entry
2016-01

OM NOM NOM, FE from IND-OBF via SSS-NIZK, PKE and FHE.

Хехехе.

Пока идут всякие революции и прочие метания говном, настоящие прорывы происходят, как обычно, в тишине институтов.

Ну, всем известно что идеальный DRM построить нельзя, по определению? ("увидеть фильм" отличается от "скопировать фильм" все меньше и меньше, поскольку копировальная техника растет)

Так вот, DRM нельзя, а идеальный обфускатор - можно. Now with proofs.

Что дает нам идеально безопасный в значении "ключи невосстановимы" DRM, способ конструировать асимметричную криптографию из симметричной и, бинго, способ выполнять шифрованный код!

Welcome to the brave new world. Сейчас это доведут до ума, и будет новая волна изменений.

То есть безопасный SaaS, P2P SaaS, вирусы, которые невозможно проанализировать, и неломаемые триалы, и много-много еще чего ;-)

https://www.simonsfoundation.org/quanta/20140130-perfecting-the-art-of-sensible-nonsense/ (slashdotted)

http://eprint.iacr.org/2013/451.pdf
http://eprint.iacr.org/2013/631.pdf

Сижу читаю.

This entry was originally posted at http://wizzard.dreamwidth.org/343921.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
mbr February 5th, 2014
> способ выполнять шифрованный код!

Дык боян же давно. Themida и VMProtect на этой почве давно свой бизнес делают.

Насчет неломаемости - не верю (с)

темидовские виртуалки для RISC сломаны давно, для CISC, говорят, у Касперского есть :)

wizzard0 February 5th, 2014
> не верю (с)

Ты же помнишь времена, когда не было стойких симметричных шифров, хотя было понятно, что их построение - возможно?

Вот мы сейчас попали в такое время с обфускаторами. Раньше считалось, что нельзя построить идеальный (где декрипт занимает O(2^n) от количества кода) обфускатор, а тут доказали, что можно. И даже привели кое-какие черновики того, как именно.


> темидовские виртуалки для RISC сломаны давно, для CISC, говорят, у Касперского есть :)
1. ну они действительно далеко в этом продвинулись, но обламывать kav все так же легко ;-)
2. темида решает ДРУГУЮ задачу, а именно, "построить достаточно оптимизированную VM". Так вот, "достаточно оптимизированную" - не очень сочетается с криптостойкостью.

Короче, тормозить будет охренительно. Но при этом будет неломаемо.

(Deleted comment)
nponeccop February 5th, 2014
вы themida видели? http://cps-vo.org/node/7662 начиная с 8 слайда

Edited at 2014-02-05 01:07 pm (UTC)

(Deleted comment)
nponeccop February 5th, 2014
Вы статью почитайте. На епринте. Текущий уровень существенно вырос, теперь больше не security by obscurity.

(Deleted comment)
nponeccop February 5th, 2014
Ну в vm-ке темиды проблема в том, что схема изначально ничего, кроме смешков, у криптоаналитиков не вызывает, потому что security by obscurity просто.

Как и везде в software protection. До настоящего времени.

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

(Deleted comment)
nponeccop February 5th, 2014
Ну это вроде первых работ по HE, я не испытываю фанатичного энтузиазма.

wizzard0 February 5th, 2014
оно как минимум будет тормозить

(Deleted comment)
(Deleted comment)
nponeccop February 5th, 2014
см. статью

amarao_san February 5th, 2014
Мне кажется, DRM от "неанализируемый код" всё-таки отличается. Потому что на выходе DRM всё равно есть анализируемая (человеком) картинка, звук, текст (ладно, ладно, картинка).

А вот неанализируемый код - это как криптография - инструмент. Как его применят - это вопрос открытый.

(Deleted comment)
amarao_san February 5th, 2014
Насколько я понимаю (этот топик, кстати, ещё два года назад мусолился, и по-моему с этой же рожей на фотке), там речь идёт о том, что код генерируется нативный. Однако, для "понимания", что он делает, нужно решить более сложную задачу, чем его исполнение.

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

Типовой пример: вместо линейного исполнения кода, все данные сабмитятся в очередь посредством размещения ссылок в очередь, после чего идёт "возврат" в диспетчер, который решает кого и куда вызывать дальше.

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

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

Если же добавить других моделей взаимодействия (callback'и, конечные автоматы, какую-нибудь локальную перлоподобную (то есть не анализируемую статически) грамматику и т.д., а потом автоматизировать размазывание императивного кода по подобным примитивам, то мало никому не покажется.

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

Получается, что "код есть, а что делает - не понятно". Остаётся только анализировать side effects, которые, очевидно, не являются методом ответа на вопрос "что делает программа", потому что иначе бы был бы метод отличить белый шум от бессигнатурного шифра, а это, насколько я знаю, не возможно в общем случае.

(Deleted comment)
amarao_san February 5th, 2014
Любую функцию, находящуюся в замыкании (то есть такую, которой можно воспроизвести внешние условия идентично снова и снова) можно описать в виде массива "входное состояние -> выходное состояние". Это потребует o(n) числа инструкций, исполняющихся в оригинальной программе, или o(1) от оригинального алгоритма.

Однако, предположим, что внутри этого кода выполняется что-то вида sha1(data+bit_sum(current_ntime)), то есть в хеше участвуют наносекунды текущего времени. В этом случае наш анализ покажет, что алгоритм зависит от окружения. Изменением окружения мы покажем, что он так же зависит от времени. И всё. Мы даже не сможем сказать, какой результат будет в следущую наносекунду.

А вот анализ самого кода, судя по бумаге, требует o(n2), что означает, что если алгоритм обфускации делает код размером не менее, например, мегабайта (и дальше линейно растёт от размера входного кода), то это будет означать, что нам потребуется анализ алгоритма с эквивалентным размером в терабайт. Печальная перспектива.

(Deleted comment)
amarao_san February 5th, 2014
Да, да. Просто пользы от получившегося дампа не больше, чем у скринкаста работы той же программы.

(Deleted comment)
amarao_san February 5th, 2014
Давай пока примем за данность, что у нас, например, мегабайт линейного кода, причём мы не можем определить там развёрнутые циклы, и алгоритма деобфускации мы пока не придумали.

Есть входные данные - 64кб. Есть состояние системы (допустим, описание ещё 64кб), и данные приложения (ещё 64кб). На выходе имеем 64кб других данных.

Предположим, мы "ломаем" алгоритм DRM-воспроизведения несжатого аудио-потока, и у нас есть подозрение, что эти 64кб - это 1 секунда 8-канального звука в HD качестве, перекодированная из сетевого формата в шифрованный формат до ресивера.

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

Что делать?

(Deleted comment)
(Deleted comment)
(Deleted comment)
amarao_san February 5th, 2014
Как показывают многие интерпретируемые языки - 10-20 кратное падение скорости по сравнению с нативным кодом принимают и прощают.

(Deleted comment)
amarao_san February 5th, 2014
Так что достаточно всё свернуть в добротный конечный автомат, у которого из доступных 200кб 100кб будет дерево состояний, 30кб кода для обработки конечного автомата и ещё 70кб будет генерировать новое дерево конечного автомата для последующего выполнения.

(Deleted comment)
wizzard0 February 5th, 2014
Собственно, деобфускатор и оптимизирующий tracing jit - это не случайно одно и то же =)

soonts February 5th, 2014
>неломаемые триалы
Про остальное не знаю, но вот это в общем-то достижимо, просто нужно мало никому.
Пример 1 - защиту thedeemon пока никто так и не сломал, хотя желающие очевидно есть (в двух словах, перенёс часть критичной логики из native code в свою собственную ни с чем не совместимую bytecode VM, когда-то писал в блоге).
Пример 2 - мой друг много лет тому назад работал в одной крупной российской IT компании, выпускающей коробочные программные продукты.
Запилил для их продуктов защиту которую нельзя сломать, потом начальство+отдел маркетинга его в частной беседе просили сделать так, шоб оно ломалось за разумное время (т.к. они считают, что в условиях России пираты помогают продажам, а не мешают).
Пример 3 - при правильном их использовании, аппаратные USB-ключи не ломаются.

nicka_startcev February 5th, 2014
>Пример 3 - при правильном их использовании, аппаратные USB-ключи не ломаются.

нет. это просто перекладывание задачи с, условно, "сломать код в компьютере" на, условно, "сломать код в микроконтроллере". В общем, просто ломание дорожает.

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

soonts February 5th, 2014
>условно, "сломать код в микроконтроллере"
Код там read only — вы можете только выкинуть оригинальную железку, и подключить вместо неё свой эмулятор из говна и палок PIC/ARM/etc.

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

nicka_startcev February 5th, 2014
опять же, всё упирается в деньги и время.

написать на каком-то ПИКе эмулятор ъ-токена - это задача для студента буквально на вечер и ценой порядка килобакса.

купить 2 копии софтины с суперхитрым ключом, один ключ протравить (снять пластик, прочитать rom/eeprom) и прочитать физически -- это дороже на 2-3 порядка и в разы дольше.

затратить тыщщу и сэкономить 10 тыщ на закупке тыщщи копий софта - это окупается.

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

(Deleted comment)
soonts February 5th, 2014
>сбросить fuse-биты
Например в процессоре xbox 360 это грубо говоря плавкие предохранители (т.н. eFuse), сгорают строго один раз, никакой ультрафиолет их обратно не восстанавливает ни на коленке, ни в лаборатории.
Там их много, некоторые сгорают при первом включении и в них закодирован ключ консоли, некоторые сгорают по-одному с каждым апгрейдом firmware, шоб нельзя было даунглейднуться на старую версию с уязвимостями.

(Deleted comment)
soonts February 5th, 2014
>самые навороченные смарт-карты
Вендоры могут шо угодно позиционировать. Карточки для спутникового ТВ во-первых должны быть дешёвыми, во-вторых и в главных в системе нет связи между картой и источником сигнала.
Т.е. добыв как-то алгоритм и данные из одной карты (обратите внимание, они признают, что это было сложно и дорого), вы сломали весь телеканал — и это неизбежное технологическое ограничение этого сценария.

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

(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(no subject) (Anonymous) Expand
(Deleted comment)
(Deleted comment)
thedeemon February 5th, 2014
Не, когда защита остается невзломанной просто потому что никому не охота тратить на ее взлом много времени и сил (например, нужны нестандартные инструменты), это задачу бизнеса решает, но неломаемой защитой вряд ли называется.
Криптографически стойкая защита в теории намного интересней, но на практике наверняка окажется непрактично медленной и обходимой окольными путями.

soonts February 5th, 2014
>задачу бизнеса решает, но неломаемой защитой вряд ли называется
А по-моему вполне достаточно шоб называться.

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

thedeemon February 5th, 2014
Когда ресурсов нужно больше, чем атомов во вселенной, то это уже не вопрос ресурсов, это уже вполне себе гарантия.

sporaw February 6th, 2014
Пример 1 - Бред
Пример 2 - Бред
Пример 3 - Бред
Извините

udpn February 6th, 2014
Самый лол заключается в том, что где-то месяц назад я только понял, что такую штуку вообще нужно сделать. Пока вкуривал полностью гомоморфное шифрование с этими гарблед киркитс, люди уже полгода как знали результат.

Недавно решил популлреквестить в опенсорсный проект, с крутейшей идеей. Две недели продолбался, сделал, нашёл ещё два таких же проекта.

Да я ж слоупок.

wizzard0 February 6th, 2014
Это бывает.

  • 1
?

Log in

No account? Create an account