Основанные на атрибутах цифровые подписи

Основанные на атрибутах цифровые подписи

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Изобретение относится к основанным на атрибутах цифровым подписям.

УРОВЕНЬ ТЕХНИКИ

Растущая потребность в обмене данными между разными сторонами, участвующими в цикле заботы о здоровье, который простирается от традиционного медицинского обслуживания через оказание медицинской помощи на дому до оздоровительных услуг, в качестве одной из основных задач ставит задачу по управлению безопасностью медицинских данных. Современные подходы, которые основаны на традиционных механизмах обеспечения безопасности совместно с дополненными необходимыми физическими и административными процедурами, ограничивают доступность медицинской информации и делают громоздким обмен медико-санитарной документацией. Цифровые технологии управления и защиты посредством политик превосходят эти традиционные подходы, предлагая возможности по реализации (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».

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

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