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

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

Info

Publication number
RU2144269C1
RU2144269C1 RU97102357/09A RU97102357A RU2144269C1 RU 2144269 C1 RU2144269 C1 RU 2144269C1 RU 97102357/09 A RU97102357/09 A RU 97102357/09A RU 97102357 A RU97102357 A RU 97102357A RU 2144269 C1 RU2144269 C1 RU 2144269C1
Authority
RU
Russia
Prior art keywords
user
transaction
public key
digital
recipient
Prior art date
Application number
RU97102357/09A
Other languages
English (en)
Other versions
RU97102357A (ru
Inventor
В.Судиа Франк (US)
В.Судиа Франк
Сирицкий Брайан (IE)
Сирицкий Брайан
Original Assignee
Сертко, Ллс
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Сертко, Ллс filed Critical Сертко, Ллс
Publication of RU97102357A publication Critical patent/RU97102357A/ru
Application granted granted Critical
Publication of RU2144269C1 publication Critical patent/RU2144269C1/ru

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4015—Transaction verification using location information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Circuits Of Receivers In General (AREA)
  • Meter Arrangements (AREA)

Abstract

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

Description

Настоящее изобретение относится к цифровым подписям. Более конкретно, настоящее изобретение относится к использованию цифровых подписей и сертификатов для цифровых подписей в коммерческих криптографических системах для ввода в действие политики секретности и требований санкционирования так, чтобы уменьшить риск пользователей.
Криптография с открытым ключом является современной компьютерной технологией обеспечения секретности, которая может поддерживать создание системы электронных документов без использования бумаги при условии, что цифровой подписи пользователя на электронном документе, то есть электронному опознаванию пользователя и проверке электронного документа, может быть дан достаточный практический и юридический смысл. Такие системы электронных документов без использования бумаги, или "архитектуры документов", будут охватывать не только торговых партнеров, работающих в соответствии со стандартными двусторонними контрактами, но также и глобальные, многосторонние системы, в которых каждая сущность теоретически может взаимодействовать с любой другой сущностью на законном основании при условии соответствующего контроля за секретностью.
Эти системы будут иметь огромное коммерческое значение, так как во многих случаях может быть реализовано снижение цен на порядок от 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-check§btec.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, могут быть любые комбинации правил, известных системе, включая, но не ограничиваясь потребностью в сопутствующей подписи, временными ограничениями, ограничениями на сумму сделки, требованиями на подтверждение и подобным.
В некоторых средах пользователи могут создавать наборы правил или правила по умолчанию для них самих, для использования с конкретными типами пользователей или сделок. Эти наборы правил или правила по умолчанию могут автоматически прилагаться ко всем сделкам этого типа пользователей или сделок. Например, пользователь, который является менеджером банка, может определить (на основании опыта), что ко всем сделкам, осуществляемым новыми кассирами, на которые он ставит сопутствующие подписи, он должен применить более ограничительные правила, чем требуется банком. Затем он должен заложить эти правила в свою систему в качестве правил по умолчанию для сделок этого типа, на которые он ставит подписи или сопутствующие подписи.
Знакомые с данной областью техники оценят тот факт, что в настоящем изобретении обычно используются электронные устройства такие, как цифровые электронные компьютеры и подобное, а также что сертификаты, сделки, сообщения, подписи и подобное являются цифровыми электронными сигналами, создаваемыми электронными устройствами и передаваемыми между электронными устройствами.
Таким образом, представлен способ секретного использования цифровых подписей в коммерческой криптографической системе. Знакомые с данной областью техники оценят тот факт, что настоящее изобретение может использоваться не описанным в исполнениях образом, эти исполнения представлены только для иллюстративных целей, а не в качестве ограничений, а настоящее изобретение ограничено только приведенной ниже формулой изобретения.

Claims (17)

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, отличающийся тем, что упомянутое, по меньшей мере, одно из правил пользователя включает, по меньшей мере, один из разрешенных типов документов упомянутой сделки, разрешенных мест назначения, в котором могут формироваться сделки, разрешенные интервалы времени, в которых может быть сформирована сделка, период времени, в пределах которого достоверна упомянутая подпись, денежное ограничение для упомянутой сделки, а также требование сопутствующей подписи для упомянутой сделки.
RU97102357/09A 1994-07-19 1995-07-19 Способ секретного использования цифровых подписей в коммерческой криптографической системе RU2144269C1 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US27743894A 1994-07-19 1994-07-19
US08/277,438 1994-07-19
PCT/US1995/009076 WO1996002993A2 (en) 1994-07-19 1995-07-19 Method for securely using digital signatures in a commercial cryptographic system

Publications (2)

Publication Number Publication Date
RU97102357A RU97102357A (ru) 1999-03-10
RU2144269C1 true RU2144269C1 (ru) 2000-01-10

Family

ID=23060862

Family Applications (1)

Application Number Title Priority Date Filing Date
RU97102357/09A RU2144269C1 (ru) 1994-07-19 1995-07-19 Способ секретного использования цифровых подписей в коммерческой криптографической системе

Country Status (12)

Country Link
US (1) US5659616A (ru)
EP (1) EP0771499B1 (ru)
JP (1) JPH10504150A (ru)
AT (1) ATE305682T1 (ru)
AU (1) AU698454B2 (ru)
CA (1) CA2194475A1 (ru)
CZ (1) CZ11597A3 (ru)
DE (1) DE69534490T2 (ru)
NO (1) NO970084L (ru)
RU (1) RU2144269C1 (ru)
TR (1) TR199600585A2 (ru)
WO (1) WO1996002993A2 (ru)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003005638A1 (fr) * 2001-07-05 2003-01-16 Gurov, Georgy Borisovich Procede de protection integree du traitement reparti de donnees dans des systemes informatiques et systeme de mise en oeuvre correspondant
US7924913B2 (en) 2005-09-15 2011-04-12 Microsoft Corporation Non-realtime data transcoding of multimedia content
RU2448365C2 (ru) * 2006-04-10 2012-04-20 Траст Интегрейшн Сервисиз Б.В. Устройство и способ защищенной передачи данных
WO2012144930A1 (ru) * 2011-04-22 2012-10-26 Общество С Ограниченной Ответственностью "Нфи-Сервис" Система заказа товаров и услуг посредством устройства сотовой связи
US8868678B2 (en) 2004-05-03 2014-10-21 Microsoft Corporation Aspects of digital media content distribution
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan

Families Citing this family (384)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US7904722B2 (en) * 1994-07-19 2011-03-08 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
CA2138302C (en) * 1994-12-15 1999-05-25 Michael S. Fortinsky Provision of secure access to external resources from a distributed computing environment
CN1912885B (zh) * 1995-02-13 2010-12-22 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US7133846B1 (en) * 1995-02-13 2006-11-07 Intertrust Technologies Corp. Digital certificate support system, methods and techniques for secure electronic commerce transaction and rights management
US6658568B1 (en) * 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
AU728942B2 (en) * 1995-06-30 2001-01-18 Canon Kabushiki Kaisha A communication apparatus and a communication system
US6766450B2 (en) 1995-10-24 2004-07-20 Corestreet, Ltd. Certificate revocation system
US5666416A (en) * 1995-10-24 1997-09-09 Micali; Silvio Certificate revocation system
US6097811A (en) * 1995-11-02 2000-08-01 Micali; Silvio Tree-based certificate revocation system
US7716486B2 (en) 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US6487658B1 (en) 1995-10-02 2002-11-26 Corestreet Security, Ltd. Efficient certificate revocation
US8732457B2 (en) * 1995-10-02 2014-05-20 Assa Abloy Ab Scalable certificate validation and simplified PKI management
US7600129B2 (en) 1995-10-02 2009-10-06 Corestreet, Ltd. Controlling access using additional data
US7337315B2 (en) * 1995-10-02 2008-02-26 Corestreet, Ltd. Efficient certificate revocation
US7822989B2 (en) * 1995-10-02 2010-10-26 Corestreet, Ltd. Controlling access to an area
US7353396B2 (en) * 1995-10-02 2008-04-01 Corestreet, Ltd. Physical access control
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US5787175A (en) * 1995-10-23 1998-07-28 Novell, Inc. Method and apparatus for collaborative document control
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
US6301659B1 (en) 1995-11-02 2001-10-09 Silvio Micali Tree-based certificate revocation system
US5774552A (en) * 1995-12-13 1998-06-30 Ncr Corporation Method and apparatus for retrieving X.509 certificates from an X.500 directory
US5774870A (en) * 1995-12-14 1998-06-30 Netcentives, Inc. Fully integrated, on-line interactive frequency and award redemption program
JPH09223085A (ja) * 1996-02-19 1997-08-26 Fuji Xerox Co Ltd 電子文書承認装置及び電子文書承認システム
JPH09284272A (ja) * 1996-04-19 1997-10-31 Canon Inc エンティティの属性情報に基づく暗号化方式、署名方式、鍵共有方式、身元確認方式およびこれらの方式用装置
US6945457B1 (en) 1996-05-10 2005-09-20 Transaction Holdings Ltd. L.L.C. Automated transaction machine
US6901509B1 (en) 1996-05-14 2005-05-31 Tumbleweed Communications Corp. Apparatus and method for demonstrating and confirming the status of a digital certificates and other data
US5903651A (en) 1996-05-14 1999-05-11 Valicert, Inc. Apparatus and method for demonstrating and confirming the status of a digital certificates and other data
CN100339784C (zh) * 1996-09-04 2007-09-26 英特托拉斯技术公司 一种提供对在线服务的访问的方法
US6055637A (en) * 1996-09-27 2000-04-25 Electronic Data Systems Corporation System and method for accessing enterprise-wide resources by presenting to the resource a temporary credential
US6470448B1 (en) * 1996-10-30 2002-10-22 Fujitsu Limited Apparatus and method for proving transaction between users in network environment
US6212634B1 (en) 1996-11-15 2001-04-03 Open Market, Inc. Certifying authorization in computer networks
US6192131B1 (en) 1996-11-15 2001-02-20 Securities Industry Automation Corporation Enabling business transactions in computer networks
DE19702049C1 (de) * 1997-01-22 1998-05-14 Ibm Zertifizierung kryptografischer Schlüssel für Chipkarten
US5982898A (en) * 1997-03-07 1999-11-09 At&T Corp. Certification process
US6275941B1 (en) * 1997-03-28 2001-08-14 Hiatchi, Ltd. Security management method for network system
US6477513B1 (en) 1997-04-03 2002-11-05 Walker Digital, Llc Method and apparatus for executing cryptographically-enabled letters of credit
WO1998050875A2 (en) * 1997-05-09 1998-11-12 Gte Government Systems Corporation Biometric certificates
US7631188B2 (en) * 1997-05-16 2009-12-08 Tvworks, Llc Hierarchical open security information delegation and acquisition
JPH10327147A (ja) * 1997-05-21 1998-12-08 Hitachi Ltd 電子認証公証方法およびシステム
US6335972B1 (en) 1997-05-23 2002-01-01 International Business Machines Corporation Framework-based cryptographic key recovery system
US7290288B2 (en) * 1997-06-11 2007-10-30 Prism Technologies, L.L.C. Method and system for controlling access, by an authentication server, to protected computer resources provided via an internet protocol network
US6339824B1 (en) * 1997-06-30 2002-01-15 International Business Machines Corporation Method and apparatus for providing public key security control for a cryptographic processor
US6018724A (en) * 1997-06-30 2000-01-25 Sun Micorsystems, Inc. Method and apparatus for authenticating on-line transaction data
IL121550A (en) * 1997-08-14 2003-07-31 Diversinet Corp System and method for handling permits
US8024269B1 (en) 1997-08-27 2011-09-20 Datatreasury Corporation Remote image capture with centralized processing and storage
US6061734A (en) * 1997-09-24 2000-05-09 At&T Corp System and method for determining if a message identifier could be equivalent to one of a set of predetermined indentifiers
US6125349A (en) * 1997-10-01 2000-09-26 At&T Corp. Method and apparatus using digital credentials and other electronic certificates for electronic transactions
US6058484A (en) * 1997-10-09 2000-05-02 International Business Machines Corporation Systems, methods and computer program products for selection of date limited information
US6052784A (en) * 1997-10-14 2000-04-18 Intel Corporation Network discovery system and method
KR100241350B1 (ko) * 1997-10-27 2000-02-01 정선종 전자 거래에서 안전한 전자 공증문서 생성방법
US6208986B1 (en) 1997-12-15 2001-03-27 International Business Machines Corporation Web interface and method for accessing and displaying directory information
US6260039B1 (en) * 1997-12-15 2001-07-10 International Business Machines Corporation Web interface and method for accessing directory information
US6192362B1 (en) * 1997-12-15 2001-02-20 International Business Machines Corporation System and method for creating a search form for accessing directory information
US6195666B1 (en) 1997-12-15 2001-02-27 International Business Machines Corporation Web interface and method for displaying directory information
US6453416B1 (en) * 1997-12-19 2002-09-17 Koninklijke Philips Electronics N.V. Secure proxy signing device and method of use
US6170058B1 (en) 1997-12-23 2001-01-02 Arcot Systems, Inc. Method and apparatus for cryptographically camouflaged cryptographic key storage, certification and use
US7328350B2 (en) 2001-03-29 2008-02-05 Arcot Systems, Inc. Method and apparatus for secure cryptographic key generation, certification and use
US7454782B2 (en) 1997-12-23 2008-11-18 Arcot Systems, Inc. Method and system for camouflaging access-controlled data
US6601172B1 (en) * 1997-12-31 2003-07-29 Philips Electronics North America Corp. Transmitting revisions with digital signatures
AU6236498A (en) * 1998-01-16 1999-08-02 Institute Of Systems Science A method of data storage and apparatus therefor
CA2228687A1 (en) * 1998-02-04 1999-08-04 Brett Howard Secured virtual private networks
US6233577B1 (en) * 1998-02-17 2001-05-15 Phone.Com, Inc. Centralized certificate management system for two-way interactive communication devices in data networks
FI980591A (fi) * 1998-03-17 2000-01-03 Sonera Oy Menetelmä ja järjestelmä sopimusosapuolen luotettavaksi ja turvallisek si tunnistamiseksi
EP1082836B1 (en) * 1998-03-18 2005-11-23 Kent Ridge Digital Labs A method of exchanging digital data
US20010044901A1 (en) * 1998-03-24 2001-11-22 Symantec Corporation Bubble-protected system for automatic decryption of file data on a per-use basis and automatic re-encryption
US6314517B1 (en) * 1998-04-02 2001-11-06 Entrust Technologies Limited Method and system for notarizing digital signature data in a system employing cryptography based security
US6848050B1 (en) 1998-04-16 2005-01-25 Citicorp Development Center, Inc. System and method for alternative encryption techniques
US7039805B1 (en) * 1998-05-20 2006-05-02 Messing John H Electronic signature method
CA2357007C (en) 1998-05-21 2002-04-02 Equifax Inc. System and method for authentication of network users with preprocessing
ES2619367T3 (es) 1998-05-21 2017-06-26 Equifax Inc. Sistema y método para la autentificación de usuarios de red
WO1999060482A1 (en) * 1998-05-21 1999-11-25 Equifax Inc. System and method for authentication of network users and issuing a digital certificate
US6718470B1 (en) * 1998-06-05 2004-04-06 Entrust Technologies Limited System and method for granting security privilege in a communication system
US6286015B1 (en) * 1998-09-08 2001-09-04 Oracle Corporation Opaque types
RU2153191C2 (ru) 1998-09-29 2000-07-20 Закрытое акционерное общество "Алкорсофт" Способ изготовления вслепую цифровой rsa-подписи и устройство для его реализации (варианты)
US6119108A (en) * 1998-10-01 2000-09-12 Aires Systems Corporation Secure electronic publishing system
US6370250B1 (en) 1998-10-29 2002-04-09 International Business Machines Corporation Method of authentication and storage of private keys in a public key cryptography system (PKCS)
US6820202B1 (en) * 1998-11-09 2004-11-16 First Data Corporation Account authority digital signature (AADS) system
US7047416B2 (en) * 1998-11-09 2006-05-16 First Data Corporation Account-based digital signature (ABDS) system
US7080409B2 (en) 1998-11-10 2006-07-18 Dan Eigeles Method for deployment of a workable public key infrastructure
RU2157001C2 (ru) 1998-11-25 2000-09-27 Закрытое акционерное общество "Алкорсофт" Способ проведения платежей (варианты)
US6173269B1 (en) 1998-12-16 2001-01-09 Zowi.Com, Inc Method and apparatus for executing electronic commercial transactions with minors
US6530022B1 (en) * 1998-12-17 2003-03-04 International Business Machines Corporation Permission-based scanning of a web site
US6330588B1 (en) * 1998-12-21 2001-12-11 Philips Electronics North America Corporation Verification of software agents and agent activities
US7209889B1 (en) * 1998-12-24 2007-04-24 Henry Whitfield Secure system for the issuance, acquisition, and redemption of certificates in a transaction network
US6587945B1 (en) * 1998-12-28 2003-07-01 Koninklijke Philips Electronics N.V. Transmitting reviews with digital signatures
DE19961151A1 (de) 1999-01-29 2000-08-03 Ibm Verfahren zum Erstellen und Lesen eines neuen Zertifikatstyps zur Zertifizierung von Schlüsseln
WO2000048108A1 (en) * 1999-02-12 2000-08-17 Mack Hicks System and method for providing certification-related and other services
AU2878700A (en) * 1999-02-12 2000-08-29 Allen Freudenstein System and method for providing certification-related and other services
US6601171B1 (en) * 1999-02-18 2003-07-29 Novell, Inc. Deputization in a distributed computing system
CN1354935A (zh) 1999-02-26 2002-06-19 奥廷提戴特控股有限公司 包括安全文件标记的数字文件管理和成像系统及方法
US20020026321A1 (en) * 1999-02-26 2002-02-28 Sadeg M. Faris Internet-based system and method for fairly and securely enabling timed-constrained competition using globally time-sychronized client subsystems and information servers having microsecond client-event resolution
EP1762958A1 (en) * 1999-03-08 2007-03-14 Spyrus, Inc. Method and system for enforcing access to a computing resource using a licensing certificate
US6256737B1 (en) 1999-03-09 2001-07-03 Bionetrix Systems Corporation System, method and computer program product for allowing access to enterprise resources using biometric devices
US7305562B1 (en) 1999-03-09 2007-12-04 Citibank, N.A. System, method and computer program product for an authentication management infrastructure
EP1037427A1 (de) * 1999-03-17 2000-09-20 Ascom Systec AG Multi Sicherheitsprotokollfähigkeit in Messaging Systemen
CA2266141A1 (en) * 1999-03-18 2000-09-18 Rdm Corporation Method for controlling the application of digital signatures to electronic documents based on electronically represented business signing rules
US6463534B1 (en) * 1999-03-26 2002-10-08 Motorola, Inc. Secure wireless electronic-commerce system with wireless network domain
US6775782B1 (en) * 1999-03-31 2004-08-10 International Business Machines Corporation System and method for suspending and resuming digital certificates in a certificate-based user authentication application system
US6671805B1 (en) * 1999-06-17 2003-12-30 Ilumin Corporation System and method for document-driven processing of digitally-signed electronic documents
AU4078700A (en) * 1999-04-13 2000-11-14 Ilumin Corporation System and method for document-driven processing of digitally-signed electronic documents
US7711152B1 (en) * 1999-04-30 2010-05-04 Davida George I System and method for authenticated and privacy preserving biometric identification systems
US8325994B2 (en) 1999-04-30 2012-12-04 Davida George I System and method for authenticated and privacy preserving biometric identification systems
EP1056014A1 (en) * 1999-05-28 2000-11-29 Hewlett-Packard Company System for providing a trustworthy user interface
US20020023057A1 (en) * 1999-06-01 2002-02-21 Goodwin Johnathan David Web-enabled value bearing item printing
US7149726B1 (en) 1999-06-01 2006-12-12 Stamps.Com Online value bearing item printing
AU3712300A (en) 1999-06-11 2001-01-02 Liberate Technologies Hierarchical open security information delegation and acquisition
NZ516669A (en) * 1999-06-18 2004-07-30 Echarge Corp Method for ordering goods, services and content over an internetwork using a virtual payment account
EP1065861B1 (en) * 1999-06-28 2008-04-09 Alcatel Lucent Method to provide authorization, a certifying authority, a terminal, a service provider and a certificate realizing such a method
US6816965B1 (en) 1999-07-16 2004-11-09 Spyrus, Inc. Method and system for a policy enforcing module
US6484259B1 (en) * 1999-07-23 2002-11-19 Microsoft Corporation Methods and arrangements for mapping widely disparate portable tokens to a static machine concentric cryptographic environment
WO2001011843A1 (en) * 1999-08-06 2001-02-15 Sudia Frank W Blocked tree authorization and status systems
EP1076279A1 (en) * 1999-08-13 2001-02-14 Hewlett-Packard Company Computer platforms and their methods of operation
EP1077436A3 (en) * 1999-08-19 2005-06-22 Citicorp Development Center, Inc. System and method for performing an on-line transaction using a single-use payment instrument
US20020029200A1 (en) 1999-09-10 2002-03-07 Charles Dulin System and method for providing certificate validation and other services
US7424616B1 (en) 1999-09-10 2008-09-09 Identrus System and method for facilitating access by sellers to certificate-related and other services
EP1218842A1 (en) * 1999-09-20 2002-07-03 Ethentica, Inc. Trust arbitrage in cryptographic authentication
ATE415670T1 (de) 1999-09-24 2008-12-15 Identrust Inc System und methode zur bereitstellung von zahlungsdienstleistungen im e-commerce
AU1432901A (en) 1999-10-18 2001-04-30 Stamps.Com Cryptographic module for secure processing of value-bearing items
US7240037B1 (en) 1999-10-18 2007-07-03 Stamps.Com Method and apparatus for digitally signing an advertisement area next to a value-bearing item
US6868406B1 (en) * 1999-10-18 2005-03-15 Stamps.Com Auditing method and system for an on-line value-bearing item printing system
US7236956B1 (en) 1999-10-18 2007-06-26 Stamps.Com Role assignments in a cryptographic module for secure processing of value-bearing items
US7567940B1 (en) 1999-10-18 2009-07-28 Stamps.Com Method and apparatus for on-line value-bearing item system
US7233929B1 (en) 1999-10-18 2007-06-19 Stamps.Com Postal system intranet and commerce processing for on-line value bearing system
US7216110B1 (en) 1999-10-18 2007-05-08 Stamps.Com Cryptographic module for secure processing of value-bearing items
EP1094424A3 (en) * 1999-10-22 2004-06-16 Hitachi, Ltd. Digital signing method
WO2001031841A1 (en) 1999-10-27 2001-05-03 Visa International Service Association Method and apparatus for leveraging an existing cryptographic infrastructure
US7321864B1 (en) * 1999-11-04 2008-01-22 Jpmorgan Chase Bank, N.A. System and method for providing funding approval associated with a project based on a document collection
US7143144B2 (en) * 1999-11-30 2006-11-28 Ricoh Company, Ltd. System, method and computer readable medium for certifying release of electronic information on an internet
US6505193B1 (en) * 1999-12-01 2003-01-07 Iridian Technologies, Inc. System and method of fast biometric database searching using digital certificates
US6671804B1 (en) 1999-12-01 2003-12-30 Bbnt Solutions Llc Method and apparatus for supporting authorities in a public key infrastructure
GB2357228B (en) 1999-12-08 2003-07-09 Hewlett Packard Co Method and apparatus for discovering a trust chain imparting a required attribute to a subject
GB2357225B (en) * 1999-12-08 2003-07-16 Hewlett Packard Co Electronic certificate
GB2357229B (en) 1999-12-08 2004-03-17 Hewlett Packard Co Security protocol
GB2357226B (en) 1999-12-08 2003-07-16 Hewlett Packard Co Security protocol
GB2357227B (en) 1999-12-08 2003-12-17 Hewlett Packard Co Security protocol
AU782518B2 (en) * 2000-01-07 2005-08-04 International Business Machines Corporation A method for inter-enterprise role-based authorization
GB2359156B (en) * 2000-02-14 2004-10-13 Reuters Ltd Methods of computer programs for and apparatus for providing and accessing digital content
WO2001061652A2 (en) * 2000-02-16 2001-08-23 Stamps.Com Secure on-line ticketing
US20060155788A1 (en) * 2000-03-09 2006-07-13 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060143252A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US6879988B2 (en) 2000-03-09 2005-04-12 Pkware System and method for manipulating and managing computer archive files
US8230482B2 (en) * 2000-03-09 2012-07-24 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060143250A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060155731A1 (en) * 2000-03-09 2006-07-13 Pkware, Inc. System and method for manipulating and managing computer archive files
US20050015608A1 (en) * 2003-07-16 2005-01-20 Pkware, Inc. Method for strongly encrypting .ZIP files
US8959582B2 (en) 2000-03-09 2015-02-17 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060143714A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US7844579B2 (en) 2000-03-09 2010-11-30 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060173848A1 (en) * 2000-03-09 2006-08-03 Pkware, Inc. System and method for manipulating and managing computer archive files
US7441263B1 (en) 2000-03-23 2008-10-21 Citibank, N.A. System, method and computer program product for providing unified authentication services for online applications
US6871276B1 (en) * 2000-04-05 2005-03-22 Microsoft Corporation Controlled-content recoverable blinded certificates
US7086085B1 (en) 2000-04-11 2006-08-01 Bruce E Brown Variable trust levels for authentication
US6965881B1 (en) * 2000-04-24 2005-11-15 Intel Corporation Digital credential usage reporting
US7047404B1 (en) * 2000-05-16 2006-05-16 Surety Llc Method and apparatus for self-authenticating digital records
EP1164745A3 (en) * 2000-06-09 2005-03-30 Northrop Grumman Corporation System and method for usage of a role certificate in encryption, and as a seal, digital stamp, and a signature
US7028180B1 (en) * 2000-06-09 2006-04-11 Northrop Grumman Corporation System and method for usage of a role certificate in encryption and as a seal, digital stamp, and signature
AU2000252248A1 (en) * 2000-06-14 2001-12-24 Smarttrust Systems Oy Interpretation of the identity of an entity
US7395246B2 (en) * 2000-06-30 2008-07-01 Intel Corporation Delegating digital credentials
US20040260657A1 (en) * 2000-07-18 2004-12-23 John Cockerham System and method for user-controlled on-line transactions
US6976164B1 (en) * 2000-07-19 2005-12-13 International Business Machines Corporation Technique for handling subsequent user identification and password requests with identity change within a certificate-based host session
US6934848B1 (en) * 2000-07-19 2005-08-23 International Business Machines Corporation Technique for handling subsequent user identification and password requests within a certificate-based host session
US6978369B2 (en) * 2000-08-04 2005-12-20 First Data Corporation Person-centric account-based digital signature system
US6983368B2 (en) * 2000-08-04 2006-01-03 First Data Corporation Linking public key of device to information during manufacture
US7082533B2 (en) * 2000-08-04 2006-07-25 First Data Corporation Gauging risk in electronic communications regarding accounts in ABDS system
US7558965B2 (en) * 2000-08-04 2009-07-07 First Data Corporation Entity authentication in electronic communications by providing verification status of device
US7552333B2 (en) * 2000-08-04 2009-06-23 First Data Corporation Trusted authentication digital signature (tads) system
US7010691B2 (en) * 2000-08-04 2006-03-07 First Data Corporation ABDS system utilizing security information in authenticating entity access
JP2004506361A (ja) * 2000-08-04 2004-02-26 ファースト　データ　コーポレイション デバイスの検証ステータスを提供することによる電子通信におけるエンティティ認証
US6789189B2 (en) * 2000-08-04 2004-09-07 First Data Corporation Managing account database in ABDS system
US7096354B2 (en) * 2000-08-04 2006-08-22 First Data Corporation Central key authority database in an ABDS system
WO2002015464A1 (en) * 2000-08-14 2002-02-21 Gien Peter H System and method for secure smartcard issuance
GB2366469B (en) * 2000-08-25 2005-02-23 Hewlett Packard Co Improvements relating to document transmission techniques II
US7275155B1 (en) * 2000-09-01 2007-09-25 Northrop Grumman Corporation Chain of trust processing
SE0003171L (sv) * 2000-09-07 2002-03-08 Bankgirocentralen Bgc Ab Nätverksrelaterat användaridentifierande system
WO2002032064A1 (en) * 2000-09-08 2002-04-18 Tallent Guy S System and method for providing authorization and other services
US20020144122A1 (en) * 2001-04-03 2002-10-03 S.W.I.F.T. System and method for facilitating trusted transactions between businesses
WO2002021408A1 (en) * 2000-09-08 2002-03-14 Tallent Guy S System and method for transparently providing certificate validation and other services within an electronic transaction
US20020038290A1 (en) * 2000-09-22 2002-03-28 Cochran Jeffrey M. Digital notary system and method
US7457950B1 (en) 2000-09-29 2008-11-25 Intel Corporation Managed authentication service
US7178030B2 (en) * 2000-10-25 2007-02-13 Tecsec, Inc. Electronically signing a document
US8285991B2 (en) * 2000-10-25 2012-10-09 Tecsec Inc. Electronically signing a document
US8275636B2 (en) 2000-10-26 2012-09-25 American International Group, Inc. Identity insurance transaction method
US7213249B2 (en) * 2000-12-22 2007-05-01 Oracle International Corporation Blocking cache flush requests until completing current pending requests in a local server and remote server
US7363339B2 (en) * 2000-12-22 2008-04-22 Oracle International Corporation Determining group membership
US7937655B2 (en) 2000-12-22 2011-05-03 Oracle International Corporation Workflows with associated processes
US7711818B2 (en) * 2000-12-22 2010-05-04 Oracle International Corporation Support for multiple data stores
US7475151B2 (en) * 2000-12-22 2009-01-06 Oracle International Corporation Policies for modifying group membership
US7415607B2 (en) * 2000-12-22 2008-08-19 Oracle International Corporation Obtaining and maintaining real time certificate status
US8015600B2 (en) * 2000-12-22 2011-09-06 Oracle International Corporation Employing electronic certificate workflows
US7802174B2 (en) 2000-12-22 2010-09-21 Oracle International Corporation Domain based workflows
US7581011B2 (en) * 2000-12-22 2009-08-25 Oracle International Corporation Template based workflow definition
US7085834B2 (en) * 2000-12-22 2006-08-01 Oracle International Corporation Determining a user's groups
US7380008B2 (en) 2000-12-22 2008-05-27 Oracle International Corporation Proxy system
US7349912B2 (en) 2000-12-22 2008-03-25 Oracle International Corporation Runtime modification of entries in an identity system
JP2002207427A (ja) * 2001-01-10 2002-07-26 Sony Corp 公開鍵証明書発行システム、公開鍵証明書発行方法、および情報処理装置、情報記録媒体、並びにプログラム記憶媒体
JP2002207426A (ja) * 2001-01-10 2002-07-26 Sony Corp 公開鍵証明書発行システム、公開鍵証明書発行方法、および電子認証装置、並びにプログラム記憶媒体
US7039807B2 (en) * 2001-01-23 2006-05-02 Computer Associates Think, Inc. Method and system for obtaining digital signatures
FR2820578A1 (fr) * 2001-02-06 2002-08-09 Picture Certification Com E Dispositif d'obliteration et de signature manuelle de document electronique, securise par carte a puce, cle publique et tiers de sequestre
US20020152086A1 (en) * 2001-02-15 2002-10-17 Smith Ned M. Method and apparatus for controlling a lifecycle of an electronic contract
GB2372342A (en) * 2001-02-17 2002-08-21 Hewlett Packard Co Determination of a credential attribute value of a digital certificate
GB2372343A (en) * 2001-02-17 2002-08-21 Hewlett Packard Co Determination of a trust value of a digital certificate
US7139911B2 (en) * 2001-02-28 2006-11-21 International Business Machines Corporation Password exposure elimination for digital signature coupling with a host identity
US7181017B1 (en) 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US20030172027A1 (en) * 2001-03-23 2003-09-11 Scott Walter G. Method for conducting a credit transaction using biometric information
US20020144120A1 (en) * 2001-03-28 2002-10-03 Ramanathan Ramanathan Method and apparatus for constructing digital certificates
US20020144110A1 (en) * 2001-03-28 2002-10-03 Ramanathan Ramanathan Method and apparatus for constructing digital certificates
US20020162004A1 (en) * 2001-04-25 2002-10-31 Gunter Carl A. Method and system for managing access to services
US20020162002A1 (en) * 2001-04-25 2002-10-31 Gunter Carl A. Method and system for controlling access to services
DE10120290A1 (de) * 2001-04-25 2002-11-07 Siemens Ag Verfahren zum Sichern einer Datenübertragung zwischen mehreren Datenübertragungseinheiten sowie zugehörige Komponenten
US6885388B2 (en) * 2001-04-25 2005-04-26 Probaris Technologies Inc. Method for automatically generating list of meeting participants and delegation permission
US20030236977A1 (en) * 2001-04-25 2003-12-25 Levas Robert George Method and system for providing secure access to applications
NO313810B1 (no) * 2001-04-25 2002-12-02 Ericsson Telefon Ab L M Kryptografisk signering i smÕ enheter
US20020162019A1 (en) * 2001-04-25 2002-10-31 Berry Michael C. Method and system for managing access to services
US20020161999A1 (en) * 2001-04-25 2002-10-31 Gunter Carl A. Method and system for expediting delegation of permission
US20030172299A1 (en) * 2002-03-05 2003-09-11 Gunter Carl A. Method and system for maintaining secure access to web server services using permissions
US20050210263A1 (en) * 2001-04-25 2005-09-22 Levas Robert G Electronic form routing and data capture system and method
US20030172297A1 (en) * 2002-03-05 2003-09-11 Gunter Carl A. Method and system for maintaining secure access to web server services using public keys
US7167985B2 (en) * 2001-04-30 2007-01-23 Identrus, Llc System and method for providing trusted browser verification
US20020188511A1 (en) * 2001-05-14 2002-12-12 Trilegiant Loyalty Solutions Interactive online point redemption system
US6785686B2 (en) * 2001-05-29 2004-08-31 Sun Microsystems, Inc. Method and system for creating and utilizing managed roles in a directory system
US7096362B2 (en) * 2001-06-01 2006-08-22 International Business Machines Corporation Internet authentication with multiple independent certificate authorities
GB2376313A (en) * 2001-06-04 2002-12-11 Hewlett Packard Co Indicating to a user if they are connected to a trusted computer platform
US7254706B2 (en) * 2001-06-29 2007-08-07 Hewlett-Packard Development Company, L.P. System and method for downloading of files to a secure terminal
US7509498B2 (en) * 2001-06-29 2009-03-24 Intel Corporation Digital signature validation
WO2003013167A1 (de) * 2001-07-20 2003-02-13 Brainshield Technologies, Inc. Vorrichtung zur digitalen signatur eines elektronischen dokuments
US20030018890A1 (en) * 2001-07-23 2003-01-23 Hale Douglas Lavell Method of local due diligence for accepting certificates
US20040128508A1 (en) * 2001-08-06 2004-07-01 Wheeler Lynn Henry Method and apparatus for access authentication entity
US20030156740A1 (en) * 2001-10-31 2003-08-21 Cross Match Technologies, Inc. Personal identification device using bi-directional authorization for access control
JP3935879B2 (ja) * 2001-11-06 2007-06-27 インターナショナル・ビジネス・マシーンズ・コーポレーション データ供給のためのシステム
US7447904B1 (en) 2001-11-14 2008-11-04 Compass Technology Management, Inc. Systems and methods for obtaining digital signatures on a single authoritative copy of an original electronic record
US7146500B2 (en) * 2001-11-14 2006-12-05 Compass Technology Management, Inc. System for obtaining signatures on a single authoritative copy of an electronic record
KR100439171B1 (ko) * 2001-11-21 2004-07-05 한국전자통신연구원 접근제어 처리 기법을 이용한 클라이언트와 시스템간의신뢰경로 보장 방법
US20030105876A1 (en) * 2001-11-30 2003-06-05 Angelo Michael F. Automatic generation of verifiable customer certificates
US7225256B2 (en) 2001-11-30 2007-05-29 Oracle International Corporation Impersonation in an access system
US7543139B2 (en) * 2001-12-21 2009-06-02 International Business Machines Corporation Revocation of anonymous certificates, credentials, and access rights
US7165718B2 (en) * 2002-01-16 2007-01-23 Pathway Enterprises, Inc. Identification of an individual using a multiple purpose card
US7231657B2 (en) * 2002-02-14 2007-06-12 American Management Systems, Inc. User authentication system and methods thereof
US7228417B2 (en) * 2002-02-26 2007-06-05 America Online, Inc. Simple secure login with multiple-authentication providers
US20030163685A1 (en) * 2002-02-28 2003-08-28 Nokia Corporation Method and system to allow performance of permitted activity with respect to a device
GB2385955A (en) * 2002-02-28 2003-09-03 Ibm Key certification using certificate chains
US20030177094A1 (en) * 2002-03-15 2003-09-18 Needham Bradford H. Authenticatable positioning data
US8086867B2 (en) * 2002-03-26 2011-12-27 Northrop Grumman Systems Corporation Secure identity and privilege system
EP1504393A4 (en) 2002-04-23 2008-03-19 Clearing House Service Company PAYMENT IDENTIFICATION CODE AND PAYMENT SYSTEM THEREWITH
US7900048B2 (en) * 2002-05-07 2011-03-01 Sony Ericsson Mobile Communications Ab Method for loading an application in a device, device and smart card therefor
US7216163B2 (en) * 2002-05-15 2007-05-08 Oracle International Corporation Method and apparatus for provisioning tasks using a provisioning bridge server
US7840658B2 (en) 2002-05-15 2010-11-23 Oracle International Corporation Employing job code attributes in provisioning
US7167871B2 (en) * 2002-05-17 2007-01-23 Xerox Corporation Systems and methods for authoritativeness grading, estimation and sorting of documents in large heterogeneous document collections
US20030221109A1 (en) * 2002-05-24 2003-11-27 Pure Edge Solutions, Inc. Method of and apparatus for digital signatures
JP4102105B2 (ja) * 2002-05-24 2008-06-18 株式会社日立製作所 電子ペンを利用した書類記入システム
KR100477645B1 (ko) * 2002-05-25 2005-03-23 삼성전자주식회사 일련번호 발생 방법 및 그 장치
US20030233542A1 (en) * 2002-06-18 2003-12-18 Benaloh Josh D. Selectively disclosable digital certificates
US7305547B2 (en) * 2002-06-28 2007-12-04 Hewlett-Packard Development Company, L.P. Method for upgrading a host/agent security system that includes digital certificate management and an upgradable backward compatible host/agent security system digital certificate infrastructure
US7590861B2 (en) 2002-08-06 2009-09-15 Privaris, Inc. Methods for secure enrollment and backup of personal identity credentials into electronic devices
US20040054898A1 (en) * 2002-08-28 2004-03-18 International Business Machines Corporation Authenticating and communicating verifiable authorization between disparate network domains
US7177847B2 (en) * 2002-10-15 2007-02-13 Microsoft Corporation Authorization token accompanying request and including constraint tied to request
US7571472B2 (en) * 2002-12-30 2009-08-04 American Express Travel Related Services Company, Inc. Methods and apparatus for credential validation
US9818136B1 (en) 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US7543140B2 (en) * 2003-02-26 2009-06-02 Microsoft Corporation Revocation of a certificate and exclusion of other principals in a digital rights management (DRM) system based on a revocation list from a delegated revocation authority
US20040205345A1 (en) * 2003-04-11 2004-10-14 Ripley Michael S. System for identification and revocation of audiovisual titles and replicators
US20040221158A1 (en) * 2003-05-02 2004-11-04 Secure Data In Motion, Inc. Digital signature and verification system for conversational messages
EP1627488A4 (en) * 2003-05-13 2008-06-04 Corestreet Ltd EFFICIENT AND SECURE DATA ACTUALITY SYSTEMS
US20040243428A1 (en) * 2003-05-29 2004-12-02 Black Steven C. Automated compliance for human resource management
US20090182602A1 (en) * 2003-05-29 2009-07-16 Hotlinkhr, Inc. Human resources method for employee demographics reporting compliance
US20090112670A1 (en) * 2003-05-29 2009-04-30 Black Steven C Human resources method for employee termination procedures
AU2004251364B9 (en) * 2003-06-24 2010-09-23 Assa Abloy Ab Access control
US7290278B2 (en) 2003-10-02 2007-10-30 Aol Llc, A Delaware Limited Liability Company Identity based service system
US7882132B2 (en) 2003-10-09 2011-02-01 Oracle International Corporation Support for RDBMS in LDAP system
US7340447B2 (en) 2003-10-09 2008-03-04 Oracle International Corporation Partitioning data access requests
US7904487B2 (en) 2003-10-09 2011-03-08 Oracle International Corporation Translating data access requests
CN100383694C (zh) 2003-10-17 2008-04-23 国际商业机器公司 为可被具有安全模块的用户设备执行的事务维护私密
US7620630B2 (en) * 2003-11-12 2009-11-17 Oliver Lloyd Pty Ltd Directory system
WO2005052752A2 (en) * 2003-11-19 2005-06-09 Corestreet, Ltd. Distributed delegated path discovery and validation
US7533407B2 (en) 2003-12-16 2009-05-12 Microsoft Corporation System and methods for providing network quarantine
US20050138388A1 (en) * 2003-12-19 2005-06-23 Robert Paganetti System and method for managing cross-certificates copyright notice
US7698557B2 (en) * 2003-12-22 2010-04-13 Guardtime As System and method for generating a digital certificate
US20050144144A1 (en) * 2003-12-30 2005-06-30 Nokia, Inc. System and method for authenticating a terminal based upon at least one characteristic of the terminal located at a position within an organization
US20050149724A1 (en) * 2003-12-30 2005-07-07 Nokia Inc. System and method for authenticating a terminal based upon a position of the terminal within an organization
WO2005070116A2 (en) 2004-01-09 2005-08-04 Corestreet, Ltd. Communication-efficient real time credentials for ocsp and distributed ocsp
US8725607B2 (en) 2004-01-30 2014-05-13 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
US7236957B2 (en) * 2004-02-10 2007-06-26 Bottomline Technologies (De) Inc. Method for remotely authorizing a payment transaction file over an open network
US20050223233A1 (en) * 2004-04-01 2005-10-06 Fujitsu Limited Authentication method and system
US8296573B2 (en) * 2004-04-06 2012-10-23 International Business Machines Corporation System and method for remote self-enrollment in biometric databases
WO2005101270A1 (en) * 2004-04-12 2005-10-27 Intercomputer Corporation Secure messaging system
US20050267954A1 (en) * 2004-04-27 2005-12-01 Microsoft Corporation System and methods for providing network quarantine
US20060075247A1 (en) * 2004-09-27 2006-04-06 Sharp Laboratories Of America, Inc. System and method for establishing an authenticated timestamp and content certification
US7630974B2 (en) 2004-09-28 2009-12-08 Oracle International Corporation Multi-language support for enterprise identity and access management
US20060085850A1 (en) * 2004-10-14 2006-04-20 Microsoft Corporation System and methods for providing network quarantine using IPsec
JP4999300B2 (ja) * 2004-10-22 2012-08-15 株式会社リコー スキャン装置、スキャンサービス利用装置、認証サービス提供装置、スキャンサービスプログラム、スキャンサービス利用プログラム、認証サービスプログラム、記録媒体、スキャン方法、スキャンサービス利用方法及び認証サービス提供方法
US7205882B2 (en) * 2004-11-10 2007-04-17 Corestreet, Ltd. Actuating a security system using a wireless device
US20060153367A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Digital signature system based on shared knowledge
US7593527B2 (en) * 2005-01-07 2009-09-22 First Data Corporation Providing digital signature and public key based on shared knowledge
US20060153369A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Providing cryptographic key based on user input data
US7693277B2 (en) * 2005-01-07 2010-04-06 First Data Corporation Generating digital signatures using ephemeral cryptographic key
US20060153364A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Asymmetric key cryptosystem based on shared knowledge
US7869593B2 (en) * 2005-01-07 2011-01-11 First Data Corporation Software for providing based on shared knowledge public keys having same private key
US20060156013A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Digital signature software using ephemeral private key and system
US7936869B2 (en) * 2005-01-07 2011-05-03 First Data Corporation Verifying digital signature based on shared knowledge
US20060153370A1 (en) * 2005-01-07 2006-07-13 Beeson Curtis L Generating public-private key pair based on user input data
US7490239B2 (en) * 2005-01-07 2009-02-10 First Data Corporation Facilitating digital signature based on ephemeral private key
EP1684204A1 (en) * 2005-01-24 2006-07-26 THOMSON Licensing Presence-based access control
EP1684153A1 (en) * 2005-01-24 2006-07-26 Thomson Licensing Presence-based access control
US8230224B2 (en) 2005-03-08 2012-07-24 International Business Machines Corporation Transmitting security data in multipart communications over a network
US7849101B2 (en) * 2005-05-12 2010-12-07 Microsoft Corporation Method and system for enabling an electronic signature approval process
JP4121134B2 (ja) * 2005-05-31 2008-07-23 インターナショナル・ビジネス・マシーンズ・コーポレーション プログラム、分類方法およびシステム
WO2006128273A1 (en) 2005-06-01 2006-12-07 Research In Motion Limited System and method for determining a security encoding to be applied to outgoing messages
US20060291700A1 (en) * 2005-06-08 2006-12-28 Ogram Mark E Internet signature verification system
US20060294366A1 (en) * 2005-06-23 2006-12-28 International Business Machines Corp. Method and system for establishing a secure connection based on an attribute certificate having user credentials
US7565358B2 (en) * 2005-08-08 2009-07-21 Google Inc. Agent rank
MX2008002616A (es) * 2005-08-24 2008-03-14 Pioneer Hi Bred Int Composiciones que proporcionan tolerancia a multiples herbicidas y metodos de uso de las mismas.
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US20070101400A1 (en) * 2005-10-31 2007-05-03 Overcow Corporation Method of providing secure access to computer resources
US7526677B2 (en) * 2005-10-31 2009-04-28 Microsoft Corporation Fragility handling
US7827545B2 (en) * 2005-12-15 2010-11-02 Microsoft Corporation Dynamic remediation of a client computer seeking access to a network with a quarantine enforcement policy
US20070198525A1 (en) * 2006-02-13 2007-08-23 Microsoft Corporation Computer system with update-based quarantine
US20070203852A1 (en) * 2006-02-24 2007-08-30 Microsoft Corporation Identity information including reputation information
US8104074B2 (en) * 2006-02-24 2012-01-24 Microsoft Corporation Identity providers in digital identity system
US8117459B2 (en) * 2006-02-24 2012-02-14 Microsoft Corporation Personal identification information schemas
US7904725B2 (en) * 2006-03-02 2011-03-08 Microsoft Corporation Verification of electronic signatures
US7793096B2 (en) * 2006-03-31 2010-09-07 Microsoft Corporation Network access protection
US7603350B1 (en) 2006-05-09 2009-10-13 Google Inc. Search result ranking based on trust
EP1868315A1 (en) * 2006-06-15 2007-12-19 Sealed SPRL Cryptographic computer-implemented method for processing a digital signature and information processing apparatus therefor.
US8078880B2 (en) * 2006-07-28 2011-12-13 Microsoft Corporation Portable personal identity information
US8121946B1 (en) 2006-08-01 2012-02-21 United Services Automobile Association System and method for modular electronic signature block
US8171469B2 (en) 2006-08-15 2012-05-01 Hewlett-Packard Development Company, L.P. Package compatibility
US8239677B2 (en) * 2006-10-10 2012-08-07 Equifax Inc. Verification and authentication systems and methods
US20080097777A1 (en) * 2006-10-23 2008-04-24 Ctm Software Corporation Electronic document execution
US8510233B1 (en) 2006-12-27 2013-08-13 Stamps.Com Inc. Postage printer
US9779556B1 (en) 2006-12-27 2017-10-03 Stamps.Com Inc. System and method for identifying and preventing on-line fraud
US8407767B2 (en) * 2007-01-18 2013-03-26 Microsoft Corporation Provisioning of digital identity representations
US8087072B2 (en) * 2007-01-18 2011-12-27 Microsoft Corporation Provisioning of digital identity representations
US8689296B2 (en) 2007-01-26 2014-04-01 Microsoft Corporation Remote access of digital identities
EP1968265A1 (en) * 2007-02-07 2008-09-10 Comodo CA Limited Method and system for securely transmitting electronic mail
US8341616B2 (en) * 2007-03-28 2012-12-25 International Business Machines Corporation Updating digitally signed active content elements without losing attributes associated with an original signing user
US20080288291A1 (en) * 2007-05-16 2008-11-20 Silver Springs - Martin Luther School Digital Signature, Electronic Record Software and Method
US20080313456A1 (en) * 2007-06-12 2008-12-18 Andrew John Menadue Apparatus and method for irrepudiable token exchange
MX2010000619A (es) * 2007-07-17 2010-05-17 William Howard Peirson Jr Sistemas y procesos para obtener y manejar firmas electronicas para documentos de transacciones de bienes raices.
KR101018001B1 (ko) * 2007-09-27 2011-03-02 주식회사 스타뱅크 통합 구조를 갖는 문서관리 시스템
US9225684B2 (en) * 2007-10-29 2015-12-29 Microsoft Technology Licensing, Llc Controlling network access
US8793487B2 (en) 2008-01-18 2014-07-29 Identrust, Inc. Binding a digital certificate to multiple trust domains
EP2243295B1 (en) * 2008-09-24 2018-02-28 Nec Corporation A method and a system for distributing tv content over a network
US20100146280A1 (en) * 2008-12-10 2010-06-10 Industrial Technology Research Institute Remote assisting method and system
US9298902B2 (en) * 2009-02-12 2016-03-29 International Business Machines Corporation System, method and program product for recording creation of a cancelable biometric reference template in a biometric event journal record
US8327134B2 (en) * 2009-02-12 2012-12-04 International Business Machines Corporation System, method and program product for checking revocation status of a biometric reference template
US8635442B2 (en) * 2009-04-28 2014-01-21 Adobe Systems Incorporated System and method for long-term digital signature verification utilizing light weight digital signatures
US8605296B2 (en) * 2009-05-28 2013-12-10 SecureCare Technologies, Inc. Digital signature system and method
US9608826B2 (en) * 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
US8606792B1 (en) 2010-02-08 2013-12-10 Google Inc. Scoring authors of posts
JP5244849B2 (ja) * 2010-04-26 2013-07-24 株式会社野村総合研究所 認証機能付き印鑑
EP2609712A1 (en) * 2010-08-24 2013-07-03 Koninklijke Philips Electronics N.V. Attribute-based digital signatures
US8782397B2 (en) * 2011-01-06 2014-07-15 International Business Machines Corporation Compact attribute for cryptographically protected messages
WO2012165337A1 (ja) * 2011-05-31 2012-12-06 Yamada Tetsuo 税管理方法、税管理システム、取引情報管理装置、および認証サーバ
US10410213B2 (en) * 2012-05-04 2019-09-10 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US11250423B2 (en) * 2012-05-04 2022-02-15 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US10423952B2 (en) 2013-05-06 2019-09-24 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
WO2015088986A1 (en) * 2013-12-09 2015-06-18 Sureclinical Inc. System and method for high trust cloud digital signing and workflow automation in health sciences
US20150186619A1 (en) * 2013-12-26 2015-07-02 Medidata Solutions, Inc. Method and system for ensuring clinical data integrity
US10521791B2 (en) * 2014-05-07 2019-12-31 Mastercard International Incorporated Systems and methods for communicating liability acceptance with payment card transactions
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US10453058B2 (en) 2014-12-17 2019-10-22 Heartland Payment Systems, Inc. E-signature
US9336092B1 (en) * 2015-01-01 2016-05-10 Emc Corporation Secure data deduplication
CN105991600B (zh) * 2015-02-25 2019-06-21 阿里巴巴集团控股有限公司 身份认证方法、装置、服务器及终端
US10868672B1 (en) 2015-06-05 2020-12-15 Apple Inc. Establishing and verifying identity using biometrics while protecting user privacy
US11140171B1 (en) 2015-06-05 2021-10-05 Apple Inc. Establishing and verifying identity using action sequences while protecting user privacy
EP3104320B1 (fr) * 2015-06-12 2018-08-15 EM Microelectronic-Marin SA Procédé de programmation de données bancaires dans un circuit intégré d'une montre
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US11113656B2 (en) 2015-08-18 2021-09-07 Walmart Apollo, Llc System for automatic signature for receipt verification
KR102210897B1 (ko) * 2015-08-24 2021-02-01 후아웨이 테크놀러지 컴퍼니 리미티드 보안 인증 방법, 구성 방법 및 관련 기기
US11328234B2 (en) 2015-12-11 2022-05-10 Sureclinical Inc. Interactive project progress tracking interface
US9800568B1 (en) * 2016-03-16 2017-10-24 F5 Networks, Inc. Methods for client certificate delegation and devices thereof
US10482468B2 (en) 2016-11-11 2019-11-19 Mastercard International Incorporated Systems and methods of improved electronic messaging
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US10541954B1 (en) * 2018-08-05 2020-01-21 Gideon Samid Cyber companion: attaching a secondary message to a primary one
KR20210055675A (ko) * 2018-09-04 2021-05-17 소니 주식회사 Ic 카드, 처리 방법 및 정보 처리 시스템
US11157626B1 (en) 2019-05-29 2021-10-26 Northrop Grumman Systems Corporation Bi-directional chain of trust network
US20210110405A1 (en) * 2019-10-09 2021-04-15 Jpmorgan Chase Bank, N.A. System and method for implementing a data contract management module
US11526859B1 (en) 2019-11-12 2022-12-13 Bottomline Technologies, Sarl Cash flow forecasting using a bottoms-up machine learning approach
US11532040B2 (en) 2019-11-12 2022-12-20 Bottomline Technologies Sarl International cash management software using machine learning
WO2021144888A1 (ja) * 2020-01-15 2021-07-22 株式会社Ｆｉｎａｌｉｔｙ Ｔｅｃｈｎｏｌｏｇｉｅｓ 決済処理装置、決済処理プログラムおよび決済処理システム
US11704671B2 (en) 2020-04-02 2023-07-18 Bottomline Technologies Limited Financial messaging transformation-as-a-service
CN113411184B (zh) * 2021-05-31 2022-06-14 胡金钱 一体化管理终端装置及一体化管理方法
CN113259137A (zh) * 2021-07-15 2021-08-13 广东电网有限责任公司江门供电局 一种基于用户属性的电网访问控制方法、系统和存储介质
US11991400B2 (en) 2022-07-15 2024-05-21 Bank Of America Corporation Device for executing audio cryptology in real-time for audio misappropriation prevention

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4625076A (en) * 1984-03-19 1986-11-25 Nippon Telegraph & Telephone Public Corporation Signed document transmission system
US5214702A (en) * 1988-02-12 1993-05-25 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5005200A (en) * 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5163091A (en) * 1990-01-29 1992-11-10 Graziano James M Knowledge based system for document authentication (apparatus)
US4981370A (en) * 1990-01-29 1991-01-01 Dziewit Halina S Document authentication apparatus
US5031214A (en) * 1990-01-29 1991-07-09 Dziewit Halina S Document authentication apparatus
US5191613A (en) * 1990-11-16 1993-03-02 Graziano James M Knowledge based system for document authentication
US5164988A (en) * 1991-10-31 1992-11-17 International Business Machines Corporation Method to establish and enforce a network cryptographic security policy in a public key cryptosystem
US5157726A (en) * 1991-12-19 1992-10-20 Xerox Corporation Document copy authentication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Сети передачи данных. Справочная служба. Рекомендации Х500-Х521, МККТТ, т. VIII, вып.8, 1988. *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003005638A1 (fr) * 2001-07-05 2003-01-16 Gurov, Georgy Borisovich Procede de protection integree du traitement reparti de donnees dans des systemes informatiques et systeme de mise en oeuvre correspondant
US8868678B2 (en) 2004-05-03 2014-10-21 Microsoft Corporation Aspects of digital media content distribution
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US7924913B2 (en) 2005-09-15 2011-04-12 Microsoft Corporation Non-realtime data transcoding of multimedia content
RU2448365C2 (ru) * 2006-04-10 2012-04-20 Траст Интегрейшн Сервисиз Б.В. Устройство и способ защищенной передачи данных
WO2012144930A1 (ru) * 2011-04-22 2012-10-26 Общество С Ограниченной Ответственностью "Нфи-Сервис" Система заказа товаров и услуг посредством устройства сотовой связи

Also Published As

Publication number Publication date
DE69534490D1 (de) 2005-11-03
AU698454B2 (en) 1998-10-29
WO1996002993A2 (en) 1996-02-01
NO970084D0 (no) 1997-01-09
ATE305682T1 (de) 2005-10-15
US5659616A (en) 1997-08-19
NO970084L (no) 1997-03-10
DE69534490T2 (de) 2006-06-29
EP0771499A2 (en) 1997-05-07
JPH10504150A (ja) 1998-04-14
CZ11597A3 (en) 1997-09-17
CA2194475A1 (en) 1996-02-01
TR199600585A2 (tr) 1997-02-21
EP0771499B1 (en) 2005-09-28
AU3715695A (en) 1996-02-16
WO1996002993A3 (en) 1996-03-07

Similar Documents

Publication Publication Date Title
RU2144269C1 (ru) Способ секретного использования цифровых подписей в коммерческой криптографической системе
US7904722B2 (en) Method for securely using digital signatures in a commercial cryptographic system
US11481768B2 (en) System and method of generating and validating encapsulated cryptographic tokens based on multiple digital signatures
US6192131B1 (en) Enabling business transactions in computer networks
Chokhani et al. Internet X. 509 public key infrastructure certificate policy and certification practices framework
US6367013B1 (en) System and method for electronic transmission, storage, and retrieval of authenticated electronic original documents
US10410213B2 (en) Encapsulated security tokens for electronic transactions
US7200749B2 (en) Method and system for using electronic communications for an electronic contract
WO1996002993A9 (en) Method for securely using digital signatures in a commercial cryptographic system
US7184988B1 (en) Methods for operating infrastructure and applications for cryptographically-supported services
KR20010043332A (ko) 인증된 문서의 전자 전송, 저장 및 검색을 위한 시스템 및방법
JP2005328574A (ja) キー寄託機能付き暗号システムおよび方法
US11334884B2 (en) Encapsulated security tokens for electronic transactions
KR100745446B1 (ko) 인증 방법, 인증 시스템, 인증 장치 및 기록 매체
CN1153582A (zh) 在商业密码系统中安全使用数字签字的方法
Skevington From security to trust-creating confidence to trade electronically
AU2008203525B2 (en) Linking public key of device to information during manufacturing
Sudia et al. Commercialization of Digital Signatures
KEY Microsoft Research, 7 JJ Thomson Avenue, Cambridge CB3 0FB, United Kingdom E-mail: diego© microsoft. com
Sabett et al. Network Working Group S. Chokhani Request for Comments: 3647 Orion Security Solutions, Inc. Obsoletes: 2527 W. Ford Category: Informational VeriSign, Inc.
Gollmann PUBLIC KEY INFRASTRUCTURES

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20030720