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

 

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

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

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

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

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

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

Имеются два типа криптографических систем, в которых использовалась цифровая подпись: это симметричные и асимметричные криптографические системы. На фиг. 1a и 1b показано использование симметричных и асимметричных алгоритмов кодирования. В симметричной (известной) криптографии, как показано на фиг. 1a, отправитель и получатель во время связи совместно используют секретный ключ 11. Этот ключ используется отправителем, который устанавливает связь, для кодирования сообщения 12 и участвующим в связи получателем для расшифровки сообщения 13. Кроме этого, он может быть использован получателем для опознавания сообщения путем использования отправителем секретного ключа для расчета на основании сообщения некоторых функций, таких как кода опознавания сообщения (MAC); таким образом, получатель может быть уверен в идентичности источника, так как только отправителю и получателю известен секретный ключ, используемый для расчета MAC. DES (стандарт шифрования данных) является примером симметричной криптографической системы.

В асимметричной (с открытым ключом) криптографии, показанной на фиг. 1b, для кодирования и расшифровки используются различные ключи. Каждому пользователю назначается пара ключей. Один из ключей 15 (открытый ключ) известен всем и используется для кодирования сообщений 17, предназначенных для данного пользователя, а другой ключ 16 (секретный ключ) известен только данному пользователю и используется для расшифровки приходящих сообщений 18. Так как не нужно держать в секрете открытый ключ, то более нет необходимости сохранять секретность при передаче совместно используемого ключа кодирования между участвующими в связи сторонами до взаимообмена секретным трафиком или сообщениями опознавания. RSA является наиболее распространенным асимметричным алгоритмом.

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

Кроме этого, цифровые подписи могут формироваться путем использования асимметричных алгоритмов кодирования, как это описано ниже и как показано на фиг. 2. Для подписи сообщения сообщение 20 вначале дигестируется (хешируется) в единый блок 22 путем использования односторонней хеш-функции 21. Односторонняя хеш-функция имеет то свойство, что при данном дигесте невозможно при помощи вычислительных средств построить какое-либо сообщение, которое можно было бы хешировать в это значение и невозможно найти два сообщения, которые можно было бы хешировать в один и тот же дигест. Затем дигест 22 кодируется при помощи секретного ключа пользователя 23, и результат 24 добавляется к закодированному или к незакодированному сообщению в качестве его подписи 25. Получатель использует открытый ключ отправителя 26 для дешифровки подписи 25 в хешированный дигест 22. Получатель также дигестирует (хеширует) в блок 27 принятое незакодированным или закодированным сообщение 20, которое было затем дешифровано получателем путем использования той же самой односторонней хеш-функции 21, используемой отправителем. Затем получатель проверяет 28 подпись отправителя путем проверки, совпадает ли хешированный дигест 22 с дигестом хешированного сообщения 27.

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

Цифровая подпись обеспечивает услугами секретности, включая (a) целостность, так как любое изменение подписываемых данных приведет к изменению дигеста и, следовательно, к другой подписи; (b) опознавание источника, так как только держатель секретного ключа, соответствующего открытому ключу, используемому для проверки достоверности подписи, может подписывать сообщение и (c) неотречение в качестве неотъемлемого доказательства для третьей стороны, что только подписчик, а не получатель или его служащие, может создавать подпись. Устройство опознавания симметричного секретного ключа, например X9.9 MAK, не предоставляет эти услуги, так как любая из двух сторон может создать устройство опознавания путем использования их общего ключа. Некоторые механизмы, рассмотренные далее, предполагают возможность прилагать несколько подписей или сопутствующих подписей к документу. Подходящий формат для этих целей, который хорошо известен в технике, определяется в "PKCS #7: синтаксис криптографического сообщения" секретность данных RSA, Inc., 1993, приведенная здесь в качестве ссылки. Каждая структура подписи документа будет содержать указание сертификата, необходимого для подтверждения достоверности подписи одновременно со строкой битов, содержащей фактическую подпись. Дополнительно в процессе расчета индивидуальной подписи может использоваться другая информация, имеющая отношение к конкретному подписчику. Эта информация, имеющая отношение к конкретному пользователю, может быть использована в процессе расчета подписи как "атрибут подписи".

Для опознавания пользователя другим пользователем для передачи сообщения способом, который гарантирует обладание секретного ключа другим пользователем, первый пользователь должен иметь возможность получить открытый ключ другого пользователя от пользующегося доверием источника. Как хорошо известно в технике, основа для использования сертификатов открытого ключа была определена в "X.509 справочник: основы опознавания", MKKTT, апрель, 1993 ("X. 509"), который приведен здесь в качестве ссылки. Эти основные сертификаты открытого ключа связывают имя пользователя с открытым ключом и подписываются пользующимися доверием источниками, называемыми органами сертификации (CA). Кроме имени пользователя и открытого ключа сертификат содержит имя CA издателя, серийный номер и срок действия.

Хотя X. 509 не ограничивает какой-либо конкретной структурой CA, но во многих исполнениях считается разумным использовать иерархические структуры, в которых CA (вообще) заверяют только сущности, которые подчиняются им. Следовательно, мы можем построить иерархию CA, как показано на фиг. 3, в которой CA более высокого уровня 31 (возможно банки) подписывают сертификаты 34 подчиненных им CA 32 (например, сертификаты компаний), а CA самого низкого уровня 32 подписывают сертификаты 35 пользователей 33. В верхушке этой иерархии (не показана) имеется относительно небольшое количество других основных CA, возможно один на страну, которые могут осуществлять "взаимную сертификацию" открытых ключей (корневых ключей).

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

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

Часто необходимо, чтобы информация, связанная с сущностью или с требованиями CA, стала бы доступной на условиях доверия. В справочнике по обеспечению секретности X.500 такая информация должна искаться посредством стандартных операций поиска в справочнике, и результат должен указываться справочником. В случае отсутствия такого обеспечивающего секретность исполнения X. 500 эта информация помещается в сертификат-атрибут, который подписывается CA так же, как и сертификат открытого ключа. Сертификаты-атрибуты должны создаваться после предоставления пользователем соответствующего удостоверения личности. Например, пользователь может представить свой сертификат открытого ключа и доказать, что он обладает соответствующим секретным ключом в качестве одной из форм идентификации. Сертификаты-атрибуты связываются с базовым сертификатом открытого ключа пользователя путем задания серийного номера базового сертификата и аннулируются посредством идентичного параллельного CRL механизма. Сертификаты-атрибуты детально рассматриваются в "X9.30 часть 3: организация сертификатов для DSA", ANSI (Американский институт национальных стандартов) X9F1, июнь 1994 года, а также в патентах США N 4868877, 5005200 и 5214702, которые хорошо известны в технике и приведены здесь в качестве ссылок.

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

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

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

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

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

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

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

Краткое описание чертежей Указанные выше цели и преимущества настоящего изобретения станут очевидными после рассмотрения приведенного далее детального описания, рассматриваемого с учетом прилагаемых чертежей, на которых аналогичные части пронумерованы одинаково и на которых: фиг. 1a и 1b - ранее известное использование симметричных и асимметричных алгоритмов для кодирования; фиг. 2 - последовательность операций, иллюстрирующая ранее известный процесс обработки цифровых подписей путем использования асимметричного алгоритма кодирования; фиг. 3 - иерархия органов сертификации подписи; фиг. 4 - дерево справочной информации (DIT); фиг. 5 - пример сертификата санкционирования; фиг. 6 - последовательность операций, иллюстрирующая ранее известный процесс ввода в действие проверяющим ограничения денежной величины сделки; фиг. 7 - последовательность операций, иллюстрирующая ранее известный процесс ввода в действие проверяющим требования на сопутствующие подписи сделки;
фиг. 8 - последовательность операций, иллюстрирующая процесс ввода в действие проверяющим ограничения на тип документа сделки;
фиг. 9 - последовательность операций, иллюстрирующая процесс ввода в действие проверяющим географического и временного контроля;
фиг. 10 - последовательность операций, иллюстрирующая процесс ввода в действие проверяющим ограничения на максимальный срок действия подписи отправителя;
фиг. 11 - последовательность операций, иллюстрирующая процесс ввода в действие проверяющим и спонсором заранее принятого ограничения по отношению к партнеру;
фиг. 12 - последовательность операций, иллюстрирующая процесс ввода в действие проверяющим требования "подтверждения" сделки;
фиг. 13 - последовательность операций, иллюстрирующая процесс сертификации устройством ключевого ограничения и некодирования;
фиг. 14 - последовательность операций, иллюстрирующая процесс удержания в секрете открытых ключей и ввода в действие подписи правил системы; а
фиг. 15 - последовательность операций, иллюстрирующая процесс проверки правил пользователя, имеющих отношение к сделке.

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

Кроме этого, сертификаты-атрибуты могут подписываться "спонсором" пользователя для указания, что подпись спонсора обязательна в официальных деловых отношениях, если данная сделка удовлетворяет требованиям, принятым или налагаемым данными атрибутами. Хотя типичный спонсор пользователя будет нанимателем пользователя, но данная модель может быть развита для включения банка пользователя, издателя кредитной карточки, бюро голосования, видеопроката, публичной библиотеки или любой другой сущности, которая может принять подпись пользователя. Этот сертификат спонсора (санкционирование), таким образом, является электронным эквивалентом "эффидевита официальной марки", используемой в смысле традиционной печати с подписью. См. "Ограничение ответственности CA и отдельных лиц относительно использования цифровых подписей", автор - Robert Jueneman, представленной ABA отделу уполномоченной рабочей группы по сертификации научной деятельности и технологий 2 июля 1993 года.

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

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

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

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

Справочник X. 500 имеет иерархическую структуру; результирующая распределенная база данных содержит информационное дерево справочника (DIT), как показано на фиг. 4. Каждый вход 41 принадлежит определенному классу объектов и состоит из множества свойств, называемых атрибутами 42. Атрибут 42 состоит из типа 43 и одного или более значений 44. Таким образом, во входе класса организации одним атрибутом является имя организации; во входе класса представителей организации атрибуты могут содержать звание и номер телефона.

Кроме этого, каждый вход имеет одно или более специальное значение-атрибут, используемый для построения имени объекта; это значение-атрибут является относительно выделенным именем (RDN) входа. Выделенное имя объекта (DN) 45, которое создается путем конкатенации относительно выделенных имен 46 всех входов из корневого пути DIT к входу, единственным образом определяет данный объект в глобальном DIT.

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

Дополнительно к применению DIT к групповым сущностям совместно с организационными линиями X.500 определяет несколько классов объектов, которые могут быть использованы для построения произвольных групп сущностей. Эти классы объектов включают организационную роль, чей атрибут, "содержащий роль", имеет список имен пользователей, которые обладают данной ролью, а также группу имен, чьи атрибуты "представители" перечисляют имена членов группы. Для передачи этой информации заслуживающим доверия способом можно определить сертификаты роли и группы, которые будут передавать имена обладателей роли или членов группы соответственно и которые будут подписаны CA, позволяя таким образом использование этого свойства за пределами среды системы справочника X.500.

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

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

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

(2) Спецификацию доверия: описание, какие пользователи и CA данного CA могут подвергаться сертификации, имеющие отношение к данному CA (например, "все подчиненные") или к DIT вообще (например, "заместители ниже организации ABC"), или к другим.

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

(4) Формы допустимых имен: определение форм допустимых имен, сертификацию которых может осуществить CA. Эта информация имеет вид (a) набора обязательств, связанных с именами, которые определяют атрибуты, которые могут использоваться для назначения имени сущностям объектов данного класса (то есть, допустимые форматы RDN для сущностей этого класса), и (b) набора правил структуры, которые определяют, классы каких объектов могут быть смежными (то есть основными или подчиненными) по отношению друг к другу в DIT, то есть порядок, в котором классы объектов могут быть связаны в цепь для формирования полной DN. Этот атрибут политики может использоваться для ограничения типа сущностей, которые могут подписывать сделку. Например, для приложений проводной связи может быть желательно, чтобы возможность подписываться имела данная организация, а не пользователи данной организации, так как это аналогично текущему режиму работы посредством использования DES MAC.

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

Атрибуты в сертификате-атрибуте пользователя или сущности могут представлять информацию, проверенную CA во время создания сертификата для данной сущности. Атрибуты политики в сертификате пользователя кроме всего прочего могут содержать:
(1) Информацию относительно обязательств: критерий, используемый для связи открытого ключа с идентификатором сертифицируемой сущности. Это включает (a) способ поставки такой, как персонально передаваемый уполномоченным агентом по почте или другим способом; (b) способ идентификации, который может, например, осуществляться посредством разумной коммерческой деятельности, проверяемый доверенной третьей стороной, двойной контроль, проверку отпечатков пальцев, полное предварительное исследование или другой способ; (c) идентификационные документы, представленные CA; а также (d) тип сущности объекта, то есть, индивидуальный, корпоративный, средства или другой.

(2) Доверенные третьи стороны: имена любых доверенных третьих сторон или агентов, вовлеченных в процесс обязательств.

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

(4) Относительный идентификатор: CA может понадобиться осуществить сертификацию только части DN (абонентского номера) индивидуальных лиц. В частности, CA может отменить ответственность за правильность персонального имени индивидуальных лиц, так как в соответствии с принципами юридического агентства подпись индивидуальных лиц является обязательной для их организационного спонсора в любом случае. Рассмотрим имя:
C=US; O=доверенные банкиры; OU=глобальная электронная коммерция; CN=Frank Sudia; TI=VP.

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

(5) Абсолютный идентификатор: мы определим относительный идентификатор как идентификатор пользователя, "имеющий отношение" к его организационному спонсору. Другими словами, удостоверяются все элементы "идентификатора кредитной карточки" пользователя, за исключением его персонального имени.

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

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

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

Когда получающий пользователь (проверяющий) принимает сделку 51 от отправляющего пользователя, то получатель вначале использует сертификат базового ключа отправителя 55 для проверки подписи отправителя 52 на сделке 51. Как будет описано далее более детально, получатель использует также сертификат санкционирования отправителя 56, подписанный спонсором отправителя 59 для проверки сопутствующих подписей 53 и нотариально засвидетельствованной метки времени 54, которые добавляются к сделке 51, а также для проверки, находятся ли значения атрибута 57 сделки 51 среди значений санкционированного атрибута 58, как описано в сертификате санкционирования 56.

Пользователь может быть ограничен рамками сделки, которые контролируют значение сделки или другие документы, которые может создать пользователь. Подпись этого пользователя будет достоверной только на начальной стадии сделки, до определенного денежного предела или между двумя граничными денежными значениями. Соответственно, как показано на фиг. 6, отправляющий пользователь передает сделку 601, подписанную 603 отправителем (в действительности кредитной карточкой пользователя 600, содержащей его секретный ключ) и прибавляет туда сертификат санкционирования 604. Проверяющий использует сертификат санкционирования 604 для проверки 607 подписи пользователя 603 и для проверки, не выходит ли денежное значение сделки 602 за рамки граничного значения атрибута сделки 605 в сертификате санкционирования 604. Кроме этого, проверяющий проверяет 609 подпись спонсора 606 на сертификате санкционирования 604, используя открытый ключ пользователя 610. Если какая-либо из этих подписей и значение атрибутов не проверяется, то сделка отменяется 611. Если проверка завершена, то сделка принимается 612.

Что касается требований к сопутствующим подписям, то могут потребоваться дополнительные подписи для того, чтобы данная подпись рассматривалась как достоверная. Могут использоваться механизмы кворума и взвешивания для организации тщательно продуманных проверок и балансов для ясного управления уровнем доверия каждого пользователя. Может быть определена также конкретная последовательность или порядок требуемых подписей. Обратимся к фиг. 7, отправляющий пользователь A передает сделку 702, подписанную 703 его собственной кредитной карточкой 700, и если необходима сопутствующая подпись пользователя B на сделке 702, то она ставится 704 кредитной карточкой пользователя B 701. Отправляющий пользователь A добавляет также свой собственный сертификат санкционирования 705 к сделке 702. Проверяющий использует сертификат санкционирования 705 для проверки 711 подписи пользователя A 703 и использует открытый ключ спонсора 713 для проверки 712 подписи спонсора 707 на сертификате санкционирования 705; если какая-либо из подписей не проверяется, то сделка отменяется 720. Если для сертификата санкционирования 705 необходимо 714 значение сопутствующей подписи 706, то получатель вводит в действие это требование путем проверки 715 сопутствующей подписи пользователя B 704 на сделке 702 и затем проверяет сертификат открытого ключа пользователя B, поставившего сопутствующую подпись 708 путем проверки 716 подписи 709 издателя сертификата, используя открытый ключ издателя 717. Если не проверяется подпись пользователя B или подпись издателя его сертификата, то сделка отменяется 722.

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

Подписи санкционирования, которые должны соответствовать ограничениям, определенным в сертификате пользователя, тоже могут отделяться от других сопутствующих подписей путем включения цели подписи в качестве атрибута подписи и путем наложения требования, чтобы указание цели подписи было включено в подписываемые данные. Для такого атрибута цели подписи могут потребоваться значения: (a) соответствующей документу подписи санкционирования, (b) соответствующая данному документу сопутствующая подпись санкционирования, где сертификат выполняющего сопутствующую подпись имеет достаточное полномочие для санкционирования документа и (c) свидетельская сопутствующая подпись, где сертификат выполняющего сопутствующую подпись сам по себе не имеет достаточного полномочия для санкционирования данного документа. Коды цели подписи рассмотрены в проекте стандарта ANSI X12.58 версии 2 (приложение), изданном Ассоциацией стандартов обмена данными (DISA), который хорошо известен в технике и приведен здесь в качестве ссылки.

Кроме этого, к пользователю могут применяться ограничения, согласно которым он должен подписывать только конкретные типы документов, такие как корреспонденция общего вида, заказы на закупку, специальные типы EDI (электронный обмен данными) сделок, деловые контракты, определенные финансовые документы и т. д. в соответствии с тем, что определено общепроизводственной политикой. Кроме этого, для большей производительности может потребоваться исключить определенный широкий класс сделок и документов. Обратимся к фиг. 8: получатель вводит в действие ограничения типа документа в сделке отправителя 801 путем, во-первых, проверки 807 подписи отправителя 803 на сделке и затем путем проверки 808 значения атрибута типа документа 802 в сделке 801 для ввода в действие ограничения типа документа 805 в сертификате санкционирования отправителя 804. Получатель затем проверяет сертификат санкционирования 804 путем использования открытого ключа спонсора 811 для проверки 809 подписи спонсора 808. Если не проверяется подпись или ограничение атрибута, то сделка отменяется 810.

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

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

Географические и временные контроли включают места расположения и период времени, на основании которых сделки считаются достоверными. Допускается использование локальной доверенности, "нотариально подтвержденной отметкой времени". Такое нотариальное подтверждение должно присоединять установленную отметку времени к подписи источника на документе и затем должно подписывать результат. Таким образом, ограничения времени дня и дня недели обычно должны размещаться смежным образом с рабочей неделей места расположения пользователя. Кроме этого, информация о месте расположения должна связываться с нотариальным заверением так, чтобы ограничивать доступ к специфическому сегменту сети, обычно это рабочая область, назначенная пользователю. "Шероховатость" контроля места расположения должна зависеть от архитектуры сети. Подписчик или компьютерная система подписчика должна прилагать к сделке заверенную отметку времени, полученную от определенного локального сервера, либо в противном случае проверяющий не сможет принять сделку, и спонсор подписывающего не будет иметь никаких обязательств по ней. Как показано на фиг. 9, отправляющий пользователь прилагает к сделке как обычно 901 сертификат санкционирования 902, санкционированную отметку времени 903 и сертификат сервера времени 904. Получатель проверяет 921 подпись отправителя 905 на сделке 901 и проверяет 922 подпись спонсора 908 на сертификате санкционирования 902. Затем получатель (1) проверяет 923, соответствует ли хешированный текст сделки с меткой времени 909 результату текста сделки 901, который был хеширован при помощи известной хеш-функции, (2) проверяет 924, чтобы время и дата 910 отметки времени сделки 903 не выходили за рамки значений атрибута санкционированных времени и даты 906, в соответствии с тем, что указано в сертификате санкционирования 902, (3) проверяет 925 подпись сервера времени 911 на отметке времени 903 и (4) проверяет 926 подпись спонсора 912 на сертификате сервера времени. Если все эти условия будут удовлетворены, то сделка принимается 931; в противном случае сделка отменяется 930.

Более того, документ не может быть достоверным до проверки его подписи в течение определенного периода времени. Для дорогих сделок этот период атрибута возраста подписи должен быть достаточно малым, в то время как в случае обычных сделок, которые, например, были переданы посредством систем хранения и передачи таких, как X.400, должен использоваться более длительный интервал (такой, как два дня). На фиг. 10 показан ввод в действие получателем значения атрибута возраста подписи. Время проверки должно соответствовать рецепту 103, подписанному доверенной службой отметки времени 104, содержащей, по крайней мере, имя получателя и подпись исходной сделки. Проверяющий должен представить копию отметки времени исходной подписи, датированной непосредственно после времени и даты, указанных на исходной сделке, так как в противном случае спонсор отменит ее. Как показано на фиг. 10, получатель (проверяющий) проверяет 121 подпись отправителя 107 на сделке 101 и проверяет подпись спонсора 115 на сертификате санкционирования 102. Затем получатель проверяет 122, чтобы различие между датой 105 и временем 106 на сделке 101 и датой 111 и временем 112 на отметке времени 103 не выходило за рамки ограничения атрибута возраста подписи 108 в сертификате санкционирования 102. Кроме этого, получатель проверяет 123, чтобы хеш 103 сделки 101 в утвержденной отметке времени 103 согласовывался с текстом сделки 101. Если все эти условия выполняются, то сделка принимается 130; в противном случае сделка отменяется 131.

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

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

На фиг. 11 проиллюстрирована проверка спонсором пользователя сделки пользователя после ее приема получателем. Получатель (партнер) проверяет 1110 подпись пользователя 1103 на сделке 1101 и проверяет 1111 подпись спонсора 1105 на сертификате санкционирования пользователя 1102. Если какая-либо из этих подписей не проверяется, то сделка 1101 отменяется 1112. Если подписи проверены и сделка принята 1113 получателем, то получатель заверяет сделку 1101, выдавая эту проверенную сделку 1114, подписывая 1116 текст 1106 исходной сделки пользователя 1101 и посылая подпись пользователя 1103 вместе с сертификатом получателя 1115. Во время ввода в действие заранее принятых ограничений партнеров для передаваемого сертификата санкционирования пользователя 1102 спонсор отправляющего пользователя проверяет 1121 подпись отправляющего пользователя 1103, которая имеется в проверенной сделке получателя 1114, и проверяет 1122 подпись получателя 1116, имеющуюся на ней. После проверки этих подписей спонсор проверяет 1123 хеш значение открытого ключа партнера путем хеширования открытого ключа получателя 1117 и путем сравнения результата с одним из хеш значений открытого ключа санкционированного партнера 1104, как это определено в сертификате санкционирования пользователя 1102 (открытый ключ получателя 1117, который хеширует спонсор для проверки, сам проверяется 1124 во время проверки спонсором сертификата получателя). Если все эти условия выполнены, то сделка принимается 1125.

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

Другой атрибут санкционирования, называемый значением "требование подтверждения", не позволяет подписи быть достоверной до момента отправления проверяющим по специальной почте или по адресу сети копии проверенной сделки третьей стороне, которая обычно является организационным спонсором пользователя или контролером работы, а также до приема сообщения о принятии/отмене, или (b) сообщения об истечении определенного времени. Это требование аналогично сопутствующей подписи, но налагается скорее после отправления сделки, а не до того. Такое подтверждение после данного факта может быть приемлемо в ситуациях с малым риском, когда может отменяться небольшое количество сделок и когда предварительное получение сопутствующей подписи от третьей стороны может оказаться излишне обременительным. Такому подтверждению может отдаваться предпочтение в случае дорогой сделки, когда отвергается положительная проверка в неавтономном режиме. В этом случае режим потока вновь устанавливается скорее для системы в неавтономном режиме, чем для системы в автономном режиме. Как показано на фиг. 12, получатель вначале, как обычно, проверяет 1211 подпись отправителя 1203 на сделке 1201 и проверяет 1212 подпись спонсора 1205 на сертификате санкционирования пользователя 1202; если какая-либо из этих подписей не проверяется, то сделка 1201 отменяется 1213. Если эти подписи проверены, то получатель посылает 1214 сообщение подтверждения, содержащее исходную сделку 1201 (текст сделки 1202 и подпись отправляющего пользователя 1203) спонсору пользователя 1215, как описано 1204 в сертификате санкционирования отправителя 1202. Получатель в ответ должен получить от спонсора 1215 то же сообщение в качестве подтверждения 1216, но подписанное 1205 спонсором. Затем получатель 1217 проверяет подпись спонсора 1220 и сообщение подтверждения 1216 и принимает 1219 эту сделку 1201.

Для создания сложных комбинаций ограничений используется выражение фильтра, которое является булевым или логическим выражением, включающим один или несколько атрибутов, и которое может разрешать строить ограничения, использующие несколько атрибутов. Утверждения этих атрибутов связываются обычными булевыми союзами "и", "или" и "не". Например, спонсор может ограничить пользователя так, чтобы он мог осуществить только сделку с типом, равным "заказ на закупку", и значение менее $100,000. Утверждения могут привести к единственному значению атрибута (равенство, меньше чем, больше чем и т.д.), к нескольким значениям атрибута (подмножество, супермножество и т.д.) либо к присутствию или отсутствию атрибута в документе. Разумеется, будет приветствоваться, если какие-либо описанные ограничения, а также другие смогут действовать одновременно для одного и того же документа или сделки. Эти сделки рассмотрены и проиллюстрированы отдельно для ясности.

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

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

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

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

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

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

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

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

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

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

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

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

Во время использования доверенности пользователь может указать, что он подписывается вместо другого пользователя путем включения в данный документ или сделку атрибута "подпись вместо" подписи, то есть имени пользователя, вместо которого он подписывается. Должен иметься достоверный сертификат доверенности, уполномачивающий подписывающего действовать вместо пользователя, за которого он подписывается. Делегирование полезно также в связи с криптографическим модулем в персональном компьютере пользователя. Хеширование и подпись документа в идеальном случае должно быть единой операцией для предотвращения фальсификации хеширования путем подделки программного обеспечения. Однако обычная кредитная карточка имеет недостаточную вычислительную мощность для хеширования очень длинного документа. Одним из решений этой проблемы является предоставление кредитной карточке возможности делегировать эту функцию криптографическому модулю путем использования очень краткосрочного сертификата делегирования, достоверного только в течение нескольких минут. Этот сертификат подписывается кредитной карточкой пользователя и указывает, что пользователь этой кредитной карточки имеет разрешение на делегирование. См., например, Gasser M., A. Goldstein, C. Kaufman и B. Lampson, "Архитектура секретности цифровой распределенной системы", труды 12-ой конференции по национальной компьютерной секретности, 1989 год; Gasser M. и E. McDermott, "Архитектура практического делегирования в распределенных системах", труды симпозиума IEEE (Институт электрических и электронных сооружений) 1990 года по надежности и секретности.

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

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

Такая функциональность может внедряться как атрибут в сертификате пользователя. Если атрибут "ограничения распределения" имеет значение TRUE, то пользователь/издатель выдает разрешение на использование сертификата (который может быть сертификатом санкционирования или сертификатом открытого ключа) только для проверки подписи; распределение или последующее опубликование запрещается. Другие пути определения этих ограничений могут заключаться во включении этого атрибута в сертификат организации, опубликовав эти ограничения как часть политики, специфической для данной отрасли, или (в настоящем исполнении X.500) путем использования механизма списка контроля за доступом для ограничения доступа к сертификату. Хотя некоторая существующая общая официальная основа для ввода в действие этого ограничения может быть найдена в праве на интеллектуальную собственность, то есть, если сертификат заявлен как непубликуемая работа, то разрешение на доступ к ней выдается только указанному проверяющему, но все еще желательны более строгие официальные основы.

Требования к кредитной карточке
К кредитной карточке предъявляются некоторые дополнительные требования во время ее использования в коммерческих системах цифровой подписи.

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

Таким образом, как показано на фиг. 13, во время представления открытого ключа 1303 для сертификации кредитная карточка 1301 должна удостоверять, что кредитная карточка 1301 защищена от воровства или неумелого обращения и содержит изолирующую ключ конструкцию. Защита должна быть обеспечена "сертификатом устройства" 1302, указывающим, что кредитная карточка принадлежит специфическому производителю или производственной линии. Затем должна быть выполнена сертификация открытого ключа 1303 устройства 1301 производителем или CA, указанного производителем. По-видимому, один из подходов создания этого сертификата устройства должен состоять в создании пары ключей устройства во время формирования кредитной карточки так, чтобы соответствующий сертификат устройства 1302 тоже мог быть включен в кредитную карточку. Сертификат устройства 1302 удостоверяет свойства 1304 карточки, а карточка создает пару ключей 1303, 1309, которые должны быть использованы пользователем карточки и на владение которыми пользователь может получить разрешение через подходящий CA. Затем во время представления нового созданного открытого ключа 1303 для сертификации ключ секретной подписи устройства 1305 должен использоваться для выполнения партнерской подписи 1306 на данных запроса сертификата 1307, уже подписанного посредством заново созданного секретного ключа пользователя 1309.

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

Кредитные карточки кроме этого необходимы для защиты от несанкционированного использования персональных идентификационных номеров (PIN). Обычно кредитная карточка защищена от несанкционированного использования посредством PIN - эквивалентом пароля. Обычно PIN может изменяться только пользователем и должен иметь определенную длину, но обычно ничто не мешает пользователю установить для PIN тривиальное число, например все 1 или 121212. От продавцов кредитных карточек необходимо потребовать использовать маршруты изменения PIN, которые обеспечивали бы нетривиальными PIN без повторения разрядов или очевидных образцов. Если PIN станут относительно длинными (по крайней мере 6 разрядов) и нетривиальными, то уменьшится возможность использования карточки кем-то, кто нашел или украл ее. Поддержка требования 6-разрядного PIN может быть найдена в "X9.26: Опознавание подписи финансовых учреждений для оптовых финансовых сделок", ANSI, 1990, который хорошо известен в технике и приведен здесь в качестве ссылки и который представляет стандарт "один из миллионов", согласно которому механизм удлинения может считаться надежным, если, наряду с другими вещами, нарушитель имеет не более чем один шанс из миллиона найти правильный пароль и если система предпринимает действие уклонения для предотвращения повторного поиска. Более того, необходимо потребовать, чтобы кредитные карточки предпринимали "действия уклонения", например, отключая на некоторый период времени или даже стирая секретные ключи, если несанкционированным пользователем будет введено слишком много неправильных PIN.

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

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

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

Как показано на фиг. 14, в криптографической системе орган сертификации (CA) 1402 издает идентификационные сертификаты 1404 для пользователей (например, для пользователя 1438) криптографической системы. Орган сертификации 1402 имеет секретный ключ 1406 и открытый ключ 1408. Секретный ключ 1406 используется для цифровой подписи сертификатов 1404 посредством цифровой подписи органа сертификации 1410.

Орган сертификации 1402 может быть любым органом сертификации из иерархии органов сертификации таких, как, например, те, которые показаны на фиг. 3. Орган сертификации 1402 определяет информацию о пользователях системы и на основании этой информации издает сертификаты 1404 для этих пользователей. Сертификат 1404, изданный органом сертификации 1402 для пользователя 1438, содержит информацию пользователя 1410, включая открытый ключ пользователя 1412 и информацию политики органа сертификации 1414 относительно этого пользователя. Для проверки включенной в сертификаты 1404 информации другими пользователями этой системы эти другие пользователи должны иметь доступ к открытому ключу 1408 органа сертификации 1402.

Лучше, если сертификаты 1404, изданные органами сертификации, будут использоваться пользователями данной системы для их идентификации другими пользователями данной системы для облегчения осуществления сделок в пределах данной системы. Получатель (пользователь системы), принимающий сделку 1440 от пользователя другой системы 1438, где сделка сопровождается сертификатом 1404, изданным органом сертификации 1402, может положиться на информацию, содержащуюся в сертификате 1402, в основном благодаря тому, что орган сертификации 1402, который издал данный сертификат 1404, ручается за информацию в данном сертификате и принимает ответственность за определенную сделку, основанную на информации сертификата. Если данный сертификат 1404 содержит информацию о политике 1414 органа сертификации, то ответственность возлагается исключительно на орган сертификации 1402 при условии, что получатель имел правильную копию открытого ключа органа сертификации 1406 и если получатель следовал политике 1414, описанной в сертификате 1404.

Так, например, предположим, что после положительного результата проверки идентичности пользователя A (1438) орган сертификации 1402 издал сертификат 1404 для пользователя A (1438). Этот сертификат включает открытый ключ 1416 пользователя (1438), политику 1414 органа сертификации 1402 по отношению к пользователю A и цифровую подпись органа сертификации 1402. Предположим, например, что политика 1414 в сертификате требует, чтобы пользователь A участвовал в сделках только по рабочим дням с девяти утра до пяти вечера. Получатель 1424 сертификата 1404 и сделки 1440 от пользователя A 1438 может осуществить сделку и быть уверенным, что орган сертификации 1402 примет ответственность за сделку, если (a) получатель проверил политику 1414 относительно сделки, то есть, если получатель проверил, что сделка осуществляется в соответствии с допустимыми временными сроками, и (b) получатель имеет достоверные копии открытого ключа 1408 органа сертификации 1402. Другими словами, если получатель не проверил сделку по отношению к политике, то сделка недействительна. Далее, если даже получатель проверил сделку с пользователем A и эта сделка допускается политикой органа сертификации по отношению к пользователю A (в соответствии с тем, что указано в сертификате), то орган сертификации 1402 не отвечает за сделку, если получатель не имел достоверную копию открытого ключа органа сертификации 1408.

Кроме этого, криптографическая система включает различных спонсоров 1418, которые также издают сертификаты для пользователей. Эти изданные спонсорами сертификаты известны также как сертификаты санкционирования 1420. Сертификаты 1420 функционируют, между прочим, для определения правил и политик 4122 издающего их спонсора. Эти сертификаты санкционирования 1420 могут быть отделены и могут отличаться от идентификационных сертификатов 1404, издаваемых органами сертификации (несмотря на то, что идентификационные сертификаты могут содержать требования политики органов сертификации). Пользователь может иметь только один идентификационный сертификат 1404, издаваемый органом сертификации 1402. Однако пользователь может иметь целый ряд сертификатов санкционирования 1420, издаваемых одним или более спонсорами 1418.

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

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

Соответственно, корневой орган сертификации 1402 содержит свой открытый ключ как коммерческую тайну, а для получения открытого ключа корневого органа сертификации 1402 пользователь (потенциальный получатель) 1424, которому необходимо осуществить сделку в этой системе, должен получить правила органа сертификации 1426, издаваемые корневым органом сертификации. Получатель 1424 должен хешировать эти правила для формирования хешированных правил 1428, которые он затем должен подписать цифровым образом для получения подписанного экземпляра хешированных правил 1430. Этот подписанный цифровым образом экземпляр хешированных правил должен быть возвращен корневому органу сертификации 1402. Такие действия получателя 1424 воспринимаются как его согласие следовать правилам органа сертификации 1402, которые он подписал. Корневой орган сертификации 1402 может также потребовать, чтобы получатель 1424 тоже получил, подписал и возвратил правила от других органов сертификации в данной системе, а также правила от спонсоров в данной системе. Например, может оказаться необходимым, чтобы получатель 1424 получил правила спонсора 1432 от спонсора 1418 и возвратил подписанный экземпляр этих правил 1434 спонсору 1418.

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

Открытый ключ корневого органа сертификации 1424 может быть издан для получателя несколькими различными путями. В предпочтительных исполнениях получателю предоставляется устройство секретности 1436, например кредитная карточка. В одном из предпочтительных исполнений открытый ключ органа сертификации 1403 сразу же становится доступным в устройстве секретности так, что как только получатель 1424 получает это устройство, он будет обладать и открытым ключом корневого органа сертификации 1408. В другом предпочтительном исполнении открытый ключ органа сертификации 1408 находится в устройстве 1436 в нерабочем виде, а корневой орган сертификации 1402 устанавливает этот ключ в рабочее состояние 1408 в этом устройстве после приема и проверки подписанных правил 1430.

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

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

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

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

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

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

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

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

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

Далее приведены примеры этих полей:
(a) Плата за подпись секретного ключа = $0.50
(b) Плата за проверку открытого ключа = $0.50
(c) Адрес услуги аннулирования = rev-checkbtec.com
(d) Плата за услугу аннулирования = $0.50
(e) Плата за услугу подтверждения = $0.50
Все платы могут быть утверждены как единообразные платы или как платы за некоторую сумму, составляющую часть суммы базовой сделки. Например, плата может быть определена как "$0.50" или как "$0.50 за $1,000 основной суммы сделки".

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

Для оплаты сделки с подтверждением сертификат может содержать также плату за подтверждение сделки, например
Плата подтверждения сделки = ($0.50 на каждые $1000 суммы сделки)
В этом случае каждая подтвержденная сделка должна стоить получателю соответствующую сумму.

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

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

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

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

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

Фиг. 15 иллюстрирует проверку сделки пользователя, которая включает правила пользователя. Сделка пользователя 1502 включает текст сделки 1506, описывающий сделку, которая должна осуществляться получателем. Пользователь применяет к тексту сделки 1506 набор правил, полученных от пользователя 1504, которые пользователь желает проверить посредством какого-либо получателя сделки 1502. Затем пользователь ставит цифровую подпись на комбинацию текста сделки 1506 и правил 1504 для формирования сделки 1502, сформировав подпись пользователя 1504, которая прилагается к сделке.

Затем сделка 1506 передается совместно с каким-либо требуемым сертификатом спонсора и/или CA, например с сертификатом CA 1503 и сертификатом спонсора 1509, получателю, который затем должен проверить сделку. Для того, чтобы это выполнить, получатель проверяет 1512 подпись пользователя 1510, используя открытый ключ пользователя 1514 из сертификата CA 1508. Если подпись пользователя принимается, то проверка продолжается, в противном случае сделка отменяется 1514. Если проверка продолжается, то получатель проверяет 1516 подпись CA 1518, используя открытый ключ CA 1520. Если подпись CA принимается, то проверка продолжается 1522 и выполняется проверка правил во всех сертификатах, включая сертификаты спонсора 1509 и правила, полученные от пользователя. В противном случае сделка отменяется 1509. Если проверка продолжается, то получатель сверяет 1522 сделку с правилами сертификата CA 1508, сертификата спонсора 1509 (и с правилами любого другого, связанного с данной сделкой сертификата). Если одно из этих правил не удовлетворяется, то сделка отменяется 1514, в противном случае проверка сделки продолжается, и она сверяется с правилами, полученными от пользователя 1504. Если сделка удовлетворяет правилам, полученным от пользователя 1504, то она принимается 1526, в противном случае она отменяется 1514.

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

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

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

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

Формула изобретения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РИСУНКИ

Рисунок 1, Рисунок 2, Рисунок 3, Рисунок 4, Рисунок 5, Рисунок 6, Рисунок 7, Рисунок 8, Рисунок 9, Рисунок 10, Рисунок 11, Рисунок 12, Рисунок 13, Рисунок 14, Рисунок 15, Рисунок 16, Рисунок 17