Объединенный

3

Здесь возможны два подхода:

1.сгенерировать случайное число и проверить, является оно простым или нет;

2.с помощью специальных алгоритмов сразу строить случайное простое

число.

Наиболее простым в реализации представляется первый подход. Здесь в свою очередь самым очевидным способом проверки простоты числа N является перебор всех

простых чисел в интервале 1 k N с проверкой на делимость. Однако, если вспомнить, что в системе RSA для обеспечения высокой стойкости необходим ключ длиной 4096, то предложенный алгоритм окажется бесполезным из-за высокой вычислительной сложности.

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

Одним из способов является тест Рабина. Он основан на малой теореме Ферма, согласно которой, напомним, для любого простого N и любого целого положительного a<N:

aN-1=1(mod N). (*)

Сама проверка может быть проведена достаточно быстро.

Пусть требуется найти вычет ad (mod N). Представим d в виде двоичного числа: d = d0 d1d2...dr (d0 - старший двоичный разряд). Положим а0 = а и по рекуррентной формуле:

ai ai2 1adi mod N

найдем ar , которое и будет ничем иным, как искомым вычетом. Сложность данного

алгоритма можно оценить как O(ln N).

Итак, воспользовавшись малой теоремой Ферма для заданного N, можно перебрать все возможные значения а, и если какое-то из них нарушит условие (*), то N следует признать составным. Но, к сожалению, теорема Ферма дает лишь необходимое, но не достаточное условие простоты. Имеются составные числа, удовлетворяющие указанному условию, они носят имя Кармайкла (Carmichael).

Пусть имеется число N= 2s t + 1, где t - нечетно, и требуется установить, простое оно или составное. Вероятностный тест Рабина заключается в следующем.

Выбирается случайное число 1 a N и проверяются два условия:

a2k t 1 mod N .

Если оба условия выполняются, то как показал Рабин, вероятность того, что число N окажется все-таки составным, равна 1/4. Если же провести не один, а m аналогичных тестов, выбирая случайное a, то можно установить простоту числа с вероятностью 4-m. Несмотря на вероятностный характер предложенного алгоритма за счет выбора большого m можно добиться того, что вероятность ошибочного выбора простого числа для создания криптосистемы окажется ниже, чем вероятность ее взлома существующими методами (например, перебором ключа).

Проблемы реализации криптосистем

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

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

4

шифрования RC4. Однако как показали специалисты Counterpane Systems, существует режим, в котором механизм шифрования становится абсолютно прозрачным. Недооценка мелочей в разное время ставила под угрозу целые технологии, уже получившие слишком большую популярность, чтобы их менять: сотовая связь GSM и CDMA, защита от копирования дисков DVD, и даже "шифрование" документов MS Word.

В целом, если проанализировать опыт взлома существующих систем защиты данных, то практически все ошибки реализации можно свести к следующим классам:

невозможность применения стойких криптоалгоритмов;

ошибки в реализации криптоалгоритмов;

неправильное применение криптоалгоритмов;

человеческий фактор.

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

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

Малая скорость стойких криптоалгоритмов. Данный фактор, затрудняющий применение хороших алгоритмов, например в системах "тотального" шифрования или шифрования "на лету", в настоящее время несколько теряет актуальность, так как современные аппаратные средства позволяют реализовывать стойкие алгоритмы шифрования, обеспечивая при этом высокую скорость работы. Так, версия файловой системы NTFS 5.0 позволяет прозрачно для пользователя организовать шифрование файлов, каталогов и целых дисков симметричным шифром с длиной ключа 128 бит.

Экспортные ограничения. Этот фактор связан с невозможность легального экспорта некоторых криптоалгоритмов или с необходимостью приобретать патент, или права на них.

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

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

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

Отсутствие проверки на слабые ключи. Некоторые криптоалгоритмы (в частности, DES, IDEA, ГОСТ в «домагмовскую» эпоху) при шифровании со специфическими ключами не могут обеспечить должный уровень криптостойкости. Такие ключи называют слабыми (weak). Хотя вероятность выбора слабого ключа мала, для серьезных систем ей пренебрегать нельзя.

Недостаточная защищенность от разрушающих программных средств.

Разрушающие программные средства (РПС) - компьютерные вирусы, троянские кони, программные закладки и т. п. программы, способные перехватить секретный ключ или сами нешифрованные данные, а также просто подменить алгоритм на некриптостойкий. В случае, если программист не предусмотрел достаточных способов защиты от РПС, они легко способны нарушить безопасность криптосистемы. Особенно это актуально для операционных систем, не имеющих встроенных средств защиты или средств разграничения доступа - типа MS DOS или Windows 95/98/ME.

5

Наличие зависимости времени работы алгоритма от ключа. Это сравнительно новый аспект недостаточно корректной реализации криптоалгоритмов. Многие криптосистемы неодинаково быстро обрабатывают разные входные данные. Это происходит как из-за аппаратных (разное количество тактов на операцию, попадание в процессорный кэш и т. п.), так и программных причин (особенно при оптимизации программы по времени). Время может зависеть как от ключа шифрования, так и от (рас)шифруемых данных. Поэтому злоумышленник, обладая детальной информацией о реализации криптоалгоритма, имея зашифрованные данные, и будучи способным какимто образом измерять время обработки этих данных (например, анализируя время отправки пакетов с данными), может попытаться подобрать секретный ключ. Известны атаки такого типа на алгоритмы RSA, Диффи-Хеллмана и на схему ЭЦП DSS, используемую в прошлом.

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

Недостатки датчика случайных чисел. Хороший, математически проверенный и корректно реализованный ДСЧ также важен для криптосистемы, как и хороший, математически стойкий и корректный криптоалгоритм, иначе его недостатки могут повлиять на общую криптостойкость системы. При этом для моделирования ДСЧ на ЭВМ обычно применяют датчики псевдослучайных чисел (ПСЧ), характеризующиеся периодом, разбросом, а также необходимостью его инициализации. Применение ПСЧ для криптосистем вообще нельзя признать удачным решением, поэтому хорошие криптосистемы применяют для этих целей физический ДСЧ (специальную плату), или, по крайней мере, вырабатывают число для инициализации ПСЧ с помощью физических величин (например, время нажатия на клавишу пользователем).

Наличие люков. Люком называется не описанная в документации на программный продукт возможность работы с этим программным продуктом. Сущность использования люков состоит в том, что при выполнении пользователем некоторых не описанных в документации действий он получает доступ к возможностям и данным, которые в обычных условиях для него закрыты (в частности - выход в привилегированный режим). Люки чаще всего являются результатом забывчивости разработчиков. В процессе разработки программы разработчики часто создают временные механизмы, облегчающие ведение отладки за счет прямого доступа к отлаживаемым частям продукта. По окончанию отладки большинство люков убирается из программы; но люди есть люди - зачастую они забывают о существовании каких-то мелких "люков". Одним из наиболее показательных примеров использования "забытых" люков является, пожалуй, широко известный в компьютерном мире инцидент с вирусом Морриса (один из первых сетевых червей, распространявшихся через Интернет. Написан аспирантом Корнельского университета Робертом Таппаном Моррисом и запущен 2 ноября 1988 года в Массачусетском технологическом институте). Одной из причин, обусловивших возможность распространения этого вируса, была ошибка разработчика программы электронной почты, входящей в состав одной из версий операционной системы UNIX, приведшая к появлению малозаметного люка. Американские специалисты оценивают ущерб, нанесенный в результате этого инцидента, более чем в 100 миллионов долларов. Причины наличия люков в криптосистемах очевидны: разработчик хочет иметь контроль над обрабатываемой в его системе информацией и оставляет для себя возможность расшифровывать ее, не зная ключа пользователя. Возможно также, что они используются для отладки и по какой-то причине не убираются из конечного продукта. Естественно, что это рано или поздно становится известным сравнительно большому кругу лиц и ценность такой криптосистемы становится почти нулевой.

Неправильное применение криптоалгоритмов. Эта группа причин приводит к тому, что оказывается ненадежными криптостойкие и корректно реализованные алгоритмы.

6

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

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

Повторное наложение гаммы шифра. Это приводит к тому, что при известном открытом тексте определяется гамма шифра, которая впоследствии используется для дешифрования другого шифрованного текста.

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

Типичным примером здесь будут все WWW-, ftp-, e-mail-клиенты. Дело в том, что для базовой (наиболее часто встречающейся) аутентификации в этих протоколах пароль должен передаваться серверу в открытом виде. Поэтому клиентские программы вынуждены шифровать (а не хешировать) пароль, причем с фиксированным ключом, чтобы не надоедать пользователю постоянными вопросами. Отсюда следует, что внутри любого браузера, почтового или ftpклиента (в старых версиях Eudora, Outlook, FAR и т. п.) лежат все пароли в практически открытом виде, и их можно легко расшифровать.

Человеческий фактор. В любой критической системе ошибки человека-оператора являются чуть ли не самыми дорогостоящими и распространенными. В случае криптосистем непрофессиональные действия пользователя сводят на нет самый стойкий криптоалгоритм и самую корректную его реализацию и применение.

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

Хакерами был придуман остроумный метод, основанный на том, что в качестве пароля человеком выбирается существующее слово или какая-либо информация о себе или своих знакомых (имя, дата рождения и т. п.). Ну, а поскольку в любом языке порядка 106 слов, их перебор займет весьма небольшое время, и от 40 до 80 % существующих паролей может быть угадано с помощью такой простой схемы, называемой "атакой по словарю". Известный вирус Морриса (в 1988 г.!) применял такой способ, при этом он с успехом пользовался следующими предположениями:

в качестве пароля берется входное имя пользователя;

пароль представляет собой двойной повтор имени пользователя;

то же, но прочитанное справа налево;

имя или фамилия пользователя;

7

то же, но в нижнем регистре.

Ихотя грамотность пользователей растет, атаки подобного вида все еще часто достигают цели.

1

КРИПТОВАЛЮТЫ И БЛОКЧЕЙН

В последние годы некоторые криптографические методы и основывающиеся на них технологии стали находить широкое применение в экономике, финансовой системе и жизни общества в целом. Среди них мы назовем технологию блокчейн (blockchain) и криптовалюты, первая из которых — биткоин (bitcoin) стала поистине всемирно известна.

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

Доказательство выполнения работы (proof-of-work) и Хешкэш (Hashcash)

По-видимому, первая система «доказательства выполнения работы» (proof-of-work)

была предложена в работе Дворка и Наора [Dwork C., Naor M. Pricing via processing or combatting junk mail // Advances in Cryptology - CRYPTO’92. - LNCS 740. - Springer-Verlag, 1993. - P. 139-147] как средство борьбы со спамом. Напомним, что спамеры рассылают по сотням тысяч, а то и миллионам адресов один и тот же рекламный текст, засоряя почтовые ящики пользователей электронной почтой.

Авторы работы 1992 года рассматривали взаимодействие почтового сервера с клиентами, которые обращаются к нему для отправки электронных писем. Дворк и Наор предложили схему, в которой каждый клиент, обратившийся к серверу для отправки письма, должен сначала решить некоторую вычислительную задачу, причем нахождение решения данной задачи требует от клиента некоторого заметного времени вычисления (скажем, несколько секунд), что, собственно, и объясняет название термина «доказательство выполнения работы». При этом задача выбирается такой, что проверка правильности решения сервером проводится очень быстро. Предполагается, что затрата нескольких секунд для решения задачи при отправке письма не очень осложнит жизнь «честного» клиента, но будет серьезным препятствием для спамера, отправляющего тысячи копий, т.к. ему пришлось бы решать задачу «доказательства работой» для каждой из них заново, и суммарные затраты его времени могли бы составить несколько часов.

Хотя данный метод борьбы со спамом не нашел практического применения, он оказался полезен при построении криптовалют и решении ряда других задач, и в настоящее время известны различные варианты его реализации. Рассмотрим подробно один такой алгоритм, предложенный в 2002 году Бэком [Back A. Hashcash – a denial of service counter-measure. 2002], и получивший название «Хэшкэш» (Hashcash).

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

1.Клиент сообщает серверу, что хочет получить некоторую услугу.

2.Сервер генерирует случайное слово r и высылает его клиенту вместе с целым числом k. (В реально применяемых протоколах длина двоичной записи r несколько сотен бит, а величина k — несколько десятков.)

3.(«работа» клиента). Клиент находит такое слово х, для которого первые k символов слова H(r||x) являются нулями

4.Клиент высылает серверу слово x. Сервер вычисляет величину H(r||x) и, если k первых символов этого слова нули, то предоставляет клиенту требуемые услуги, иначе — не предоставляет.

Изучим свойства этого протокола, начав с рассмотрения основного, третьего, шага. Главный вопрос — как найти слово x, удовлетворяющее условию второго шага «Хешкэш». Оказывается, что для «идеальной» хеш-функции нет лучшего подхода, чем последовательное вычисление значений H(r||x1), H(r||x2), H(r||x3), ..., где x1, х2, х3, ... —

2

генерируемые случайно слова (на практике это часто просто последовательные числа 1, 2, 3, ...).

Описанный протокол имеет довольно много полезных свойств.

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

Во-вторых, мы описали так называемый интерактивный протокол, когда сервер и клиент обмениваются несколькими сообщениями. Его можно легко превратить в неинтерактивный. Для этого сервер может потребовать от клиента выполнения шага 2, т.е. поручить ему генерировать и слово r (конечно, пара r||x может порождаться как одно слово u). Клиент, нашедший такое слово, может отправлять его серверу для получения услуги; предварительный обмен сообщениями не требуется.

Здесь, однако, возникают две легкопреодолимые трудности.

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

Другая, сходная трудность — клиент может попытаться использовать слово u, найденное для одного сервера, для получения услуги от другого. Для решения этой проблемы сервер может потребовать от клиентов присылать ему слова вида servername||u , для которых, по-прежнему, k начальных символов в H(servername||u) равны 0. (Здесь servername — имя сервера.) Предполагается, что имя сервера общеизвестно, скажем, хранится на его сайте. В этом случае клиент не сможет использовать найденное им слово servername||u для другого сервера.

Рассмотрим еще одну схему «доказательства работой», находящую широкое практическое применение. В предыдущей схеме трудоемкость задачи определялась числом начальных нулевых символов в значении хеш-функции — в среднем требовалось вычислить 2k значений хеш-функции. Иногда может возникнуть необходимость в увеличении трудоемкости задачи (например, при появлении более мощных компьютеров). Такое увеличение легко получить, перейдя от k к k + 1 и, тем самым, увеличив среднее число перебираемых вариантов вдвое, до 2k+1. В некоторых ситуациях такой шаг — увеличение в два раза — может оказаться слишком большим, и система с возможностью более плавного увеличения трудоемкости может оказаться предпочтительной. Такая система известна и также базируется на хеш-функции.

Для ее описания рассмотрим хеш-функцию H, значения которой - слова длины n бит. Заметим сразу, что их можно рассматривать как целые числа из диапазона 0,2n- 1 (в современных стандартах хеш-функций n = 256 или 512 бит). Заменим в вышеописанном протоколе шаг 3 следующим образом:

(«работа» клиента). Клиент находит такое слово x, для которого

H(r||x) < Y, (*)

где целое число Y — параметр метода, для которого должны выполняться условия 0≤Y≤2n-1. Понятно, что при случайном выборе слова r||x вероятность выполнения неравенства (*) равна Y/2n и, следовательно, при увеличении Y на единицу эта вероятность увеличивается на 1/2n. При n = 256 или 512 эта величина очень мала, поэтому возможно плавное уменьшение Y, и увеличение обратной величины, равной среднему количеству перебираемых значений хеш-функции (т.е. объему работы). Стоит отметить, что первая система (с k нулями в начале значения хеш-функции) фактически является частным случаем второй, если мы возьмем Y = 2-k.

Датирование документов (time-stamping)

Самые различные фирмы, организации, банки, а иногда и отдельные люди, ведут записи, фиксирующие расходы и доходы. До появления «безбумажной информатики» в крупных организациях такие записи собирались в так называемые бухгалтерские книги (ledger) или реестры, которые велись таким образом, чтобы, насколько возможно,

3

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

вбольницах при ведении истории болезни, в патентных бюро и многих других областях.

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

Одно из первых решений было предложено в начале 90-х годов прошлого века в работах Хабера, Сторнетты и Байера [Haber S., Stornetta W. S. How to time-stamp a digital document // Journal of Cryptology. - 1991. - V. 3, N. 2. - P. 99-111, Bayer D., Haber S., Stornetta W. S. Improving the efficiency and reliability of digital time-stamping // Sequences II. - Springer, New York. - 1993. - P. 329-334], которые рассматривали задачу «датирования» цифровых документов, т.е. снабжения их информацией о времени создания (time-stamp). Датирование напоминает нанесение на почте штемпеля на конверт, где указано время его отправки (с точностью до часа), что и объясняет название time-stamp. Начнем этот раздел с рассмотрения задачи датирования цифровых документов, т.к. она представляет самостоятельный практический интерес и при ее решении были открыты новые методы, которые в дальнейшем стали использоваться во многих криптографических системах.

Рассмотрим некоторое сообщество, участники которого время от времени производят документы x1, х2, ..., представленные в виде цифровых файлов. Например, это может быть биржа, участники которой заключают договоры о купле-продаже, или бухгалтерия, где создаются финансовые документы и т.п. Наша задача — построить систему, в которой каждый документ был бы датирован, т.е. снабжен сведениями о времени его создания, причем так, чтобы никто не мог создать документ «из прошлого», т.е. с датой, соответствующей прошедшему времени.

Сначала рассмотрим решение этой задачи с участием доверенной третьей стороны (trusted third party, ТТР), называемой в данном случае «лицо, наносящее временной штамп» (Time Stamping Authority, в дальнейшем — TSA). Будем считать, что все участники и TSA связаны компьютерной сетью, что они договорились использовать одну и ту же хеш-функцию H и что TSA имеет свою электронную подпись, подлинность которой может проверить любой участник. Обозначим подпись TSA к документу и через CTSA(u), тогда подписанный документ будет выглядеть как u|| CTSA(u).

Опишем теперь протокол датирования документа. Пусть один из участников, A (Алиса), создала документ x и хочет добавить к нему сведения о дате. Опишем работу протокола по шагам:

1.Алиса вычисляет хеш-функцию H(x) и отправляет ее к TSA.

2.TSA, получив H(x), формирует слово (файл) H(x)||tx, где tx — время получения документа x (скажем, в заранее обусловленном формате: ГОД, МЕСЯЦ, ДЕНЬ, ЧАС,

МИНУТА, СЕКУНДА).

3.TSA подписывает слово H(x)||tx, т.е. вычисляет подпись CTSA(H(x)||tx), и высылает ее и tx Алисе.

4.Алиса, получив время и подпись TSA, формирует документ с «заверенной» датой

w(x) = x|| tx || CTSA(H(x)||tx)

Любой участник, скажем B (Боб), может проверить подлинность даты в некотором документе w’(x) = x’|| tx’ || CTSA(H(x’)||tx’). Для этого Боб должен вычислить H(x’) и проверить подлинность подписанного сообщения x’|| tx’ || CTSA(H(x’)||tx’).

Если это сообщение выдерживает проверку, то Боб делает вывод о том, что действительно документ x’ был датирован в момент tx’; в противном случае Боб делает вывод о том, что w’(x) подделан, т.е. x’ был создан после или до даты tx’. Подтверждает этот вывод следующее строго доказанное в соответствующей литературе утверждение: В

4

описанной системе никто из участников не может сформировать документ в момент времени Т1 с датой Т2, предшествующей Т1.

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

В следующем разделе мы рассмотрим предложенную в работах Хабера, Сторнетты и Байера систему датирования, в которой TSA не может «приделать» фальшивое время, т.е. обязан быть честным. Важно отметить, что в этой системе впервые появилась цепочка связанных данных (или блоков данных — blockchain, или технология цепной записи данных), нашедшая широкое применение в криптовалютах и многих других приложениях.

Блокчейн (blockchain)

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

Итак, пусть Алиса создала документ x и хочет снабдить его заверенной датой. В рассматриваемой схеме датирование документа будет проводить TSA, которое вышлет Алисе соответствующий сертификат. В качестве примера можно считать, что TSA — это банк, Алиса — клиент банка и у нее есть там счет, документ — это распоряжение о покупке какого-либо товара или оплаты услуг. Считаем, что банк ставит на документе дату его исполнения.

В рассматриваемом протоколе TSA присваивает каждому документу индивидуальный порядковый номер (п) и нам будет удобно обозначать имя n-ого клиента как IDn (идентификатор клиента), а высылаемый им файл — как хп. Представим последовательность действий следующим образом:

1.Алиса вычисляет хеш-функцию H(x) и сообщает в TSA о желании датировать документ.

2.TSA, получив H(x), присваивает номер данному запросу (пусть это будет п) и вычисляет сертификат

Certn = (n,tn, IDn, H(xn), Ln), sn = CTSA(Certn),

где, как и ранее, tn — время получения H(x), sn — подпись TSA к Certn,. IDn — идентификатор Алисы, a Ln — «связующая информация» (linking information) или, короче, «связка»:

Ln = (tn-1, IDn-1, H(xn-1), H(Ln-1)).

Затем TSA дожидается поступления следующего запроса, которому присваивается номер п + 1, и высылает Алисе Certn, sn и имя последующего клиента IDn+1.

3. Алиса, получив Certn, sn, IDn+1, может проверить правильность датирования, убедившись, что время tn правильное, H(xn) совпадает с отправленным ей H(x) и подпись

5

TSA sn верна.

Заметим, что в этой схеме все документы как бы связаны в одну цепь в порядке их формирования TSA через Ln: n-й документ привязан к (n — 1).

Допустим теперь, что Боб решил проверить подлинность даты на документе Алисы х. Для этого он запрашивает у Алисы сертификат Certn, sn и IDn+1, проверяет подпись TSA sn. Если подпись не верна, он делает вывод о попытке подделки сертификата. Верности подписи было бы достаточно для проверки подлинности документа, если бы Боб доверял TSA. Но Боб предполагает, что не только Алиса, но и TSA могут не быть честными. По этой причине Боб проводит еще одну проверку: сначала он вычисляет H(Ln), которое мы обозначим через h*, а затем запрашивает сертификат у IDn+1, который по запросу вышлет ему Certn+1, sn+1 и IDn+2. Из Certn+1 Боб найдет Ln+1, по которому, в свою очередь, найдет H(Ln). Теперь он может сравнить это значение с ранее вычисленным h*. Если они не совпадают, то Алиса и TSA пытались подделать дату. Однако даже в случае совпадения Боб может провести еще одну дополнительную проверку: аналогично только что проведенной он может вычислить h**=H(Ln+1), затем запросить сертификат у IDn+2, который по запросу вышлет ему Certn+2, sn+2 и IDn+3. По этим данным он точно также найдет H(Ln+1) и сравнит это значение с h**. Если они совпадают, а у Боба все же остаются сомнения, он может аналогично сравнить H(Ln+2) у IDn+4. При желании он может двигаться по цепочке «информационно связанных» документов все дальше, переходя от n+2 к n+3 и т.д., до последнего датированного документа. Важно отметить, что двигаясь по цепочке сертификатов, Боб не получает сведений о содержании датированных документов, т.к. сертификаты содержат только значения их хеш-функций (но не сами документы).

Таким образом, описанное соединение документов в цепочку при помощи связок (Ln) в случае изменения (искажения, подделки) i- ого сертификата Certi приводит к тому, что все последующие сертификаты Certi+1, Certi+2, ... становятся недействительными. Это объясняется тем, что связка Li+1 «привязана» к предыдущей, Li.

Остановимся теперь на двух обобщениях описанной системы. Во-первых, можно формировать сертификат не для одного документа хп, а для целой группы, объединяя в один «блок» сообщения, поступившие за определенный период времени (скажем, за 10 минут). В этом случае сертификат Certn может содержать несколько ID и соответствующих им H, снабженных одним L. В этой ситуации естественно использовать название «блокчейн» (blockchain), или цепочка блоков или цепная запись данных.

Другое обобщение связано с заменой цепочки на дерево. Точнее, представим себе, что последовательность блоков и соответствующих им сертификатов растет как бинарное дерево, так, что у некоторых узлов дерева, соответствующим блокам, имеются два сына. Каждый блок, соответствующий сыну, привязан при помощи связки к L отца, но не связан с L своего «брата». Такие деревья с узлами, связанными при помощи хеш-функций, называются деревьями Меркля (Merkle Tree). В отличие от системы, когда все блоки связаны в одну цепь, древовидная структура позволяет просматривать при проверке не все данные, следующие за проверяемым блоком, а только часть дерева, выходящую из проверяемого узла. Возможны ситуации, когда такое уменьшение проверок дает некоторое уменьшение трудоемкости, правда за счет уменьшения надежности — короткую цепочку легче подделать.

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

Ln = (tn-1, IDn-1, H(xn-1), H(Ln-1),noncen),