недель, но дело будет сделано. Тем не менее такая схема усложнит работу взломщика ( в мире продаже всякой чепухи по почте "усложнит" быстро превращается в "сделает слишком дорогой". Другой подход, предложенный в [185], предлагает набирать статистику по шифрованным данным .

Глава 4

Промежуточные протоколы 4.1 Службы меток времени

Во многих ситуациях людям нужно убедиться, что определенный документ уже существовал в определенный момент времени. Примером является спор об авторских правах или патенте. Дело выигрывает сторона, которая представит более раннюю копию спорной работы. Бумажные документы заверяются нотариусами и хранятся у юристов. Если возникает спор, нотариус или юрист свидетельствует, что письмо существовало в определенный момент времени.

В цифровом мире все гораздо сложнее. Нет способов обнаружить признаки подделки электронного докуме н-та. Его можно бесконечно копировать и изменять, не оставляя никаких следов . Несложно и изменить время создания компьютерного файла. Никто не может взглянуть на документ и с полной уверенностью сказать: "Да, этот документ был создан раньше 4 ноября 1952 года"

Этой проблемой задались Стюарт Хабер (Stuart Haber) и В. Скотт Сторнетта (W. Scott Stornetta) из Bellcore [682, 683, 92]. Им потребовался протокол цифровых меток времени со следующими свойствами :

- Метка времени должна существовать сама по себе, независя от физической среды, используемой для ее хранения.

- Должно быть невозможно тайно изменить ни единого бита документа.

- Должно быть невозможно задать для документа метку времени, отличного от текущего.

Решение с посредником

В этом протоколе участвуют Трент, обладающий надежной службой меток времени, и Алиса, которая хочет задать метку времени для документа.

(1) Алиса передает копию документа Тренту.

(2) Трент записывает время и дату получения документа, оставляя у себя копию для безопасного хранения.

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

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

Во вторых, самой базе данных придется быть очень большой. Велики будут требования и к пропускной си о-собности линии связи.

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

И в четвертых, может оказаться невозможным найти такого честного Трента для ведения службы меток времени. Может быть, Алиса использует метку времени Боба. Ничто не остановит Алису и Боба от сговора и пометки документа тем временем, которое им нужно .

Улучшенное решение с посредником

Большинство этих проблем легко снимаются при использовании однонаправленной хэш-функции и цифр о-вых подписей:

(1) Алиса вычисляет значение однонаправленной хэш-функции для документа.

(2) Алиса передает это значение Тренту.

(3) Трент добавляет время и дату получения этого значения и затем подписывает результат цифровой подп и-сью.

(4) Трент отправляет подписанное значение хэш-функции вместе с меткой времени Алисе.

Это решает все проблемы, кроме последней. Алисе больше не нужно беспокоиться о раскрытии содержания

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

Протокол связи

Одним из путей решения этой проблемы является установление связи между меткой времени Алисы и ме т-ками времени, ранее созданными Трентом. Весьма вероятно, что эти метки были созданы не для Алисы, а для других людей. Так как порядок, в котором Трент получает различные запросы о метках времени не может быть известен заранее, перед меткой времени для Алисы должна была появиться другая метка времени. И так как запрос, пришедший позже, связан с меткой времени Алисы, то ее метка должна была появиться раньше . Эти две метки содержат между собой запрос Алисы как будто в сэндвиче .

Если а - это имя Алисы, Hn - значение хэш-функции, для которого Алиса хочет зафиксировать время, а Тп.1 -предыдущая метка времени, то протокол имеет следующий вид :

(1) Алиса посылает Тренту H„ и А.

(2) Трент посылает Алисе обратно:

Тп =SK(n,A,Hn,Tn,In-1,Hn-1,Tn-1,Ln)

где состоит Ln - это информация о следующей хэшированной связи:

Ln =H(In-1,Hn-1,Tn-1,Ln-1)

Sk указывает, что сообщение подписано открытым ключом Трента. Имя Алисы определяет ее как отпр а-вителя запроса. Параметр n указывает последовательность запросов. Это n-ая метка времени, которую создал Трент. Параметр Tn - это время. Дополнительно используется информация об идентификаторе, ор и-гинального значения хэш-функции, времени и хэшированной метка предыдущего документа, помеченного Трентом.

(3) Когда Трент помечает следующий документ, он посылает Алисе идентификатор отправителя этого док у-мента: In-1.

Если кто-то оспаривает метку времени Алисы, ей надо только связаться с отправителями предыдущего и следующего документов: In-1 н In+1. Если и их свидетельство под вопросом, можно обратиться к авторам документов In-1 н In+1 и т.д. Любой может показать, что его документ был помечен после одного документа и перед другим.

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

Распределенный протокол

Люди умирают, метки времени теряются. Между пометкой документа и его оспариванием может произойти многое, что помешает Алисе получить копию метки времени In-1. Эта проблема может быть частично снята вставкой меток времени предыдущих 10 человек в метку Алисы и последующей передаче Алисе имен следу ю-щих 10 человек. Так у Алисы появится гораздо больше возможностей найти людей, все еще хранящих свои метки времени.

Развивая эту идею, следующий протокол позволяет обойтись и без Трента:

(1) Используя в качестве входа Hn, Алиса генерирует последовательность случайных чисел с помощью кри п-тографически безопасного генератора случайных чисел.

Vi, V2, Vs, . . . Vk

(2) Алиса рассматривает каждое из этих чисел как идентификатор , I, другого человека и посылает каждому из этих людей Hn.

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