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

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

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

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

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

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

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

Ниже настоящее изобретение описано со ссылками на сопровождающие чертежи, где:

на фиг.1 показана инфраструктура системы с открытым ключом;

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

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

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

на фиг.5 показана последовательность операций для процесса администрирования в отношении списка хеш-значений;

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

на фиг.7 показана вторая часть процесса, изображенного на фиг.6;

на фиг.8 показаны типичные хеш-значения и их списки;

на фиг.9 показана система, содержащая сеть с несколькими сетевыми узлами;

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

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

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

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

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

На фиг.1 показана типичная система с открытым ключом согласно первому аспекту настоящего изобретения. Система включает первый 11 и второй 13 серверы удостоверяющего центра, сервер 12 хеш-значений, а также клиентские терминалы 14-17. Серверы 11-13 и клиенты 14-17 связаны с сетью общего пользования, например с Интернетом. Сервер 11, 13 удостоверяющего центра отвечает за общее использование одного или нескольких таких центров в системах с открытым ключом, имеющих инфраструктуры с открытым ключом. Согласно настоящему изобретению, использование удостоверяющего центра в пределах системы хотя и поддерживается, но не требуется для безопасной доставки цифровых данных, например открытых ключей, как описано ниже. Кроме того, сервер хеш-значений или удостоверяющий центр могут также быть эмулированы распределенной одноранговой системой, например сформированной клиентскими терминалами 14-17 или их подмножеством. Соответствующий открытый ключ РК1-РК4 существует для каждого из клиентских терминалов 14-17 или для соответствующих пользователей клиентских терминалов 14-17.

В общем случае клиентские, то есть действующие от имени соответствующих пользователей терминалы 14-17 и серверы 11-13 общаются друг с другом через сеть общего пользования. Прямая связь, предпочтительно между каждым из серверов 11-13, которая не показана на фиг.1, может при необходимости обеспечить более безопасный маршрут связи, чем Интернет.

Обычно используемый сценарий осуществления безопасной связи между двумя терминалами в пределах системы с открытым ключом, которая обеспечивает определенный уровень целостности верифицируемой информации и аутентификацию пользователя, может быть осуществлен следующим образом. После запроса владельца (то есть клиента) открытого ключа РК1 удостоверяющий центр, например СА1 11, сначала выдает сертификат для открытого ключа РК1 клиентского терминала 14, таким образом удостоверяя, что РК1 является аутентичным и связан с клиентским терминалом 14 или соответствующим ему пользователем. Этот сертификат cert_CA1 (PK1) находится в открытом доступе или выдается на оставшиеся клиентские терминалы 15-17 в системе. Клиентский терминал 14 может затем получить данные, которые зашифрованы с помощью PK1 в этих терминалах. Однако такая аутентификация открытого ключа PK1 предполагает, что СА1 является третьим доверенным лицом, которому вынуждены доверять все терминалы, осуществляющие такую связь. Далее необходимо аутентифицировать РК для СА1 посредством цепочки сертификатов, ведущей к корневому СА. В общем случае концепция удостоверяющего центра основана на нефальсифицированном сертификате, который может быть подтвержден с использованием общедоступной информации, но должен быть выдан с использованием закрытой информации, известной лишь самому удостоверяющему центру. Это приводит к еще одному следствию. Приходится не только доверять удостоверяющему центру, но и сам процесс подтверждения должен быть защищен от фальсификации, - другими словами, необходимо обеспечить, чтобы информация для проверки сертификата, то есть открытый ключ СА1, не мог быть подменен злоумышленником.

Сервер 12 хеш-значений хранит в памяти список хеш-значений для открытых ключей. Согласно данному предпочтительному варианту выполнения настоящего изобретения, эти открытые ключи дополнительно подписаны по меньшей мере одним из центров 11 или 13. Хеш-значение для открытого ключа PK1 хранится в списке хеш-значений сервера 12 хеш-значений. Как более подробно описано ниже в отношении фиг.5, сервер 12 хеш-значений вычисляет хеш-значение для хранимого списка хеш-значений и выдает вычисленное хеш-значение и список хеш-значений, так что они становятся открыто доступными для всех терминалов. В последующем описании такое хеш-значение из списка хеш-значений называется также мета хеш-значением.

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

В одном из вариантов выполнения настоящего изобретения клиентский терминал 15 получает список хеш-значений и мета хеш-значение на его основе из сервера 12 хеш-значений. На основе полученного мета хеш-значения клиентский терминал 15 выполняет процесс аутентификации или верификации открытого ключа РК1 для клиентского терминала 14 перед тем, как использовать открытый ключ РК1 для верификации, аутентификации или шифровки данных. Кроме того, клиентский терминал 15 может также проверить аутентичность своего собственного открытого ключа РК2, включенного в список хеш-значений. Соответствующий процесс в клиентском терминале более подробно описан ниже со ссылками на фиг.6 и 7.

Сервер 12 хеш-значений на фиг.1 может быть также выполнен как часть серверов 11 и 13 удостоверяющего центра, как часть другого сервера в сети, осуществляющего хранение или обработку цифровых данных, которые нужно надежно распределить, с помощью одноранговой системы клиентских терминалов. В качестве хеш-алгоритмов можно, например, использовать SHA1 или MD5.

На фиг.2 показаны функциональные блоки сервера хеш-значений, изображенного на фиг.1.

Типичный сервер хеш-значений содержит центральный процессорный блок 21, сетевой интерфейсный блок 22, связанный с Интернетом, блоки 23 операторского ввода/вывода, предназначенные для взаимодействия с оператором, запоминающее устройство 24 и дополнительные запоминающие устройства 25, 26.

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

Запоминающее устройство 24 может быть организовано как оперативное запоминающее устройство (RAM), электрически стираемое программируемое постоянное запоминающее устройство (EEPROM), постоянное запоминающее устройство (ROM), жесткий диск, магнитный дисковод и/или привод оптического диска. Оперативная система сервера, а также прикладное программное обеспечение для выполнения необходимых операций хранятся в запоминающем устройстве 24.

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

На фиг.3 показан типичный список хеш-значений 32 для открытых ключей (РК1-РК4), записанных в сервере хеш-значений. Уникальный идентификатор, связанный с открытым ключом и, таким образом, связанный также с его хеш-значением, записан в колонке 31. Уникальные идентификаторы предпочтительно сформированы из адресов электронной почты соответствующих владельцев открытых ключей РК1-РК4. Список хеш-значений 32 дополнительно содержит мета хеш-значение для списка хеш-значений удостоверяющего центра СА2. Кроме того, этот список может дополнительно включать хеш-значение для открытого ключа удостоверяющего центра СА2.

Наконец, вычисляют мета хеш-значение для списка хеш-значений 32 или, предпочтительно, для списка хеш-значений 32 и связанных с ними адресов 31 электронной почты.

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

В колонке 41 помещен идентификатор пользователя, который является уникальным для пользователя. Идентификатор пользователя может, например, служить заменой или соответствовать адресам электронной почты на фиг.3 или же может быть связан с ними согласно дополнительной ссылочной таблице. Этот уникальный идентификатор 41 может также быть номером свидетельства социального страхования или любым другим опознавательным номером. Предпочтительно, чтобы сервер хеш-значений или удостоверяющего центра обеспечивал, чтобы для каждого уникального идентификатора всегда был только один действительный открытый ключ. Эта уникальная информация позволяет отправителю сообщения, которое зашифровано с использованием указанного открытого ключа, идентифицировать владельца этого открытого ключа. Колонка 42 содержит список открытых ключей для пользователей, идентифицированных в колонке 41. Колонка 43 содержит список сертификатов для связанных открытых ключей, сертификатов, выданных одним из центров СА1 или СА2. Каждая запись в списке 41-43 соответствует одной записи в списке хеш-значений на фиг.3.

Помимо открытых ключей РК1-РК4 для пользователей 1-4 последний пункт таблицы на фиг.4 включает открытый ключ РК_СА2 центра СА2. Соответствующий сертификат СА1_cert (РК_СА2) выдается центром СА1.

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

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

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

На шаге 53 вычисляют хеш-значение для открытого доступа.

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

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

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

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

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

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

В процессе 60-68 на фиг.6 на шаге 61 из первого сервера хеш-значений первоначально получают список хеш-значений и мета хеш-значение для него. После этого, на шаге 62 из второго сервера хеш-значений получают второе мета значение из списка хеш-значений в сервере хеш-значений. Наконец, на шаге 63 путем сравнения полученных мета хеш-значений определяют, соответствуют ли оба мета хеш-значения друг другу.

Кроме того, каждый из шагов 61 и 62 может дополнительно включать шаг верификации подписи, выданной соответствующим сервером хеш-значений для данного мета хеш-значения и/или шаг дешифровки полученной информации, если полученная информация зашифрована посредством ключа, например полученного в процессе взаимной аутентификации. Как станет более очевидным из последующего описания, различные подпроцессы, например шаги 64 и 65 или шаги 66 и 67, можно в качестве опции объединить с общими шагами 61-63, изменяя необходимый уровень безопасности в процессе аутентификации для открытого ключа.

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

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

После шага 63 сравнения мета хеш-значение вычисляют 64 в клиентском терминале на основе списка хеш-значений, полученного из сервера хеш-значений. Вычисленное мета хеш-значение сравнивают на шаге 65 с одним из полученных мета хеш-значений.

Кроме того, на шаге 66 хеш-значение вычисляют для специального открытого ключа РК, входящего в список хеш-значений. Предпочтительно, чтобы этот шаг 66 и последующий шаг 76 проводился по меньшей мере для желаемого открытого ключа, который должен быть аутентифицирован клиентским терминалом. На основе вычисленного хеш-значения Н(РК) соответствующее хеш-значение, хранимое в полученном списке хеш-значений, можно верифицировать путем сравнения 67. Если такое совпадение удается верифицировать, согласованность открытого ключа и списка хеш-значений считается установленной. Таким образом, путем верификации целостности и аутентичности списка хеш-значений с использованием мета хеш-значения можно аутентифицировать целостность открытого ключа, входящего в этот список, как описано ниже.

Процесс, иллюстрированный на фиг.6, продолжается шагами 71-74 на фиг.7, включая три дальнейших подпроцесса для процесса аутентификации.

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

Кроме того, сертификат рассматриваемого открытого ключа может быть верифицирован на дополнительном шаге 72. Наконец, для проверки, обладает ли третье лицо или предполагаемый владелец открытого ключа фактическим секретным ключом, соответствующим открытому ключу, на последующем дополнительном шаге 73 верифицируют подпись секретного ключа, обычно обращаясь к случайным данным, выдаваемым клиентским терминалом в качестве случайного запроса. В общем случае на шаге 73 для проверки обладания соответствующим секретным ключом к открытому ключу для предполагаемого владельца пары ключей можно использовать любой доступный способ типа "доказательства с нулевым знанием" (Zero-Knowledge-Proof-Of-Knowledge).

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

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

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

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

На фиг.8 список 800 включает цифровые данные 801, которые должны быть безопасно распределены между клиентскими терминалами. Эти цифровые данные 800 могут, например, соответствовать открытым ключам 42 или открытым ключам 42 вместе с соответствующими сертификатами 43 или представлять эти объекты, как показано на фиг.4. Каждая запись данных в списке 800 имеет уникальный идентификатор 802, аналогичный колонке 31 и колонке 41 на фиг.3 и 4. Список 800 дополнительно содержит хеш-значение 804, вычисленное для каждой записи 803 данных, соответствующей хеш-значению 32 на фиг.3.

Кроме того, второй идентификатор 801 ассоциируется с каждой записью в списке 800, предпочтительно задавая время, когда данные были внесены в список, в порядке возрастания по мере продолжения списка. В последующем описании колонка 801 называется временем поступления соответствующих данных. Следует отметить, что это время могло бы также соответствовать времени вычисления соответствующего хеш-значения 804, если оно отличается от времени поступления самих данных. Кроме того, соответствующее время в колонке 801 и уникальный идентификатор 802 данных для каждой записи данных можно заменить лишь одним уникальным идентификатором. Другой сценарий заключается в использовании одного из списков, показанных на фиг.3 и 4, и представлении временных параметров в дополнительном списке, причем предпочтительно, чтобы соответствующие записи были связаны друг с другом посредством указателей. Однако можно также не использовать такие идентификаторы 801, а вместо них реализовать описанную ниже концепцию, в которой используются другие способы или средства, которые обеспечивают такие же функциональные возможности связи различных вспомогательных хеш-значений 812 с соответствующими сегментами в таблице 800.

Записи в списке 800 разделены на последовательные сегменты. Предпочтительно, чтобы эти сегменты шли строго последовательно и не перекрывались. Однако они могут перекрываться или даже чередоваться. В данном предпочтительном варианте выполнения настоящего изобретения эти сегменты разделены в соответствии с временными интервалами. Естественно, со временем к списку 800 добавляются новые записи данных, например новые выданные открытые ключи для новых возможных клиентов и/или пользователей, работающих в сети, или для новых выпущенных продуктов программного обеспечения. Эти записи накапливают, а затем при необходимости вычисляют хеш-значения 804. Все записи, поступившие спустя некоторое время, например через час, через день или через неделю, в заданное время, и не входящие в другой сегмент, формируют следующий сегмент. Как показано на фиг.8, сегмент завершается в моменты времени Т150 и Т200. Следовательно, все записи, поступившие после момента Т150 и до запланированного момента Т200, формируют сегмент, а именно: все записи данных D101-D150. Согласно другому сценарию, список 800 сегментируют по числу записей данных, формируя, таким образом, сегменты из равного количества записей, а не из равных отрезков времени для данных, входящих в список. В еще одном сценарии должны использоваться различные сегменты для различных видов данных или для различных видов идентификаторов данных, например адресов пользователей электронной почты. Последний сценарий представляет собой еще одну процедуру сегментации, которая не определяется только временем попадания данных в список.

Каждый сегмент списка 800 используется для вычисления вспомогательного хеш-значения. Это является аналогом генерации мета хеш-значения для списков, показанных на фиг.3 и 4, если рассматривать каждый сегмент как отдельный список. Аналогично случаю мета хеш-значения, идентифицированный хеш алгоритм для вспомогательного хеш-значения может быть применен или исключительно к рассматриваемым данным, или к этим данным и к оставшимся записям в каждом ряду списка. В данном случае вспомогательного хеш-значения, хеш-алгоритм может быть применен ко всем хеш-значениям 804 в соответствующем сегменте или, предпочтительно, ко всем хеш-значениям 804 и к соответствующим данным 803, идентификаторам (ID) данных 802 и временам 801 в сегменте, или к любому поднабору или заданной комбинации перечисленных объектов. Вспомогательное хеш-значение 812 для каждого сегмента в списке 800 является записью в другом списке 810, который дополнительно включает хеш-идентификатор 811 для каждого вспомогательного хеш-значения. Этот список 810 может храниться как отдельный список или как "виртуальный список", если, например, он входит в список 800 с дополнительным индикатором, например флагом, идентифицирующим записи для вспомогательных хеш-значений.

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

Теперь записи в списке 810 используют для вычисления мета хеш-значения 821, как показано в отдельном списке 820. Вновь этот список может входить в любой другой список, например в список 800 или 810. Можно даже распределить или опубликовать последнее мета хеш-значение и удалить старое, таким образом не сохраняя мета хеш-значения, как показано в списке 822 на фиг.8. Это мета хеш-значение вычисляют, как было описано выше со ссылками на фиг.3-5. Понятно, что список 810 можно рассматривать как список, изображенный на фиг.3, где каждое вспомогательное хеш-значение 812 соответствует хеш-значению в колонке 32, а идентификаторы 811 хеш-значений соответствуют колонке 31. Как и в вышеописанном процессе аутентификации, мета хеш-значение распределяют и связывают с информацией о времени или информацией о действительности, например, с хеш-идентификатором 822, определяя время его вычисления, что необходимо для указания, все ли еще действительны полученное мета хеш-значение и соответствующий список хеш-значений или, например, уже имеется более поздняя их версия. В принципе, эта информация требуется только для одного из мета хеш-значений или списка (HVL) соответствующих хеш-значений до тех пор, пока оба идентифицируются как соответствующие друг другу.

Согласно данному предпочтительному варианту выполнения изобретения, мета хеш-значение 821 вычисляют вместе с последним вспомогательным хеш-значением 812, охватываемым мета хеш-значением. На примере, показанном на фиг.8, мета хеш-значение mh1 вычисляют в момент Т150, как обозначено соответствующим идентификатором 822 хеш-значений. В этом случае идентификатор является тем же, что и идентификатор 811 хеш-значений для соответствующего последнего охваченного вспомогательного хеш-значения ah2. В другом варианте выполнения изобретения могут использоваться независимые расписания для вычисления хеш-значений 812 и 821, которые не совпадают в отношении полностью охваченных сегментов. Как показано на фиг.8, мета хеш-значение mh2 вычислено в момент Т222, тогда как последнее охваченное вспомогательное хеш-значение аh3 охватывает записи данных в списке 800 до момента Т200. Этот сценарий иллюстрирует отличие от случая данного предпочтительного варианта выполнения изобретения, согласно которому мета хеш-значение (то есть mh2) не охватывает все данные 803 (то есть, от D201 до D222), поступившие в то время (то есть Т222), когда было вычислено мета хеш-значение.

Согласно данному предпочтительному варианту выполнения изобретения, процесс аутентификации отличается от вышеописанного процесса аутентификации следующим. Шаги 61-65 применимы в соответствие с описанным в отношении фиг.6. Эти шаги включают шаг 63 сравнения по меньшей мере двух мета хеш-значений для одного и того же рассматриваемого в данное время списка хеш-значений, причем каждое получено из разных источников на шагах 61 и 62. Затем на шаге 65 эти мета хеш-значения сравнивают с локальным мета хеш-значением, вычисленным клиентским терминалом по соответствующему списку хеш-значений, который в данном варианте выполнения изобретения является списком 810. Путем верификации факта, что все рассматриваемые мета хеш-значения для этого списка хеш-значений совпадают, можно установить аутентичность и целостность этого списка хеш-значений на основе того, что источники полученных мета хеш-значений являются различными и независимыми. Затем вычисляют мета хеш-значение 821 с использованием вспомогательных хеш-значений 812. Таким образом, данные 803, которые подлежат аутентификации в клиентском терминале, например открытый ключ РК, непосредственно не соответствуют никакому хеш-значению в списке вспомогательных хеш-значений 810, полученном на шаге 61. Поэтому перед продолжением шага 66 и последующих за ним шагов необходимо выполнить следующие шаги.

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

Согласно первому варианту выполнения изобретения, относящемуся к процессу аутентификации, клиентский терминал устанавливает, какое вспомогательное хеш-значение 812 соответствует рассматриваемому открытому ключу 803, подлежащему аутентификации, и какой сегмент списка 800 соответствует этому вспомогательному хеш-значению 812. Таким образом, клиентский терминал устанавливает, какой сегмент включает указанный открытый ключ. Затем клиентский терминал запрашивает этот идентифицированный сегмент списка 800 по меньшей мере у одного заданного сервера, предпочтительно у того же самого сервера хеш-значений, который выдает также список хеш-значений. Для выполнения этих шагов установления и запроса можно использовать и рассматривать различные подходы в рамках изобретения. Один из возможных подходов состоит в том, чтобы связать каждый открытый ключ с информацией о времени, которую сертификатор, например клиентский терминал, может установить. Такая информация однозначно определяет соответствующий сегмент в списке 800, что и используется в данном предпочтительном варианте выполнения изобретения. Однако различные подходы могут не (только) использовать упорядоченные во времени сегменты или могут не использовать идентификаторы 800, 811 и/или 822 времени. В другом подходе может, например, иметься идентификатор, который связан с каждым ключом, непосредственно определяющий или указывающий соответствующий сегмент. В еще одном подходе идентификатор 811 хеш-значений может включать информацию, обеспечивающую идентификацию всех охватываемых открытых ключей 803. Таким образом, клиент может идентифицировать соответствующее вспомогательное хеш-значение 812 для указанного открытого ключа, которое, в свою очередь, определяет желаемый сегмент в списке 800.

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

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

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

Получив сегмент списка 800, соответствующий рассматриваемому открытому ключу 803, клиентский терминал может продолжить работу шагом 66 и последующими шагами процесса аутентификации, как показано на фиг.6.

Преимущество данного предпочтительного варианта выполнения изобретения, в котором используются вспомогательные хеш-значения, является уменьшение количества распределяемых хеш-значений. Когда новое мета хеш-значение вычислено и выдано в клиентские терминалы, необходимо также распределить новый, расширенный список хеш-значений, из которого вычислено мета хеш-значение, и на это имеются две очевидные причины. Первая, для максимальной безопасности список хеш-значений должен охватывать полный список данных 803, который необходимо распределить или выдать. Второе, согласно шагам 64 и 65, в вышеописанном процессе аутентификации мета хеш-значение вычисляется также клиентским терминалом, которому требуется полный список хеш-значений. Список 810 вспомогательных хеш-значений, из которого вычисляется мета хеш-значение 821, все еще охватывает все данные 803, но содержит меньше записей, чем первоначальный список 800. Таким образом, первоначально на клиентские терминалы нужно подать список с меньшим количеством записей. Сокращение размера первоначального списка 800 до списка 810 вспомогательных хеш-значений непосредственно зависит от размеров сегментов. Однако увеличение размеров сегментов подразумевает, например, наличие больших временных рамок для каждого сегмента, что может быть нежелательным. Это означает, что в процессе аутентификации в клиентский терминал придется передать больше сегментов и, таким образом, больше данных, что также является нежелательным. В связи с этим в еще одном варианте выполнения изобретения предусмотрены многоуровневые сегменты, в которых используется концепция списка вспомогательных хеш-значений последовательно со списком 810 хеш-значений в соответствие с древовидной структурой, в качестве корня которой взято мета хеш-значение. В частности, полученный список 810 хеш-значений сегментирован согласно любому из вышеописанных вариантов выполнения изобретения. Эти сегменты используются для вычисления второго набора вспомогательных хеш-значений, аналогичного списку 810, вместо целевого результирующего мета хеш-значения 822. Эту процедуру можно повторить для любого количества уровней, причем глубина уровня может быть как заданной величиной, так и переменной. В частности, при использовании вышеупомянутого второго варианта выполнения изобретения, согласно которому в процессе аутентификации назначенный сервер определяет и выдает требуемый сегмент в клиентский терминал, последовательная многоуровневая организация и генерация вспомогательных хеш-значений будут целиком внутренними процессами для сервера, в результате чего требуемое управление списком и организация связей не затрагивает клиентские терминалы. Таким образом, сервер или несколько серверов могут создавать многоуровневые сегменты, соответствующие их внутренним функциональным возможностям.

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

Еще один вариант выполнения изобретения, относящийся к созданию списка хеш-значений, необходимых для вычисления мета хеш-значения, заключается в следующем. Этот полный список хеш-значений - список 800, 32 или, если применим, список 810 - необходим для вычисления мета хеш-значения. Следует вновь отметить, что полный список в этом смысле относится по меньшей мере ко всем хеш-значениям 804, 812 или 32 из указанного списка, но может содержать произвольное, но заданное количество дополнительных записей из соответствующего списка. Однако можно воспользоваться тем фактом, что этот список накапливался в течение долгого времени путем добавления новых записей в этот продолжающийся список. Однажды попав в список, запись остается неизменной. Таким образом, новый список хеш-значений, соответствующий новому мета хеш-значению, включает все записи ранее действительного списка хеш-значений. Это позволяет при получении нового хеш-значения обновлять список хеш-значений в клиентском терминале, а не заменять весь список. Предположим, что клиентский терминал уже обладает списком хеш-значений при получении нового мета хеш-значения для этого списка. Вместо того, чтобы получить новый соответствующий список хеш-значений, клиентский терминал может получить в этот список хеш-значений только новые записи, а затем должным образом изменить список, уже имеющийся на месте. Этот вариант выполнения изобретения можно комбинировать с подходом с сегментированным списком и, возможно, многоуровневыми сегментами.

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

В дополнение к перекрестной адресации отдельных хеш-значений между различными списками, сами списки хеш-значений, например, выданные различными серверами 12 хеш-значений или служб 11, 13 сертификации, также могут быть объединены в один список. Кроме того, объединенный список может быть представлен третьим лицом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно данному предпочтительному варианту выполнения изобретения в отношении данного вопроса, вышеописанный многоуровневый подход шифрования применен к распределению цифровых данных через сеть, включающую несколько узлов. До сих пор безопасное распределение цифровых данных через сеть согласно настоящему изобретению было описано в терминах дистрибьютора или отправителя и получателей этих цифровых данных. Однако те же самые концепции можно применить к сети, которая используется как среда для распределения цифровых данных. Поэтому на фиг.9 показан типичный пример сети 900, включающей несколько узлов 906-909. Эти узлы сети обычно связаны и способны к обмену данными друг с другом. Различные терминалы и серверы 901-905 общаются друг с другом через указанную сеть 900 и сами могут рассматриваться как узлы сети. Согласно данному предпочтительному варианту выполнения изобретения, сеть 900 представляет собой Интернет. Связи между множеством узлов в сети обычно устанавливаются через различные линии связи между этими узлами, в результате чего возможны одна или несколько прямых связей или связей через другие узлы. На фиг.9 отправитель 901 стремится послать цифровые данные получателю 902 через сеть 900. Цифровые данные, которые будут переданы в пользовательский терминал 902, зашифрованы до передачи этих зашифрованных данных с использованием по меньшей мере шифрования с открытым ключом при использовании открытого ключа получателя. Для этого отправитель 901, который, как предполагается, предварительно зашифровал данные, получает открытый ключ получателя 902. Согласно предпочтительному варианту выполнения изобретения, для безопасного обеспечения отправителя 901 открытым ключом получателя 902 используются списки хеш-значений, как описано для такой системы с открытым ключом. Все соображения относительно списков хеш-значений остаются справедливыми и поэтому в дальнейшем не обсуждаются.

Получив открытый ключ доступа получателя 902, отправитель 901 шифрует цифровые данные согласно вышеуказанной концепции многоуровневого шифрования, которая применима не только к отправителю и получателю, но также и к узлам сети. Согласно одному из вариантов выполнения изобретения, один или несколько сетевых узлов выполняют соответственно один или несколько процессов шифрования и дешифровки, соответствующие различным уровням шифрования, как описано выше. Например, узел 906 может дополнительно зашифровать сообщение (зашифрованные данные и симметричный ключ), посланное отправителем 901, а с другой стороны, узел 909 может дешифровать зашифрованные данные и/или зашифрованный ключ согласно одному или нескольким уровням шифрования перед тем, как передать это сообщение получателю 902.

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

В рассматриваемом примере предполагается, что зашифрованные данные предназначены для посылки через узел А (906) и узел D (909) получателю 902. Такое задание маршрута через известные и заданные узлы сети может потребоваться, например, в целях безопасности, ради отслеживания сеанса связи и для регистрации информации, связанной с распределением данных, которое реализуется указанными узлами сети. Следует вновь отметить, что в общем случае любой терминал или сервер, связанный с этой сетью 900, может сам рассматриваться как узел сети, и поэтому перед тем, как послать передаваемые данные конечному получателю 902, их может быть необходимо послать в специальный сервер аутентификации или подтверждения. На фиг.10 на шаге 111 отправитель сначала зашифровывает цифровые данные посредством ключа S шифрования. Затем сам этот симметричный ключ S зашифровывают с использованием открытого ключа, соответствующего получателю 902, как показано на шаге 112. Следуя шагам шифрования 113 и 114, полученный в результате зашифрованный симметричный ключ S вновь зашифровывают, применяя в соответствующих процессах шифрования первый открытый ключ РК_d узла D и второй открытый ключ РК_а узла А. Затем этот зашифрованный ключ S шифрования посылают вместе с зашифрованными данными (шаг 115) в сеть, в частности в узел А.

При таком многоуровневом шифровании, в котором используется первый открытый ключ узла D, а затем открытый ключ узла А, отправитель обеспечивает ситуацию, когда зашифрованное сообщение посылается получателю 902 через узел А и узел D, как будет понятно из последующего описания в связи с фиг.11 и 12.

На фиг.10 показана последовательность операций, которая продолжается на фиг.11.

Узел А получает сообщение, которое выслал отправитель 901, причем сообщение состоит из зашифрованных цифровых данных и асимметрично зашифрованного ключа S. Узел дешифрует зашифрованный ключ S с использованием своего секретного ключа SK_a, как показано шагом 121. Поскольку только узел А обладает этим секретным ключом, который соответствует открытому ключу, использованному отправителем на шаге 114, этот шаг 121 дешифровки выполняет только узел А. Понятно, что этот шаг 121 дешифровки противоположен шагу 113 шифрования, который был выполнен отправителем 901. Для получения в конце концов ключа S шифрования, необходимого для дешифровки зашифрованных данных, все шаги шифрования должны быть полностью инвертированы на соответствующем шаге дешифровки. Следовательно, получатель 902, получив сообщение, посланное отправителем 901, может дешифровать ключ S шифрования, только если, соответственно, узел А действительно дешифровал зашифрованный ключ S. Это обеспечивает ситуацию, при которой данные могут быть дешифрованы только тогда, когда они переданы через узел А. Кроме того, следует отметить, что для безопасности системы существенно, чтобы отправитель 901 мог быть уверен, что при выполнении шага 114 шифрования он применил аутентичный открытый ключ РК_а, связанный с узлом А. Это необходимое аутентифицированное соответствие открытого ключа РК_а и узла А предпочтительно достигается путем распределения открытых ключей с помощью вышеописанных списков хеш-значений и, возможно, цифровых сертификатов. То же относится ко всем открытым ключам, используемым в этом процессе распределения.

На фиг.9 и 11 предполагается, что узел А в соответствии с указанием отправителя 901 передает сообщение в узел D. Эти параметры маршрута могут содержаться в сообщении и анализироваться каждым узлом сети. Однако в этом типичном примере сообщение посылается в узел D через узел В сети. Как показано в последовательности операций на фиг.11, вследствие этого узел А предписывает и обеспечивает, чтобы сообщение посылалось через узел В. Соответственно, на выходе шага 121 дешифровки ключ S, который все еще зашифрован в отношении открытого ключа PK_d, шифруют с использованием открытого ключа узла В. Как обсуждалось в отношении узла А, чтобы в результате оказалось возможным в конце концов получить простой текст ключа S шифрования, сообщению необходимо пройти через узел В. Затем узел А посылает зашифрованные данные вместе с зашифрованным ключом S в узел В.

Теперь узел В может послать полученное сообщение еще и в другие узлы сети помимо целевого узла D (не показано). Необходимые для этого шаги были бы аналогичны шагам 120-123 на фиг.11. Однако следует отметить, что шаг 122 является необязательным шагом, и узел А мог бы послать сообщение в узел В без шифрования ключа S специально для узла В.

Типичная последовательность операций, изображенная на фиг.11, продолжена на фиг.12, где показано, как на шаге 130 узел В получает сообщение. Следующий шаг 131 соответствует шагам 121, но в отношении узла В и его секретного ключа. Узел В в конечном счете посылает результирующее сообщение в узел D, который выполняет процесс дешифровки (шаг 134) в отношении зашифрованного ключа S и его секретного ключа. Наконец, сообщение посылается получателю 902, как показано шагом 135. Получив обе части сообщения (шаг 136), получатель оказывается в состоянии дешифровать ключ S на шаге 137 путем применения своего секретного ключа РК_R. При таком доступе к ключу S как к простому тексту получатель может затем дешифровать полученные данные, как показано шагом 138.

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

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

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

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

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

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

Сервер генерирует или получает безопасную и конфиденциальную случайную величину R. Этот шаг 142 на фиг.13а может быть выполнен один раз, а затем эта величина может быть зафиксирована на этом сервере или может быть восстановлена или обновлена с течением времени. Получив и, если требуется, дешифровав маркер Т, сервер вычисляет хеш-значение для сообщения, по меньшей мере включающего маркер Т и случайно выбранную, но фиксированную величину R, как показано на шаге 144. Вычисленное хеш-значение обозначено S и служит информацией о симметричном ключе для безопасной связи между сервером и клиентом, составляя общий секрет для этих двух объектов. Сервер раскрывает этот общий секрет S клиенту, возможно после асимметричного шифрования с использованием ранее полученного открытого ключа для клиента, как показано на шаге 145. Сервер не должен хранить ни эту величину S или маркер S данных, ни сведения по идентификации соответствующего клиента.

Вместо этого, как показано на шагах 146 и 147, клиент может симметрично зашифровать сообщение, то есть цифровые данные, которые нужно безопасно и конфиденциально послать в сервер. Вместе с этим сообщением в сервер также передается маркер Т. Для этого и для последующей передачи сообщений и данных можно использовать все ранее описанные альтернативные варианты выполнения изобретения, относящиеся к вышеуказанным способам распределения. Если маркер был зашифрован, например, открытым ключом сервера, сервер соответственно дешифрует маркер Т, как обозначено необязательным шагом 148. После этого сервер легко может повторно вычислить общий секрет S, который использовался для симметричного шифрования рассматриваемого сообщения. Аналогично шагу 144, на шаге 149 сервер хеширует маркер Т и секретную случайную величину R. С помощью этого вычисленного значения S на шаге 150 сервер дешифрует полученное сообщение. Возможное желательное сообщение с ответом клиенту может быть зашифровано с использованием той же самой величины S и соответствующей схемы симметричного шифрования, как показано шагами 151 и 152, поскольку обе стороны обладают значением S, которое является для них общим секретом. Альтернативно, аналогичный процесс можно выполнить с использованием нового общего секрета S.

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

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

Согласно еще одному варианту выполнения изобретения, маркер Т заменяют новым маркером Т после каждого соединения или после указанного количества соединений между сервером и клиентом. Для этого новым маркером Т может служить часть сообщения, которое посылал клиент серверу. Альтернативно, она может использоваться для генерации нового маркера, например с использованием указанной функции, возможно, включающей хеширование этой части сообщения. Это подразумевает, что сервер предоставляет клиенту новое значение S, например, посылая его клиенту вместе с сообщением-ответом. В частности, в процессе такой связи сервер получает от клиента сообщения. Часть этих сообщений является основой для нового маркера. Согласно нескольким рассмотренным процедурам для этого варианта выполнения изобретения, эта часть может быть частью зашифрованного сообщения, частью дешифрованных данных в сообщении, хеш-значением для одной или обеих вышеупомянутых частей или только их части, или любой комбинацией этих сегментов данных. Затем сервер вычисляет новую криптографическую информацию S по новому маркеру и случайной величине R, как описано и показано на шагах 144 и 149. Однако сообщение-ответ клиенту или его данные зашифрованы с использованием старого предыдущего ключевого значения S, как описано в шагах на фиг.13а и 13b. Это зашифрованное сообщение-ответ дополнительно включает новое ключевое значение S, которое также зашифровано с использованием старого ключевого значения S и выслано вместе с сообщением-ответом клиенту. Возможно также, что сообщение-ответ включает только этот новый ключ S.

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

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

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