Переезд в Калугу

Все, мы покинули Москву :)  Уже работаю из дома - из своей, а не снимаемой в default city квартиры. Свершилось! Впрочем, Москва в 3-х часах езды, поэтому туда тоже можно будет ездить иногда. Радует то, что ряд стереотипов начинает рушиться. Например, больше становится компаний, готовых работать с людьми удаленно, не требуя от них переезда в место своей дислокации. Современные технологии связи обеспечивают такие возможности. Выгода для всех участников процесса налицо. Те, кто не понимает этого (а точнее, не принимает в силу сложившихся стереотипов, придумывая разнообразные, зачастую нелепые, объяснения, почему так не делать), ограничивают сами себя. Такие необоснованные ограничения зачастую являются плохо прикрытым результатом управленческого непрофессионализма. Забавно было слушать некоторых товарищей, отговаривавших меня от таких действий, называя переезд дауншифтингом :) Как-как, а так я бы это не стал называть :) Дауншифтинг был, когда я с позиции руководителя работ в одном Калужском НИИ уехал в Москву работать простым системным программистом,  не выигрывая на тот момент ни по позиции, ни по деньгам. Уехал за профессиональным ростом, который, полагаю, состоялся. Теперь настало время развиваться дальше.

PS. К Москве отношусь положительно. Можно даже сказать, люблю этот город. Обязательно будем периодически туда ездить. Может, даже появится время наконец-то погулять по городу без суеты и насладиться им в полной мере.

Атаки на системы клиент-банк

Прочитал интересную новость. Эта информация выявляет в очередной раз очень интересную проблему безопасности систем клиент-банк, о которой так много рассуждают разного рода специалисты. Рассуждают, в основном, в своем кругу, поэтому широкому кругу пользователей систем клиент-банк результаты этих бесед неизвестны. Совершенно очевидно, что с помощью классической криптографии защититься от этих атак невозможно. Ни GUI клиент (если это толстый клиент), ни криптопровайдер, ни драйвер устройства (речь идет о токене) никак не защищены от исследования. Да, используются протоколы классической криптографии, но они никак не рассчитаны на то, что приложение, их использующее, будет выполняться на недоверенной платформе. Использование токенов с  ЭЦП на борту также не дает гарантий безопасности, т.к. на подпись такому токену, как правило, отправляется хеш-сумма подписываемого документа. Таким образом, остаются способы подсунуть на подпись хеш-сумму другого документа. Чтобы создать программу, производящую такие зловредные действия для конкретной клиентской части, достаточно произвести ее тщательный анализ с помощью IDA.  Т.к. клиентская часть ничем не защищена и одинакова для многих тысяч пользователей, исследования принесут море удовольствия и не займут много времени, а атака может стать достаточно массовой. Хорошо документированные сервисы MS Crypto API еще более упрощают задачу :)
Один из технических выходов из ситуации - рандомизация каждой конкретной клиентской части. Т.е. ее структура должна стать совсем другой! Это означает  отказ от стандартизации, которая считается догмой. В частности,  имеет смысл подумать от использовании обфускации и White-Box криптографии, применяя эти механизмы, пусть и в автоматическом режиме, но уникально для каждой клиентской части. Однако, не смотря на техническую возможность, если не обезопасить полностью, то сильно снизить риски, существуют еще и административные вопросы, связанные, например, с сертификацией. Пока все участники процесса не осознают давно уже назревшую необходимость перемен, вряд ли мы увидим какой-то великий прогрессивный сдвиг в направлении улучшения защиты. Способы решения проблем будут, скорее всего, локальными и уже сейчас представлены - одноразовые пароли, SMS-уведомления и т.д. У них есть свои недостатки, связанные с недостаточной гибкостью. Например, SMS - это сервис, не гарантирующий доставку сообщений. С большой вероятностью антивирусные компании будут создавать свои механизмы противодействия атакам на клиентскую часть, что уже радует.

PS. Техническое описание атаки: http://habrahabr.ru/company/eset/blog/107520/
Красиво :)

О студентах...

Преподаю в Калужском филиале Бауманки. Все говорят о деградации студентов. Типа, с каждым курсом все глупее и глупее. Говорят все, включая самих студентов :) Я пришел к выводу, что на самом деле люди не глупее, у них всего-навсего ценности несколько другие. И, плюс к этому, колоссальная неуверенность в себе, усугубляемая тем, что многие из них еще не знают чего конкретно хотят и, как следствие, не знают куда расти. Да и такого жесткого мотиватора, который был у моего поколения в 90-е, у нынешних студентов нет. Т.е. вопрос далеко не в умственных способностях, с которыми у большинства все нормально, а в банальной мотивации. И давить надо именно на мотивацию, а в плане науки, при наличии желания, они сами все, что им надо, вытянут из преподавателя плюс к стандартным материалам. Кое-что уже получается. Думаю, с переездом в Калугу из Москвы будет получаться еще больше...

Проблема декомпозиции многомерных полиномов

Хороший приятель дал интересную ссылку  на статью, посвященную сабжу. Очень интересная работа - однозначно позволяет расширить кругозор и, возможно, улучшить качество моего LRC-метода, т.к. прицел в ней идет на схожие конструкции. Ну или придумать атаку на него :) В последнее время как раз немножко увлекся компьютерной алгеброй и символьными вычислениями и обнаружил, что русскоязычных книг на эту тему не очень много. Доходчивое описание базиса Гребнера, например, встречается достаточно редко. 

Одно из самых доходчивых: 

Кокс Д., Литтл Дж., О'Ши Д. Идеалы, многообразия и алгоритмы. Введение в вычислительные аспекты алгебраической геометрии и коммутативной алгебры.

Есть еще достаточно неплохая книга:

Прасолов В.В. Многочлены.

Уход...

Вчера был мой последний день работы в компании "Актив". Для меня это был целый этап в жизни.  Этап, когда я, попав в реально сильный и передовой коллектив в качестве слабенького системного программиста, вырос до эксперта, к мнению которого в Компании прислушивались. Это был хороший, сильный коллектив. Это были люди, которые меня многому научили. Я счастлив, что мне удалось в качестве и разработчика, и руководителя поучаствовать в целом ряде флагманских проектов. Почему ухожу? Наверное, пришло время. Я стал чувствовать себя не в своей тарелке - хочется большего, хочется движухи и более амбициозных проектов, хочется поменьше разговоров и побольше реальных дел,  хочется, чтобы никто не висел грузом на моих ногах, не давая мне развиваться, а также очень хотелось довести мой самый любимый Проект, посвященный обфускации, до конца, не смотря на то, что все люди, которые в него верили и продолжают, покинули компанию по похожим причинам. Что интересно, если бы Проект не был актуальным, то не создавалось бы сейчас в параллели некоторое количество аналогов, за развитием которых я внимательно слежу. Хотелось не разговоров о развитии, а реального развития - выхода на международные рынки. Хотелось роста. Хотелось выполнения данных мне обещаний. Ну что ж... Консервативный путь развития тоже имеет право на существование, но это не мой путь...

Обфускаторы, виртуализаторы, конечные автоматы и защита софта

Частенько приходится слышать что-то вроде этого: "Обфускация - ерунда, а вот виртуализация кода - практически неломаемая штука". Встречается еще и что-то вроде такого: "Это не обфускация. Наш метод базируется на сложной задаче декомпозиции большого конечного автомата". И т.д., и т.п. Если взглянуть в вики, то можно прочитать вот что: Обфускация (от лат. obfuscate — затенять, затемнять; и англ. obfuscate — делать неочевидным, запутанным, сбивать с толку) или запутывание кода — приведение исходного текста или исполняемого кода программы к виду, сохраняющему ее функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции. Т.е. и виртуализация, и создание в программе некоторого конечного автомата (что и есть виртуализация), что-то выполняющего, также являются одними из разновидностей этой самой обфускации. Виртуализация кода подразумевает под собой перевод исходного, как правило машинного, кода в код некоторого виртуального процессора с последующим встраиванием интерпретатора этого кода в тело защищаемой программы. Такой подход усложняет анализ защищенного кода, но не делает невозможным взлом программы и исследование логики ее работы. Аналогичное можно сказать и про декомпозицию конечного автомата, т.е. в данном случае про создание соответствия между исходным автоматом (x86 кодом, например) и полученным в результате обфускации автоматом. В теории все звучит достаточно неплохо, однако на практике, имея доступ к утилите, осуществляющей защиту, в подавляющем большинстве случаев, наделав простых сэмплов, можно набить шаблоны и снять защиту.
В последнее время стали популярны стековые ВМ в самом простом исполнении. Каждой ассемблерной инструкции ставится в соответствие некий обработчик, который делает то же самое, что и исходная инструкция вплоть до сохранения регистра флагов. Плюс имеется некий цикл выборки команд и передачи управления обработчикам. Помнится, был такой язык Forth. Так вот, стековые ВМ очень похожи по архитектуре. У Ахо, Сети, Ульмана такая архитектура называется абстрактной стековой ВМ. Не уверен точно, но, возможно, идея использования виртуального процессора пошла со времен, когда люди столкнулись с виртуальной машиной Visual Basic-а. Соблазны использовать такого рода обфускацию следующие:
1. "Эксперты" нараспев говорят, что это круто.
2. Маркетологи нараспев говорят, что п.1.
3. Размер запутуанного кода вырастает не так сильно.
4. Реализация не требует особых математических знаний и навыков, что позволяет справиться с задачей рядовому системному программисту.
5. Сроки реализации прогнозируемы по времени.
6. Результат тоже прогнозируем.
7. Легко накручивать сверху фичи - контроль целостности, несколько циклов выборки, отсутствие циклов выборки, предварительный анализ флагов и создание обработчиков, которые могут их как угодно менять и т.д.
8. Ломать это бывает лениво.
9. Пипл схавает, ибо ничего лучшего за эти деньги на рынке нет.
Мое глубокое убеждение в том, что без качественной обфускации тела самой ВМ ее можно декомпилировать, а следовательно, и взломать. Поэтому обычно тело ВМ чем-нибудь морфят и вообще всячески защищают. От качества морфера зависит очень многое. Большинство морферов работают на уровне одной инструкции, не анализируя графа потока управления в целом (см. п. 9). Зачастую здесь на помощь приходит антиотладка (эвенты, многопоточность и т.д.). Т.е. достаточно старые приемы, никак не обоснованные математически и дающие сомнительную стойкость в сочетании с жуткими тормозами и глюками. Причем, чем больше антиотладки, тем больше этих самых глюков. Замедление 4-5 порядков - это норма для таких ВМ. Часто можно встретить выполнение логических инструкций на базе стрелки Пирса, например, что хорошо конвертируется обратно посредством вбивания шаблона в декомпилятор.
А можно ли создать идеальный обфускатор? Нет, т.к. существует класс подпрограмм, которые, чем ни накрой, не защитишь. Вырожденный случай - программа, распечатывающая сама себя. А можно ли создать хороший обфускатор - такой, чтобы крайне сложно было написать автоматический деобфускатор? Да. Но для этого нужно, как минимум, уметь делать следующее:
1. Отслеживать граф потока данных защищаемой подпрограммы.
2. Распознавать переменные на стеке.
3. Обфусцировать не на уровне одной инструкции, а на уровне всей подпрограммы, а лучше - на уровне программы.
4. Использовать минимальный набор инструкций.
А для того чтобы создать сам механизм обфускации на уровне всей подпрограммы, необходимо неплохо разбираться в математике и криптографии. В частности, методы White-Box криптографии после некоторой модификации вполне подходят и для решения задачи обфускации. Совершенно очевидно, что создание такого обфускатора - более ресурсоемкое занятие. Причем, в целях ограничения размера, код можно и на стековой ВМ интерпретировать - еще уровень защищенности добавится. Т.е. значимость системных программистов в данной работе не отвергает никто. Однозначно можно утверждать, что это работа не для одного человека, а для целой команды. Работу эту делать долго и может встретиться масса подводных камней. Плюс еще есть немаловажный политический момент. К сожалению, очень много специалистов по защите софта таковыми себя только мнят. Любой человек мало-мальски знающий ассемблер, немножко знающий WinAPI и PE-формат, а также умеющий пользоваться IDA и OllyDbg - уже такой специалист. Если он еще и C++ знает, то вообще очень крут :) Вот так, на таком уровне понимания, и пишется подавляющее большинство программных защит. Не удивительно, что и стойкость их невысока, и взламываются они достаточно стандартно. Один такой "эксперт" мне сказал как-то: "Специалисту по защите софта не надо знать математику, ему надо знать что с чем в нужный момент поксорить". О чем можно было говорить дальше? На пути создания хорошего обфускатора стоит еще и вопрос окупаемости, т.к. обфускация в подавляющем большинстве случаев используется для защиты относительно недорогого софта, а протекторы с кучей фич, пусть и в большинстве своем несложно отламываемых, стоят недорого, принося авторам мизерные доходы. Мнение "экспертов" вкупе с непониманием, как извлечь выгоду из столь дорогого в производстве продукта, крайне отрицательно сказываются желании инвесторов полноценно финансировать создание обфускаторов. Таким образом, действительно интересные идейно, но крайне глючные в реализации, продукты создаются энтузиастами и забрасываются на этапе альфа-версий в лучшем случае - либо создаются на инвестиции различного рода секретных ведомств, что сильно ограничивает к ним доступ со стороны простых смертных, да и, в силу ограниченности применения, продукты тоже глючные. В связи с таким положением дел я бы рекомендовал для действительно стойкой защиты софта использовать ключи с загружаемым кодом. Либо, если есть ощущение собственной крутости, не надеяться на протекторы, а писать защиту для своих программ самостоятельно, используя сторонние продукты не более как на вспомогательный инструмент, т.к. производители таких продуктов полагаются, в основном, на п. 9.

Интересное мнение про обфускацию

Наткнулся на subj. Особенно понравилось fuzzy security - как нельзя точно. Вообще говоря, г-н Барак послужил источником вдохновения для целого ряда людей, занимающихся теориями в области обфускации, хотя его доказательство о невозможности обфускации, мягко говоря ... Впрочем, каждый может оценить это самостоятельно.

Последний рабочий день перед отпуском

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

White-Box Cryptography and SPN ciphers. LRC method.

In English now.
http://eprint.iacr.org/2010/419.pdf

White-Box криптография

Переложили проект на ресурс компании "Актив".
Оттуда удобнее скачивать. Кстати, следуя предложенной схемке, можно построить сверхбыструю асимметричную конструкцию - 32 операции xor с 16-и байтовыми числами. И все! Конечно, надо еще смотреть, но было бы прикольно и очень-очень быстро!

Вычисления над зашифрованными данными

Крайне интересная тема. Если кому-то вдруг удастся создать такое, то в этом случае решится целый ряд проблем, связанных с выполнением кода на недоверенных платформах. Действительно, если производить необходимые вычисления над зашифрованными данными (без расшифровки оных), то наличие доступа к этим данным мало что даст злоумышленнику.
Есть в сети две очень интересные работы, посвященные сабжу. Обе доказывают, что теоретически такое возможно, но на практике сейчас это применить не видится реальным. Надо подумать об этом...
http://crypto.stanford.edu/craig/craig-thesis.pdf
http://eprint.iacr.org/2009/616.pdf

White-Box криптография

Известный факт, что асимметричная криптография - это очень медленная штука. В связи с этим в мире достаточно много попыток создать асимметричные схемы, работающие со скоростью блочного шифра. Более того, существуют попытки (пока безуспешные) превратить классические блочные шифры в асимметричные посредством встраивания в их реализацию секретного ключа. Действительно, если бы это удалось, то, имея на руках только алгоритм шифрования, сложно было бы получить алгоритм расшифрования. Полагаю, мне удалось внести свою скромную лепту в эту область. В виду своей лени положил проект в depositfiles. Там же в архиве статья, опубликованная мною на РусКрипто-2010. Вроде как удалось придумать достаточно интересное решение проблемы.

SaaS vs Hardware dongles

Частенько приходится слышать в последнее время о том, что модель SaaS вытеснит электронные ключи и все, кто занимается защитой софта будут каждый день и много раз в день поднимать руку со словами: "Свободная касса". Действительно, вместо того чтобы продавать софт и бояться, что его украдут, люди спокойно положат его к себе на сервер, а клиент через web-интерфейс будет авторизоваться и получать необходимые услуги, если заплатит. Понятно, что при этом электронные ключи станут вовсе не нужны. Прекрасная, глубоко оптимистичная теоретическая модель. Надо отметить, что далеко не новая. Здесь же рядом гнездятся идеи с облачными вычислениями и виртуализацией. Уже идут разговоры об online-ERP, online-бухгалтерии, online-смете и т.д. Да и проекты существуют уже... Но есть смысл иногда спускаться с небес на землю. Я вот, к примеру, пишу эти строки из Калуги, где Интернет стоит относительно немаленьких денег. Дешевый Интернет у нас, как известно, только в Москве и немножко в области, хотя Калуга подтягивается и здесь уже можно начинать жить :) Ну есть еще Питер и ряд городов-миллионников, где стоимость трафика все-таки подороже, чем в Москве. Это во-первых. Во-вторых, качество этого самого Интернета. Даже в Москве бывает так, что его попросту нет - проблемы у провайдера. В-третьих, доступность из произвольных точек - мобильный не очень скор, не очень надежен и не всегда представлен. Что делать если проблема у провайдера? Работа ведь встанет. Итак, первый довод - не всегда дешевый, быстрый и доступный Интернет. Втрой довод - персональные данные. Что-то я как-то сильно с трудом себе представляю, что клиент будет в восторге, когда узнает, что информация, которую он считает конфиденциальной в рамках своей компании, будет храниться на каком-то сервере в какой-то конторе рядышком с базой конкурентов. Да и специфика российского бизнеса такова, что бухгалтерия не совсем белая и пушистая. И совсем непрозрачная. И хранить, и считать что-то не у себя... Вряд ли это будет с восторгом воспринято бизнесом. Можно поставить сервер с софтиной в компании-клиенте, чтобы компьютеры компании-клиента могли обращаться к нему. Но его уже надо защищать или зарабатывать на поддержке, что совсем из другой оперы, и давно живет и существованию донглов не мешает. Плюс к тому, компьютеры компании-клиента должны быть объеденены в единую сеть. А если есть удаленный офис? Доступ к серверу через Интернет? Или по другому каналу? Насколько это дешевле и надежнее, чем раздать людям донглы по 300-700 рублей за штуку и забыть? И главное, идея с сервером в компании-клиенте, на котором крутится софт, тоже далеко не нова, но как-то ключи оно не вытеснило. Очевидно, такие решения все-таки из другого сегмента, в том числе и ценового. Подход SaaS, конечно, очень песпективен, но вряд ли он заменит донглы в близком будущем. Более того, смею предполагать, что и не ударит эта технология по электронным ключам сильно.

Первый пост

Ну вот, это мой первый персональный блог. Здесь буду публиковать то, что, на мой взгляд, является интересным в тех областях, в которых я кручусь. Ну и, конечно, мои личные впечатления от различных событий. Иногда, но достаточно редко, будут появляться сорцы. Впрочем, совсем редко - у меня немного времени для кодирования чего-то для себя. Больше будет ссылок на всякие, на мой взгляд, интересные источники и статьи. Ну и свои статьи тоже буду здесь дублировать по мере их появления. Для первого раза достаточно.