...
Примечание
Этот закон используется в главе 6.
Закон 8. Без ключа у вас не шифрование, а кодирование
Это универсальный закон – никаких исключений. Только убедитесь, действительно ли используются ключи и насколько хорошо организовано управление ими. Очень похожее мнение высказывает Скотт Кулп (Scott Culp) в своем законе № 7 "Безопасность зашифрованных данных определяется безопасностью ключа их расшифровки".
Ключ при шифровании используется для обеспечения уникальности результатов в условиях, когда каждый использует тот же самый небольшой набор алгоритмов. Разработать хороший криптографический алгоритм трудно, поэтому только небольшая их часть используется во многих различных приложениях. Необходимость в новых криптографических алгоритмах появляется нечасто потому, что известные сейчас алгоритмы могут использоваться во многих областях (подпись сообщения, блочное шифрование и т. д.). Если хорошо известный (и предсказуемый) тип атаки методом грубой силы занимает много времени, то нет достаточных причин для замены криптоалгоритма. Уже было написано, что не следует полностью доверять новым криптографическим алгоритмам.
В ранней истории криптографии большинство схем зависели от взаимодействующих сторон, использующих ту же самую систему скремблирования (скремблирование – шифрование путем перестановки и инвертирования групп символов) посылаемых друг другу сообщений. Ключ или разновидность ключевой фразы (pass-phrase) обычно не использовались. Двум сторонам нужно было договориться о схеме преобразования, например о замене каждой на букву, находящуюся в алфавите на три позиции дальше, чем заменяемая, и они могли посылать сообщения.
Позже начали использовать более сложные системы. Результат преобразования сообщения с их помощью зависел от слова или фразы, устанавливающих начальное состояние процесса преобразования сообщений. Такие системы были широко известны. Они позволяли обмениваться сообщениями со многими сторонами и обеспечивали определенную безопасность при условии использования различных фраз.
Рассмотренные два типа систем позволяют лучше увидеть концептуальное различие между кодированием и шифрованием. При кодировании ключ не используется, и если вовлеченные в обмен информацией стороны хотят обеспечить секретность, то их схема кодирования должна быть секретной. При шифровании используется ключ (или ключи), который обе стороны должны знать. Алгоритм шифрования может быть известен, но если у злоумышленника нет ключей, знание алгоритма ему не поможет.
Конечно, проблема состоит в том, что схемы кодирования редко удается сохранить в тайне. Перед обменом каждый получит копию алгоритма. Если ключ не использовался, то каждый, получивший копию программы, сможет расшифровать все зашифрованное этой программой. Это не сулило ничего хорошего массовому рынку криптографических средств. Использование ключа позволяет применять известные хорошие алгоритмы во многих приложениях. Что вы сделаете, когда столкнетесь с криптографическим средством, о котором известно, что в нем используется тройное DES-шифрование, но вводить пароли не нужно? Бегите прочь! Возможность расшифровки сообщений, зашифрованных DES и его разновидностями (подобно 3DES), зависит от секретности ключа. Если ключ известен, то тайны могут быть расшифрованы. Откуда средство берет ключ для работы, если не от пользователя? Откуда-то с жесткого диска компьютера.
Этот вариант лучше использования слабого алгоритма? Вероятно, это слегка лучше, если зашифрованные файлы предназначены для переноса на другой компьютер, например через сеть. Если их перехватят вне компьютера, то они могут остаться в безопасности. Однако если модель угрозы включает людей, имеющих непосредственный доступ к компьютеру, то ситуация сильно меняется, поскольку они могут завладеть ключами. Криптографы хорошо поднаторели в определении схем кодирования и расшифровки сообщений. Если вы говорите о встроенной в продукт массового рынка схеме кодирования, забудьте о возможности сохранения в тайне алгоритма ее работы. У злоумышленника будут все необходимые возможности для определения схемы кодирования.
Если вы столкнетесь с системой, про которую говорят, что она шифрует коммуникации и при этом, кажется, ей не нужно обмениваться ключами, хорошо подумайте над этим. Задайте производителю побольше вопросов о том, как именно она работает. Вспомните все, что ранее говорилось о надежном обмене ключами. Если ваш производитель замалчивает вопросы обмена ключевой информацией и не может досконально объяснить детали точного решения проблемы обмена ключами, то, вероятнее всего, вы встретили небезопасное средство. В большинстве случаев для вас должна быть нормой необходимость иметь программные ключи в различных конечных точках коммуникаций.
...
Примечание
Этот закон используется в главах 6 и 10.
Закон 9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем
Это утверждение о паролях в особенности относится к программам, которые в той или иной форме хранят пароль на компьютере клиента в архитектуре клиент-сервер. Помните, что клиентская машина всегда полностью контролируется работающим на ней пользователем. Поэтому в общем случае нельзя гарантировать безопасное хранение информации на клиентском рабочем месте. Как правило, сервер отличается тем, что пользователь-злоумышленник вынужден взаимодействовать с сервером при помощи сетевых средств через, скорее всего, ограниченный интерфейс. Допускается единственное исключение из правила о недопущении хранения информации на уязвимой машине клиента: хранимая информация должна быть зашифрованной. Этот закон – фактически специфический вариант предыдущего: "Без ключа у вас не шифрование, а кодирование". Ясно, что это относится к паролям, поскольку они специфический вариант информации. О паролях говорится отдельно, потому что в приложениях безопасности они часто заслуживают специального внимания. Каждый раз, когда приложение запрашивает у вас пароль, вам следует задуматься: "Каким образом пароль будет сохранен?" Некоторые программы не хранят пароль после его использования, потому что они больше не нуждаются в нем. По крайней мере, до следующего раза. Например, многие Telnet– и ftp-клиенты вообще не запоминают пароли. Они сразу передают их серверу. Другие программы предложат "вспомнить" ваш пароль. Они могут предложить щелкнуть на иконке вместо ввода пароля.
Насколько надежно эти программы хранят ваш пароль? Оказалось, что в большинстве случаев они не могут надежно хранить ваш пароль. Согласно предыдущему закону, поскольку преобразование выполнялось без использования ключа, то все, что они могут сделать, – это закодировать пароль. Это может быть очень сложный алгоритм кодирования, тем не менее это кодировка, потому что у программы должна быть возможность расшифровки пароля для последующего использования. Если программа сможет это сделать, то сможет и кто-то еще.
Данный факт также универсален, хотя могут быть очевидные исключения. Например, Windows предложит вам сохранить пароли для доступа по телефонной линии dial-up. Вы щелкаете на иконке и регистрируетесь у вашего Интернет-провайдера. Судя по всему, ваш пароль хранится где-нибудь на жестком диске в закодированном виде и его можно декодировать, правильно? Не обязательно. Майкрософт разработал процедуру сохранения этого пароля во время регистрации пользователя Windows. (Регистрация – процедура идентификации пользователя при вхождении в компьютерную систему.) Если у вас есть такой сохраненный пароль, пробуйте щелкнуть на кнопке "Отмена" вместо ввода вашего пароля регистрации во время загрузки Windows. Вы найдете, что ваш сохраненный пароль для доступа по телефонной линии недоступен, потому что Windows использует пароль регистрации для разблокировки пароля доступа по телефонной линии. Все необходимое для выполнения этих операций хранится в файле с расширением. pwl в директории Windows.
Иногда, по ряду причин, программное обеспечение захочет сохранить нужную ему информацию на машине клиента. Например, Web-браузеры сохраняют файлы cookies (в системах с удаленным доступом – пароль, порождаемый сервером при первом подключении и отсылаемый пользователю; при последующих подключениях пользователь должен предоставлять серверу этот пароль) и, иногда, пароли. (Последние версии браузера Internet Explorer предложат запомнить ваши имена и пароли.) Программы, которые для доступа к серверу используют компоненту идентификации, типа Telnet-клиентов и программ чтения почты, также часто сохраняют пароль. С какой целью сохраняются ваши пароли? Для того, чтобы вы не должны были вводить их каждый раз.
Очевидно, что включение в программы такой возможности не является хорошей идеей. Если на вашей машине есть иконка, просто щелкнув на которую, вы получаете доступ к серверу, и при этом серверу автоматически передаются ваше имя и пароль, то любой подошедший может сделать то же самое. С точки зрения безопасности, можно ли было сделать что-нибудь худшее, чем это? Как мы увидим, да.
Давайте рассмотрим пример клиента электронной почты, который услужливо помнит за вас ваш пароль. Вы делаете ошибку, оставляя на мгновение злоумышленника наедине с вашим компьютером. Что он может сделать? Ясно, что он может легко прочитать вашу почту и получить постоянный доступ к ней. Поскольку в большинстве случаев пароли почты передаются открыто (и давайте предположим, что в нашем случае это так и есть), то если у злоумышленника есть программа "захвата пакетов" (packet capture program), он мог бы быстро загрузить ее на ваш компьютер. Или если у него был бы наготове портативный компьютер (laptop), он смог бы переписать ваши пароли. Это лучше, чем типичная мониторинговая атака, так как у него есть возможность заставить ваш компьютер переслать кому-либо ваш пароль по его желанию.
Однако у него может не быть времени для таких сложных приготовлений. Тогда он может незаметно вынуть дискету из-за пазухи и скопировать файл. Возможно, вместо этого злоумышленник смог бы переслать файл через сеть, если был бы уверен, что не будет где-нибудь зарегистрирован в системном журнале и обнаружен. Конечно, предварительно ему следовало бы знать, на какой файл или на какие файлы обратить внимание. Это потребовало бы дополнительной подготовки или исследования. Злоумышленник должен был бы знать, какую почтовую программу вы обычно используете. Но если он находится в вашем офисе, то у него хорошие шансы обменяться с вами почтой, а каждое электронное письмо, которое вы посылаете злоумышленнику, сообщает ему в заголовке, какую программу электронной почты вы используете.
Что содержится в украденном злоумышленником файле? Ваш сохраненный пароль, конечно. Некоторые программы сохраняют пароль в явном виде, позволяя злоумышленнику прочитать его непосредственно. Это плохо с точки зрения безопасности, и, как будет видно дальше, подобные программы незатейливо просты. В этом случае вы должны попробовать отключить любые возможности программы, позволяющие локализовать место хранения пароля, если это возможно.
Если при просмотре файла ничто не напоминает пароль, то можно найти копию такой же почтовой программы, воспользоваться вашим файлом и щелкнуть на кнопке "Соединить". У злоумышленника появилась возможность получать вашу почту. Если он все еще не удовлетворил своей любознательности, то теперь он может организовать перехват пакетов и на досуге найти пароль. Но, возможно, есть причина, по которой злоумышленник не хочет (или не может) щелкнуть на кнопке "Соединить" и наблюдать за мгновенной передачей пароля. Возможно, злоумышленник не может добраться до сервера в данный момент, потому что сервер находится в защищенной сети. Вероятно, вы использовали протокол, который не посылает пароль в явном виде.
Подумайте над следующим: без всякой помощи ваша почтовая программа знает, как расшифровать пароль и отослать его (или некоторую его форму). Как она это делает? Очевидно, она знает что-то, что не знает злоумышленник, по крайней мере сейчас. Программа или знает алгоритм раскодировки, который является одинаковым для каждой копии этой программы, или знает секретный ключ расшифровки пароля, который должен храниться на вашем компьютере.
В любом случае, если действительно украдены правильный файл или файлы, то у злоумышленника есть все для определения вашего пароля даже без попытки использовать его. Если это простое декодирование, то можно определить алгоритм с использованием эксперимента и догадки или дизассемблировать часть программы, реализующей этот алгоритм и определить его. На это может потребоваться время, но при известной настойчивости есть все для его определения. Затем ваш секрет может быть рассказан остальным, чтобы каждый смог это легко сделать.
Если программа действительно использует шифрование, то в случае кражи нужного файла или файлов и это не является гарантией безопасности. Ведь если программа может расшифровать пароль, а все действия злоумышленника по его раскодировке ни к чему не привели, то ясно, что программа где-нибудь должна хранить ключ расшифровки. Злоумышленнику следует только удостовериться в том, что файл ключа расшифровки тоже украден.
Разве программа не могла потребовать, чтобы законный пользователь помнил ключ расшифровки? Могла, но тогда почему пароль клиента запоминается в первую очередь? Только для того, чтобы пользователь не вводил пароль постоянно.
...
Примечание
Этот закон используется в главе 6.
...
Приоткрывая завесу
Будьте бдительны!
Недавно усилился интерес к обсуждению совершенных атак для выяснения причин быстрого распространения злонамеренного программного кода и увеличения числа нападений. К счастью, большинство атак ориентировано на использование уже известных уязвимостей операционных систем и программ приложений. Например, в этом году многие атаки вируса Code Red и его модификаций были нацелены на уязвимости атакованных программных средств, известные в течение длительного времени. Грустно сознавать (и это смущает как с профессиональной, так и с личной точки зрения), что целый ряд сетевых администраторов и специалистов не смогли обеспечить работоспособность своих систем, своевременно исправляя найденные в них ошибки. Ни сколь угодно длительное обучение, ни подробная документация не сможет защитить ваши системы, если вы потеряете бдительность и перестанете поддерживать высокую квалификацию в области настройки своих систем.
Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности
Писатели знают, что они не в состоянии качественно вычитать корректуру своей собственной работы. Программисты должны знать, что они не смогут протестировать на ошибки свои собственные программы. Большинство компаний, разрабатывающих программное обеспечение, понимая это, нанимают тестировщиков программного обеспечения. Они ищут ошибки в программах, которые препятствуют выполнению заявленных функций. Это называется функциональным тестированием.
Функциональное тестирование значительно отличается от тестирования безопасности, хотя на первый взгляд это близкие понятия. Оба тестирования ищут дефекты программ, правильно? И да, и нет. Тестирование безопасности требует гораздо более глубокого анализа программы и обычно включает экспертизу исходного кода программы. Функциональное тестирование проводится для гарантии того, что большой процент пользователей сможет эксплуатировать программу без жалоб. Защититься от среднего пользователя, случайно споткнувшегося на проблеме, намного легче, чем попытаться защититься от хорошо осведомленного хакера, пытающегося взломать программу любым доступным ему способом.
Даже без подробного обсуждения того, что собой представляет аудит безопасности, его необходимость очевидна. Сколько коммерческих средств подвергается проверке безопасности? Практически ни одно. Обычно даже те немногие, которые имеют хотя бы поверхностный обзор безопасности, считаются безопасными. Хотя позднее часто становится очевидным, что они не прошли должную проверку.
Заметьте, что этот закон содержит слово "начала". Аудит безопасности – только один шаг в процессе создания безопасных систем. Для того чтобы понять, что в защите систем программного обеспечения полно недостатков, достаточно лишь ознакомиться с архивами списка отчетов любой уязвимости. Более того, можно увидеть одни и те же ошибки, неоднократно допущенные различными производителями программного обеспечения. Ясно, что это относится к классу систем, не подвергавшихся аудиту даже в минимальном объеме.
Вероятно, OpenBSD представляет собой один из наиболее интересных примеров роли аудита в разработке более безопасной системы программного обеспечения. С самого начала в проекте OpenBSD, являющемся ответвлением от главного проекта NetBSD, было решено обратить особое внимание на вопросы безопасности. Команда разработчиков OpenBSD потратила пару лет, занимаясь аудитом исходного кода для поиска и устранения ошибок. Разработчики исправляли любые найденные ошибки независимо от того, относились они к безопасности или нет. При нахождении общей ошибки они возвращались назад и просматривали все исходные коды, чтобы убедиться в том, что подобная ошибка не была сделана где-нибудь еще.
В конечном результате OpenBSD часто считается одной из наиболее безопасных операционных систем. Часто, когда обнаруживается новая ошибка в операционных системах NetBSD или FreeBSD (другой вариант BSD систем), в аналогичных условиях признается неуязвимость OpenBSD. Иногда причиной подобной неуязвимости является решение выявленной в других системах проблемы (случайно) во время обычного процесса исправления всех ошибок. В других случаях недостаток системы защиты был ранее выявлен и устранен. И в этих случаях системы NetBSD и FreeBSD (если в их составе была та же самая часть программного кода) были уязвимы, потому что никто не просматривал базу данных новых исправлений ошибок в OpenBSD (все исправления в OpenBSD обнародованы).