Realinformatik

Архив

Пришел очередной, мартовский выпуск "Крипто-Граммы" (CRYPTO-GRAM, www.counterpane.com) с очередной "проповедью" Брюса Шнайера (Bruce Shneier) о критериях оценки перспективных крипторешений. Читателям "Компьютерры" знаком этот замечательный автор и этот замечательный жанр по двум статьям (см. # 34 [262], 1 сентября 1998 года, стр. 36-38 и #10 [288], 9 марта, стр. 31-32).

   В этот раз Шнайер пишет о том, как не надежно полагаться на многократный процесс обнаружения/ликвидации недочета в протоколе при стандартизации последнего. Мне это живо напоминает мэйнстрим обсуждений в "общей информатике" лет так 20 назад: о том, что вместо "отладки" неплохо бы изучить вопрос о том, как писать программы без ошибок.

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

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

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

   Но очень часто буквальное выполнение задания заказчика оказывается навешиванием все более совершенных замков на кривую дверь, готовую вот-вот слететь с петель. У меня было несколько персональных неудач в таких ситуациях (предвиденных и оговоренных, что еще обиднее), и я особенно болезненно на них реагирую.

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

   В #11 [289] от 16 марта ("Метка под мышкой", стр. 16) была опубликована информация о "проблеме GUID", заключающейся в утечке данных о номерах сетевой платы в составе документов MS Word, а в #12 [290] от 23 марта ("Microsoft следит за тобой", стр. 4) Михаил Попов привел способ ее "ручного" устранения.

   25 марта Сергей Алпатов из ЗАО Microsoft в ответ на запрос "Компьютерры" по поводу GUID, отправленный при подготовке "Метки..." к печати, любезно прислал специальный выпуск бюллетеня Microsoft от 20 марта, в котором приводится адрес Web-страницы со следующими "официальными" средствами, предназначенными для купирования проблемы GUID:

   1) "заплата", позволяющая блокировать запись уникального номера идентификации в новые документы MS Office (Office 97 Unique Identifier Patch);

   2) Утилита для удаления уникального идентификатора MS Office 97 (Office 97 Unique Identifier Removal Tool).

   Хотя позднее эта информация и была разослана зарегистрированным пользователям оригинального MS Office 97, на всякий случай воспроизвожу этот адрес http://officeupdate.microsoft.com. Там же находятся и ссылки на аналогичные заплаты и утилиты для локализованных версий.

   Кроме того, в бюллетене говорится: "Уникальный идентификатор, формируемый в документах MS Office 97, содержит информацию, часть которой считывается из сетевой платы, а не из личного идентификатора пользователя, что не дает возможности точно определить автора документа".

   Это совершенно правильно - ведь владелец компьютера (и сетевой платы) совершенно не обязательно является автором любого из подготавливаемых на нем документов. Однако вывод, который из этого делают в Microsoft: "Уникальные номера идентификации Office ни в коей мере не нарушают вашу конфиденциальность", кажется мне все же слишком беспечным.

   Тем временем, эти публикации породили - не скажу поток, но - ручеек откликов. Один из читателей задается вопросом: а как вообще можно сформировать уникальный идентификатор, не включая в него аппаратно-зависимые данные? Можно, и достаточно просто: например, сгенерировав достаточно большое случайное число или использовав ту же самую аппаратно-зависимую информацию, но исключив возможность ее восстановления (подвергнув процедуре одностороннего криптостойкого хеширования).

   Максим Степин из г. Гусь-Хрустальный находит вопрос "особых свойств" приложений, могущих привести к утечке информации, "болезненным". И приводит такой пример:

   "Однажды в сохраненном DOC-файле я обнаружил (просматривая его в текстовом виде) строку "You found a secret area!". А как раз перед этим игрался в "Quake".

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

   Правда, дело давнее (Win 3.11, Word 6.0), но, с другой стороны, с течением времени DOC-формат только толстеет".

   Еще один читатель прислал нам реальный пример того, как такое происходит: прайс-лист некоей московской лавки в формате MS Word, в который, как муха в янтарь, "влип" - невидимый глазу, вооруженному лишь Word'ом, но заметный при просмотре в текстовом режиме - кусок другого документа, в формате MS Excel, содержащего данные об операциях компании с характерными примечаниями "оформлено", "проведено", "нал" и т. п.

   Что здесь можно сказать? Приведенные примеры не специфичны для MS Office, они суть следствие того, что приложение захватывает пространство на диске под файл с документом, предварительно размечает его и не очищает неиспользованные куски этого файла, в которых могут размещаться данные из удаленных файлов, старого файла подкачки и т. п. Этим грешат многие популярные приложения, разработанные без учета специфики работы с данными ограниченного доступа.

   Конкретно пользователям MS Word можно дать следующие советы (в порядке от элементарной предусмотрительности до тяжелой паранойи):

   1) отключите опции fast save ("быстрое сохранение") и back copies ("резервные копии");

   2) сохраняйте передаваемые (по сетям, либо на сменных носителях) документы в формате RTF или текстовом формате (в зависимости от их характера и последующего использования);

   3) "зонируйте" данные разного режима доступа: располагайте файлы с конфиденциальной (или просто персонально значимой информацией) на надежно шифрованном (например, PGPdisk - см. #7 [285] от 16 февраля, стр. 30-33) томе и переназначьте туда же autosave ("автосохранение"); перед запуском коммуникационного софта демонтируйте этот том, предварительно экспортировав все подлежащие отправке данные на открытый том.