Бомба формата doc
Неожиданный взгляд на электронный документ
Вам уже приходилось подписывать электронные документы? И как, не заметили ничего странного? Заметили? Именно об этом сейчас и пойдет речь!
Начнем немного издалека. Что мы подписываем, когда мы подписываем бумажный документ? Вопрос звучит странно, согласен, но ответ кажется довольно простым. Мы ставим подпись, как знак нашего согласия с содержанием документа. «Я такой-то такой-то, прошу предоставить мне отпуск с <Дата1> по <Дата2>». Все просто и понятно.
А что закрепляет наша подпись в электронном документе, кроме нашего желания отдохнуть с <Дата1> по <Дата2>? Ставя подпись под электронным документом, созданным, скажем, в популярном текстовом процессоре, мы своей подписью закрепляем, что <Дата2> записана шрифтом Courier New высотой 11 кеглей. This makes no sense, как сказали бы наши английские друзья, ибо будь эта дата написана шрифтом Times New Roman высотой 14 кеглей, отдыхать мы больше не станем. Иными словами, подписывая электронный документ, мы, желая того или нет, своей подписью закрепляем еще и его форму. Но это сущие пустяки, по сравнению с тем, о чем я поведаю дальше…
Не секрет, что большинство современных электронных документов имеют в своем арсенале не только элементы оформления, но и могут содержать некий код на достаточно мощном языке программирования, скажем, Visual Basic for Applications. Так вот, своими руками, имея под этими самыми руками только кажущийся таким безобидным Visual Basic, можно создать самодельную бомбу. Нет, офис она, конечно, не разнесет, а вот шуму наделать может немало. Как? Попытаюсь пояснить на маленьком примере.
Например, написали вы заявление на отпуск и отправили его своему непосредственному начальнику на утверждение. А заявление не простое, а в виде doc-файла, да не просто, а с макросом на Visual Basic. Желая понежиться подольше в лучах теплого летнего солнышка, вы полагаете, что отдохнуть с 10 июля по 10 августа, будет как раз то, что нужно. Доходит заявление до вашего босса, макрос определяет имя его машины, немного меняет текст заявления, и ваш начальник видит, что вы хотите отдохнуть с 10 по 15 июля, ибо больше вам совесть не позволяет. Шеф, радуясь, что под его началом трудится такой ответственный сотрудник, подписывает это заявление и посылает дальше по инстанции. Следующая инстанция получает документ уже с «реальным» сроком отпуска, протяженностью в один месяц, но, видя подпись вашего начальника, скорее всего, не будет вникать в суть вопроса. Так оно дойдет и до бухгалтерии, где вас одарят щедрыми отпускными.
Скажете, такое невозможно? Меняя документ, макрос изменит и значение hash-функции, делая недействительной цифровую подпись. А если документ не будет сохраняться, просто макрос будет менять текст при открытии? Если ЭЦП не встроена в тело документа, а помещена в один контейнер с документом? Согласен, что в заявлении макрос вызовет подозрение, а как быть в случае с электронной формой, которая изначально содержит макросы, проверяющие корректность введенных данных? В любом случае это всего лишь умозрительный пример, показывающий, что электронный документ, это не только содержащаяся в нем «реальная» информация, но и служебная «электронная» информация (стили оформления, макросы и т.п.). Эта информация не несет для подписанта «экономического» смысла, но, тем не менее, также закрепляется его подписью. Получается, что, подписав электронный документ, мы берем на себя ответственность за все содержащиеся в нем макросы, а также за все их действия в настоящем и будущем? А оно … нам надо?
Комментарии 14
Согласен с Вами, Михаил. Данный пример скорее карикатура, чем пособие по надувателству своего босса. Я привел этот пример, чтоб показать, что современный электронный документ может обладать определенным поведением. Ставя ЭЦП под таким документом, трудно быть уверенным до конца в том, что:
1. Мы видим "настоящее" содержимое документа.
2. Следующий пользователь увидит то же самое, что и мы.
3. Документ в будущем не "выкинет какой-либо фокус".
Уважаемый Михаил, о "продвинутом руководителе, знающем, что такое VBA" - это вы что, серьёзно?
Да, Наталья, "ликбез" в области правового регулирования ЭЦП мне не помешает. Буду благодарен, если Вы укажете, законодательство каких стран уже содержит данные меры.
Наталья, огромное спасибо! Просто потрясен глубиной и широтой Ваших знаний!
Вкратце - вводятся понятия машиночитаемого и человекочитаемого представления документа. А как решение, например, предлагается создать и сертифицировать средства по переводу некоторых видов документов (форматов файлов) из машиночитаемого в человекочитаемый вид, которые в спорных ситуациях помогут установить правильную, юридически значимую трактовку документа.
2 Сергей Данилов:
Думаю, что использование только сертифицированных программ оправдано в "специализированных" системах электронного документооборота, как в приведенном в статье примере с системами сдачи отчетности в электронном виде. Также данный подход применим к системам "банк-клиент", где клиенту передается ( и оплачивается им) специализированное ПО для обмена сообщениями с банком. Сертифицировать же "все и вся" кажется не только неразумным, но и технически неосуществимым.
Для "общих" целей, на мой взгляд, целесообразнее применять подход, упомянутый Натальей в ее топике о законодательных инициативах разных стран в этой области. Законодательно "спускается сверху" или устанавливается сторонами в договоре ограничение на использование определенных форматов и установка дополнительных требований к документам (отсутствие макросов и т.п.).
Я несколько иное хотел сказать.
Документы по своей структуре, формату и правилам визуализации могут быть очень разными. Поэтому просто ограничить использование макросов и (расплывчатая формулировка) скрытого кода явно недостаточно. Взять, к примеру, способ подмены шрифтов из статьи указанной Натальей.
Нужны некоторые способы в спорных ситуациях определить "правильную" версию документа в человекочитаемом виде. Для этих целей предлагается создать ряд эталонных программ, которые всегда будут однозначно переводить текст из "машинного" в "человеческий" вид. Эти программы должны быть законодательно утверждены как эталонные и, как следствие, сертифицированы именно для этого. Программы в дальнейшем могут распространяться бесплатно.
О сертификации СЭД или обычных приложений-редакторов я не говорю.
В итоге, в большинстве случаев я работаю с привычными мне приложениями-редакторами, а в спорных случае или при работе с важными документами использую программы-эталоны.
В качестве аналогии могу привести историю с БТИ (Бюро технической инвентаризации). Поступили жалобы на БТИ, что при измерении площадей земельных участков и жил. площадей полученные результаты сильно разнились с ожидаемыми результатами. Оказалось, что сотрудники БТИ бездумно использовали в своей работе купленную на рынке китайскую рулетку с очень большой погрешностью. В итоге, были повторены все замеры, но уже с хорошей рулеткой изготовленной по ГОСТу. Эту рулетка можно сравнить с эталонным приложением визуализации.
Сергей, спасибо за приведенный пример!
Все же я вижу некоторые проблемы, которые могут встретиться при изготовлении "эталонных программ".
1. Формат, используемый "неэталонным" приложением, может быть закрытым.
2. В отличии от рулетки, программы постоянно обновляются, это зачастую приводит и к смене используемого формата.
3. Неизвестно, как к этой инициативе отнесутся производители ПО, если наряду с их "небесплатными" программами будут существовать еще и некие "эталонные" (считай, лучшие), да к тому же еще и бесплатные версии.
4. Возникает вопрос, на каком уровне сертифицировать такие "эталонные" программы - на национальном или международном, кто выступит в роли сертифицирующего органа?
5. Кто возьмется бесплатно изготовить такие "эталоны"?
6. The last but not the least: Такие программы будут бесполезны, если для обмана пользователей была изменена среда, а не сама программа отображения документа, как в случае со шрифтом из вышеупомянутой статьи.
Еще пара слов по поводу форматов. Есть тенденция (или мода) использовать для государственных нужд (включая образование) открытое ПО и открытые форматы. Стоит ли считать началом тенденции признание властями штата Массачусетс изначально проприетарного (хотя и Microsoft пытается его и сертифицировать через ECMA) формата Microsoft Office Open XML - время покажет.
Законодатель может определить перечень открытых форматов для обмена между правительствиннеми организациями и для обращения к ним организаций и частных лиц. Устанавливать же подобные правила для всех - вопрос спорный. В принципе, бизнес всегда может установить любые правила в рамках договора