АНАЛИТИЧЕСКИЙ ОБЗОР ИНФРАСТРУКТУРЫ ПОДПИСЕЙ БЕЗ ИСПОЛЬЗОВАНИЯ КЛЮЧА

Подписи без ключа являются альтернативным решением для традиционных подписей, которые используются в инфраструктуре открытых ключей. Слово «без ключа» не означает, что криптографические ключи не используются во время создания подписи. Ключи по-прежнему необходимы для аутентификации, но сами подписи могут быть надежно проверены без необходимости сохранять секретность ключей. Таким образом система подписей без ключа не подвергаются компрометации ключей и, тем самым, обеспечивает решение проблемы долгосрочной достоверности цифровых подписей. Традиционные подписи в PKI могут быть защищены штампами времени, но пока технология штампов времени [1] сама по себе основана на PKI, проблема компрометации ключа остается открытой. При реализации подписи без ключа, функция идентификации владельца подписи и функция защиты целостности подписи разделяются и передаются криптографическим методам, которые лучше подходят соответствующей функции. Например, идентификация владельца подписи может быть все еще выполнена с использованием криптографических систем с открытым ключом, но целостность подписи защищена с помощью шифрования без ключа, так называемой односторонней беспорядочной хеш-функции, которая является обычным математическим метод, не использующим закрытых ключей.

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

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

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

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

Чтобы использовать такие подписи на практике, нужна подходящая инфраструктура Keyless Signatures Infrastructure — аналогична PKI. Такая инфраструктура представляет множество серверов агрегации, которые вместе создают глобальные хэш-деревья каждый раунд. Серверы агрегации первого уровня - шлюзы - отвечают за сбор запросов непосредственно от клиентов; каждый сервер агрегации получает запросы от серверов нижнего уровня, хэширует их вместе в хеш-дерево и отправляет верхнее хэш-значение дерева в на серверы более высокого уровня. Затем сервер ожидает ответа от сервера более высокого уровня и путем объединения полученного ответа с подходящими цепочками хеширования из собственного дерева хешей - создает и отправляет ответы для каждого сервера нижнего уровня.

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

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

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

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

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

SI использует механизм хеширования и публикации для защиты целостности информации: во-первых, данные хэшируются, во-вторых, хеши данных хэшируются в хеш-дерево для масштабируемости, в-третьих, корень хэш-дерева публикуется в широко засвидетельствованном месте (СМИ).

Если подписи на цифровом активе будут защищены таким образом, невозможно будет подвергнуть сомнению существование подписей завтра. Но, по-прежнему существует угроза злоупотребления ключами аутентификации для подписей KSI, но сделать подпись «задним числом» математически невозможна [3, 4, 5, 6]. Чтобы предотвратить подпись «задним числом» в PKI, необходима надежная служба штампа времени. Интернет-стандарт криптографического штампа времени [2] не является полноценным решением, потому что: во-первых, задействованы человеческие факторы (можно было подкупить центр TSA, чтобы, например, изменить штаны времени) и во-вторых, подпись TSA также зависит от того, как долго будет секретен закрытый ключ.

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

Существует несколько причин, по которым серверные подписи могут быть предпочтительнее, например:

1. снижение вычислительных затрат на создание цифровых подписей пользователей

2. снижение риска неправильного использования криптографических ключей пользователями

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

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

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

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

Таблица 1.

Сравнение PKI и KSI

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

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

Список литературы:

1. Adams С. Internet X.509 Public Key Infrastructure Time-Stamp Protocol  (TSP) / Request for Comments 3161 URL: https://www.ietf.org/rfc/rfc3161.txt (дата обращение: 21.12.2017)
2. Asokan N., Tsudik G. Waidner, M.: Server-supported signatures // Journal of Computer Security 5 (1) (1996), P. 131–143
3. Buldas, A., Laanoja, R.: Security proofs for hash tree time-stamping using hash functions with small output size //ACISP 2013 P. 235–250
4. Buldas A. Laanoja, R. Laud, P. Truu, A., Bounded preimage awareness and the security of hash-tree key-less signatures // ProvSec 2014, LNCS 8782, P. 130–145
5. Buldas,A., Niitsoo M., Optimally tight security proofs for hash-then-publish time-stamping. // ACISP 2010 P. 318–335.
6. Buldas A., Saarepera M., On provably secure time-stamping schemes,: ASIACRYPT 2004 P. 500–514. Springer
7. Merkle R.C., Protocols for public-key cryptosystems // Proceedings of the 1980 IEEE Symposium on Security and Privacy P. 122–134