 |
||||||
 |
 |
|||||
 |
|
 |
|
 |
 |
 |
|
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
Читая журналисткие работы Киви Бёрда, неоднократно замечал, как экстраполируя современную ситуацию на недалёкое будущее, он приводит сюжет Minority Report, весьма хорошего фильма Спилберга (особенно если закрыть глаза на некоторые косяки, которых, впрочем, в любом голливудском кине навалом), в качестве своеобразного "ориентира" высокотехнологичной политики и политики безопасности. Возможно, будет небезынтересен ещё один такой "ориентир", к которому движемся (или нас стараются двигать) в ногу ровным маршем. Тем, кто не имеет предубеждений против японского анимэ, советую взглянуть на сериал (именно сериал, поскольку есть ещё несколько одноимённых полнометражных анимационных фильмов) Ghost In The Shell Standalone Complex, "Призрак в доспехе. Синдром одиночки". (Ещё встречался перевод "автономный комплекс", но это дословный перевод с английского, контекстуально неверный.) Сериал состоит из двух сезонов по 26 связанных эпизодов, продолжительность каждого эпизода 25 минут. Действие происходит в 30-е годы XXI века, в основном на территории Японии. Несмотря на несколько минувших мировых войн (а во многом и благодаря им) информационные и кибернетические технологии развились до такой степени, что значительная часть мирового населения с ранних лет оснащается т.н. кибермозгом, включающим вычислительные и запоминающие устройства, машинно-мозговой интерфейс, средства беспроводной связи, короче, вполне себе полноценным компьютером. Нередки и другие кибернетические расширения типа усиленных искусственных конечностей. Но, как несложно догадаться, этот "дивный новый мир" в плане инфобезопасности мало чем отличается от положения сегодняшних дней (иное было бы по меньшей мере неубедительно :-). Более того, человек, не владеющий "чёрной магией" ИТ, не отделается уже одним лишь затрояненным ПК, присоединённым к бот-сети для рассылки спама, или обчищенным электронным счётом: теперь взломают его собственный мозг или, того хуже, его "призрак", саму душу. А последствия -- от использования вычислительных ресурсов кибермозга в личных целях взломщика, до слежки за человеком с помощью его собственных глаз или убеждения говорить и делать навязанные ему вещи. Ну, и, конечно, все прочие атрибуты современного общества тоже на местах: коррупция, ксенофобия, экономический спад, слияние бизнеса, организованной преступности и властных структур, монополии на рынке СМИ, тотальная слежка, видимая свобода демократического общества, прикрывающая цензуру и бесследные исчезновения людей. Главные персонажи -- сотрудники 9 отдела Полиции общественной безопасности Японии, особого элитарного военизированного подразделения, расследующего высокотехнологичные преступления, случаи терроризма и выполняющего разную "скользкую" работёнку типа политических убийств. Как зачастую бывает в анимэ и в жизни, мир не делится чётко на чёрное и белое, на хороших и плохих, героев и антигероев. И хотя главные персонажи обычно действуют во имя высоких целей и собственных идеалов, методы порой бывают чудовищны. Из разряда "Добро обязательно победит зло!.. поставит его на колени... и зверски убьёт". Этой краткой рецензией даю свою рекомендацию. Если не воспринимаете просмотр анимэ за признак инфантилизма и ещё не смотрели этот фильм, обязательно сделайте это -- о затраченном времени не пожалеете. Да, что любопытно: во вселенной сериала нынешние США больше не являются Соединёнными Штатами Америки, а стали Американской Империей (АНБ, правда, никуда не делось). Вполне в духе текущих тенденций. :-) |
Учитывая их крупный размер и бережное обращение с ними, я решил их не заменять, а переподписать с новой датой окончания действия. Продлить, в общем. Что и было сделано. Обновлённую копию загрузил на серверы ключей. А пару дней назад выясняется, что на всех серверах ключей лежат неработоспособные копии моего ключа -- корреспондент, желавший мне написать, не смог зашифровать сообщение. Вскрытие показало, что на всех серверах ключей подключи моего ключа не были пролонгированы и продолжают значиться как истекшие. Судя по всему, серверы во избежание "замусоривания" своих баз просто срезали с подключей "дубликатные" автоподписи, даже не проверив их срок службы. Что интересно, эта особенность характерна только для автоподписей подключей и не затрагивает автоподписи на базовом ключе (переподписание ключа с новым сроком службы -- давно устоявшаяся практика продления действия ключа). Короче, если ключ, взятый вами с сервера, отказывается работать, обновите копию из "официального источника". |
Попытавшись разобраться в причинах, я пришёл к заключению, что депрессию нагоняет нынешний вид кода. Вака, изначально имевшая не слишком опрятный код, разрастаясь в openSpace стала довольно удручающим зрелищем. Ядро программы совершенно не разбито на модули, код местами крайне запутан, расширять его становится всё труднее, многие из последних изменений напоминают какие-то костыли. И хотя задача по рефакторингу кода была поставлена на этап pre-1.0, стало ясно, что, не занявшись рефакторингом сейчас, туда мы просто не доберёмся. Короче, "мы новый мир построим". В новогодние каникулы я начну писать openSpace с нуля. Разработка будет вестись в расчёте на PHP 5 с упором на модульность, компартментацию кода и его безопасность (никаких больше вызовов GnuPG через странного вида Perl-обёртки). Часть процедур, которые и сейчас имеют разумный вид, будут заимствованы с минимальными изменениями или вообще без них. Возможно, коснусь и структуры БД: сейчас она не оптимальна ни по объёму, ни по скорости, но я пока не имею чёткого плана её универсальной оптимизации. В процессе UTF-8 будет сделана основной и единственной кодировкой программы. Ждать скорого выхода openSpace 2.0 не стоит. Скорее всего, доведение кода до сколь-нибудь вразумительного состояния займёт не менее полугода. [Добавлено]: К сожалению, не удалось найти время, чтобы к сроку упаковать дистрибутив 0.8.24a. Если ничего не стрясётся, выпущу его в понедельник. |
|
Как бы то ни было, но некоторым умельцам удалось извлечь шифровальные ключи из программных плееров, а последним ударом для AACS стало восстановление т.н. ключа обработки (processing key), позволяющего фактически снимать защиту со всех выпущенных на сегодня дисков с видео высокой чёткости. 128-битовый криптографический ключ начал растекаться по Сети. В ответ на это, AACS Licensing Authority (AACS LA), организация, ответственная за поддержку системы защиты, называя ключ "технологией обхода защиты" (circumvention technology), накануне разослала администраторам веб-сайтов, разместивших 32-байтовый код (в том числе и Digg.com, оказавшийся просто заваленным комментариями и ссылками с ключом обработки), официальные требования удалить информацию со своих страниц под угрозой судебного преследования по нормам DMCA. Но, судя по всему, джинна уже выпустили из бутылки... 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Предлагаю всем внести свою лепту в борьбу с претеснениями и абсурдным приравниванием криптоключа к технологии обхода DRM-защиты. Размещайте эти цифры в Сети, сообщайте их всем, печатайте их на футболках. Не позволим поставить большие числа вне закона! |
Тематика OLPC получила значительное внимание мировой прессы, поэтому я не стану рассматривать концепцию проекта в целом (интересующихся адресую, например, к недавней статье в Компьютерре), а сосредоточусь на, пожалуй, более интересном для читателей предмете: подсистеме безопасности детских компьютеров, получившей название BitFrost. Складывается впечатление, что разработчикам удалось создать одну из первых исключительно защищённых систем, при этом не накладывающей практически никаких ограничений на пользовательские характеристики операционной системы и ПО. На меньшее они и не могли пойти, ведь одна из главных целей OLPC -- позволить детям (даже больше: подвигать, провоцировать их) модифицировать, дорабатывать и перерабатывать свои системы, которые, в то же время, не должны приходить в негодность, если пользователь сделал что-нибудь не так или стал жертвой внешней атаки. К сожалению, цель была достигнута за счет несовместимости с существующим ПО. Наиболее распространённая сегодня концепция безопасности восходит своими корнями к первым UNIX-системам. Каждый файл там имел владельца и подчинялся набору правил доступа, определявших, кто мог читать его, изменять или исполнять (владелец мог делать всё). С незначительными различиями от ОС к ОС эта идея сохраняется поныне. Однако то, что было рационально и достаточно более 30 лет назад в досетевую эпоху, уже не является таковым в сегодняшнем объединённом мире. Проблема в том, что в большинстве случаев исполняемое приложение обладает тем же объёмом привилегий, как и сам исполняющий его пользователь: если пользователь запустит вредоносную или просто небезопасную программу (сознательно или даже под влиянием социальной инженерии, что особенно реально для целевой аудитории OLPC), это может поставить под угрозу все его данные просто потому, что программа способна делать всё, что угодно, стоит лишь её запустить. Исключение составляют разве что программы, исполняемые в ограниченной среде виртуальных машин, "песочниц". Разработчики BitFrost и XO (операционной системы ноутбука) взяли за основу именно идею "песочницы". Запускаемая программа не получает автоматический доступ ко всем ресурсам системы, а только к тем, которые она запросила в момент установки (что предотвращает ущерб от последующей эксплуатации "дырявой" программы другим приложением). Хитрость в том, что программа (особенно программа злонамеренная) не может затребовать все ресурсы разом -- ряд прав доступа являются взаимоисключающими, и авторы прибегли к серьёзному анализу, чтобы одновременно обеспечить безопасность системы и работоспособность программ (которые могут писать и сами дети). Таким образом, если, к примеру, пользователь устанавливает программу-плеер, ей будет предоставлен read-only-доступ ко всем музыкальным файлам в системе (и только к файлам этого типа), однако, программа не сможет вместе с этим запросить доступ к сетевому интерфейсу. В обычных условиях программа имеет доступ только к собственным файлам приложения и временных файлов: всё ПО запускается в своей chroot-директории и не "видит" ничего вне её пределов (необходимые библиотеки мэппятся внутрь директории). Программы не могут работать с пользовательскими файлами напрямую. Вместо этого они полагаются на объектно-ориентированный интерфейс хранилища данных. Иными словами, программа не может использовать системные вызовы read()/write() для доступа к произвольным файлам, не может даже просмотреть список файлов ребёнка (за исключением случая, когда программе требуется доступ к файлам определённого типа на чтение, что было описано выше). Если программе нужно открыть определённый пользовательский файл, она делает запрос к центру безопасности XO, который, в свою очередь, выводит на экран диалоговое окно открытия файла. Когда пользователь выбирает файл, система делает его копию-на-запись в директорию временных данных программы и передаёт программе путь к файлу внутри chroot-директории. В итоге, файл как бы появляется в доступном для программы пространстве, но даже если будет удалён программой, можно будет восстановить его из исходной копии. Аналогичная концепция опосредованного доступа к определённым ресурсам применяется и в других ситуациях. Например, программа, даже запросившая доступ к веб-камере при инсталляции, не сможет активировать её самостоятельно -- это бы представляло угрозу приватности. Вместо этого программа передаст запрос к центру безопасности XO, а уже это доверенное приложение спросит пользователя, разрешить ли программе сделать это. В то же время, разработчики старались насколько это возможно минимизировать число различных запросов к пользователю (ведь зачастую ребёнок не способен сделать обдуманный рациональный выбор относительно собственной безопасности и целостности ПК): любое недопустимое действие должно просто блокироваться системой. Здесь были приведены лишь несколько значимых элементов BitFrost. Всем заинтересованным читателям рекомендую обратиться к спецификациям системы, где она описана в больших деталях, не перегруженных техническими подробностями (разработчики планируют выпустить техническую документацию позднее). Это исключительно интересная концепция, которая с неизбежностью будет реализована в других системах, по крайней мере частично. А что касается проекта OLPC, то подозреваю, что будущие обладатели этих ноутбуков, повзрослев, ещё дадут фору своим сверстникам из более благополучных стран. |
Ключ 0x8443620A уже доступен на этом сайте и в базах основных депозитариев интернета; за две-три недели он должен обойти всю сеть pgp.net. Новый ключ имеет перекрёстные подписи с прежним, что должно упростить вам (если вы мой постоянный корреспондент) установление его подлинности. Базовый ключ подписи -- это RSA v4 4096 бит с неограниченным сроком. Основное же отличие схемы нового ключа в том, что среднесрочные (на один год) подключи теперь будут применяться как для шифрования, так и для подписи данных, а базовый ключ, хранящийся отдельно и особо безопасным образом, будет использоваться исключительно в целях сертификации. Такая схема сломает совместимость с некоторыми ранними версиями ПО, впрочем, большинство пользователей уже переключились на PGP 9 и GnuPG 1.4.x, что должно сгладить этот недостаток. Если же трудности возникнут у слишком многих, я добавлю ещё один временный подключ к прежнему открытому ключу и продлю его жизнь до будущего лета. Затем ключ 0x4D8BB49E будет аннулирован и, вероятно, удалён. |
Читатели моего блога достаточно компетентны в сетевых технологиях, но всё-таки для начала приведу пару слов о принципах действия динамических веб-сайтов. Когда вы открываете подобный сайт (скажем, интернет-магазин), он автоматически присваивает вам случайный номер, называемый идентификатором сессии (этот номер сохраняется в cookie браузера и передаётся сайту при открытии каждой страницы). Он служит как опознавательный знак для веб-сайта, дабы он мог отличать вас, когда вы переходите от страницы к странице, и на каждой странице отображать, к примеру, ваше персональное меню или корзину с покупками, выбранными ранее. Вся эта информация -- персональное меню, покупки -- размещается на диске сервера во временном файле, одноимённом с номером сессии. К сожалению, за всем этим удобством скрывается угроза безопасности: если злоумышленник сумеет тем или иным образом узнать номер вашей текущей сессии, он сможет передать его с собственного компьютера и эффективно выдать себя за вас и, как следствие, получить доступ ко всем вашим приватным данным на данном веб-сайте. В заключение отмечу, что однажды присвоенная сессия действует не вечно: если вы не проявляете активность на сайте в течение некоторого времени (обычно, часа), она аннулируется; однако файл сессии может быть удалён очень нескоро! Итак, возвращаемся к поставленной задаче. Поскольку при авторизации на сайте пароль открыто передаётся через Сеть, наблюдателю на канале связи ничего не стоит перехватить его, чтобы в дальнейшем входить на сайт под именем легитимного пользователя. Таким образом, цели, преследуемые в данной работе: - защита от пассивных атак, т.е. простого прослушивания трафика между пользователем и сайтом с целью перехвата пароля; - защита от активных атак, т.е. более открытых действий злоумышленника, направленных, к примеру, на захват текущей авторизованной сессии. Перед потенциальным злоумышленником также стоят две альтернативные цели: - задача-минимум: захватить сессию легитимного пользователя; - задача-максимум: раскрыть пароль пользователя. Наиболее элегантное и простое решение здесь -- SSL, обеспечивающий шифрование всего трафика между пользователем и сайтом на транспортном уровне, а также аутентификацию сайта. Как уже отмечалось, это сравнительно дорого... Альтернатива На этапе аутентификации пользователя для входа на сайт можно применить простой протокол "запрос-ответ", не раскрывающий пароль на канале связи. Для этого потребуется реализовать миниатюрное приложение на javascript, обеспечивающее необходимые преобразования на стороне пользователя. Как часто бывает в таких описаниях, роль пользователя выполнит Анна, а сервера -- Борис; числовые индексы переменных обозначают номер этапа, значение которого принимает переменная. Протокол может выглядеть так: 1) Анна инициирует начало протокола (для этого ей нужно открыть страницу с формой для ввода имени и пароля). Вместе с этим, Борис определяет IP-адрес Анны (который ещё пригодится), а также присваивает ей (передаёт) идентификатор неавторизованной гостевой сессии -- sid. 2) Далее Борис генерирует и отправляет Анне r = H(k,t1,ip1), где H -- операция хэширования, k -- секретный показатель, известный только Борису, t1 -- метка времени начала исполнения протокола, ip1 -- IP-адрес Анны, определённый на этапе 1. Кроме того, Борис сохраняет ip1 и t1 в переменных сессии Анны.3) Анна вычисляет h = H(r,u,p), где u и p -- её логин и пароль, соответственно.4) Анна возвращает Борису h,u,sid1 5) Время поступления ответа на этапе 4 сравнивается с меткой времени, сохранённой на этапе 2. Если ответ получен в допустимом интервале, исполнение протокола продолжается. 6) Борис по u извлекает из базы данных пароль Анны p. 7) Борис самостоятельно вычисляет h' = H( H(k,t1,ip4), u4, p6) 8) Борис сравнивает h, полученный от Анны на этапе 4, с h', вычисленный им самим на этапе 7. 9) При их соответствии Борис генерирует новый идентификатор авторизованной сессии sid', помещает ip4 в переменные сессии и сообщает sid' Анне. Векторы атак Попробуем атаковать протокол с различных направлений. В роли пользователя снова выступит Анна, сервером будет Борис, Николай -- пассивным наблюдателем, Виктор -- активным взломщиком. На начальном этапе Николай, находясь на канале связи между Борисом и Анной, может определить идентификатор сессии, присвоенный Анне. Это не даёт ему преимуществ, поскольку пока это сессия неавторизованного гостя, не обладающего привилегиями. Этап 2, опять же, не сообщает Николаю ничего полезного. Хотя он знает IP Анны и может угадать метку времени, он не имеет представления о секретном ключе Бориса, используемом для имитозащиты передаваемых данных. Когда на этапе 4 Анна возвращает свои подсчёты серверу, Николай видит лишь очередной хэш, не несущий информации о пароле. Хотя ему известны и значение r (перехваченное на этапе 2), и логин Анны, он никогда не видел её пароль, так что его восстановление из h равносильно (в идеале) полному перебору результата функции хэширования. Получается, что у Николая не слишком много шансов определить пароль Анны, и наша основная задача -- скрыть пароль на канале связи -- выполнена. Но может быть взлом удастся более смелому Виктору, обладающему также более серьёзными ресурсами для нападения? У него есть несколько вариантов. Например, он мог бы попытаться подделать значение h, передаваемое на этапе 4, но, не зная пароль Анны, это бесперспективно -- Борис выявит расхождения в пересчитанном h' на восьмом этапе. Виктор мог бы вклиниться в протокол на этапе 9 и перехватить идентификатор авторизованной сессии. Однако если Анна включила в настройках openSpace привязку сессии к IP, такая смена адреса (поскольку легитимный адрес Анны Борис сохранил в переменных сессии) тут же приведёт к инвалидации сессии. Казалось бы, вариантов нет. Но вместо всего этого шаманства Виктор пойдёт самым простым путём, известным как "атака гроссмейстера". Расположив свой компьютер на канале связи между Борисом и Анной, он атакует протокол с самого первого этапа. Когда Анна запрашивает с сайта страницу логина (инициирует протокол), Виктор перехватывает запрос и пересылает его от своего имени (т.е. со своего IP). В результате Борис назначает Виктору гостевой идентификатор sid Анны. Виктор, притворившись Борисом, пересылает идентичные данные от себя к Анне (запрошенную страницу и sid). Анна вычисляет ответ на запрос Бориса и возвращает его наряду с остальными данными. Виктор вновь пассивно ретранслирует эту информацию Борису. Тот проверяет правильность ответа, используя IP, хранящийся в сессии и убеждается в том, что ответ получен он Анны, ведь пароль должна была знать только она. Следовательно, Борис создаёт авторизованную сессию и возвращает её номер источнику запроса -- Виктору! Здесь нет возможности определить, что источник не тот, за кого себя выдаёт; и даже после авторизации сессия не будет прервана, поскольку IP источника (Виктора) идентичен на всех этапах протокола. Чтобы успешно завершить нападение Виктор лишь должен вернуть Анне от имени Бориса какую-нибудь стандартную ошибку HTTP и прервать связь, чтобы она списала всё это на проблемы с сервером. Контрзащита К сожалению, я не вижу иного пути улучшить этот протокол, кроме следующего: 1) Анна инициирует исполнение протокола. Борис узнаёт её IP и присваивает ей гостевой sid. 2) Борис посылает r = H(k,t1) 3) Анна вычисляет и возвращает Борису h = H(r,u,p,ip), u, sid1, где ip -- известный ей самой IP-адрес её машины.4) Борис по u извлекает из базы данных пароль Анны p. 5) Борис вычисляет h' = H( H(k,t1), u3, p4, ip3), используя для ip3 источник ответа, полученного на этапе 3.6) Борис сравнивает h и h', при соответствии которых помещает ip3 в переменные новой авторизованной сессии, а её идентификатор возвращает Анне. Что будет, если и теперь Виктор попытается транслировать сообщения между участниками протокола, а в конце захватить авторизованную сессию? На этапе 3 он перехватывает значение h. Не зная пароля Анны он не может изменить его, поэтому передаёт Борису в исходном виде. Разумеется, Борис получает IP Виктора в качестве источника ответа и использует этот IP на этапе 5, повторно вычисляя хэш. В итоге, на этапе 6 Борис обнаруживает расхождения и прерывает протокол. Проблема здесь в том, что для данного протокола любой посредник -- будь то легитимный прокси, NAT или исходящий узел сети Tor -- также расценивается нападающим. В этом случае можно, к примеру, предоставить Анне самостоятельно указать на третьем этапе IP, соединение с которого Борис примет. В общем, это просто тренировка для ума, и весьма маловероятно, что подобное будет реализовано на практике. Но всё же, какие ещё есть недостатки или потенциал для улучшения? |
Самую лучшую иллюстрацию этой концепции опубликовал на днях Иан Григг. Сравните сами влияние режима шифрования на сокрытие исходного изображения (первая картинка) при использовании ECB (вторая картинка, каждый блок шифртекста назависим от других) и CBC (третья картинка, каждый последующий блок зависит от результата объединения всех предыдущих блоков). |
|
 |
