RU2623724C2 - Основанные на атрибутах цифровые подписи - Google Patents
Основанные на атрибутах цифровые подписи Download PDFInfo
- Publication number
- RU2623724C2 RU2623724C2 RU2013112947A RU2013112947A RU2623724C2 RU 2623724 C2 RU2623724 C2 RU 2623724C2 RU 2013112947 A RU2013112947 A RU 2013112947A RU 2013112947 A RU2013112947 A RU 2013112947A RU 2623724 C2 RU2623724 C2 RU 2623724C2
- Authority
- RU
- Russia
- Prior art keywords
- signature
- key
- attributes
- signing
- module
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
- H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
- H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
- H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Algebra (AREA)
- Mathematical Analysis (AREA)
- Mathematical Optimization (AREA)
- Mathematical Physics (AREA)
- Pure & Applied Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Storage Device Security (AREA)
Abstract
Изобретение относится к области безопасности данных. Технический результат – улучшение безопасности данных за счет использования цифровой подписи для документа и возможности ее изменения. Система основанной на атрибутах цифровой подписи содержит: первый модуль (1) формирования подписи для формирования первой подписи (10) для документа (11) на основе первого ключа (12) подписи и документа (11); и модуль (2) повторного подписания, выполненный с возможностью формирования второй подписи (13) для документа (11) на основе первой подписи (10) и ключа (14) повторного подписания, при этом модуль (2) повторного подписания выполнен с возможностью обработки атрибутов (15, 16), связанных с первой подписью (10) и/или второй подписью (13), причем вторая подпись (13) связана со вторым набором атрибутов (16), определяемым ключом (14) повторного подписания, при этом второй набор атрибутов (16) содержит множество атрибутов; и генератор (3) ключей повторного подписания для формирования ключа (14) повторного подписания на основе второго ключа (18) подписи, связанного со вторым набором атрибутов (16'), при этом ключ (14) повторного подписания позволяет модулю (2) повторного подписания преобразовать первую подпись (10) во вторую подпись (13), связанную со вторым набором атрибутов (16), и при этом второй ключ (18) подписи позволяет второму модулю (4) формирования подписи сформировать подпись (19), связанную со вторым набором атрибутов (16ʺ), на основе документа (11); при этом генератор (3) ключей повторного подписания выполнен с дополнительной возможностью формирования первого ключа (12) подписи на основе второго ключа (18) подписи, причем первый ключ (12) подписи и ключ (14) повторного подписания формируются как пара ключей, и первый ключ (12) подписи предоставляется первому модулю (1) формирования подписи, а ключ (14) повторного подписания предоставляется модулю (2) повторного подписания. 4 н. и 5 з.п. ф-лы, 3 ил.
Description
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Изобретение относится к основанным на атрибутах цифровым подписям.
УРОВЕНЬ ТЕХНИКИ
Растущая потребность в обмене данными между разными сторонами, участвующими в цикле заботы о здоровье, который простирается от традиционного медицинского обслуживания через оказание медицинской помощи на дому до оздоровительных услуг, в качестве одной из основных задач ставит задачу по управлению безопасностью медицинских данных. Современные подходы, которые основаны на традиционных механизмах обеспечения безопасности совместно с дополненными необходимыми физическими и административными процедурами, ограничивают доступность медицинской информации и делают громоздким обмен медико-санитарной документацией. Цифровые технологии управления и защиты посредством политик превосходят эти традиционные подходы, предлагая возможности по реализации (1) сквозной конфиденциальности и безопасности в неоднородных сетях, обеспечивая защиту данных независимо от инфраструктуры, по которой перемещаются данные, или ведомственных границ; (2) криптографической защиты ролевых или основанных на атрибутах механизмов управления доступом, которые наиболее важны в приложениях связанных с медицинским обслуживанием, которые позволяют только пользователям с соответствующими атрибутами (например, ролями) расшифровывать или подписывать сообщение, на основе секретного ключа, связанного с его/ее атрибутами.
Одним из важных аспектов делопроизводства в медицинском обслуживании является обеспечение невозможности отказа от происхождения, что означает, что получатель данных может проверить происхождение данных. В обычной жизни цифровые подписи используются для реализации свойства невозможности отказа от авторства. В обычных схемах подписи для каждого пользователя формируется пара из личного и открытого ключа, и из этой пары секретный ключ может использоваться для подписания сообщения, в то время как открытый ключ может использоваться для проверки подписи в сообщении. Тем не менее в организации медицинского обслуживания, атрибуты, как правило, используются для описания роли и идентификационных данных пользователя, и разрешение на доступ к данным предоставляется на основе атрибутов пользователя. Таким образом, пользователь может создать или изменить, а затем подписать данные, если и только если он/она имеет правильный набор атрибутов. Для этих целей, используются основанные на атрибутах подписи, как описывается, например, в «Attribute Based Group Signatures”, International Association for Cryptologic Research (IACR), под авторством Dalia Khader, 2007 г., 241. Следовательно, в медицинском обслуживании атрибуты рассматриваются как основной источник обеспечения происхождения данных. Эти атрибуты также могут содержать индивидуальные атрибуты, которые уникальны для индивидуума в конкретной области (например, имя или идентификатор). Например, аптека примет рецепт, если он был подписан определенным пользователем с определенной ролью (например, доктором Джоном Смитом). В другом случае использования, который относится к медицинским исследованиям, при которых важна анонимность, пациент может подписать свою медико-санитарную документацию, используя только его неуникальные атрибуты (такие как те, что он мужчина в возрасте от 30 до 40 лет). Следовательно, важным компонентом системы основанного на атрибутах шифрования (ABE) для защиты медицинских данных является схема основанной на атрибутах подписи (ABS).
В основанной на атрибутах подписи (ABS) данные подписываются, используя секретный ключ SKω, который связан с набором ω атрибутов, которыми обладает пользователь. Чтобы иметь возможность подписания сообщения, пользователь получает от доверенного авторитетного источника конкретный личный ключ, который соответствует набору сертифицированных атрибутов, которыми он/она обладает. Как уже упомянуто, пользователь также может иметь гибкие возможности по выбору подмножества секретного ключа, который относится к подмножеству атрибутов, которое он/она может пожелать использовать для конкретной операции подписания.
РАСКРЫТИЕ ИЗОБРЕТЕНИЯ
Технический результат, обеспечиваемый настоящим изобретением, заключается в улучшении безопасности данных за счет использования цифровой подписи для документа и за счет обеспечения возможности изменения подписи (авторизованным пользователем).
Было бы желательно иметь усовершенствованную систему основанной на атрибутах цифровой подписи. Для более эффективного решения данной проблемы в первом аспекте изобретение предоставляет систему, содержащую:
первый модуль формирования подписи для формирования первой подписи для документа на основе первого ключа подписи и документа; и модуль повторного подписания, выполненный с возможностью формирования второй подписи для документа на основе первой подписи и ключа повторного подписания, при этом модуль повторного подписания выполнен с возможностью обработки атрибутов, связанных с первой подписью и/или второй подписью.
Данная система позволяет реализовать конфигурирование возможностей повторного подписания на основе атрибутов, связанных с подписями. Благодаря наличию модуля повторного подписания полномочия на подписание могут быть делегированы, не выдавая делегированному лицу ключа подписи делегирующего лица. Наоборот, делегированному лицу предоставляется возможность преобразования его или ее подписи в подпись делегирующего лица, используя модуль повторного подписания, который может быть полудоверенным модулем или посредником. Посредством конфигурирования модуля повторного подписания для обработки атрибутов, связанных с подписями, функциональные возможности повторного подписания становятся более гибкими. Не требуется, чтобы задачи делегирования выполнялись в виде от пользователя к пользователю, так как атрибуты ключей могут использоваться для указания на то, например, какие атрибуты, связанные с первой подписью, требуются для использования модуля повторного подписания, и/или какие атрибуты связаны со второй подписью. Следовательно, делегирующие лица могут делегировать задачи группе пользователей на основе их атрибутов. Модуль повторного подписания может быть выполнен с возможностью преобразования первой подписи во вторую подпись, при этом вторая подпись замещает первую подпись для документа, и вторая подпись может проверяться независимо от первой подписи.
Вторая подпись может быть связана со вторым набором атрибутов, который определяется ключом повторного подписания, при этом второй набор атрибутов содержит множество атрибутов. Модуль повторного подписания позволяет реализовать преобразование первой подписи в подпись, которая связана со вторым набором атрибутов. Это позволяет реализовать несколько сценариев использования, которые не могут быть реализованы при помощи существующих систем основанной на атрибутах цифровой подписи. Например, система позволяет делегировать полномочие на подписание документов с конкретным набором атрибутов пользователю, не выдавая пользователю ключа подписи, связанного с этим набором атрибутов. Вместо этого, пользователю выдается только первый ключ подписи, и модулю повторного подписания предписывается преобразовать подпись, сформированную при помощи первого ключа подписи, в требуемую вторую подпись, связанную со вторым набором атрибутов. Модуль повторного подписания может быть реализован в качестве полу-доверенного посредника.
В качестве альтернативы или в дополнение, первая подпись может быть связана с первым набором атрибутов, при этом первый набор атрибутов содержит множество атрибутов, и модуль повторного подписания может быть выполнен с возможностью формирования второй подписи, только если первый набор атрибутов отвечает набору условий. Это позволяет делегирующему лицу авторизовать группу пользователей, не указывая конкретных ID пользователей делегированных лиц. Вместо этого, авторизация может выполняться на основе атрибутов (например, ролей) пользователей, которые представлены в их первых ключах подписи.
Система может содержать генератор ключей повторного подписания для формирования ключа повторного подписания на основе второго ключа подписи, связанного со вторым набором атрибутов, при этом ключ повторного подписания позволяет модулю повторного подписания преобразовать первую подпись в подпись, которая связана со вторым набором атрибутов, и при этом второй ключ подписи позволяет второму модулю формирования подписи сформировать подпись, которая связана со вторым набором атрибутов, на основе самого документа. Как правило, управление вторым ключом подписи вручается лицу, которое обладает полномочиями на подписание документов со вторым набором атрибутов. Использование генератора ключей повторного подписания в соответствии с тем, что описано, позволяет реализовать то, что лицо может создать ключ повторного подписания путем предоставления второго ключа подписи генератору ключей повторного подписания. В системе основанной на атрибутах подписи может не требоваться никакого основного ключа. Это позволяет относительно простым способом делегировать полномочия на подписание.
Генератор ключей повторного подписания может быть выполнен с возможностью дополнительного формирования первого ключа подписи на основе второго ключа подписи, при этом первый ключ подписи и ключ повторного подписания формируются как пара ключей, и первый ключ подписи предоставляется первому модулю формирования подписи, а ключ повторного подписания предоставляется модулю повторного подписания. Данная схема позволяет разрешить пользователю, у которого нет ключа, подписывать документы со вторым набором атрибутов. Предназначенный первый ключ подписи может быть выдан пользователю для подготовки первой подписи, при этом данная первая подпись затем может быть преобразована в подпись, которая связана со вторым набором атрибутов посредством модуля повторной подписи и ключа повторной подписи. Таким образом, генератору ключей повторного подписания не требуется знать о любых существующих ключах, которыми владеет делегированный пользователь, так как делегированное лицо получает новый первый ключ подписи от генератора ключей повторного подписания, при этом данный первый ключ подписи может использоваться совместно с модулем повторного подписания и ключом повторного подписания для подписания сообщения от имени делегирующего лица.
Система может содержать генератор ключей повторного подписания, выполненный с возможностью формирования ключа повторного подписания в зависимости от набора условий, при этом ключ повторного подписания позволяет модулю повторного подписания преобразовывать подпись, которая связана с любым набором атрибутов, отвечающим набору условий, во вторую подпись. Это делает систему более гибкой, так как нет необходимости в создании ключа повторного подписания для каждого пользователя, а вместо этого существующие пользователи, у которых есть первые ключи подписи, связанные с соответствующими наборами атрибутов, которые отвечают набору условий, могут преобразовать свои подписи в подпись, которая связана со вторым набором атрибутов. Набор условий может именоваться политикой.
Модуль повторного подписания может быть выполнен с возможностью использования открытого ключа для проверки того, связана ли первая подпись с набором атрибутов, который отвечает набору условий, и формирования второй подписи только в случае, когда первая подпись связана с набором атрибутов, который отвечает набору условий. Это повышает безопасность системы и/или предотвращает формирование ложных подписей, так как преобразовываться могут только предназначенные подписи.
Система может содержать модуль делегирования для предоставления возможности пользователю, который владеет вторым набором атрибутов, делегировать его полномочия на подписание документа подписью, которая связана со вторым набором атрибутов, другому пользователю, посредством предоставления модулю повторного подписания ключа повторного подписания. Это способствует делегированию полномочий на подписание. Управляемый пользователем процесс делегирования может дополнительно содержать разрешение делегированному лицу предписывать модулю повторного подписания преобразование первой подписи в соответствующую вторую подпись, используя ключ повторного подписания. Дополнительно модуль делегирования может разрешать пользователю отменять или удалять ключ повторного подписания из модуля повторного подписания. Это позволяет легко отзывать полномочия на подписание.
В другом аспекте изобретение представляет рабочую станцию, содержащую изложенную систему.
В еще одном другом аспекте изобретение предоставляет способ формирования основанной на атрибутах цифровой подписи, содержащий этапы, на которых:
формируют первую подпись для документа, на основе первого ключа подписи и документа; и
формируют вторую подпись для документа, на основе первой подписи и ключа повторного подписания, включая обработку атрибутов, которые связаны с первой подписью и/или второй подписью.
В другом аспекте изобретение предоставляет компьютерный программный продукт, содержащий инструкции, предписывающие процессорной системе выполнять изложенный способ.
US 2009/0327735 A1 раскрывает систему посреднической повторной подписи для преобразования подписи делегированного лица в сообщении m в подпись делегирующего лица в том же сообщении m. Данный документ не раскрывает систему основанной на атрибутах подписи.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Эти и прочие аспекты изобретения очевидны и будут объяснены со ссылкой на описываемые ниже варианты осуществления, при этом на чертежах:
Фиг. 1 является схемой системы основанной на атрибутах цифровой повторной подписи;
Фиг. 2 является блок-схемой способа основанной на атрибутах цифровой повторной подписи;
Фиг. 3 является функциональной схемой собственно схемы основанной на атрибутах посреднической повторной подписи.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
В данном описании раскрывается схема основанной на атрибутах посреднической повторной подписи (ABPRSS). В качестве примеров будет описано несколько вариантов системы. Тем не менее специалист в соответствующей области способен реализовать вариации этих примеров и объединить признаки, описанные в разных примерах. Основанная на атрибутах подпись может рассматриваться как вид групповой подписи. Она позволяет модулю проверки определить атрибуты (например, роль) подписывающего лица. Тем не менее на практике существуют сценарии, при которых подпись одного субъекта преобразуется в подпись другого субъекта. Одним из примеров является сценарий делегирования, однако он не является ограничением. На эти сценарии могут быть направлены усилия разных вариантов предлагаемой здесь схемы. В схему вводится полудоверенный посредник или в общем модуль повторного подписания, который преобразует подпись субъекта A (делегированного лица) в подпись субъекта B (делегирующего лица), используя выданный делегирующим лицом ключ повторного подписания.
Несмотря на то что основанная на атрибутах подпись полезна в ряде сценариев в повседневной жизни, однако деятельность, связанная с медицинским обслуживанием, выдвигает ряд дополнительных, желательных особенностей, которые недоступны в существующей схеме, основанной на атрибутах подписи. В медицинском обслуживании пользователю может очень часто требоваться делегировать возможность подписания одному из его коллег (или подчиненных). Например, врач может желать, чтобы медсестра подписывала рецепт от его имени. Наивным подходом будет тот, при котором врач передает свой секретный ключ медсестре, которая затем выполнит подписание от его имени, используя обычные схемы ABS. Как очевидно, основной недостаток состоит в том, что медсестра запоминает секретный ключ врача и может продолжать использовать его без разрешения врача. Схема посреднической повторной подписи предоставляет альтернативу, которая обеспечивает делегирование возможностей таким образом, при котором можно обеспечить достаточную степень безопасности и эффективности. Используемое здесь слово «безопасность» означает то, что делегированное лицо не может узнать секретный ключ делегирующего лица, а слово «эффективность» в широком смысле означает то, что нагрузка на делегированное лицо в плане хранения ключа и т.д. также минимальна.
Следовательно, предлагается ABPRSS, при этом подпись для врача создается делегированным лицом и полудоверенным посредником. Например, врач (делегирующее лицо) формирует ключ повторной подписи из своего секретного ключа 
(пример второго ключа подписи), который связан с набором атрибутов 
. Ключ повторной подписи затем используется полудоверенным модулем посредником для преобразования подписи медсестры (сформированной, используя ее собственный секретный ключ 
(пример первого ключа подписи)) в подпись врача (делегирующего лица), только если медсестра желает, чтобы полудоверенный посредник преобразовал ее подпись в подпись врача (делегирующего лица). Одно из желательных свойств такой системы состоит в том, чтобы никто самостоятельно (медсестра или посредник) не имели возможности создания подписи от лица врача. В дополнение, даже в случае сговора между медсестрой и полу-доверенным посредником отсутствовала возможность восстановления ими секретного ключа 
врача (делегирующего лица).
Конечно, возможности применения такой системы не ограничиваются лишь сценариями делегирования. В другом примере, ABPRSS может использоваться для преобразования подписи служащего, которая может быть проверена при помощи открытого ключа служащего, в подпись ведомства или компании, которая может быть проверена открытым ключом ведомства или компании. Это позволяет предотвратить утечку информации в отношении корпоративной структуры компании или профиля служащего, при этом все же предоставляя возможность организации внутреннего аудита.
Другим вариантом применения ABPRSS является сценарий, при котором документ подписывается несколькими субъектами по цепочке делопроизводства и каждый субъект обладает разным набором атрибутов. Следовательно, посредством использования предложенной схемы, требуется, чтобы с документом хранилась лишь одна подпись, которая при проверке подтвердит, что документ был подписан правильными субъектами, используя действующие ключи подписи.
Обращаясь к Фиг. 1, будет описан вариант осуществления ABPRSS. Фиг. 1 показывает схему, иллюстрирующую аспекты системы основанной на атрибутах цифровой подписи. Например, система может быть реализована на распределенной компьютерной системе, с приемлемым загруженным в нее программным обеспечением.
Система может содержать задающий модуль (не показан) для формирования открытого ключа и мастер ключа. Более того, система может содержать модуль формирования ключа (не показан) для формирования первого ключа 12 подписи и/или второго ключа 18 подписи, по мере необходимости, на основе мастер ключа. Данная часть системы не показана по соображениям сохранения ясности.
Система может содержать первый модуль 1 формирования подписи для формирования первой подписи 10 для документа 11, на основе первого ключа 12 подписи и документа 11. Первый ключ 12 подписи может быть связан с набором атрибутов 15’, в соответствии со схемой, основанной на атрибутах подписи, позволяя первому модулю 1 формирования подписи формировать подпись 10, которая связана с данным набором атрибутов 15. Тем не менее это не является ограничением. Также возможно, что первый ключ 12 подписи и первая подпись 10 не имеют связанных с ними атрибутов 15’, 15. После преобразования модулем повторного подписания, вторая подпись 13 может быть связана с набором атрибутов 16, 16’’’, которые определяются ключом 14 повторного подписания. И наоборот, может быть так, что первый ключ 12 подписи и первая подпись 10 связаны с набором атрибутов 15’, 15, которые могут проверяться модулем 2 повторного подписания в отношении политики, которая содержит набор условий 17, 17’, для управления тем, какие пользователи могут преобразовывать свои первые подписи во вторые подписи, в то время как вторая подпись 13 и ключ 14 повторного подписания не имеют связанных с ними атрибутов 16, 16’’’. Также возможно, как показано на Фиг. 1, что первый ключ 12 подписи и первая подпись 10 связаны с первым набором атрибутов 15’, 15, которые могут проверяться по отношению к набору условий 17, 17’, и что ключ 14 повторного подписания и вторая подпись 13 связаны с другим вторым набором атрибутов 16’’’, 16.
Система может дополнительно содержать модуль 2 повторного подписания для формирования второй подписи 13 для документа 11 на основе первой подписи 10 и ключа 14 повторного подписания. Модуль повторного подписания может обрабатывать атрибуты 15, которые связаны с первой подписью 10 и/или атрибуты 16’’’, которые связаны с ключом 14 повторного подписания. Также модуль повторного подписания может обрабатывать любые атрибуты 16 второй подписи 13, например, предписывая привязку данной второй подписи 13 к набору атрибутов 16. Как правило, данный набор атрибутов 16 соответствует набору атрибутов 16’’’, который связан с ключом 14 повторного подписания. Следовательно, набор атрибутов 16, связанный со второй подписью 13, может отличаться от атрибутов 15 (если это имеет место), которые связаны с первой подписью 10.
Как упомянуто ранее, первая подпись 10 может быть связана с первым набором атрибутов 15, при этом первый набор атрибутов 15 содержит множество атрибутов. Модуль 2 повторного подписания может быть выполнен с возможностью оценки набора атрибутов 15, которые связаны с первой подписью 10, для проверки того, разрешено ли применительно к первой подписи 10 преобразование во вторую подпись 13. Данная проверка может выполняться явно, используя алгоритм проверки схемы основанной на атрибутах подписи в сочетании с открытым ключом 20 для проверки соответствия набора атрибутов 15 в отношении политики, которая содержит набор условий 17’ применительно к атрибутам. В качестве альтернативы, проверка может выполняться неявно. В последнем случае, набор условий 17 встроен посредством шифрования в ключ 14 повторного подписания таким образом, что алгоритм, который использует ключ 14 повторного подписания для преобразования первой подписи 10 во вторую подпись 13, не сможет создать действующую вторую подпись 13 до тех пор, пока первый набор атрибутов 15 не будет отвечать набору условий 17. В целом модуль 2 повторного подписания может быть выполнен с возможностью формирования второй подписи 13, только если первый набор атрибутов 15 отвечает набору условий 17 или 17’.
Система может содержать второй модуль 4 формирования подписи для формирования подписи 19, которая связана со вторым набором атрибутов 16’’, на основе документа 11 и второго ключа 18 подписи. Данный второй набор атрибутов 16’’ соответствует второму набору атрибутов 16, который связан со второй подписью 13 и со вторым набором атрибутов 16’’’, которые связаны с ключом 14 повторного подписания.
В типичном сценарии, второй модуль 4 формирования подписи и второй ключ 18 подписи используются пользователем, обрабатывающим второй набор атрибутов 16’. Первый модуль 1 формирования подписи и модуль 2 повторного подписания используются пользователем, который авторизован пользователем, обрабатывающим атрибуты, на подписание от его или ее лица. Генератор 3 ключей повторного подписания может управляться пользователем, обрабатывающим атрибуты, для формирования ключа 14 повторного подписания для авторизации конкретного пользователя или группы пользователей на подписание от его или ее лица.
Система может содержать генератор 3 ключей повторного подписания для формирования ключа 14 повторного подписания на основе второго ключа 18 подписи, который связан со вторым набором атрибутов 16’. В данном случае, ключ 14 повторного подписания разрешает модулю 2 повторного подписания преобразовать первую подпись 10 во вторую подпись 13, которая связана со вторым набором атрибутов 16.
Генератор 3 ключей повторного подписания также может быть выполнен с возможностью формирования ключа 14 повторного подписания, который способен преобразовывать первую подпись 10, которая связана с набором атрибутов 15, который отвечает набору условий 17, определяемых ключом 14 повторного подписания. Таким образом, такой ключ повторного подписания связан с набором условий 17, или политикой, в отношении атрибутов. В процессе преобразования посредством модуля 2 повторного подписания, атрибуты 15, которые в цифровом виде представляются первой подписью 10, посредством шифрования объединяются с набором условий 17, которые в цифровом виде представляются ключом 14 повторного подписания, чтобы образовать вторую подпись 13. Когда ключ 14 повторного подписания связан со вторым набором атрибутов 16’’’, то процесс повторного подписания может эффективно замещать атрибуты 15, связанные с первой подписью 10, атрибутами 16, 16’’’, которые связаны с ключом 14 повторного подписания.
Генератор 3 ключей повторного подписания может быть выполнен с возможностью дальнейшего формирования первого ключа 12 подписи, на основе второго ключа 18 подписи. Упомянутый первый ключ 12 подписи и ключ 14 повторного подписания могут формироваться как пара ключей, разработанных для совместного использования способом, который описан выше; например, первый модуль 1 формирования подписи формирует первую подпись 10, на основании первого ключа 12 подписи, а модуль 2 повторного подписания преобразует первую подпись 10 во вторую подпись 13, используя ключ 14 повторного подписания. С этой точки зрения, первый ключ 12 подписи может предоставляться первым модулем 1 формирования подписи, а ключ 14 повторного подписания может предоставляться модулем 2 повторного подписания.
Генератор 3 ключей повторного подписания может быть выполнен с возможностью формирования ключа 14 повторного подписания в зависимости от набора условий 17’’. Данный набор условий 17’’ может указываться пользователем посредством устройства ввода пользователя, которое может быть частью модуля 5 делегирования, который будет описан далее. Ключ 14 повторного подписания может разрешать модулю 2 повторного подписания преобразование перовой подписи 10, которая связана с любым набором атрибутов 15, отвечающим набору условий 17’’, во вторую подпись 13.
В качестве альтернативы или в дополнение, модуль 2 повторного подписания может быть выполнен с возможностью использования открытого ключа 20 для проверки того, связана ли первая подпись 10 с первым набором атрибутов 15, отвечающим набору условий 17’. Соответственно, модуль 2 повторного подписания может быть выполнен с возможностью формирования второй подписи 13 только в том случае, если первая подпись 10 связана с набором атрибутов 15, отвечающим набору условий 17’. Для обеспечения такого поведения, модуль 2 повторного подписания может быть выполнен с защитой от несанкционированного вмешательства, используя технологии цифровой защиты, известные в соответствующей области техники.
Когда как первая подпись 10, так и вторая подпись 13 связаны с набором атрибутов, тогда описанная здесь система может использоваться для замещения первой подписи 10, которая связана с первым набором атрибутов 15, второй подписью 13, которая связана со вторым набором атрибутов.
Система может содержать модуль 5 делегирования для того чтобы позволить пользователю, который владеет вторым набором атрибутов 16’, делегировать его полномочия на подписание документа 11 подписью, которая связана со вторым набором атрибутов 16, другому пользователю посредством предоставления модулю 2 повторного подписания ключа 14 повторного подписания. Модуль 5 делегирования может дополнительно быть выполнен с возможностью разрешения пользователю определения набора условий 17, 17’, 17’’ используемых генератором 3 ключей повторного подписания и/или модулем 2 повторного подписания. Модуль делегирования может содержать интерфейс пользователя, предлагающий пользователю соответствующие опции делегирования.
Проверка второй подписи 13 (опционально связанной со вторым набором атрибутов 16) может выполняться, используя модуль проверки (не показан). Данный модуль проверки может проверять аутентичность второй подписи. Данная проверка проверяет, является ли вторая подпись 13 действительной подписью для документа 11. Когда вторая подпись связана со вторым набором атрибутов 16, тогда модуль проверки дополнительно может проверять второй набор атрибутов 16 второй подписи в отношении набора условий применительно к атрибутам. Данные проверки могут выполняться, используя алгоритм проверки подписи, примеры которого описываются далее.
Система может быть реализована в рабочей станции. В качестве альтернативы, система может быть реализована в распределенной системе. Например, первый модуль 1 формирования подписи, модуль 2 повторного подписания, и генератор 3 ключей повторного подписания могут размещаться на отдельных компьютерных устройствах. Генератор 3 ключей повторного подписания может размещаться на том же компьютерном устройстве, что и второй модуль 4 формирования подписи. В отличие от использования разных физических машин, также существует возможность предоставления каждому пользователю доступа к соответствующим модулям и ключам на основе системы входа пользователя в систему.
Фиг. 2 иллюстрирует пример способа формирования основанной на атрибутах цифровой подписи. Описанная выше система может быть реализована таким образом, что она выполнена с возможностью выполнения следующего способа или его модификации. На этапе 200, запускается задающий алгоритм с тем, чтобы получить параметры открытого ключа и мастер ключа. На этапе 201, для первого пользователя формируется первый ключ подписи, используя алгоритм формирования ключа. На этапе 202, для второго пользователя формируется второй ключ подписи, используя тот же самый или другой алгоритм формирования ключа. На этапе 203, используя алгоритм формирования повторного ключа, формируется ключ повторного подписания, на основе второго ключа подписи. Данный ключ повторной подписи сохраняется в модуле повторной подписи, например, полу-доверенном сервере. На этапе 204, первым пользователем, используя первый ключ подписи, подписывается сообщение или документ, и получают первую подпись. На этапе 205, определяется, должна ли быть преобразована первая подпись. Если она не должна быть преобразована, то процесс возвращается к этапу 204. В противном случае, на этапе 206, первая подпись передается модулю повторного подписания для преобразования. На этапе 207, модуль повторного подписания принимает первую подпись и идентифицирует ключ повторной подписи в своем средстве хранения, например, посредством поиска по базе данных. Дополнительно модуль повторного подписания может проверить, согласуются ли первая подпись и ключ повторного подписания, т.е. разрешено ли преобразование первой подписи во вторую подпись, используя ключ повторного подписания, а также проверяет первую подпись, чтобы убедиться в том, что это хорошо согласованная (или сконструированная) подпись. На этапе 208, если не разрешено преобразование первой подписи, или она не является хорошо согласованной (или сконструированной) подписью, процесс может создать сообщение об ошибке и вернуться к этапу 204, в противном случае он продолжается на этапе 209. На этапе 209, модуль повторного подписания преобразует первую подпись во вторую подпись, используя алгоритм повторного подписания. На этапе 210, вторая подпись передается обратно системе первого пользователя, и первый пользователь может сохранить вторую подпись в зоне открытого хранения или передать ее, например, конкретному целевому пользователю. На этапе 211, другой пользователь или целевой пользователь принимает вторую подпись и запускает алгоритм проверки для проверки второй подписи. Данная проверка может выполняться в отношении набора условий по атрибутам, которые, как ожидается, представляет вторая подпись.
Способ может быть полностью или частично реализован в программном обеспечении, в качестве компьютерного программного продукта, содержащего инструкции, предписывающие процессорной системе выполнить способ.
Схема основанной на атрибутах посреднической повторной подписи (ABPRSS) позволяет посреднику преобразовать подпись 
субъекта B (делегированного лица), которая подписана, используя секретный ключ 
в подпись 
субъекта A (делегирующего лица), используя ключ повторной подписи.
В данном описании «посредник» относится к модулю, выполненному с возможностью выполнения вычисления применительно к формированию повторной подписи. Данный модуль или посредник может быть предоставлен со свойствами цифровой безопасности для зашиты модуля от использования злоумышленниками, такого как неправильного обращения ключей повторного подписания. Несмотря на то что характерные схемы будут описаны со ссылкой на ключи и подписи делегирующего и делегированного лиц, следует понимать, что описываемые здесь преобразования и алгоритмы также могут использоваться в различных сценариях, в которых участвует преобразование одной подписи в другую подпись, и в которых участвует схема основанной на атрибутах подписи.
Схема основанной на атрибутах подписи (ABSS) может содержать следующие алгоритмы: 1) Задающий; 2) Формирования Ключа; 3) Подписания и 4) Проверки. Схема основанной на атрибутах посреднической повторной подписи (ABPRSS) расширяет возможности посредством добавления двух алгоритмов: 1) Формирования Повторного Ключа и 2) Повторного Подписания. Ниже дано краткое описание каждого из этих алгоритмов:
Задающий: Задающий алгоритм конфигурирует параметры системы на фазе инициализации и выдает открытые параметры 
и мастер ключ 
.
Формирование Ключа 
: Алгоритм формирования ключа берет в качестве входных данных набор атрибутов 
, которыми владеет пользователь, и мастер секретный ключ 
, и он выдает секретный ключ пользователя 
.
Формирование Повторного Ключа 
: Алгоритм Формирования Повторного Ключа, в качестве примера, берет в качестве входных данных секретный ключ пользователя , который связан с набором атрибутов и выдает ключ повторной подписи, который может использоваться для преобразования подписи субъекта «A» в подпись субъекта «B».
Подписание 
: Данный алгоритм запускается делегированным лицом для создания подписи первого уровня. Он берет в качестве входных данных 
, связанный с набором атрибутов 
, опционально ключ повторной подписи 
и сообщение 
.
Повторное Подписание 
: Данный алгоритм может запускаться полу-доверенным посредником. Он берет в качестве входных данных ключ повторной подписи, который связан с набором атрибутов 
и подписью делегированного лица, т.е. 
. Он выдает подпись для делегирующего лица, т.е. 
.
Проверка 
: Данный алгоритм запускается модулем проверки. Алгоритм берет в качестве входных данных сообщение 
, открытый ключ 
и подпись 
. Алгоритм возвращает 1, если подпись 
является действительной подписью и в противном случае символ ошибки 
.
Ниже описываются два варианта осуществления, именуемые как «первая схема» и «вторая схема». Данные варианты осуществления используют два разных примера схем ABPRSS. В первой схеме, ключ повторной подписи, который связан с набором атрибутов « 
(которым владеет делегирующее лицо)», делится на два компонента, один для делегированного лица, а другой для полу-доверенного посредника, таким образом, что каждый из них по отдельности не может сформировать подпись для делегирующего лица. Во второй схеме, ключ повторной подписи выдается только полу-доверенному посреднику, в то время как делегированное лидо осуществляет подписание, используя его или ее собственный секретный ключ, который связан с набором атрибутов « 
(которым владеет делегированное лицо)». Во второй схеме, не требуется взаимодействия между делегированным лицом и делегирующим лицом, и делегированному лицу не требуется хранить дополнительных ключей повторной подписи для подписания от лица делегирующего лица. Если делегированное лицо (субъект «B») хочет преобразовать его или ее подпись в подпись делегирующего лица (субъекта «A»), тогда субъект «B» может создать подпись первого уровня таким образом, что она может быть преобразована полудоверенным посредником.
Следует понимать, что первая схема и вторая схема представляют собой лишь примеры возможных реализаций систем и способов, описываемого здесь вида. Возможны модификации этих схем. Описываемые ниже алгоритмы могут использоваться специалистом в соответствующей области техники, например, для реализации других модулей системы, описанной со ссылкой на Фиг. 1, или для дальнейшего определения этапов способа, описанного со ссылкой на Фиг. 2.
В первой схеме, первая часть ключа повторной подписи 
выдается субъекту A (делегированному лицу), а вторая часть ключа повторной подписи 
выдается посреднику. Действительная подпись может быть создана полудоверенным посредником, только если субъект A (делегированное лицо) первым подписывает сообщение. В данном случае, делегированное лицо должно хранить дополнительный секретный ключ, т.е. часть ключа повторной подписи .
Во второй схеме, делегированное лицо создает подпись первого уровня 
, используя секретный ключ 
, который связан с набором атрибутов 
, которым владеет делегированное лицо. Нет необходимости во взаимодействии между делегированным лицом и делегирующим лицом. Если делегированное лицо хочет чтобы его подпись была преобразована в подпись субъекта A (делегирующего лица), тогда подпись делегированного лица содержит несколько дополнительных компонентов. Эти дополнительные компоненты позволяют посреднику преобразовать подпись 
в подпись субъекта A (делегирующего лица) 
.
Фигура 3 предоставляет функциональную схему собственно схемы основанной на атрибутах посреднической повторной подписи. На этапе 301, субъект «A» формирует ключ повторной подписи 
, используя Алгоритм Формирования Повторного Ключа. 
может содержать два компонента: один для посредника, а другой для субъекта «B». Это относится к случаю первой назначенной схемы. Во второй представленной выше схеме, он содержит один компонент для посредника. На этапах 302 и 303, ключи повторной подписи, т.е. 
и 
, отправляются посреднику «P» и субъекту «B» соответственно. На этапе 304, субъект «B» формирует его или ее подпись, используя 
(в первой схеме) или 
(во второй схеме). На этапе 305, субъект «B» отправляет выходные данные этапа 4 посреднику «P». На этапе 306, полудоверенный посредник преобразует принятую подпись субъекта «B» в подпись субъекта «A». На этапе 307, посредник «P» отправляет подпись, созданную от имени субъекта «A» модулю проверки «V» (или получателю подписанного сообщения). На этапе 308, модуль проверки «V» подтверждает, является ли подпись подписью от субъекта «A» и является ли она подписанной секретным ключом, который относится к корректному набору атрибутов.
В первой схеме, атрибутами пользователя являются элементы 
, и предполагается, что существует самое большее 
атрибутов. На практике, можно использовать стойкую к конфликтам хэш-функцию для отображения строки атрибута в элементе . Схема содержит четыре алгоритма:
Задающий. Задающий алгоритм выбирает билинейную группу 
с порядком 
равным простому числу и генераторы 
и 
случайных чисел. В дополнение, алгоритм задания выбирает в произвольном порядке 
, и для набора атрибутов 
, он задает 
и 
для 
. Открытый ключ 
и мастер ключ 
содержат следующие компоненты:
Формирование Ключа 
. Алгоритм формирования ключа выдает секретный ключ пользователя, который связан с набором атрибутов 
. Алгоритм выбирает произвольный элемент 
(где x уникальный для каждого пользователя). Секретный ключ 
содержит следующие компоненты:
Формирование Повторного Ключа 
. Данный алгоритм запускается делегирующим лицом. Алгоритм повторного ключа выдает ключи повторной подписи, которые могут использоваться посредником и делегированным лицом для подписания от имени делегирующего лица. Алгоритм выбирает произвольные элементы 
и разбивает их на две части 
, 
таким образом, что 
. Ключ повторной подписи 
содержит следующие два компонента, один для делегированного лица, а другой для посредника:
Подписание 
. Данный алгоритм запускается делегированным лицом для подписания сообщения 
. Алгоритм выбирает произвольный элемент 
и вычисляет подпись 
, которая содержит следующие компоненты:
Повторное Подписание 
. Данный алгоритм выполняется посредником. Перед созданием подписи второго уровня (или итоговой), посредник проверяет подпись, созданную делегированным лицом следующим образом:
Теперь если 
, тогда посредник может перейти к преобразованию подписи, созданной делегированным лицом, чтобы создать подпись второго уровня (или итоговую). Алгоритм выбирает произвольный элемент 
и создает подпись второго уровня:
Проверка 
. Если имеет место равенство, тогда подпись принята.
Ниже дано описание второго варианта осуществления системы основанной на атрибутах посреднической повторной подписи. Система содержит реализацию следующих алгоритмов.
Задающий. Задающий алгоритм выбирает билинейную группу с порядком равным простому числу и генераторы и случайных чисел. Он так же выбирает билинейное отображение 
. В дополнение к этому, алгоритм задания выбирает в произвольном порядке 
, и для набора атрибутов , он задает и 
. Открытый ключ и мастер ключ содержат следующие компоненты:
Формирование Ключа . Алгоритм формирования ключа выдает секретный ключ пользователя, который связан с набором атрибутов . Алгоритм выбирает произвольный элемент 
таким образом, что 
(где x, t и q уникальны для каждого пользователя). Секретный ключ содержит следующие компоненты:
Формирование Повторного Ключа 
. Алгоритм формирования повторного ключа выдает ключи повторной подписи, которые могут использоваться посредником для преобразования подписей делегированного лица в подписи делегирующего лица. Алгоритм выбирает произвольные элементы . Ключ повторной подписи содержит следующие два компонента:
Подписание 
. Данный алгоритм запускается делегированным лицом для подписания сообщения . Алгоритм выбирает произвольный элемент и вычисляет подпись 
, используя его/ее собственный секретный ключ. Подпись 
, которая так же может именоваться как 
, содержит следующие компоненты:
Повторное Подписание 
. Данный алгоритм выполняется посредником. Алгоритм выбирает произвольный элемент и преобразует подпись делегированного лица в подпись делегирующего лица. Перед преобразованием подписи, посредник может проверить, действительно ли это действующая подпись от соответствующего делегированного лица. Проверка проходит следующим образом:
Теперь если , тогда проверка пройдена успешно, и посредник может затем перейти к формированию подписи второго уровня (или итоговой). Формирование подписи второго уровня содержит следующие этапы:
- На первом этапе он вычисляет следующее:
- На втором этапе он вычисляет следующее:
- На третьем этапе он вычисляет следующее:
где «H» является хэш-функцией.
- На четвертом этапе он вычисляет следующее:
- И на заключительном этапе он выдает подпись:
Проверка 
. Для проверки преобразованной подписи, модуль проверки может выполнять следующие этапы:
- На первом этапе он вычисляет следующее:
- На втором этапе он принимает подпись, если имеет место равенство:
Следует понимать, что алгоритмы, описанные выше в первом и втором вариантах осуществления, могут применяться в вариантах осуществления системы, описанной со ссылкой на Фиг. 1, и варианты осуществления способа, описанного со ссылкой на Фиг. 2.
Следует иметь в виду, что изобретение также применяется в компьютерных программах, в частности компьютерных программах на или в носителе, используемом для воплощения изобретения на практике. Программа может быть выполнена в виде исходного кода, объектного кода, промежуточного кода между исходным и объектным, такого как в виде частично скомпилированного, или в любом другом виде, приемлемом для использования при реализации способа в соответствии с изобретением. Также следует иметь в виду, что программа может обладать множеством разных архитектурных исполнений. Например, программный код, реализующий функциональные возможности способа или системы в соответствии с изобретением, может быть подразделен на одну или более подпрограмму. Специалисту в соответствующей области будет очевидно множество разных способов распределения функциональных возможностей между этими подпрограммами. Подпрограммы могут храниться вместе в одном исполняемом файле с тем, чтобы образовывать самостоятельную программу. Такой исполняемый файл может содержать исполняемые компьютером инструкции, например, процессорные инструкции и/или интерпретирующие инструкции (например, инструкции интерпретатора Java). В качестве альтернативы, одна или более или все из подпрограмм могут храниться, по меньшей мере, в одном внешнем файле-библиотеке, и быть связаны с основной программой либо статически, либо динамически, например, во время выполнения программы. Основная программа содержит, по меньшей мере, одну процедуру вызова, по меньшей мере, одной подпрограммы. Также подпрограммы могут содержать вызов функций друг друга. Вариант осуществления, который относится к компьютерному программному продукту, содержит исполняемые компьютером инструкции, соответствующие каждому этапу обработки, по меньшей мере, одного из изложенных здесь способов. Эти инструкции могут быть подразделены на подпрограммы и/или храниться в одном или более файлах, которые могут быть связаны статически или динамически. Другой вариант осуществления, который относится к компьютерному программному продукту, содержит исполняемые компьютером инструкции, соответствующие каждому средству, по меньшей мере, одной из изложенных здесь систем и/или продуктов. Эти инструкции могут быть подразделены на подпрограммы и/или храниться в одном или более файлах, которые могут быть связаны статически или динамически.
Носителем компьютерной программы может быть любой объект или устройство, выполненное с возможностью переноса программы. Например, носитель может быть выполнен в виде носителя данных, такого как ROM, например, CD-ROM или полупроводниковое ROM, или носителя магнитной записи, например, жесткого диска. Кроме того, носитель может быть передаваемым носителем, таким как электрический или оптический сигнал, который может переноситься через электрический или оптический кабель или посредством радиосвязи или другого средства. Когда программа воплощена в таком сигнале, то носитель может состоять из такого кабеля или другого устройства или средства. В качестве альтернативы, носителем может быть интегральная схема, в которой может быть воплощена программа, при этом интегральная схема выполнена с возможностью или используется при выполнении соответствующего способа.
Следует отметить, что упомянутые выше варианты осуществления иллюстрируют, нежели ограничивают изобретение, и что специалисты в соответствующей области будут иметь возможность разработать множество альтернативных вариантов осуществления, не отступая от объема прилагаемой формулы изобретения. В формуле изобретения, любые ссылочные обозначения, помещенные между круглых скобок не должны толковаться как ограничивающие пункт формулы изобретения. Использование глагола «содержать» и его спряжений не исключает наличие элементов или этапов, отличных от перечисленных в пункте формулы изобретения. Употребление элементов в единственном числе не исключают наличия множества таких элементов. Изобретение может быть реализовано посредством аппаратного обеспечения, содержащего несколько отдельных элементов, и посредством приемлемым способ запрограммированного компьютера. В пункте формулы изобретения, который относится к устройству, и перечисляет несколько средств, несколько из этих средств могут быть воплощены в одном и том же элементе аппаратного обеспечения. Всего лишь факт того, что определенные меры перечисляются в разных взаимозависимых пунктах формулы изобретения, не указывает на то, что для достижения преимущества не может использоваться комбинация этих мер.
Claims (17)
1. Система основанной на атрибутах цифровой подписи, содержащая:
первый модуль (1) формирования подписи для формирования первой подписи (10) для документа (11) на основе первого ключа (12) подписи и документа (11); и
модуль (2) повторного подписания, выполненный с возможностью формирования второй подписи (13) для документа (11) на основе первой подписи (10) и ключа (14) повторного подписания, при этом модуль (2) повторного подписания выполнен с возможностью обработки атрибутов (15, 16), связанных с первой подписью (10) и/или второй подписью (13), причем вторая подпись (13) связана со вторым набором атрибутов (16), определяемым ключом (14) повторного подписания, при этом второй набор атрибутов (16) содержит множество атрибутов; и
генератор (3) ключей повторного подписания для формирования ключа (14) повторного подписания на основе второго ключа (18) подписи, связанного со вторым набором атрибутов (16'), при этом ключ (14) повторного подписания позволяет модулю (2) повторного подписания преобразовать первую подпись (10) во вторую подпись (13), связанную со вторым набором атрибутов (16), и при этом второй ключ (18) подписи позволяет второму модулю (4) формирования подписи сформировать подпись (19), связанную со вторым набором атрибутов (16ʺ), на основе документа (11);
при этом генератор (3) ключей повторного подписания выполнен с дополнительной возможностью формирования первого ключа (12) подписи на основе второго ключа (18) подписи, причем первый ключ (12) подписи и ключ (14) повторного подписания формируются как пара ключей, и первый ключ (12) подписи предоставляется первому модулю (1) формирования подписи, а ключ (14) повторного подписания предоставляется модулю (2) повторного подписания.
2. Система по п. 1, в которой первая подпись (10) связана с первым набором атрибутов (15), при этом первый набор атрибутов (15) содержит множество атрибутов, и модуль (2) повторного подписания выполнен с возможностью формирования второй подписи (13), только если первый набор атрибутов (15) отвечает набору условий (17, 17').
3. Система по п. 2, в которой ключ (14) повторного подписания посредством шифрования включает в себя набор условий по отношению к атрибутам.
4. Система по п. 2, в которой генератор (3) ключей повторного подписания выполнен с возможностью формирования ключа (14) повторного подписания в зависимости от набора условий (17ʺ), при этом ключ (14) повторного подписания позволяет модулю (2) повторного подписания преобразовывать первую подпись (10), связанную с любым набором атрибутов, отвечающим набору условий (17ʺ), во вторую подпись (13).
5. Система по п. 2, в которой модуль (2) повторного подписания выполнен с возможностью использования открытого ключа (20) для проверки того, связана ли первая подпись (10) с первым набором атрибутов (15), отвечающим набору условий (17'), и формирования второй подписи (13) только в случае, когда первая подпись (10) связана с набором атрибутов (15), отвечающим набору условий (17').
6. Система по п. 1, дополнительно содержащая модуль (5) делегирования для предоставления возможности пользователю, который владеет вторым набором атрибутов (16'), делегировать его полномочия на подписание документа (11) подписью, связанной со вторым набором атрибутов (16), другому пользователю посредством предоставления модулю (2) повторного подписания ключа (14) повторного подписания.
7. Рабочая станция, содержащая систему по п. 1.
8. Способ формирования основанной на атрибутах цифровой подписи, содержащий этапы, на которых:
формируют (201) первую подпись для документа на основе первого ключа подписи и документа; и
формируют (202) вторую подпись для документа на основе первой подписи и ключа повторного подписания, включая обработку атрибутов, связанных с первой подписью и/или второй подписью, причем вторая подпись связана со вторым набором атрибутов, определяемым ключом повторного подписания, при этом второй набор атрибутов содержит множество атрибутов; и
способ дополнительно содержит этап, на котором:
формируют первый ключ подписи и ключ повторного подписания на основе второго ключа подписи, связанного со вторым набором атрибутов, при этом первый ключ подписи и ключ повторного подписания формируются как пара ключей, при этом ключ повторного подписания позволяет преобразовывать первую подпись во вторую подпись, связанную со вторым набором атрибутов, и при этом второй ключ подписи позволяет формировать подпись, связанную со вторым набором атрибутов, на основе документа.
9. Носитель, содержащий компьютерную программу, содержащую инструкции для предписания процессорной системе выполнять способ по п. 8.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP10173838 | 2010-08-24 | ||
| EP10173838.3 | 2010-08-24 | ||
| PCT/IB2011/053672 WO2012025866A1 (en) | 2010-08-24 | 2011-08-22 | Attribute-based digital signatures |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| RU2013112947A RU2013112947A (ru) | 2014-09-27 |
| RU2623724C2 true RU2623724C2 (ru) | 2017-06-28 |
Family
ID=44645160
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2013112947A RU2623724C2 (ru) | 2010-08-24 | 2011-08-22 | Основанные на атрибутах цифровые подписи |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US9401811B2 (ru) |
| EP (1) | EP2609712A1 (ru) |
| JP (1) | JP2013536651A (ru) |
| CN (1) | CN103069745B (ru) |
| BR (1) | BR112013004074A2 (ru) |
| RU (1) | RU2623724C2 (ru) |
| WO (1) | WO2012025866A1 (ru) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2885893B1 (en) * | 2012-08-17 | 2018-09-26 | Koninklijke Philips N.V. | Attribute-based encryption |
| CN104184584A (zh) * | 2013-05-27 | 2014-12-03 | 华为技术有限公司 | 多重签名的方法及其装置 |
| KR20150084221A (ko) | 2014-01-13 | 2015-07-22 | 삼성전자주식회사 | 어플리케이션 패키지의 재서명 장치, 방법 및 상기 어플리케이션 패키지를 실행하는 단말장치 |
| US9230133B2 (en) | 2014-01-14 | 2016-01-05 | International Business Machines Corporation | Secure access for sensitive digital information |
| US10452869B2 (en) * | 2014-05-07 | 2019-10-22 | Infineon Technologies Ag | Systems and methods for processing and verifying data using signatures |
| US9544150B2 (en) | 2014-06-04 | 2017-01-10 | International Business Machines Corporation | Using multiple digital identification documents to control information disclosure |
| US10097354B2 (en) | 2015-08-21 | 2018-10-09 | International Business Machines Corporation | Privacy control using unique identifiers associated with sensitive data elements of a group |
| EP3179670A1 (en) * | 2015-12-11 | 2017-06-14 | Gemalto Sa | Secure electronic device with mechanism to provide unlinkable attribute assertion verifiable by a service provider |
| US10218515B2 (en) * | 2016-08-26 | 2019-02-26 | Microsoft Technology Licensing, Llc | Evolving a signature during trust verification of an object |
| US10116450B1 (en) * | 2016-11-02 | 2018-10-30 | ISARA Corporation | Merkle signature scheme using subtrees |
| CN106789066B (zh) * | 2016-12-12 | 2019-09-24 | 西北工业大学 | 基于ip签名的代理重签名方法 |
| US11356427B1 (en) | 2017-02-15 | 2022-06-07 | Wells Fargo Bank, N.A. | Signcrypted envelope message |
| US11354660B1 (en) | 2017-04-27 | 2022-06-07 | Wells Fargo Bank, N.A. | Encapsulation of payment information |
| US11647006B2 (en) * | 2018-05-10 | 2023-05-09 | Telecom Italia S.P.A. | Protecting signaling messages in hop-by-hop network communication link |
| CN108777626A (zh) * | 2018-08-16 | 2018-11-09 | 西南交通大学 | 一种支持动态属性空间的属性基网络签名方法 |
| US11601284B2 (en) * | 2019-06-14 | 2023-03-07 | Planetway Corporation | Digital signature system based on a cloud of dedicated local devices |
| US10581616B1 (en) | 2019-07-11 | 2020-03-03 | ISARA Corporation | Managing nodes of a cryptographic hash tree in a hash-based digital signature scheme |
| JP7348848B2 (ja) * | 2020-01-16 | 2023-09-21 | 株式会社国際電気通信基礎技術研究所 | 統合属性ベースグループ署名処理方法、統合属性ベースグループ署名処理システム、および、プログラム |
| US11165588B1 (en) * | 2020-04-09 | 2021-11-02 | International Business Machines Corporation | Key attribute verification |
| CN113271200A (zh) * | 2021-05-26 | 2021-08-17 | 陕西理工大学 | 一种抗量子攻击的格属性签名方法 |
| WO2023152797A1 (ja) * | 2022-02-08 | 2023-08-17 | 富士通株式会社 | 検証方法、検証プログラムおよび情報処理装置 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040181756A1 (en) * | 2000-06-06 | 2004-09-16 | Berringer Ryan R. | Creating and verifying electronic documents |
| US20090327735A1 (en) * | 2008-06-26 | 2009-12-31 | Microsoft Corporation | Unidirectional multi-use proxy re-signature process |
| US20100037062A1 (en) * | 2008-08-11 | 2010-02-11 | Mark Carney | Signed digital documents |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5422953A (en) * | 1993-05-05 | 1995-06-06 | Fischer; Addison M. | Personal date/time notary device |
| RU2144269C1 (ru) * | 1994-07-19 | 2000-01-10 | Сертко, Ллс | Способ секретного использования цифровых подписей в коммерческой криптографической системе |
| US7003480B2 (en) * | 1997-02-27 | 2006-02-21 | Microsoft Corporation | GUMP: grand unified meta-protocol for simple standards-based electronic commerce transactions |
| US6151676A (en) * | 1997-12-24 | 2000-11-21 | Philips Electronics North America Corporation | Administration and utilization of secret fresh random numbers in a networked environment |
| JP4185363B2 (ja) * | 2001-02-22 | 2008-11-26 | ビーイーエイ システムズ， インコーポレイテッド | トランザクション処理システムにおけるメッセージ暗号化及び署名のためのシステム及び方法 |
| US7181017B1 (en) * | 2001-03-23 | 2007-02-20 | David Felsher | System and method for secure three-party communications |
| ATE270800T1 (de) * | 2002-05-24 | 2004-07-15 | Swisscom Mobile Ag | Vorrichtungen und verfahren zur zertifizierung von digitalen unterschriften |
| JP4591894B2 (ja) * | 2003-10-17 | 2010-12-01 | インターナショナル・ビジネス・マシーンズ・コーポレーション | セキュリティモジュールを有するユーザ装置により実行できる処理に対するプライバシの維持 |
| US8276209B2 (en) * | 2004-09-17 | 2012-09-25 | Koninklijke Philips Electronics N.V. | Proximity check server |
| JP2006325072A (ja) * | 2005-05-20 | 2006-11-30 | Kddi R & D Laboratories Inc | 属性情報交換システム、属性情報交換方法および通信端末 |
| WO2008028291A1 (en) * | 2006-09-08 | 2008-03-13 | Certicom Corp. | Authenticated radio frequency identification and key distribution system therefor |
| DE502007003579D1 (de) * | 2007-01-15 | 2010-06-10 | Stepover Gmbh | Verfahren und Vorrichtung zum Sichern eines Dokuments mit eingefügtem Signaturabbild und biometrischen Daten in einem Computersystem |
| US8171527B2 (en) * | 2007-06-26 | 2012-05-01 | General Instrument Corporation | Method and apparatus for securing unlock password generation and distribution |
| EP2166493A1 (en) * | 2008-09-12 | 2010-03-24 | BRITISH TELECOMMUNICATIONS public limited company | Control of supply networks and verification of items |
| DE102008055076A1 (de) * | 2008-12-22 | 2010-07-01 | Robert Bosch Gmbh | Vorrichtung und Verfahren zum Schutz von Daten, Computerprogramm, Computerprogrammprodukt |
| EP2355402A1 (en) * | 2010-01-29 | 2011-08-10 | British Telecommunications public limited company | Access control |
| MA34182B1 (fr) | 2010-04-30 | 2013-04-03 | Syngenta Participations Ag | Procédé de reduction d'infections virales a vecteurs insecte |
| US8527777B2 (en) * | 2010-07-30 | 2013-09-03 | International Business Machines Corporation | Cryptographic proofs in data processing systems |
-
2011
- 2011-08-22 CN CN201180040747.4A patent/CN103069745B/zh active Active
- 2011-08-22 JP JP2013525395A patent/JP2013536651A/ja active Pending
- 2011-08-22 EP EP11755144.0A patent/EP2609712A1/en not_active Withdrawn
- 2011-08-22 US US13/818,178 patent/US9401811B2/en active Active
- 2011-08-22 BR BR112013004074A patent/BR112013004074A2/pt not_active IP Right Cessation
- 2011-08-22 RU RU2013112947A patent/RU2623724C2/ru active
- 2011-08-22 WO PCT/IB2011/053672 patent/WO2012025866A1/en active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040181756A1 (en) * | 2000-06-06 | 2004-09-16 | Berringer Ryan R. | Creating and verifying electronic documents |
| US20090327735A1 (en) * | 2008-06-26 | 2009-12-31 | Microsoft Corporation | Unidirectional multi-use proxy re-signature process |
| US20100037062A1 (en) * | 2008-08-11 | 2010-02-11 | Mark Carney | Signed digital documents |
Non-Patent Citations (1)
| Title |
|---|
| HEMANTA MAJI et al, статья "ATTRIBUTE-BASED SIGNATURES: ACHIEVING ATTRIBUTE-PRIVACY AND COLLUSION-RESISTANCE", опубл. 15.04.2008 на 23 листах. * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2012025866A1 (en) | 2012-03-01 |
| BR112013004074A2 (pt) | 2016-07-26 |
| RU2013112947A (ru) | 2014-09-27 |
| EP2609712A1 (en) | 2013-07-03 |
| US9401811B2 (en) | 2016-07-26 |
| CN103069745A (zh) | 2013-04-24 |
| US20130159730A1 (en) | 2013-06-20 |
| CN103069745B (zh) | 2017-04-19 |
| JP2013536651A (ja) | 2013-09-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2623724C2 (ru) | Основанные на атрибутах цифровые подписи | |
| Pussewalage et al. | Privacy preserving mechanisms for enforcing security and privacy requirements in E-health solutions | |
| Sajid et al. | Data privacy in cloud-assisted healthcare systems: state of the art and future challenges | |
| Ibraimi et al. | Secure management of personal health records by applying attribute-based encryption | |
| Sun et al. | Cross-domain data sharing in distributed electronic health record systems | |
| Zhou et al. | PSMPA: Patient self-controllable and multi-level privacy-preserving cooperative authentication in distributedm-healthcare cloud computing system | |
| Abbas et al. | A review on the state-of-the-art privacy-preserving approaches in the e-health clouds | |
| US20120260094A1 (en) | Digital rights managmenet using attribute-based encryption | |
| EP2885893B1 (en) | Attribute-based encryption | |
| Pussewalage et al. | Attribute based access control scheme with controlled access delegation for collaborative E-health environments | |
| Huang et al. | A hierarchical framework for secure and scalable EHR sharing and access control in multi-cloud | |
| Jiang et al. | Attribute-based encryption with blockchain protection scheme for electronic health records | |
| Khan et al. | Fine-grained access control to medical records in digital healthcare enterprises | |
| Pussewalage et al. | An attribute based access control scheme for secure sharing of electronic health records | |
| T. de Oliveira et al. | A break-glass protocol based on ciphertext-policy attribute-based encryption to access medical records in the cloud | |
| Alam et al. | Garbled role-based access control in the cloud | |
| Sethia et al. | CP-ABE for selective access with scalable revocation: A case study for mobile-based healthfolder. | |
| Garson et al. | Security and privacy system architecture for an e-hospital environment | |
| Chen | A trusted user-to-role and role-to-key access control scheme | |
| Debnath et al. | A secure revocable personal health record system with policy-based fine-grained access control | |
| Khan et al. | Toward a synergy among discretionary, role-based and context-aware access control models in healthcare information technology | |
| Choksy et al. | Attribute based access control (ABAC) scheme with a fully flexible delegation mechanism for IoT healthcare | |
| Mohammadi et al. | A consumer-centered security framework for sharing health data in social networks | |
| Fugkeaw | An efficient and scalable vaccine passport verification system based on ciphertext policy attribute-based encryption and blockchain | |
| Ibrahim | New secure solutions for privacy and access control in health information exchange |