УСТРОЙСТВО ОБРАБОТКИ ИНФОРМАЦИИ, УСТРОЙСТВО ОБРАБОТКИ ВЕРИФИКАЦИИ И ИХ СПОСОБЫ УПРАВЛЕНИЯ Российский патент 2008 года по МПК G06F3/00 G07D7/00 G06K3/00 

Область техники, к которой относится изобретение

Настоящее изобретение имеет отношение к устройству обработки информации, устройству обработки верификации и их способам управления.

Уровень техники

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

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

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

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

Цифровая подпись

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

Пусть Ks (2106) является секретным ключом, и Kp (2111) является открытым ключом. Отправитель применяет процесс 2102 хеширования к данным М. (2101) для вычисления значения дайджеста H(M) 2103 как данных фиксированной длины. Затем отправитель применяет процесс 2104 подписи к данным фиксированной длины H(M) с использованием секретного ключа Ks (2106) для формирования данных S (2105) цифровой подписи. Отправитель отправляет эти данные S (2105) цифровой подписи и данные М (2101) получателю.

Получатель преобразовывает (расшифровывает) принятые данные S (2110) цифровой подписи с использованием открытого ключа Kp (2111). Получатель формирует значение дайджеста фиксированной длины: H (M) 2109 путем применения процесса 2108 хеширования к принятым данным М (2107). Процесс 2112 верификации проверяет, соответствуют ли расшифрованные данные значению дайджеста H(M) или нет. Если два набора данных не соответствуют друг другу в результате этой верификации, может быть обнаружено, что данные были изменены.

Для цифровой подписи используются такие криптографические системы с открытым ключом, как RSA, DSA (будут подробно описаны позже) и т.п. Безопасность этих цифровых подписей основана на факте, что для субъекта, кроме держателя секретного ключа, трудно в терминах вычислений подделать подпись или декодировать секретный ключ.

Хеш-функция

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

В особенности, односторонняя хеш-функция отличается тем, что если заданы данные М, то трудно в терминах объема вычислений вычислить данные М' открытого текста, которые удовлетворяют условию H(М') = H(M). В качестве односторонней хеш-функции доступны такие стандартные алгоритмы, как MD2, MD5, SHA-1 и т.п.

Криптографическая система с открытым ключом

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

Известны цифровые подписи, использующие криптографическую систему с открытым ключом, подпись RSA, подпись DSA, подпись Шнорра (Schnorr) и т.п. В этом случае будет проиллюстрирована подпись RSA, описанная в Р.Л.Райвест (R.L. Rivest), А. Шамир (A. Shamir) и Л. Альдеман (L. Aldeman): "Способ получения цифровых подписей и криптографические системы с открытым ключом", Communications of the ACM, v. 21, n. 2, стр 120 - 126, февраль 1978. Также дополнительно будет объясняться подпись DSA, описанная в Федеральном стандарте обработки информации (FIPS) 186-2, Стандарт цифровой подписи (DSS), январь 2000.

Подпись RSA

Генерируются простые числа p и q для получения n = pq. λ(n) определяется как наименьший общий множитель для p-1 и q-1. Выбирается число e, взаимно простое (не имеющее общих делителей) с λ(n) для получения секретного ключа d = 1/e (mod λ(n)), где e и n являются открытыми ключами. Также пусть H() является хеш-функцией.

Формирование подписи RSA

Последовательность формирования подписи для документа М.

Пусть s: = H (M) ^d (mod n) является данными подписи.

Верификация подписи RSA

Последовательность верификации подписи (s, T)

для документа М.

Документ верифицирован, если H(M) = s^e (mod n).

Подпись DSA

Пусть p и q являются простыми числами, и p-1 является значением, которое делит q (является делителем q). Пусть q является элементом (производящим элементом) порядка q, который произвольно выбран из Z_p* (мультипликативной группы за исключением нуля из циклической группы Z_p порядка p). Пусть x, произвольно выбранное из Z_p*, является секретным ключом для получения открытого ключа у путем y: = g^x mod p. Пусть H() является хеш-функцией.

Формирование подписи DSA

Последовательность формирования подписи для документа М.

1) α является произвольно выбранным из Z_q для получения T: = (g^ α mod p) mod q.

2) Получаем c: = H(M).

3) Получаем s: = α ^ - 1 (с + хТ) mod q, чтобы определить (s, T) как данные подписи.

Верификация подписи DSA

Последовательность верификации подписи (s, T) для документа М.

Документ верифицирован, если T = (g^(h(M) s ^-1) y ^ (T s ^-1) mod p) mod q.

Инфраструктура открытых ключей

Для обращения к ресурсам на сервере в коммуникации клиент-сервер требуется аутентификация (подтверждение подлинности) пользователей. В качестве одного средства аутентификации пользователей используется сертификат для открытого ключа, такой как описан в рекомендации X.509 Международного союза электросвязи (ITU-U) и т.п. Сертификат для открытого ключа представляет собой данные, которые гарантируют привязку между открытым ключом и его пользователем, и является подписанным в цифровой форме доверенным третьим лицом, называемым центром сертификации (CA). Схема аутентификации пользователей с использованием протокола SSL (протокола безопасных соединений SSL), используемая в браузере, реализована путем подтверждения, имеет ли пользователь секретный ключ, соответствующий открытому ключу, включенному в сертификат для открытого ключа, предоставленный пользователем.

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

В рекомендации X.509 v.3 Международного союза электросвязи (ITU-U), описанной в рекомендации X.509/ISO/IEC 9594-8 Международного союза электросвязи (ITU-U): "Информационная технология - Взаимодействие открытых систем - Каталог: Структура сертификата для общего ключа и атрибутов", идентификатор и информация открытого ключа субъекта, которые должны быть заверены (сертифицированы), включаются как данные, которые должны быть подписаны. С помощью операции подписи, такой как упомянутый выше алгоритм RSA и т.п., для дайджеста, полученного путем применения хеш-функции к этим данным, которые должны быть подписаны, формируются данные подписи. Данные, которые должны быть подписаны, имеют дополнительное поле "extensions" ("расширения"), которое может включать в себя расширенные данные, уникальные для приложения или протокола.

Фиг.15 показывает формат, определенный рекомендацией X.509 v.3, и ниже будет объяснена информация, показанная в каждом индивидуальном поле. Поле 1501 "version" ("версия") хранит версию рекомендации X.509. Это поле является необязательным и представляет значение v1, если оно опущено. Поле 1502 "serial Number" ("серийный номер") хранит серийный номер, уникально назначенный центром сертификации (CA). Поле 1503 "signature" ("подпись") хранит схему подписи сертификата открытого ключа. Поле 1504 "issuer" ("издатель") хранит идентификационное имя формата X.500 центра сертификации (CA) как издателя сертификата открытого ключа. Поле 1505 "validity" ("срок действия") хранит период действия (дата начала и дата конца) открытого ключа.

Поле 1506 "subject" ("субъект") хранит идентификационное имя формата X.500 держателя секретного ключа, соответствующего открытому ключу, включенному в этот сертификат. Поле 1507 "subjectPublicKeylnfo" ("информация открытого ключа субъекта") хранит открытый ключ, который сертифицирован. Поле 1508 "issuerUniqueIdentifier" ("уникальный идентификатор издателя"), и поле 1509 "subjectUniqueIdentifier" ("уникальный идентификатор субъекта") являются необязательными полями, добавленными со времени версии v2, и соответственно хранят уникальные идентификаторы центра сертификации (CA) и держателя.

Поле 1510 "extensions" ("расширения") является необязательным полем, добавленным в версии v3, и хранит наборы трех значений, то есть тип расширения (extnId) 1511, критический бит (critical) 1512 и значение расширения (extnValue) 1513. Поле "extensions" ("расширения") версии v3 может хранить не только стандартный тип расширения, определенный рекомендацией X.509, но также и уникальный новый тип расширения. Поэтому то, как распознавать поле "extensions" ("расширения") версии v3, зависит от стороны приложения. Критический бит 1512 указывает, является ли этот тип расширения обязательным или им можно пренебречь.

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

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 является диаграммой, показывающей пример компоновки системы, соответствующей вариантам воплощения настоящего изобретения;

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

Фиг.3 является блок-схемой, показывающей пример компоновки аппаратных средств системы, соответствующей вариантам воплощения настоящего изобретения;

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

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

Фиг.6A и 6B являются изображениями для объяснения примера цифровых данных, соответствующего вариантам воплощения настоящего изобретения;

Фиг.7A и 7B являются изображениями для объяснения промежуточного цифрового документа и цифрового документа, соответствующих вариантам воплощения настоящего изобретения;

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

Фиг.9A и 9B являются изображениями, показывающими пример структуры цифрового документа, соответствующей вариантам воплощения настоящего изобретения;

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

Фиг.11A и 11B являются изображениями, показывающими пример структуры данных подписи после процесса преобразования, соответствующей вариантам воплощения настоящего изобретения;

Фиг.12 является изображением для объяснения примера просмотра цифровых данных, соответствующего третьему варианту воплощения настоящего изобретения;

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

Фиг.14A является диаграммой, показывающей общий пример процесса формирования подписи;

Фиг.14B является диаграммой, показывающей общий пример процесса верификации подписи; и

Фиг.15 является изображением для объяснения формата данных сертификата открытого ключа X.509 v.3.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Теперь будут подробно описаны предпочтительные варианты воплощения настоящего изобретения в соответствии с сопроводительными чертежами.

<Первый вариант воплощения>

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

Фиг.1 является диаграммой, показывающей пример компоновки системы, соответствующей этому варианту воплощения. Система, показанная на фиг.1, сконфигурирована путем соединения сканера 101, компьютера 102 как устройства обработки для формирования и верификации цифрового документа, компьютера 103 для редактирования и модифицирования цифрового документа и принтера 104 для печати цифрового документа через сеть 105.

Фиг.2 является функциональной блок-схемой, показывающей пример функциональной компоновки системы, соответствующей этому варианту воплощения. В отношении фиг.2 устройство 201 ввода изображений принимает данные изображения. Информация 202 о ключах включает в себя ключ шифрования, используемый для формирования цифровой подписи, и ключ расшифровки, используемый для верификации цифровой подписи. Устройство 203 формирования цифрового документа как устройство обработки информации формирует цифровой документ 204 путем присоединения информации подписи к входным данным изображения на основе входных данных изображения и ключа шифрования информации 202 о ключах. Устройство 205 обработки цифрового документа (устройство обработки верификации) верифицирует сформированный цифровой документ 204 с использованием ключа расшифровки информации 202 о ключах и выполняет такие операции, как модифицирование данных, редактирование, печать и т.п. цифрового документа. Обработка цифровой подписи будет объясняться в соответствии с криптографической системой с открытым ключом. В этом случае ключ шифрования информации 202 о ключах соответствует секретному ключу 406, и ключ расшифровки информации 202 о ключах соответствует открытому ключу 414.

Фиг.3 является блок-схемой, показывающей пример внутренней компоновки аппаратных средств устройства формирования цифрового документа 203 и устройства операции цифрового документа 205. Центральный процессор 301 управляет устройством в целом путем выполнения программного обеспечения. Память 302 временно хранит программное обеспечение данных, выполняемых центральным процессором 301. Жесткий диск 303 хранит программное обеспечение и данные. Модуль 304 ввода-вывода принимает входную информацию от клавиатуры, мыши, сканера и т.п. и выводит информацию на дисплей и принтер.

Процесс формирования цифрового документа

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

В процессе 401 формирования цифрового документа, соответствующем этому варианту воплощения, процесс 404 ввода бумажного документа вводит бумажный документ 403. Затем процесс 405 формирования промежуточного цифрового документа формирует промежуточный цифровой документ путем анализа бумажного документа 403. Процесс 407 формирования информации подписи формирует информацию подписи на основе промежуточного цифрового документа и секретного ключа 406. Процесс 408 присоединения информации подписи соединяет промежуточный цифровой документ с информацией подписи. Процесс 409 архивации цифрового документа формирует цифровой документ 411 путем объединения промежуточного цифрового документа и информации подписи. Цифровой документ 411 соответствует цифровому документу 205 на фиг.2. Процесс 410 передачи цифрового документа передает цифровой документ 411 процессу 402 обработки цифрового документа.

В процессе 402 обработки цифрового документа процесс 412 приема цифрового документа принимает цифровой документ 411. Процесс 413 извлечения цифрового документа извлекает промежуточный цифровой документ и информацию подписи из принятого цифрового документа 411. Процесс 415 верификации информации подписи выполняет верификацию на основе промежуточного цифрового документа, информации подписи и открытого ключа 414. Процесс 416 обработки документа выполняет такую операцию, как модифицирование, редактирование, печать и т.п. извлеченного цифрового документа.

Далее будут описаны подробности функциональных блоков на фиг.4. Подробности процесса 405 формирования промежуточного цифрового документа будут описаны ниже со ссылкой на фиг.5 и фиг.6A и 6B. Фиг.5 является блок-схемой последовательности этапов, показывающей пример обработки в процессе 405 формирования промежуточного цифрового документа, соответствующем этому варианту воплощения. Фиг.6A и 6B показывают пример цифровых данных и результат процесса разделения на области.

В отношении фиг.5, на этапе S501 данные, полученные процессом 404 ввода бумажного документа, оцифровываются для формирования цифровых данных. Фиг.6A показывает пример сформированных цифровых данных.

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

Процесс разделения на области извлекает такие наборы, как группа из 8 связанных черных пикселей контура, группа из 4 связанных белых пикселей контура и т.п., в цифровых данных и может извлечь области с такими названиями признака, как текст, изображение или фигура, таблица, рамка и линия. Такая схема описывается в патенте США №5680478. Следует отметить, что способ реализации процесса разделения на области не ограничивается таким заданным процессом, но могут быть применены другие способы.

Фиг.6B показывает пример результата разделения на области путем определения атрибутов на основе количеств извлеченных признаков. Следует отметить, что в качестве атрибутов соответствующих областей 602, 604, 605 и 606 показывают текстовые области и 603 показывает область цветной фотографии.

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

На этапе S504 каждая область, полученная на этапе S502, преобразовывается в информацию передачи. Информация передачи требуется для визуализации. Более точно информация передачи включает в себя растровое изображение с переменной разрешающей способностью, векторное изображение, одноцветное изображение или цветное изображение, размер файла каждой информации передачи, текст как результат распознавания символов, если атрибутом итересующей разделенной области является текст, позиции и шрифты индивидуальных символов, достоверность символов, полученных распознаванием символов, и т.п.. Беря фиг.6B в качестве примера, текстовые области 602, 604, 605 и 606 преобразовываются в векторные изображения, а область 603 цветной фотографии преобразовывается в цветное растровое изображение.

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

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

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

На этапе S801 значение дайджеста данных, которые должны быть подписаны, формируется для каждых данных, которые должны быть подписаны. Следует отметить, что данные, которые должны быть подписаны, являются данными, которые включены в промежуточный цифровой документ, и могут рассматриваться как информация a (701) передачи, информация b (702) передачи или информация (703) документа на фиг.7A (будут описаны позже). Чтобы сформировать значение дайджеста, этот вариант воплощения применяет хеш-функцию. Поскольку хеш-функция была описана в параграфах "Описания предшествующего уровня техники", ее подробное описание будет опущено.

На этапе S802 идентификатор данных, которые должны быть подписаны, формируется для каждых данных, которые должны быть подписаны. Следует заметить, что идентификатор должен уникально идентифицировать только данные, которые должны быть подписаны. Например, в этом варианте воплощения, унифицированный идентификатор ресурса (URI), заданный документом RFC2396, применяется в качестве идентификатора данных, которые должны быть подписаны. Однако настоящее изобретение не ограничивается этой спецификацией, и различные другие значения могут быть применены как идентификаторы.

На этапе S803 проверяется, были ли процессы этапов S801 и S802 применены ко всем данным, которые должны быть подписаны. Если такие процессы были применены ко всем данным, которые должны быть подписаны ("ДА" на этапе S803), поток последовательности этапов переходит на этап S804; иначе поток последовательности этапов возвращается на этап S801.

На этапе S804 выполняется процесс формирования значения подписи с использованием секретного ключа 406 для всех значений дайджеста, сформированных для идентичного цифрового документа на этапе S801, и всех идентификаторов, сформированных на этапе S802, для вычисления значения подписи. Чтобы сформировать значение подписи, этот вариант воплощения применяет цифровую подпись, описанную в параграфах "Описания предшествующего уровня техники". Детализированное описание практической арифметической обработки цифровой подписи будет опущено. Данные M (2101) в потоке процесса формирования подписи, показанном на фиг.14A, соответствуют всем значениям дайджеста, сформированным на этапе S801, и всем идентификаторам, сформированным на этапе S802 (эта группа данных будет называться как агрегированные данные). Аналогично секретный ключ Ks 2106 соответствует секретному ключу 406 на фиг.4.

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

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

Ниже будет описана структура цифрового документа 411, соответствующая этому варианту воплощения, со ссылкой на фиг.9A и 9B. Фиг.9A и 9B показывают пример структуры цифрового документа 411, соответствующей этому варианту воплощения. Фиг.9A показывает структуру всего цифрового документа 411. Как показано на фиг.9A, цифровой документ 411 предпочтительно включает в себя информацию подписи 901, данные 1 (902), которые должны быть подписаны, и данные 2 (903), которые должны быть подписаны. Фиг.9B показывает пример подробной структуры информации 901 подписи на фиг.9A. Как показано на фиг.9B, информация 901 подписи предпочтительно включает в себя значение 904 подписи, идентификатор (905) данных 1, которые должны быть подписаны, значение (906) дайджеста данных 1, которые должны быть подписаны 1 (906), идентификатор (907) данных 2, которые должны быть подписаны, и значения (908) дайджеста данных 2, которые должны быть подписаны. Данные 905 - 908 формируют агрегированные данные 909.

Фиг.9A показывает пример структуры цифрового документа 411, когда одна информация 901 подписи формируется для двух данных 1 (902), которые должны быть подписаны, и данных 2 (903), которые должны быть подписаны. Фиг.9B показывает пример подробной структуры информации 901 подписи. На фиг.9B идентификатор (905) данных 1, которые должны быть подписаны, и идентификатор (907) данных 2, которые должны быть подписаны, сформированы на этапе S802, описанном выше. Кроме того, значение дайджеста (906) данных 1, которые должны быть подписаны, и значения дайджеста (908) данных 2, которые должны быть подписаны, сформированы на этапе S801, описанном выше. Значение 904 подписи сформировано на этапе S804 с использованием данных 905 - 908, то есть агрегированных данных 909.

Затем ниже будет описан процесс 408 присоединения данных подписи со ссылкой на фиг.7A. Номера позиций 701 и 702 обозначают две части информации передачи промежуточного цифрового документа, сформированного в процессе 405 формирования промежуточного цифрового документа; и 703 - информацию документа. Номера позиций 704 и 705 обозначают две части информации подписи, сформированной в процессе 407 формирования информации подписи.

В каждую информацию подписи встраивается идентификатор, который указывает информацию передачи, или информацию документа, соответствующую данным, которые должны быть подписаны, как описано выше. На фиг.7A идентификатор 706, который указывает данные, которые должны быть подписаны (то есть информация 701 передачи), встраивается в информацию 704 подписи. Информация подписи и данные, которые должны быть подписаны, не всегда должны иметь взаимно однозначное соответствие. Например, идентификаторы 707 и 708, которые соответственно указывают информацию 702 передачи и информацию 703 документа как данные, которые должны быть подписаны, могут быть внедрены в информацию 705 подписи.

Следует заметить, что информация a (701) передачи рассматривается как данные 1 (902), которые должны быть подписаны, и информация b (702) передачи и информация 703 документа 703 рассматриваются как данные 2 (903), которые должны быть подписаны. Также информацию 1 (704) подписи и информацию 2 (705) подписи можно рассматривать как информацию 901 подписи.

Ниже будет описан процесс 409 архивации цифрового документа со ссылкой на фиг.7A и 7B. Промежуточный цифровой документ и информация подписи, сформированные в процессах, описанных до настоящего момента, существуют как независимые данные, как показано на фиг.7A. Следовательно, процесс архивации цифрового документа архивирует эти данные для формирования одного цифрового документа. Фиг.7B показывает пример данных архива промежуточного цифрового документа и информации подписи. Данные 709 архива соответствуют цифровому документу 411, показанному на фиг.4. Что касается позиций 701 - 705, показанных на фиг.7A, позиция 701 соответствует позиции 713; позиция 702 - позиции 714; позиция 703 - позиции 712; позиция 704 - позиции 710 и позиция 705 - позиции 711.

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

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

Возможность верификации в преобразованном содержании будет описана ниже в связи с процессом обработки цифрового документа.

Процесс обработки цифрового документа

Цифровой документ 411, принятый в процессе 412 приема цифрового документа на фиг.4, в процессе 413 извлечения цифрового документа 413 подвергается обработке, обратной процессу 409 архивации цифрового документа. Таким образом, индивидуальные данные промежуточного цифрового документа и информации подписи извлекаются из цифрового документа 411.

В процессе 415 верификации информации подписи входные данные М (2107) в потоке последовательности этапов процесса верификации подписи, показанном на фиг.14B, соответствуют агрегированным данным 909. Аналогично данные S (2110) цифровой подписи соответствуют информации 901 подписи, и открытый ключ 2111 соответствует открытому ключу 414 на фиг.4. Таким образом может быть проверено, были ли изменены агрегированные данные 909 или нет.

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

В отношении фиг.10, на этапе S1001 информация 901 подписи извлекается из цифрового документа 411 процессом 413 извлечения цифрового документа. Тогда производится верификация на основе значения 904 подписи, включенном в информацию 901 подписи, с использованием способа, описанного на фиг.14B, были ли изменены агрегированные данные 909 или нет. Таким образом формируется значение 2109 дайджеста, чтобы получить идентификатор 905 и значение 906 дайджеста и идентификатор 907 и значение 908 дайджеста как входные данные М. Кроме того, значение 904 подписи расшифровывается с использованием открытого ключа 414 для формирования значения дайджеста. Тогда проверяется, совпадают ли два сгенерированных дайджеста или нет. Если эти значения совпадают, то определяется, что агрегированные данные 909 не были изменены.

Если верификация потерпела неудачу на этапе S1002 ("Неудачно" на этапе S1002), процесс верификации подписи заканчивается, и "Неудачно" возвращается в качестве результата. С другой стороны, если верификация имела успех на этапе S1002 ("Удачно" на этапе S1002), выполняются процессы на этапах от S1003 до S1008 для соответствующих идентификаторов 905 и 907, включенных в агрегированные данные 909.

На этапе S1004 данные 902 или 903, которые должны быть подписаны, извлекаются из цифрового документа 411 на основе идентификатора 905 или 907. На этапе S1005 проверяется, могут ли быть получены данные 902 или 903, которые должны быть подписаны. Если данные 902 или 903, которые должны быть подписаны, могут быть получены, поток последовательности этапов переходит на этап S1006. Если данные 902 или 903, которые должны быть подписаны, не могут быть получены, поток последовательности этапов переходит на этап S1008. Если следующий идентификатор существует, выполняется процесс на этапе S1004 для соответствующих данных, которые должны быть подписаны. Если существуют данные, которые должны быть подписаны, которые не могут быть получены из цифрового документа 411, на устройстве 205 обработки цифрового документа может быть отображено сообщение, указывающее, что подсодержание, соответствующее интересующему идентификатору, не включено как данные, которые должны быть верифицированы. Это отображение может быть сделано путем использования устройства отображения компьютера 103 или принтера 104 в компоновке, показанной на фиг.1.

На этапе S1006 значение H (M) дайджеста данных 902 или 903, которые должны быть подписаны, вычисляется на основе способа, показанного на фиг.14B. На этапе S1007 проверяется, соответствует ли результат вычисления дайджеста значению 906 или 908 дайджеста, включенному в агрегированные данные 909. Если два значения соответствуют друг другу, поток последовательности этапов переходит к этапу S1008. Если существует следующий идентификатор на этапе S1008, процесс на этапе S1004 выполняется для соответствующих данных, которые должны быть подписаны. Если два значения дайджеста не соответствуют друг другу, процесс верификации подписи заканчивается, и "Неудачно" возвращается в качестве результата. Если на этапе S1008 определяется, что для всех идентификаторов были сделаны повторные процессы, процесс верификации подписи заканчивается, и "Удачно" возвращается в качестве результата. Ниже будет описан процесс 416 обработки цифрового документа на фиг.4. Обработка включает в себя процесс употребления содержания, такой как просмотр, печать и т.п. Однако то, как употреблять содержание, не влияет на этот вариант воплощения до тех пор, пока выполнен процесс, который позволяет пользователю пользоваться содержанием. Поэтому подробное описание этого процесса будет опущено. С другой стороны, процесс преобразования содержания преобразует новый цифровой документ 411, и преобразованный цифровой документ 411 может являться вводом для процесса 402 обработки цифрового документа.

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

Ниже будет объяснена верификация преобразованного цифрового документа 411 со ссылкой на фиг.11A и 11B. В этом случае мы предполагаем, что пользователь, который принимает цифровой документ 411, показанный на фиг.9A и 9B, выполняет процесс преобразования для удаления данных 1 (902), которые должны быть подписаны, и распространяет как содержание только данные 2 (903), которые должны быть подписаны.

Цифровой документ 411, который должен быть распространен, в это время перезаписывается, как показано на фиг.11A и 11B. Более точно, цифровой документ 411 включает в себя информацию 901 подписи и данные 2 (903), которые должны быть подписаны. В это время, например, когда данные 901 подписи модифицируются, например, путем удаления данных 905 и 906, которые не требуются после верификации подписи для устранения избыточности, само значение 904 подписи становится недействительным. Поэтому информация 901 подписи, включающая в себя информацию с 904 по 908, будет использоваться без любых изменений.

Ниже будет исследован случай, в котором делается обработка на основе блок-схемы последовательности этапов на фиг.10. На этапе S1005 делается попытка получить данные 1 (902), которые должны быть подписаны, на основе идентификатора 905 данных 1 (902), которые должны быть подписаны. Однако данные 1 (902), которые должны быть подписаны, не могут быть получены, так как они не архивированы в цифровом документе 411 на фиг.11A и 11B. Поэтому на этапе S1005 определяется "НЕТ", поток последовательности этапов переходит к этапу S1008, и процессы от этапа S1004 продолжаются для следующего идентификатора (идентификатора 907 в этом случае). Таким образом, для данных 1 (902), которые должны быть подписаны, процесс определения соответствия дайджеста на этапе S1007 пропускается. С другой стороны, данные 2 (903), которые должны быть подписаны, получаются на этапе S1004, и процесс определения соответствия дайджеста может быть выполнен. Поэтому можно верифицировать, были ли изменены данные 2 (903), которые должны быть подписаны, или нет.

Таким образом, может быть обеспечен механизм, который пропускает процесс определения соответствия дайджеста для подсодержания, которое включено в агрегированные данные 909, но не архивировано в цифровом документе 411, и гарантирует неизменение/изменение для архивированного подсодержания.

В обычном процессе формирования подписи значения подписи должны быть обеспечены для данных 1 и 2 (902 и 903), которые должны быть подписаны соответственно. Поэтому нагрузка на вычислительный процесс становится более тяжелой. В частности, объем вычислений увеличивается пропорционально количеству разделов разделенных данных, которые должны быть подписаны.

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

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

<Второй вариант воплощения>

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

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

Таким образом, в этом варианте воплощения, даже когда результат проверки соответствия на этапе S1007 является "Неудачно", процессы верификации из этапов S1003 к S1008 продолжаются для всех оставшихся идентификаторов, включенных в агрегированные данные 909, без принудительного завершения процесса. Затем в качестве результата верификации возвращается список подсодержания, которое не было изменено и которое было изменено. Таким образом, пользователю можно сообщить об информации, связанной с присутствием/отсутствием изменения для соответствующего подсодержания через компьютер 103, принтер 104 и т.п. Таким образом, пользователь может разрешить содержание, когда некоторое подсодержание было изменено, но другое подсодержание не было изменено. Поэтому можно обеспечить механизм, который допускает, чтобы подсодержание, которое не было изменено, было повторно использовано.

<Третий вариант воплощения>

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

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

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

Когда отображение делается в формате, показанном на фиг.6B, некоторые части информации (602 - 606) прямоугольника могут быть выбраны указателем устройства. Так как такая информация прямоугольника является модулем раздела, который может быть легко обработан как структура данных, которая внутренне уже поддерживается, такой выбор информации прямоугольника является процессом, который соответствует процессу 407 формирования информации подписи, который должен быть выполнен непосредственно после выбора.

Фиг.12 показывает пример, в котором выбраны две разделенные области 602 и 606 из фиг.6B как данные, которые должны быть подписаны. На фиг.12 выбранные разделенные области выделены, таким образом обеспечивая структуру экрана, которая позволяет пользователю легко идентифицировать выбранные области.

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

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

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

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

Следует заметить, что область 1301 может использоваться как одна из разделенных областей, и информация различия между областями 606 и 1301 может использоваться как новая разделенная область. В первом случае размер данных цифрового документа 411 увеличивается, но обработка является простой. В последнем случае требуется новый процесс разделения на области.

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

<Вариант воплощения, основанный на других криптографических алгоритмах>

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

<Другие варианты воплощения>

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

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

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

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

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

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

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

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

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

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

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

Изобретение относится к средствам обработки информации и средствам верификации. Техническим результатом является повышение точности верификации подписи за счет верификации составного содержания цифровых данных. Устройство обработки информации содержит первый модуль формирования, выполненный с возможностью формировать данные, которые будут подписаны, второй модуль формирования, выполненный с возможностью формировать первые значения дайджеста данных, которые должны быть подписаны, и идентификаторы, используемые для идентификации данных, которые должны быть подписаны, третий модуль формирования, выполненный с возможностью формировать информацию подписи на основе множества первых значений дайджеста и идентификаторов, полученных из цифрового документа, и четвертый модуль формирования, выполненный с возможностью формировать первый подписанный цифровой документ на основе информации подписи и данных, которые должны быть подписаны. Устройство верификации верифицирует цифровой документ на основе первого подписанного цифрового документа, сформированного устройством обработки информации. Способы описывают работу данных устройств. 5 н. и 10 з.п. ф-лы, 20 ил.

1. Устройство обработки информации, содержащее

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

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

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

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

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

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

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

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

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

модуль сравнения, выполненный с возможностью сравнивать первое значение дайджеста и второе значение дайджеста; и

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

модуль обработки, выполненный с возможностью применять обработку к первому подписанному цифровому документу; и

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

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

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

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

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

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

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

этап извлечения, на котором извлекают информацию подписи из первого подписанного цифрового документа;

этап определения, на котором определяют, были ли изменены первое значение дайджеста и идентификатор в информации подписи или нет;

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

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

этап сравнения, на котором сравнивают первое значение дайджеста и второе значение дайджеста; и

этап формирования результата верификации, на котором формируют результат верификации на основе результата сравнения.