Как читать эту книгу 8 страница

Математика достаточно сложна, но основная идея в том, что каждый получает две части: часть "да" и часть "нет". Когда приходит время восстановить секрет, люди предоставляют одну из своих частей. Какую конкретно зависит от того, хотят ли они, чтобы секрет был раскрыт. Если предоставлено m или больше долей "да" и меньше чем n долей "нет", то секрет может быть восстановлен. В противном случае, это невозможно.

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

Совместное использование секрета с вычеркиванием из списка

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

3.8 Криптографическая защита баз данных

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

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

Схема, предложенная в [550, 549], прямолинейна. Выберите однонаправленную хэш-функцию и симметричный алгоритм шифрования. У каждой записи в базе данных два поля. Индексным полем является фамилия члена, и именно оно обрабатывается однонаправленной хэш-функцией. Поле данных, в котором хранится полное имя и адрес члена, шифруется с помощью используемой в качестве ключа фамилии. Если вы не знаете фамилии, вы никогда не сможете расшифровать поле данных.

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

В [550] авторы используют эту систему для защиты словаря из 6000 испанских слов. Они сообщают о том, что потеря производительности, вызванная шифрованием, минимальна. В более сложной схеме [549] используется поиск по нескольким индексам, но идея остается той же. Основная проблема, связанная с этой системой, состоит в том, что вы не сможете найти человека, не зная, как пишется его фамилия. Можно попробовать несколько вариантов, пока не будет найден правильный, но неудобно перебирать всех, чьи фамилии начинаются на "Sch" при поиске "Schneier."

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

4 Промежуточные протоколы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

T_n=S_K(n,A,H_n,T_n,I_n-1,H_n-1,T_n-1,L_n)

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

L_n =H(I_n-1,H_n-1,T_n-1,L_n-1)

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

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

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

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

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

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

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

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

V₁, V₂, V₃,... V_k

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

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

(4) Алиса собирает и хранит все подписи как метку времени.

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

Этот протокол работает, потому что подделать метку времени Алиса может, только договорившись о сотрудничестве со всеми k людьми. Так как на этапе (1) она выбирала их случайным образом, вероятность этого очень низка. Чем коррумпированнее общество, тем больше должно быть число k.

Кроме того, должен использоваться некоторый механизм, учитывающий то, что ряд людей не смогут вовремя возвратить метку времени. Все, что нужно для правильной метки времени - это некоторое подмножество k. Детали зависят от реализации.

Дальнейшая работа

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

Эти протоколы меток времени запатентованы [684, 685, 686]. Патенты принадлежат дочерней компании Bellcore, названной Surety Technologies, которая продает Систему цифрового нотариата, поддерживающую эти протоколы. В первой версии клиенты посылали запросы о "заверении" на центральный координирующий центр. Следуя методике Меркла по использованию хэш-функций для построения деревьев [1066], сервер строит дерево значений хэш-функции, листья которого представляют собой все запросы, полученные в течение данной секунды, и посылает каждому автору запроса список значений хэш-функции, описывающий путь от его листа до корня. Клиентская часть программного обеспечения сохраняет этот список и может выдать "сертификат" Цифрового нотариата для любого файла, который был сертифицирован. Последовательность корней этих деревьев образует "Запись универсального подтверждения" ("Universal Validation Record"), которая будет доступна в электронном виде во многих хранилищах (и также выпущена на CD-ROM). Клиентская часть также содержит функцию "подтверждения", позволяющую пользователю проверить, был ли заверена именно текущая форма файла (запросив из хранилища корень соответствующего дерева и сравнив его со значением хэш-функции, соответствующим образом рассчитанным для файла, и сертификатом). За дальнейшей информацией обращайтесь в Surety Technologies, 1 Main St., Chatham, NJ, 07928; (201) 701-0600; Fax: (201) 701-0601.

4.2 Подсознательный канал

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

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

Простым подсознательным каналом может быть число слов в предложении. Нечетное число слов в предложении может соответствовать "1", а четное число слов -"0". Так, пока вы читаете этот самый обычный абзац, я передал вам сообщение "110". Проблематичность этого метода в том, что он является обычной стеганографией (см. раздел 1.2), ключ не используется и безопасность зависит от секретности алгоритма.

Густавус Симмонс придумал идею организации подсознательного канала с помощью обычного алгоритма цифровой подписи [1458, 1473]. Так как подсознательные сообщения спрятаны в том, что выглядит нормальными цифровыми подписями, это форма маскировки. Уолтер видит, как подписанные безобидные сообщения передаются туда и обратно, но реальная передаваемая информация проходит незаметно для него по подсознательному каналу. В действительности, алгоритм подсознательного канала в подписях не отличим от нормального алгоритма в подписях, по крайней мере для Уолтера. Ер не только не может прочитать сообщение, передаваемое по подсознательному каналу, но у него вообще нет ни малейшего представления о существовании такого сообщения. В общем случае протокол выглядит примерно так:

(1) Алиса создает безобидное сообщение, все равно какое.

(2) Используя общий с Бобом ключ, Алиса подписывает безобидное сообщение, пряча свое подсознательное сообщение в подписи. (Это суть подсознательного протокола, см. раздел 23.3).

(3) Алиса посылает подписанное сообщение Бобу через Уолтера.

(4) Уолтер читает безобидное сообщение и проверяет подпись. Не обнаружив ничего подозрительного, он передает подписанное сообщение Бобу.

(5) Боб проверяет подпись под безобидным сообщением, убеждаясь, что сообщение получено от Алисы.

(6) Боб игнорирует безобидное сообщение и, используя общий с Алисой секретный ключ, извлекает подсознательное сообщение.

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

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

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

Применения подсознательного канала

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

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

Подписи, свободные от подсознательного канала

Алиса и Боб обмениваются подписанными сообщениями, обговаривая сроки контракта. Они используют протокол цифровой подписи. Однако, эти переговоры на самом деле маскируют шпионскую деятельность Алисы и Боба. Используя алгоритм цифровой подписи, они не волнуются о подписываемых ими сообщениях. Для обмена секретной информацией они используют подсознательный канал в подписях под документами. Контрразведка, однако, не знает, что переговоры о контракте и используемые подписанные сообщения являются только прикрытием. Для противодействия подобной схеме были разработаны схемы подписи, свободной от подсознательного канала. Используемые в этих схемах цифровые подписи невозможно изменить для организации подсознательного канала. Подробности см. в [480, 481].

4.3 Неотрицаемые цифровые подписи

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

Alice Software Company (Компания программного обеспечения Алисы) распространяет продукт DEW (Do-Everything-Word, Делая со словом что угодно). Для гарантии отсутствия вирусов каждая копия содержит цифровую подпись. Однако, создатели хотят, чтобы только легальные покупатели продукта, а не компьютерные пираты могли проверить подпись. В то же время, если обнаруживаются копии DEW, содержащие вирус, у Alice Software Company не должно быть возможности отрицать правильную подпись.

Неотрицаемые подписи [343,327] удобны для решения подобных задач. Как и обычная цифровая подпись, неотрицаемая цифровая подпись зависит от подписанного документа и закрытого ключа человека, подписавшего документ. Но, в отличие от обычных цифровых подписей, неотрицаемая подпись не может быть проверена без разрешения подписавшего. Хотя для этих подписей можно было бы подобрать название получше, например, "непередаваемые подписи", существующее название обусловлено тем обстоятельством, что если Алисе придется либо подтвердить, либо отрицать подпись - может быть в суде - она не сможет ложно отрицать свою настоящую подпись. Несмотря на сложность математики основная идея проста:

(1) Алиса предъявляет Бобу подпись.

(2) Боб создает случайное число и посылает его Алисе.

(3) Алиса выполняет вычисления, используя случайное число и свой закрытый ключ, и посылает Бобу результат. Алиса может выполнить эти вычисления только, если подпись правильна.

(4) Боб проверяет это.

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

Боб не может повернуться и убедить Кэрол, что подпись Алисы правильна, потому что Кэрол не знает, что числа Боба случайны. Он может легко без помощи Алисы изложить протокол на бумаге и послать результат Кэрол. Кэрол может удостовериться в правильности подписи Алисы только, если она сама выполнит этот протокол с Алисой. Сейчас кажется, что в этом немного смысла, но он появится, когда вы взглянете на математику раздела 23.4.

Это решение не совершенно. Иво Десмедт и Моти Юнг (Moti Yung) показали, что в некоторых случаях Боб может убедить Кэрол в правильности подписи Алисы [489].

Например, Боб покупает легальную копию DEW. Он может подтвердить подпись под программным продуктом, когда захочет. Тогда, Боб может убедить Кэрол, что он работает на Alice Software Company, и продать ей пиратскую копию DEW. Когда Кэрол попытается подтвердить подпись Боба, он одновременно подтверждает подпись у Алисы. Когда Кэрол посылает ему случайное число, он отправляет его Алисе. Ответ Алисы он пересылает Кэрол. Кэрол убеждается в том, что она - легальный покупатель, хотя она таковым не является. Такое вскрытие является прмером проблемы великого гроссмейстера и подробно рассматривается в разделе 5.2.

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

Ряд вариантов неотрицаемых подписей отделяет связь между подписавшим и сообщением от связи между подписавшим и подписью [910]. В одной схеме кто угодно может проверить, что подпись действительно была создана ее автором, а для проверки правильности подписи для данного сообщения требуется сотрудничество подписавшего.

Близким понятием является доверительная неотрицаемая подпись [1229]. Представьте, что Алиса работает на Toxins, Inc., и передает обличающие документы в газету, используя протокол неотрицаемой подписи. Алиса может подтвердить свою подпись только репортеру газеты и никому больше. Однако, негодяй Боб подозревает, что источником документов является Алиса. Он требует, чтобы Алиса использовала протокол снятия подписи, чтобы очистить свое имя, а Алиса отказывается. Боб настаивает, что единственной причиной отказа Алисы является ее виновность, и убивает ее.

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

4.4 Подписи уполномоченного свидетеля

Alice Software Company добилась бурного роста продаж, продавая DEW - такого, что Алиса большую часть времени посвящает подтверждению неотрицаемых подписей, а не работе над новыми возможностями.

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

Оказывается, это возможно с использованием подписи уполномоченного свидетеля [333,1213]. Алиса может подписать документ, так что Боб убедится, что подпись правильна, но не сможет убедить в этом третье лицо. В то же время Алиса назначает Кэрол на должность будущего свидетеля своей. Алисе даже не нужно заранее просить разрешения у Кэрол, ей только нужно использовать открытый ключ Кэрол. И Кэрол сможет подтвердить подпись Алисы, если Алиса уехала из города, уволилась, была повышена или умерла.

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

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

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

4.5 Подписи по доверенности

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

Решением этого являются подписи по доверенности[1001]. Алиса передает Бобу полномочия так, чтобы имели место следующие свойства:

— Различимость. Кто угодно может отличить подписи по доверенности от обычных подписей.

— Неподдельность. Только сам подписывающий и назначенный им подписывающий по доверенности может создать правильную подпись по доверенности.

— Отличие подписи по доверенности. подписывающий по доверенности не может создать правильную подпись по доверенности, которую можно выдать за оригинальную подпись.