<< Предыдущая

стр. 32
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

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


С появлением новых версий программ, поддерживающих более длинные
ключи, далеко не все пользователи стали использовать новые настройки.
Ведь обновление программного обеспечения не происходит одновременно
у всех пользователей. Значит, если всегда создавать документы с самыми новы-
ми настройками защиты, некоторые пользователи, все еще использующие пре-
дыдущие версии программ, не смогут работать с такими документами. А период
времени, по истечении которого у подавляющего большинства пользовате-
лей будет установлена версия программы, поддерживающая длинные ключи,
иногда исчисляется годами.
В некоторых странах, например во Франции, были свои ограничения, отме-
ненные позже, чем в США, и документы, созданные версиями программ,
которые были предназначены для таких стран, гораздо дольше не защища-
лись длинными ключами.
Ну и, разумеется, далеко не все разработчики после снятия экспортных ог-
раничений (окончательно произошедшего в октябре 2000 года) оперативно
выпустили обновленные версии своих продуктов.
Как следствие всего перечисленного выше, сейчас (на конец 2003 года) до-
кументы, защищенные 40-битовыми ключами, встречаются гораздо чаще,
чем документы, при зашифровании которых использовались более длинные
ключи.
Если рассматривать все форматы представления данных, поддерживающих
защиту шифрованием, то грубо можно выделить три уровня защиты (по
максимальному времени, затрачиваемому на получение расшифрованных
данных).
1. Моментальные — пользователю придется ждать менее минуты.
2. Гарантированные — ключ может быть найден на современной технике за
время, соизмеримое со временем жизни человека.
3. Стойкие — невозможно дать гарантию, что данные когда-либо удастся
расшифровать.
Учитывая развитие вычислительной техники, некоторые зашиты со време-
нем могут переходить в более низкий (по номеру и стойкости) уровень.
На настоящий момент к первому уровню можно отнести защиты, в которых
применяются нестойкие алгоритмы, а также алгоритмы с ключами длиной
до 32 бит. Алгоритмы второго уровня работают с ключами, длина которых
лежит в диапазоне от 32 до 64 бит, хотя даже 56-битовый ключ на персо-
нальном компьютере будет подбираться очень долго.
Несколько лет назад соотношение этих трех уровней было примерно сле-
дующим. Основная масса защит попадала на первый уровень. Правильно
реализованные защиты (использовавшие стойкое шифрование с 40-битовьш
Глава 18. Причины ослабления средств защиты 219

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


18.3. Претензии на универсальность
Идея создания универсальных средств DRM, пригодных для защиты доку-
ментов любых типов, кажется очень соблазнительной, но ее практическая
реализация почти всегда обречена на неудачу.
Так как DRM для защиты не в состоянии обойтись исключительно метода-
ми, имеющими математическое обоснование стойкости, необходимо макси-
мально сократить пространство, в котором защищенные данные присутст-
вуют в расшифрованном виде.
Это сравнительно просто реализовать, если защита встроена непосредствен-
но в программу, воспроизводящую защищенное произведение. Тогда сразу
после проверки прав доступа и расшифрования контент может быть ото-
бражен на экране (или выведен в звуковой тракт) и уничтожен.
Но если предполагается, что защищенный файл может обрабатываться лю-
бой программой и эта программа даже не будет подозревать, что работает
в каких-то особых условиях, путь, проходимый расшифрованной информа-
цией, становится чрезмерно длинным. На этом пути существует огромное
количество мест, из которых расшифрованная информация может быть по-
хищена.
Возможно, в будущем и будет создана система DRM общего назначения,
в которой расшифрованная информация на всем пути до ушей и глаз поль-
зователя окажется надежно защищена от перехвата. Но маловероятно, что
эта система будет построена на базе Windows — уж слишком разнообразны
и сложны происходящие у нее внутри процессы, чтобы их все строго кон-
тролировать. Скорее уж корпорация Microsoft воспользуется патентом
№6330670, выданным ей 11 декабря 2001 года, и реализует на практике
описанную в нем операционную систему со встроенным управлением циф-
ровыми правами (Digital Rights Management Operating System, DRMOS).
220 Часть IV. Основные аспекты защиты данных


18.4. Погоня за прибылью
Наверное, большинство разрабатываемого программного обеспечения —
коммерческое, т. е. создается с целью получения прибыли. И надо всегда
помнить, что хотя и принято считать, что разработчик трудится на благо
пользователей и в своих действиях руководствуется их интересами, на самом
деле это не так.
В интересах разработчика — создать программу, которую будут покупать.
В интересах пользователя — получить программу, которая выполняет тре-
буемые функции. Если пользователь увидит, что программа работает не так,
как ему хочется, он просто не станет покупать такую программу. Это стиму-
лирует разработчика выслушивать и исполнять желания пользователей.
В системах, связанных с защитой, эта схема работает плохо. Так как недос-
татки защиты вскрываются лишь тогда, когда защита будет взломана,
у пользователя нет возможности отказаться от покупки по причине очевид-
ной неработоспособности программы. Следовательно, у разработчика нет
причины изначально создавать надежную защиту.
Вместо этого разработчики предпочитают тратить ресурсы на то, что помо-
гает привлечь пользователей и заставить их покупать программу: на рекла-
му, добавление полупрозрачных окон и озвученных меню. И практика пока-
зывает, что хорошо разрекламированное и раскрашенное, но небезопасное
средство защиты продается гораздо лучше, чем качественно выполненная
защита с простым интерфейсом.
Также достаточно сильным стимулом к выпуску новых версий программ-
ного обеспечения является желание как можно быстрее заполнить новую
рыночную нишу. И, следуя этому желанию, на рынок часто выбрасывается
сырой программный продукт, в котором вопросы защиты не проработаны
до конца — все равно проблемы некоторое время останутся незамеченными.
Разработчик зарабатывает желанные деньги, а за его ошибки, в конечном
счете, будут расплачиваться пользователи.

18.5. Технологические причины
Разработка программного обеспечения давно уже превратилась в отдельную ин-
дустрию, которая живет по своим законам и использует свои технологии. Эти
технологии призваны сократить время разработки, повысить качество готовой
продукции и, в конечном итоге, повысить прибыть от продажи программ.




i
18.5.1. Эффективность разработки
Для обеспечения максимальной производительности труда программистов
при разработке средств защиты применяются те же самые идеи организации
Глава 18. Причины ослабления средств защиты 221

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



18.5.2. Преемственность
Если первая версия программного продукта оказалась более-менее успеш-
ной, то через некоторое время выпускается следующая версия, в которой
исправляются обнаруженные ошибки и добавляются новые функции, при-
думанные разработчиками. И этот процесс может повторяться очень долго,
т. к. почти в любой программе есть что исправить или добавить.
Разумеется, при выпуске каждой новой версии разработчики стремятся ис-
пользовать как можно больше из того, что уже было создано, а не пишут
весь код заново. Со временем это часто приводит к тому, что почти любой
модуль, входящий в состав программы, представляет собой нагромождение
заплаток и надстроек, но вся система в целом является более-менее работо-
способной.
Если защита добавляется в уже спроектированную систему, то функции
безопасности будут реализованы как надстройки над существующими про-
цессами обработки информации. А это редко дает хорошие результаты.
Прежде всего, если программная система изначально не задумывалась для
обработки защищенной информации, то с большой вероятностью никакие
модификации и дополнения не позволят нейтрализовать все недостатки,
присущие базовой системе — проектирование защищенных систем очень
сильно отличается от проектирования обычных программных комплексов.
Кроме того, надстройки почти всегда усложняют систему и, следовательно,
затрудняют анализ происходящих в ней процессов. Но убедиться в том, что
при разработке защиты не было упущено никаких важных моментов, мож-
но, только проведя всесторонний анализ и тестирование защитных функ-
ций. Следовательно, убедиться в стойкости системы защиты будет крайне
трудно.
Однако мало кто из разработчиков решается на полное перепроектирование,
ведь это потребует громадных затрат времени и денег.
222 Часть IV. Основные аспекты защиты данных


18.6. Отсутствие ответственности
Очень серьезным фактором, способствующим появлению многочисленных
программ, не способных правильно выполнять обещанные защитные функ-
ции, является отсутствие ответственности разработчика за ущерб, понесен-
ный пользователем в результате применения программы.
Программная индустрия, наверное, единственная в мире позволяет разра-
ботчикам избегать ответственности за то, что они плохо выполняют свою
работу и не держат данных обещаний.
Сейчас при установке почти любой программы пользователю предоставля-
ется возможность ознакомиться с лицензионным соглашением, в котором
перечисляется все, что пользователю запрещено делать с купленной про-
граммой. И с большой вероятностью в лицензионном соглашении содер-
жится пункт, согласившись с которым, пользователь не сможет предъявить
разработчику никаких претензий. Разумеется, пользователь не обязан со-
глашаться, но тогда он не сможет установить и использовать программу.
С такими условиями распространения обычных программ еще как-то можно
смириться. Но, к сожалению, подобным образом поступают и производите-
ли средств защиты. А если разработчик защиты не несет ответственности за
надежность своих решений, трудно поверить, что пользовательские данные
будут находиться в безопасности.

18.7. Сложность контроля
Современные программные системы имеют весьма сложное внутреннее уст-
ройство. Для того чтобы, имея в распоряжении исполняемые файлы, полу-
чить определенную информацию о происходящих внутри них процессах,
требуется провести весьма сложный и дорогостоящий анализ. Но для про-
стых программ такой анализ обычно и не требуется — по результатам рабо-
ты довольно просто можно оценить, насколько хорошо реализованы те или
иные функции.
Однако с защитой, как обычно, все иначе. Качество защиты невозможно
оценить по внешним признакам. Значит, требуется выполнение анализа.
Но рядовой пользователь не сможет самостоятельно выполнить такой анализ
и оценить его результаты. Следовательно, придется нанимать высококвали-
фицированного специалиста, способного выполнить подобную работу и,
разумеется, оплатить его услуги. А это могут себе позволить далеко не все.
Вот и получается, что контроль реализации защитных функций приобретае-
мого продукта почти никогда не производится. А вспомнив перечисленные
ранее технологические и экономические причины, а также отсутствие ответ-
ственности, становится совершенно понятно, почему так часто приходится
слышать о взломе той или иной защиты.
Часть V

ЗАМЕТКИ ОБ ИССЛЕДОВАНИЯХ
СРЕДСТВ ЗАЩИТЫ

Глава 19. Кому это нужно

Глава 20. Интернет — кладезь информации

Глава 21. Инструментарий исследователя

Глава 22. Реконструкция криптографических
протоколов

Глава 23. Чего ожидать в будущем
224 Часть V. Заметки об исследованиях средств защиты


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


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


19.1. Время создавать защиту
За разработку своей защиты имеет смысл браться в трех случаях, когда:
О система защиты разрабатывается как коммерческий проект;
• существующие средства защиты не способны обеспечить необходимую
функциональность;
П существующие средства защиты не подходят по соображениям безопас-
ности.
Первый случай, когда защита разрабатывается с целью извлечения прибыли,
особого интереса не представляет — это обыкновенный коммерческий про-
ект, в котором обеспечение надежности защиты вполне может не играть ни-
какой роли. Единственная цель разработчика — извлечь максимум прибыли.
Во втором случае пользователю необходимо защищать информацию в неко-
торых уникальных условиях, для которых ни одна из существующих систем
не была предназначена. Подобные ситуации появляются регулярно как пря-
мое следствие развития технологий. Пока не было дисков, пригодных для

<< Предыдущая

стр. 32
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>