Method for securely using digital signatures in a commercial cryptographic system.

METHOD FOR SECURELY USING DIGITAL SIGNATURES IN A COMMERCIAL CRYPTOGRAPHIC SYSTEM

BACKGROUND OF THE INVENTION

The invention relates to digital signatures. More specifically, this invention relates to the use of digital signatures and digital signature certificates in a commercial cryptographic system to enforce security policies and authorization requirements in a way that reduces risks to users.

Public key cryptography is a modern computer security technology that can support the creation of electronic document systems without the use of paper, provided that sufficient practical and legal significance can be attributed to the user's digital signature on an electronic document, that is, to the authentication and electronic verification of the user of the electronic document. These types of paperless electronic document systems, or document architectures, will not only encompass business partners that

2ü operate under normal bilateral contracts, but also global multilateral systems in which, in theory, any entity can correspond with any other entity in a legally verifiable manner, provided that appropriate security controls are observed at all times.

RBF:23874

These systems will have enormous commercial significance, as in many cases they can achieve cost reductions of around 10% compared to current paper-based transaction procedures. This improvement is dramatic enough that many organizations will be compelled to adopt them, for economic and competitive reasons, once their practicality has been demonstrated.

No one disputes that paper is a troublesome anachronism in the electronic world, or that verifying signatures executed with pen and ink is costly and prone to errors. However, at least with paper, the signer retains basic contextual controls over the preparation and physical delivery of the document. On the other hand, in a digitally signed electronic document, the signer only controls the encoded signature. All controls of time, place, and form are absent, and there is nothing to distinguish a valid user signature from one fraudulently produced by another user who somehow obtained the smart card and PIN (personal identification number) of the first user. It wouldn't take losses of many millions or many billions of dollars to wipe out all the savings produced by this novelly combined office automation technology. Therefore, digital signatures will initially be used only in consumer e-wallet applications, where the risk is low, and in wholesale financial transfers, where extremely strict security procedures are already the norm. However, these uses will have little overall commercial impact.

So far, large corporations and banks have refused to invest in these technologies, due to the absence of well-defined risk models and audit standards, and due to uncertainty regarding legal aspects and obligations. Serious investments to commercialize digital signatures will only occur when national legal and auditing experts have determined that these 15 systems contain adequate security controls to ensure their reliability in intra- and inter-corporate mainnetwork business transactions, which are typically in the $10,000 to $10 million range. In order to achieve this goal, it is necessary to formulate 20 security controls to reduce to the lowest technically conceivable level the risks to participants in document systems with digital signatures.

There are two types of cryptographic systems in which digital signatures have been used: symmetric cryptographic systems and asymmetric cryptographic systems. Figures 1(a) and 1(b) illustrate the use of symmetric and asymmetric algorithms for encryption. In symmetric (conventional) cryptography, as shown in Figure 1(a), the receiver of a communication shares a secret key. This key is used by the sender, the person who originates the communication, to encrypt message 12, and by the receiver of the communication to decrypt message 13. It can also be used by the receiver to authenticate a message, by requiring the sender to use the secret key to compute some function, such as a Message Authentication Code (MAC) based on the message; in this way the receiver can be sure of the identity of the one who originates the message, since only the sender and the receiver know the secret key used to compute the MAC, DES is an example of a symmetric cryptographic system.

In the asymmetric (public key) cryptography illustrated in FIGURE 1(b), different keys are used to encrypt and decrypt a message. Each user is associated 20 with a key pair. One key 15 (the public key) is publicly known and is used to encrypt messages 17 intended for that user, and the other key 16 (the private key) is known only to that user and is used to decrypt received messages 18. Since it is no longer necessary to keep the public key secret, it is also no longer necessary to secretly transmit a shared encrypted key between the communicating parties before exchanging confidential traffic or authentication messages. RSA is the best-known asymmetric algorithm.

However, a digital signature is a block of data appended to a data unit that forms the message, allowing the recipient to verify the origin of the message's data unit and protect it against forgery. Some asymmetric algorithms (e.g., RSA) can also provide authentication and non-repudiation through the use of digital signatures. To sign the data, the sender encrypts it using their own private key. To validate the data, the receiver decrypts it using the sender's public key. If the message is successfully decrypted using the sender's public key, then the message must have been originally encrypted by the sender, since the sender is the only entity that knows the corresponding private key. Using this method to sign documents, the encrypted document is linked to the signature, since the recipient cannot read the message without decrypting the signature data block. The message encrypted by the signature can then be encrypted for the recipient using the recipient's public key as usual.

Digital signatures can also be formed using algorithms for asymmetric encryption, as described below and illustrated in FIGURE 2. To sign a message, the message 20 is first digested (shredded) to form a single block 22 using a one-way shredding function 21. A one-way hash function has the property that, when given the digested product, it is not capable of computationally constructing any message that has been hashed to that value, or of finding two messages that have been hashed to the same digested product. The digested product 22 is then encrypted with the user's private key 23, and the result 24 is appended as a signature 25 to the encrypted message. The receiver uses the sender's public key 26 to decrypt the signature 25 in the digested, shredded product 22. The receiver also digests (shreds) the message 20 that it received, whether unencrypted or encrypted, and which was subsequently decrypted by the receiver, to form a block 27 using the same one-way shredding function 21 that the sender used. Next, the receiver verifies the sender's signature by checking that the digested product 22 of the decrypted message is the same as the digested product 27 of the decrypted message.

Separating the message signature in this way, meaning that it does not require the sender and receiver to encrypt and decrypt the entire message in order to verify the signature, greatly reduces the amount of data that needs to be encrypted. This is important because public-key algorithms are generally substantially slower than conventional algorithms, so processing the entire message to verify the signature would take a considerable amount of time. The signing process also introduces redundancy into the message, which, because the message must be broken down according to the specified digested product, allows the receiver to detect unauthorized modifications to the message.

A digital signature provides the following security services: (a) integrity, because modifying the data being signed will result in a different digested product, and consequently a different signature; (b) authentication of origin, because only the holder of the private key corresponding to the public key used to validate the signature could have signed the message; and (c) non-repudiation, as irrevocable proof to a third party that only the signatory, and not the recipient or their employees, could have created the signature. A symmetric secret-key authenticator, such as the X9.9 MAC, does not provide these services, since either party can create the authenticator using the key they share.

Several of the mechanisms discussed herein assume the ability to add multiple signatures or joint signatures to a document. A useful format for this purpose, as is well known in the art, is defined in PAKCS #7: Cryptographic Message Syntax, RSA Data Security, Inc., 1993, a document incorporated herein by reference. Each signature structure in a document will contain an indication of the certificate required to validate the signature, along with a bit string containing the actual signature. Additionally, other information relevant to the particular signer can be included in an individual signature computation. This signer-specific information can be included in the signature computation as signature attributes.

In order for one user to identify another user for message transmission in a way that guarantees the second user possesses the private key, the first user must be able to obtain the other user's public key from a trusted source. This is well known in the X.5Q9: The Directory: Authentication Framework, CC1TT, April. 1993 (X.509), a scheme for the use of public key certificates was defined, which is incorporated herein by reference. These basic public key certificates link a username to a public key and are signed by a trusted issuer called a Certificate Authority (CA). In addition to containing the username and public key, the certificate also contains the name of the issuing CA, a serial number, and a validity period.

Even though X.509 does not impose any particular structure on CAs, many forms of implementation find it reasonable to impose a hierarchical structure in which each CA (in general) only certifies entities that are subordinate to it. Therefore we can construct a hierarchy of CAs, as shown in FIGURE 3, in which the higher level CAs 31 (perhaps banks) sign the certificates 34 of the CAs 32 below them (e.g., Companies), and the lowest level of CAs 32 sign certificates 35 of users 33. At the top of that hierarchy (not shown) are other, relatively few, root CAs, perhaps one per country, which can cross-reference public keys with each other (root keys).

2Q Several security architectures define mechanisms to build a certification path through the hierarchy to obtain a given user's certificate and all the necessary Cñ certificates to validate it. These architectures share the common characteristic that a user only needs to trust a single public key to obtain and validate any other certificate. The trusted key can be that of a high-level CA (in a centralized trust model) or of the local CA that issued the user's certificate (in a decentralized model).

Certificates also contain an expiration date. If it becomes necessary to cancel a certificate before its expiration date, such as if the name association becomes invalid, or the corresponding private key is lost or compromised, the certificate can be added to the CA's Certificate Revocation List (CRL) or hot list. This list is signed by the CA and widely distributed, possibly as part of the CA directory registration. The certificate remains with the CRL until its expiration date.

Often, it is necessary to make certain information about an entity or CA available in a reliable manner. In a secure X.500 directory, this information would be collected through normal directory operations, and the result would be signed by the directory. In the absence of such X.500 security, this information is placed in an attribute certificate, which is signed by the CA in the same way as a public key certificate. Attribution certificates would be created upon presentation of the appropriate credentials by the user.

For example, the user would present their public key certificate and verify that they possess the corresponding private key, as a form of identification. Attribution certificates are linked to the user's basic public key certificate by referencing the basic certificate's serial number and are revoked using an identical, parallel CRL mechanism. Attribution certificates are further discussed in X9.30 Part 3: Certificate Management for DSA. ANSI X9F1, June, 1994, and US Patents

Nos. 4,868,877, 5,005,200 and 5,214,702, all of which are well known in the art and are incorporated by reference herein.

An attribute certificate is a separate structure from a public key certificate, because the proper separation of duties may often require that the CA issuing the attribute certificate be different from the CA issuing the public key certificate; a central CA will rarely be able to possess the security or authority required to sign all of a user's authorizations. Having separate CAs generate various types of attribute certificates distributes risks more appropriately. Additionally, the defined attributes may not be required for all domains, networks, or applications. The need for these attributes and additional domain-specific attributes is determined by each domain or activity.

The user's basic public key certificate remains compatible with X.509, allowing it to be used with other applications and the use of commercial products for certificate generation.

It is desirable to be able to build a reliable organization that uses digital signature and certification mechanisms to enforce a rules-defined security policy within this organizational structure.

It is also desirable to use digital signature and certification mechanisms to encode an industry-wide security and authorization information policy in signatures and certificates in order to allow the verifier of a signature to decide whether to accept the signature or certificate as valid, thereby accommodating and facilitating electronic business transactions.

It is also desirable to reduce the risks associated with digital signature systems, particularly with end-user smart cards, by relying on the use of public key certificates and attribute certificates.

It is also desirable to prevent such a digital signature system from being used by any party that intends to accept a transaction in contravention of the applicable authorization certificates, when that party has not signed the applicable system rules agreement pertaining to that signer authorization communication system.

BRIEF DESCRIPTION OF THE INVENTION

This and other objects of the invention are achieved in accordance with the principles of the invention by providing a system for securely using digital signatures in a commercial cryptographic system, which enables the encoding of industry-wide security and authorization information policies in signatures and certificates, by employing attribute certificates to impose policy and authorization requirements in addition to value limits, Joint signature requirements and documentary restrictions that can be imposed on transactions, an organization can impose geographical and time controls, age limitations for signing, limitations on the pre-approved counterparty and confirmation-a requirements with respect to any transaction by employing attribution certificates for the user carrying out the transaction. Restrictions on certificate distribution can be set using attribution certificates. Certificates can also be used to ensure key restriction and prevent the decryption of smart cards in this system.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects and advantages of the invention will be apparent after taking into account the detailed description taken in conjunction with the accompanying drawings, in which identical reference symbols refer in all cases to identical parts, and in which:

Figures 1(a) and 1(b) show how to use the symmetric and asymmetric encryption algorithms according to the previous technique:

FIGURE 2 is a flowchart illustrating the process of a digital signature according to the above technique, using an asymmetric algorithm for encryption;

FIGURE 3 shows a hierarchy of signature certification authorities;

FIGURE 4 shows a directory information tree (DIT);

FIGURE 5 shows an example of an authorization certificate;

FIGURE 6 is a flowchart illustrating the process according to the above technique of a monetary value restriction on a transaction imposed by the verifier;

FIGURE 7 is a flowchart illustrating a process in accordance with the above technique of joint signature requirement in a transaction imposed by the verifier;

Figure 8 is a flowchart illustrating the process of a document-type restriction in a transaction, imposed by the verifier;

FIGURE 9 is a flowchart illustrating the process of geographical and temporal control in a transaction imposed by the verifier;

FIGURE 10 is a flowchart illustrating the process of restricting the maximum age of the sender in the signature, imposed by the verifier;

FIGURE 11 is a flowchart illustrating the process of a previously approved counterparty restriction imposed by the verifier and sponsor;

FIGURE 12 is a flowchart illustrating the process of certifying a device for key restriction and no decryption;

FIGURE 14 is a flowchart illustrating the process for keeping public keys secret and enforcing the system rules; and

FIGURE 15 is a flowchart illustrating the process of verifying user rules in a transaction.

DETAILED DESCRIPTION OF THE INVENTION

The following general principles and philosophies are reflected in the signature verification model defined in this invention. First, the CA and user certificates may contain attributes that document the conditions and assumptions under which they were created. Verifiers can simply reject all certificates and transactions that do not meet their minimum standards.

Also, attribution certificates can be signed by a user's sponsor, meaning that the sponsor's signature will be honored for 10 official business transactions, if the transaction meets the requirements set or implied by the attributes. While the user's sponsor will typically be the user's employer, the model can be extended to include the bank, credit card issuer, polling station, video rental center, the user's public library, or any other entity that accepts the user's signature. This sponsor's certificate (of authorization) is therefore the electronic equivalent of a legal trademark attestation, as used in the context of a traditional signature seal. See Robert Jueneman, "Limiting the Liability of CAs and Individuals Regarding the Use of Digital Signatures," presented to the ABA Section of the Science and Technology Certifying Authorities Working Group, July 25, 1993.

Furthermore, industries can develop industrial policy statutes that establish minimum requirements for signature verification. All participants would sign these multilateral agreements to ensure that all counterparties are subject to the codified restrictions. Sponsor certificates should normally be required in all cases, and digital signatures would otherwise be considered null and void in their absence. The industry-wide policies would also define (1) relevant document types and classes, (2) signatory positions and titles, and (3) coded symbols to incorporate by reference standard contractual terms and conditions.

Furthermore, there must be strict adherence to the principle that all restrictions can be imposed in a completely automated manner (i.e., verification at sight), without reference to paper agreements and human interpretations, which is sometimes also referred to as fully machine-directed processing. In complex and/or high-volume environments, this is required to lend credibility to these security controls in the eyes of legal and auditing experts. References to trusted third parties should also be minimized to reduce verification lag times.

While these restrictions may seem complex, they simply reflect standard business procedures designed to be explicit for the purpose of machine verification. Previously, such controls were implemented within the sponsor's computer system before the transaction was sent externally. However, with the advent of distributed multilateral transactions, the verifying user is typically outside the sender sponsor's system line, and therefore the verifier is obliged to enforce the sponsor's authorization model, as reflected in the attribution certificates. Once this methodology has been specified, office software vendors will develop menu-driven systems for creating and controlling user attributes, and the cost to user organizations will be relatively low.

Organizational Structure in Certificates

The certificates themselves can reflect the structure of a sponsoring organization. Because many authorization decisions are based on the user's position within an organization, the organizational structure and the user's position within it can be specified in the certificates, as part of the user's name. Names in certificates are specified according to the model of

X.500 Directory, as follows.

The X.500 Directory structure is hierarchical; the resulting distributed database comprises the Directory Information Tree (DIT), as illustrated in Figure 4. Each entry 41 is of a specific object class and consists of a series of characteristics called attributes 42. An attribute 42 consists of a type 43 and one or more values ​​44. Thus, in an organization class entry, one attribute is the name of the organization; in an organizational person class entry, attributes may include the title and telephone number.

Each entry also contains one or more special attribute values ​​that are used to construct the object's name; this attribute value is the relative distinguished name (RDN) of the entry. The distinguished name (DN) of an object, which is created by concatenating the relative distinguished names of all entries from the root DIT to the entry, uniquely identifies the object in the global DIT.

Several of the attributes defined in X.500 can be usefully included in the user's attribution certificate. For example, the object class can be used to distinguish between entities (e.g., users and 25 positions) whose distinctive names have the same form.

The title can also be used to make authorization decisions.

In addition to using the DIT to group entities along organizational lines, X.500₅ It defines several object classes that can be used to construct arbitrary entity drawings. These object classes include the organizational role, whose role occupant or position attribute provides a list of the names of users holding the position and a list of the group.₁₀ of names whose member attribute provides a list of group member names. To transmit this information reliably, position and group certificates could be defined that transmit the names of the occupants or group members, respectively.₁₅ position or paper, and that are signed by a CA, so that_HE makes it possible to use this feature outside the context of an X.500 directory system.

Group and job certificates can be used in conjunction with a signature mechanism₂₀ joint signatures can be used to simplify the construction of joint signature requirements. For example, a transaction might require the signatures of three individuals holding the position of purchasing agent. A user can also indicate the role in which they are acting by including the position or role in the signature computation.

2i as an attribute of the signature (signer by). The claimed position can then be compared against a position certificate (or the user's attribution certificate) during verification.

Information on Policies in Certificates

Another embodiment of this invention is to encode information regarding a CA's security policy in the attribute certificates of the CA and its subscribers, so that a signature verifier can use the information to determine whether to accept a signature as valid. In general, the CA certificate will transmit the rules that a CA uses when making certification decisions, while the user certificate will transmit the information that the CA uses when applying these rules.

The attributes in CA certificates can indicate security policies and security information for a particular CA. This policy information can also be inherited by subordinate CAs, allowing for the easy construction of security scopes that share a common policy. Policy attributes in a CA certificate can include, among other things:

( 1) Limitations of liability: the amount for which a CA is liable in the event of various problems (e.g., compromise of the CA key, defective lamination); this may be that there is no liability, that there is full liability, or for a specific amount of money.

( 2) Trust specification: a description of which users and CAs a given CA can certify, expressed in terms of the same CA (e.g., all subordinates), or with respect to the DIT in general (e.g., the subordinate tree under organization ABC), or with respect to others.

(3) Required Attributes: A list of those attributes in the user's attribute certificates that must be verified against the transaction and/or its context in order for the transaction to be considered authorized. These attributes would be found in the sponsor's certificate(s) and would allow a single authorization certificate to contain authorization attributes for use with multiple applications. Some suggested user authorization attributes are defined later.

( 4) Permitted name forms: A specification of the permitted name forms that the CA may certify. This information is maintained as (a) a set of name bindings that defines the attributes that can be used to qualify entries of a given object class (i.e., the allowed RDN formats for entries of this class), γ (b) a set of structural rules that defines which object classes can be adjacent (i.e., superior or subordinate) to one another in the DIT, That is, the order in which the object classes can be chained together to form a complete DN. This policy attribute can be used to restrict the type of entities that can sign transactions. For example, for wire transfer applications, it may be desirable to restrict signing ability to the IQ organization itself rather than to users within the organization, as this is similar to the current mode of operation using DES-type MACs.

( 5) Cross-certifications: it may be desirable from an efficiency point of view to allow entities that₁₅ They certify, and as organizations, cross-certify each other in order to constrain the length of certification paths. On the other hand, it is not desirable to allow certification paths to contain arbitrary numbers of cross-certifications, as it is difficult for two-factor authentication to determine the level of trust in the entity at the other end. Many certification architectures restrict certification paths to contain only one cross-certification. To accommodate a wider range of policies, an attribute can be added to the 25-attribute certificate associated with the associated certificate, indicating that the cross-certifier explicitly allows the use of cross-certified certificates issued by the CA, which are cross-certified.

The attributes in the attributes certificate of a₅ The user or entity can represent the information verified by the CA when it creates the certificate for the entity. Policy attributes in a user certificate can include, but are not limited to:

(1) Linking information: the criteria used to link the public key to the entity being certified. This includes (a) the method of delivery, such as in-person submission, submission through an authorized agent, by mail, or by some other means; (b) the means of identification as it is in accordance with reasonable commercial practices, by verification by a trusted third party, by dual control, by fingerprint comparison, by a full background investigation, or by some other means; (o) the identification documents submitted to the 2q CA; and (d) the type of entity of the subject, i.e., individual, corporation, device, or other.

(2) Accredited third parties: the names of any accredited third parties or agents involved in the liaison process.

(3) Positions: For authorization purposes, it may be useful to indicate which positions (both internal and external to the organization) the user may hold or occupy. This contrasts with a position certificate, which would be issued for the position and would contain the names of all occupants.

(4) Relative Identity: A CA may wish to certify only a portion of an individual's ID. In particular, the CA may decline responsibility for the accuracy of an individual's personal name, since, according to the agency's legal principles, the individual's signature in any case binds the organization's sponsor. Consider the name:

C=US; O=Bankers Trust; OU=Global Electronic Commerce; CN=Frank Sudia; TI=VP.

The CA could certify only the validity of the organization, the organizational unit, and the holding portions of the individual's distinctive name, all of which are easy to verify, while the personal name alone would be considered as reasonably correct. Given the relative ease with which falsified identification documents can be obtained, this avoids the need for prohibitively expensive background checks. In an ordinary business situation, that type of identification can be trusted, but not in a process involving a will or inheritance, for example.

(5) Absolute Identity. We define relative identity as the user's identity relative to their organizational sponsor. In other words, we certify all elements of the user's identity on their business card, except for their personal name. As an exception, some CAs may be able to certify the absolute identity of select users, such as the children of wealthy clients, diplomats, or national security operatives, almost certainly supported by biometric techniques. This would be rare and is mentioned here only to provide a complete picture and round out the concept of relative identity. Information on Authorization in Certificates

Attributes can convey restrictions that control the conditions under which a signature is valid. Without these restrictions, the risk of forgery would be considered excessive, since an electronic signature can be placed on almost any digital document by anyone who possesses the smart card and the user's personal identification number (PIN). In an electronic environment, normal contextual controls for document creation and physical delivery are either weak or nonexistent.

It is even difficult to trust genuine users to freely make offline commitments, and therefore organizations will welcome the ability to positively restrict the scope of express signature authorization. Such authorization attributes, in addition to normal X.500 attributes, may include Transaction Limits, Joint Signature Requirements, Document Types, Subject Matter Restrictions, Authorized Signatories, Geographic and Time Controls, Signing Age, Pre-Approved Counterparties, Delegation Controls, and the Requirement of

Confirm-A. These attributes can be encoded in one or more authorization certificates signed by the signer's organizational sponsor or by an external CA acting on behalf of the organization. An example of an authorization certificate and an associated transaction is shown in FIGURE (5).

When a receiving user (verifier) ​​receives a transaction 51 from a sending user, the receiver first uses the sender's basic key certificate 55 to verify the sender's signature 52 on transaction 51.

As will be described in more detail below, the receiver also uses the sender's authorization certificate 56, signed by the sender's sponsor 59, to verify the joint signatures 53 and the date-print notarization 54 added to the transaction 51, and to verify that the transaction's attribute values ​​57 fall within the authorized attribute values ​​58 as specified in the authorization certificate 56.

The user may be subject to transaction limits that control the value of transactions or other documents the user can initiate. The user's signature will only be valid for transactions that originate either up to a certain monetary limit or between two monetary value limits. According to this 10 as shown in FIGURE 6, the sending user sends a transaction 601 signed 603 by the sender (actually by the user's smart card 600 containing their private key) and adds to it an authorization certificate 604. The verifier uses the authorization certificate 604 (5) to verify the user's signature 603 and to verify that the monetary value 602 of the transaction falls within the transaction limit set by the attribute value 605 in the authorization certificate 604. The verifier also verifies the sponsor's signature 606 in the authorization certificate 604._r using the sponsor's public key 610. If any of these signatures and attribute values ​​do not match, the transaction is rejected 611. If the verification is complete, it is accepted 612.

Regarding joint signature requirements, additional signatures may be required for a given signature to be considered valid. Quorum mechanisms can be used to construct sufficiently elaborate checks and balances to explicitly govern the level of trust in each user. The particular sequence or order of the required signatures can also be specified. Referring to FIGURE (7), sender user A sends a transaction 702 signed 703 by his own smart card 700, and, if joint signature of user 3 is required in transaction 702 signed 704 by smart card 701 of user B. Sender user A also adds his own authorization certificate 705 to transaction 702. The verifier uses the authorization certificate 705 to verify 711 the signature 703 of user A, and uses the sponsor's public key 713 to verify 712 the sponsor's signature 707 on the authorization certificate 705; if any signature is not verified, the transaction is rejected 720. If the authorization certificate 705 establishes the requirement 714 of a joint signature value 706, the receiver enforces this requirement by proceeding to verify 715 the signature 704 of user B who jointly signs in transaction 702, and then verifies the public key certificate 708 of user B who has the joint signature by verifying 716 the signature 709 of the certificate issuer, using the issuer's public key 717. If the signature of user B or the issuer of their certificate is not verified, the transaction is rejected 722.

The use of joint signatures allows an organization to effectively define checks and balances and explicitly specify the level of trust in a user. Joint signatures also greatly reduce the risks resulting from the inadvertent compromise of a private key due to theft, misuse, or loss of a smart card or PIN. In particular, it is believed that the ability to require joint signatures, value limits, and related controls will allow organizations to carefully control and fine-tune all signature authorizations, putting in their hands all the necessary tools to control and limit their risks. Furthermore, the use of joint signatures allows the authorization function to be distributed across multiple locations and equipment platforms, thereby mitigating the risks that can result from access control failures on some of those platforms. See U.S. Patents Nos. 4,868,877, 5,005,200, and 5,214,702.

Authorization signatures, which must satisfy the restrictions specified in the signer's certificate, can also be distinguished from other joint signatures if the purpose of the signature is included as an attribute of the signature, and if an indication of the purpose of the signature is required to be included in the data being signed. This purpose-of-the-signature attribute could require the values ​​of: (a) an authorizing signature appropriate to the document, (b) a joint authorizing signature appropriate to the document, where the certificate of the joint signatory has sufficient authority to authorize the document, and (c) a joint signature of a witness when the certificate of the joint signatory alone does not have sufficient authority to authorize the document. The purpose codifications of signatures are discussed in the ANSI X12.58 version 2 standard document (Appendix) issued by the Data Interchange Standards Association (DISA), which is well known in the art and is incorporated herein by reference.

Users can also be restricted to signing only certain types of documents, such as ordinary correspondence, purchase orders, specific EDI transaction types, commercial contracts, specific financial instruments, etc., as defined in industry policies. It might also be desirable, for efficiency reasons, to exclude certain general classes of transactions and documents. Referring to FIGURE 8, the receiver imposes the document type restriction on the sender's transaction 801, first verifying the sender's signature 803 in the transaction, then verifying the document type attribute value 802 within transaction 801 to impose the document type restriction 805 included in the sender's authorization certificate 804. The receiver then verifies the authorization certificate (804) using the sponsor's public key (811) to verify the sponsor's signature (809). If either signature or attribute constraint is not verified, the transaction is rejected (810).

It is also desirable to add positive or negative restrictions related to the subject matter or context of the transaction. For example, to restrict an agent so that they can only sign purchase orders for a certain type of merchandise (such as office supplies), or to deny authority, for example, by prohibiting an agent from purchasing pornographic material. Restrictions on specific matters are imposed by the recipient of the transaction in the same way as restrictions on document type, and may be implicit in many document types but nevertheless require a separate specification for more generic document types.

An organization may indicate that there are specific authorized signatories, meaning that only specific individuals can sign on behalf of the organization, similar to a normal corporate resolution for this purpose.

This could complement the document type concept as an additional control for signing corporate documents. This restriction can be implemented by specifying that a joint signature is required, in which the title of the joint signatory (in their distinctive name) must match one appearing on a specific list contained in a certificate of authorization. This is instead of naming a list of one or more required joint signatories.

Geographic and temporal controls include locations and time periods within which transactions are considered valid. The use of a reliable local date-certifying notary is assumed. This notary would add a reliable date and time stamp to the signature of the person who originated the document and then sign the resulting document.

In this way, time-of-day and day-of-week restrictions will typically coincide with the user's company's business week. Additionally, location information would be associated with the notary to restrict access to a specific network segment, typically the user's assigned work area. The granularity of location controls would depend on the network architecture. The signer or the signer's computer system must add a certified date and time stamp from a specific local server to the transaction, otherwise the verifier cannot accept the transaction and the signer's sponsor will not be bound by it. As shown in FIGURE 9, the sender adds an authorization certificate (902) to transaction 901, as usual, an authorized time-print (903), and a certificate (904) from a date-time server. The receiver verifies (921) the sender's signature (905) in transaction 901 and verifies (922) the sponsor's signature (908) in the authorization certificate (902). Then the₁₅ receiver (1) verifies 923 that the unusable print date time and transaction text information 909 matches the result of the transaction text 901 shredded with a known shredding function, (2) verifies 924 that the time and date 910 of the transaction print date and time 903 fall within the authorized attribute values ​​906 for the date and time, as specified in the authorization certificate 902, (3) verify the date/time server's signature on the date/time printout, and (4) verify the sponsor's signature on the date/time server's certificate. If all these conditions are met, the transaction

<td>931 is accepted!</td><td>Yeah</td><td>not the transaction</td><td>HE</td><td>rejects 930.</td><td></td>

<td>Besides,</td><td>a</td><td>document may</td><td>No</td><td>to be valid</td><td>unless</td>

<td>that the firm</td><td>HE</td><td>check within</td><td>of</td><td>a period of</td><td>time</td>

<td colspan="2">specific. For</td><td>transactions</td><td colspan="2">This is very valuable</td><td>period</td>

<td>attribution</td><td>of</td><td colspan="3">The age of the firm can be very</td><td>short,</td>

Whereas for more typical transactions, especially those sent through store-and-forward systems such as x.400, a longer time interval (such as two days) may be appropriate. Figure 10 shows how a verifier imposes the signature-age attribute value. The verification date and time would be provided using a 103 receipt signed by a trusted 104 date and time server and containing, at a minimum, the recipient's name and the signature of the original transaction. The verifier must provide a copy with the date and time stamp of the original signature, which is dated shortly after the date and time of the original transaction; otherwise, the sponsor will reject it. As shown in FIGURE 10, the receiver (verifier) ​​verifies the sender's signature in transaction 101 and the sponsor's signature in the authorization certificate. The receiver then verifies that the difference between the date and time in transaction 101, and the date and time in transaction 111, is correct.

112 The date and time printout 103 is located within the attributive restriction 108 regarding the age of the signature required in the authorization certificate 102. The receiver also verifies that the useless information 110 of transaction 101 within the reliable date and time printout 103 matches the text of transaction 101. If all these conditions are met, the transaction is accepted; otherwise, the transaction is rejected. 131. A similar concept is that of the minimum age of a signature. In this case, the signature would not be valid until a minimum amount of time has elapsed since it was signed. This allows for the reporting of a lost smart card and for a revocation notification to be sent to the recipient. The control attribute can specify a maximum/minimum age for the signature.

A pre-approved counterparty attribution value restricts an entity to dealing only with a specific set of known, trusted partners. This is a common requirement in telephone banking systems, which typically require all authorized beneficiaries to be specified in advance. Another way to say this is that free-form transfers are prohibited. Sponsors realize that, in the event of an error, they have a better chance of successfully reversing it if they deal with a large, solvent, and reputable party than if they deal with a small, unknown, and unauthorized one. Separate certificates can be issued for each counterparty to prevent a competitor from obtaining the user's customer list (excluding themselves) on a single certificate. The approved counterparty can be encoded as a common name, a distinctive name, a certificate number, or as the unusable information value of either the distinctive name or the public key of the counterparty. To claim the benefit of the transaction, the verifier must accept a certificate that matches the encoded counterparty value.

Figure 11 shows the user sponsor's verification of the user's transaction, 15 after it has been received by a receiver. The receiver (counterparty) verifies 1110 the user's signature 1103 on transaction 1101, and verifies 1105 the sponsor's signature 1105 on the user's authorization certificate 1102. If either of these signatures is not verified, transaction 1101 is rejected 1112. If the signatures are verified and the transaction is accepted 1113 by the receiver, the receiver endorses the transaction 1101 by issuing its verified transaction notice 1114 by countersigning 1116 the text 1106 of the user's original transaction 1101 and the sender's signature 25 1103 with the receiver's certificate 1115 attached. By imposing the previously approved counterparty restriction on the sender user's authorization certificate 1102, the sender user's sponsor verifies 1121 the sender user's signature 1103, as included in the receiver's verified transaction 1114, and verifies 1122 the receiver's signature 1116 therein. If these signatures are verified, The sponsor then verifies 1123 the worthless information value of the counterparty's public key by mincing the receiver's public key 1117 and comparing the result with one of the worthless information values ​​1104 of the authorized counterparty's public key as specified in the user's authorization certificate 1102 (the receiver's public key 1117 that the sponsor minces for verification is itself verified 1124 when the (Sponsor verifies the recipient's certificate). If these conditions are met, the transaction is accepted 1125.

The attribute values ​​of delegation controls can limit the types and value ranges of authorizations that a CA can specify when issuing an attribute certificate. They can also limit the scope and depth to which a user can delegate their signing authority to others. For example, a root CA can restrict an organizational CA to issuing authorizations that only allow its end users to sign documents within a range of documents related to state tax administration. Or, a CA can grant a user certain authority with the stipulation that it can only be delegated to another person at the level of deputy treasurer or higher for a period not exceeding 30 days and without the right to further subdelegate.

Another authorization attribute called a confirm-a requirement prevents the signature from being valid unless the verifier sends a copy of the verified transaction to a third party, typically the organizational sponsor or the user's work supervisor, at a specified mail or network address, and either (a) receives an acceptance/rejection message, or (b) a specified amount of time elapses. This requirement is similar to joint signature but occurs after the transaction has been submitted rather than before. Such post-transaction confirmation may be acceptable in low-risk situations where few transactions would be rejected and obtaining the third party's joint signature in advance would be excessively complicated. Alternatively, it may be preferred in high-value cases where positive online confirmation is required. In this case, the flow pattern reverses back to an online system instead of an offline system. As shown in the FIGURE

12, first the receiver, as is customary, verifies 1211 the sender's signature 1203 on transaction 1201, and verifies 1212 the sponsor's signature 1205 on the user's authorization certificate 1202; if either of these signatures is not verified, transaction 1201 is rejected 1213. If the signatures are verified, the receiver sends 1214 a confirmation message consisting of the original transaction 1201 (the transaction text 1202 and the sender's signature 1203) to the user's sponsor 1215, as specified 1204 in the sender's authorization certificate 1202. The receiver must receive from sponsor 1215 the same return message as confirmation 1216, but signed 1205 by the sponsor. The receiver then verifies 1217 the sponsor's signature 1220 and the confirmation message 1216, and accepts 1219 the transaction 1201.

To create complex combinations of restrictions, a filter expression—a Boolean or logical expression involving one or more attributes—can be used to construct restrictions involving multiple attributes. Attribute assertions are linked with the usual Boolean connectives: AND, OR, and NOT. For example, the sponsor can restrict a user to submit a transaction of type AND purchase order with a value less than $100,000. The assertions can involve either a single attribute value (equal to, less than, greater than, etc.), multiple values ​​for an attribute (subordinate set, upper set, etc.), or the presence or absence of a document attribute. It will naturally be apparent that any of the constraints described, as well as others, can be active simultaneously for the same document or transaction. These restrictions were discussed and illustrated separately for clarity.

The use of authorization attributes allows a receiver to verify both authorization and authentication. In such a frame, the sponsor's certificates, secured by the sponsoring organization's certificate, would be interpreted as authorizing the transaction to which they apply, assuming all specified restrictions are met.

It is necessary to define a set of basic policies to be used throughout the financial services industry and in other industries in order to provide a well-defined and predictable level of service for the verification process. These policies would be approved multilaterally by each participating company and may stipulate that certain restrictions and authorizations discussed in this section would be considered as always in effect unless expressly revoked. One of the most important elements of these industry agreements would be the definition and coding of document types. This has to be done industry by industry, since it is obvious that the rules will be very different, for example, for customs inspectors, airline inspectors, auditors, tax officers, etc.

Certain authorization attributes may be related to the specific content of the document itself. This can cause problems for automated machine verification, since the verifier's computer may not always be able to determine the values ​​of such attributes for a given document or transaction. Examples include transaction monetary limits, document types, and security or confidentiality labels. Therefore, it is desirable to provide a standard data block, preferably at the beginning of the document or transaction, that clearly encodes the attribute, for example, the monetary value of the transaction, the document type, or the security sensitivity label. This document label will be added by the signer's computer for the verifier's convenience and to aid in the verification process. However, in the event of a conflict between the label and the actual document content, the document's language would prevail. For structured transactions, such as EDI transactions, where document types and monetary values ​​are already fully machine-readable, document labels would not be necessary.

As a possible convenience for processing simple authorizations, especially where a given user signs many similar transactions, it would often be useful to copy the user's public key from their basic authentication certificate and include it as another attribute of the authorization certificate. This allows the authorization certificate to serve both purposes (authentication and authorization), and allows the sender to omit the basic authentication certificate from each transaction. Additionally, when a device is relied upon to satisfy a given condition, it might also be advantageous to copy the user's device public key into the authentication or authorization certificate, thus eliminating the need to send the device certificate with each transaction. Third-Party Interactions

Other additional useful features of digital signatures, apart from those that can be provided using attribute certificates, involve interaction between a signer and third parties of various types.

One use for digital signatures is electronic notarization. As discussed above, there will be a need to notarize documents using a trusted third party to provide an accurate date, time, and/or location. Simply relying on the originators of the signatures to provide this information accurately makes the signatures vulnerable to fraud based, for example, on the pre-dating or post-dating of documents. An electronic notary would be trusted under their CA's policies to accurately provide this information. The multi-signature capability already assumed can be expanded to provide an operational framework for this service.

For notarization purposes, date and time stamp information and location will be included as signature attributes. Individual signature structures can either be detached and stored, or, if desired, sent separately from the document.

Multiple signatures or joint signatures on the document itself can also be distinguished from countersignatures, which are firm in the signature structure within which they are found and not in the document itself; a countersignature thus provides proof of the order in which the signatures were executed. Because a countersignature is itself a signature structure, it can contain countersignatures; this allows for the construction of arbitrarily long chains of countersignatures. Therefore, electronic notarization will consist of countersigning the signature of the person who originated the document and including a date and time stamp within the signed information. For very high risk applications, it might also be desirable to require multiple signatures on each certificate from one or more CAs, with the signatures running in separate cryptographic facilities and with different private keys.

Several service levels can be defined for 15 electronic notaries based on the level of data verification carried out before signing (ranging from the simple existence of the document, in which case notarization can be completely automatic, to human verification of the document content) and based on 20 the data retention and auditing capacity.

Another use for digital signatures is to delegate general power of attorney certificates. Because users are often tempted to entrust their devices or smart cards to others, such as secretaries or colleagues, when they go on vacation, the frequent situation in which one user obtains another user's smart card and PIN exposes the smart card to potential misuse. The system therefore facilitates the issuance of general power of attorney certificates, which allow a delegate to associate their own smart card signature with the authority of the delegating user. The general power of attorney certificate will include, at a minimum, the name of the delegating individual, the delegate's public key certificate identification, a short validity period, and will be signed by the delegating individual. Another possibility is for the delegate to create a new key pair to be used exclusively with the signature of the person delegating, including the new public key in the general proxy certificate. This would eliminate any potential confusion between the delegate's use of the private key on behalf of the person delegating and its use on their own behalf.

The problem of sharing nano smart cards can be greatly reduced by providing a functional alternative that preserves the principle of individual accountability. Large-scale implementation of this feature would make it practical to prohibit smart card lending, which is a highly desirable goal.

The use of delegation certificates discussed above 25 implies that the user is acting as a CA.

In some cases, particularly those where the transaction crosses organizational boundaries, there may be concerns that the level of controls and auditing available with the individual user's cryptographic device (e.g., a smart card) is insufficient. In such cases, delegation certificates could be issued by a CA as standard authorization certificates, at the request of the delegator. This also allows delegation certificates to be revoked using the standard CRL mechanism. User certificates can then specify a list of potential delegates, and the delegation certificate itself will contain an attribute naming the person delegating.

When exercising general power of attorney, a user can indicate that they are signing on behalf of another user by including the signature attribute "signing-on-the-respect-of" in the document or transaction. This attribute specifies the name of the user for whom the document is being signed. A valid delegation certificate must exist authorizing the signer to act on behalf of the user for whom they are signing. Delegation is also useful in connection with a cryptographic module on the user's personal computer. The process of extracting and signing a document should ideally be a single operation to prevent the replacement of useless or false information by cutting out programming elements. However, a typical smart card lacks the computing power to randomly extract a very long document. One solution is to have the smart card delegate this function to the cryptographic module using a very short-lived delegation certificate, valid for only a few minutes. This certificate is signed by the user's smart card and indicates that the smart card user has authorized the delegation. See, for example: Gasser, M., A. Goldstein, C. Kaufman, and B. Lampson, The Digital Distributed System Security Architecture, Proceedings of the 12th. National Conference on Computer Security, 1989; Gasser, M. and E. McDermott, An Architecture for Practical Delegation in a Distributed System, Proceedings of the 1990 IEEE Symposium on Security and Privacy.

Public Key Not-Public

However, a more fundamental problem is ensuring that all potential recipients will actually use the certificate and attribute verification methods described above. Even though these methods allow sponsoring organizations to protect themselves, and their users and those with whom they transact, from liability based on fraudulent transactions by allowing them to verify the identity and qualifications of those with whom they transact, and the characteristics of the transactions before they are carried out, there is no guarantee that all recipients will actually verify in this way. If a receiver acts on a transaction without first verifying the attributes of both the sender and the transaction, and if it is subsequently found that the sender sent a fraudulent or unauthorized transaction, the receiver may then claim liability from the sender or their sponsor by alleging that the receiver was unaware of any requirement that mandated the verification of the user's basic signature authorization. One way to ensure that sponsors and other entities are protected from liability in such a situation is to require the signatory to include the random shredding value of each of their identity and authority certificates as attributes within their signature. This can prevent a verifier from claiming that they were unaware of such certificates and the restrictions they impose; however, the signatory may (intentionally or unintentionally) omit to do this. Another more emphatic way to ensure that the verifier complies is to prevent the distribution to a user (or to a user's device or smart card) of the root key, the public key of the final authority, that is, the highest-level certification authority whose key potential certifiers will need to be able to verify any part of a transaction. Unless the user enters into a contract with the cryptographic system and agrees to verify all parties and all transactions according to pre-established rules, users are not technically forced to verify every aspect of their transactions. However, failing to fully verify transactions would violate the contract between users and the cryptographic system, thereby absolving all other parties involved in the system—for example, a sponsor whose employee acted without authority—of liability. The recipient who failed to verify would then bear all the risks associated with that unverified transaction. Furthermore, because the system's root authority key is considered a trade secret, no one who has not signed the system's rules agreement can possess a copy of it, and no one can claim to have verified any part of the transaction. This would make it much more difficult for an external verifier to claim that they incurred a loss by "reasonably" relying on the transaction, even if it was indeed valid. This method of maintaining the system's root key as a trade secret lends particular strength and effectiveness to all the restriction and authorization methods described herein. We believe that the possibility of incurring potentially high liabilities in valuable transactions will persuade users to employ the five-attribute verification methods in accordance with this invention.

Restrictions on the distribution of Certificates

Users and organizations need the ability to restrict the distribution of all types of certificates for a number of reasons. First.

Certificates often contain confidential business information that the user or organization would prefer not to share with others, but which is nevertheless shared with the verifier through the certificate, even if only for the limited purpose of verifying the signature. Furthermore, the user's basic privacy rights can be violated if their public keys and network addresses are published. For example, they may be bombarded with unsolicited business proposals and advertising once their public keys are compromised.

2Q have disseminated. In addition, the organization may have a general policy that opposes distributing user IDs and public keys, as these could be used as entry points for various types of security attacks.

This functionality can be implemented as an attribute in the user certificate. If the Distribution-restriction attribute is TRUE, the user/issuer grants permission to use the certificate (which can be an authority or public key certificate) only for signature verification; further distribution or publication is prohibited. Other ways to specify this restriction may include placing the attribute in the organization's certificate, publishing the restriction as part of the industry-specific policy, or (in a true X.500 implementation) using the X.500 access control list mechanism to restrict access to the certificate. Even if a general legal basis for imposing this restriction could be found in copyright law, i.e., if the certificate is declared as an unpublished work for which a license is granted only to the named verifier, a stronger legal basis would always be desirable.

Smart Card Requirements

There are some additional requirements for smart cards when used with commercial digital signature systems.

The first requirement is private key confinement and self-certification. In other words, the user's private signing key must never be able to leave the smart card.

In other words, the user's private key signature must never be allowed to leave the smart card. Only in this way can it be guaranteed that the key cannot be stolen by purely electronic means, leaving no trace. This principle of private key confinement is vital to the concept of non-repudiation.

Thus, as illustrated in FIGURE 13, when a public key 1303 is provided for certification, the card 1301 must attest that the card 1301 is tamper-proof and has a key confinement design. This proof can be provided by means of a device certificate 1302 that declares the card originates from a manufacturer or product line.¹⁵ specific products. Therefore, the device's public key 1308 (1301) must be certified by the manufacturer or the manufacturer's designated CA. One possible approach to creating this device certificate would be to generate the device key pair during smart card manufacturing, so that the corresponding device certificate 1302 can also be included on the card. The device certificate 1302 certifies the card's properties 1304, and the card generates a key pair 1303, 1309 which the card user must use, and which the user can have certified as their property by any appropriate CA they wish. Then, when a newly generated public key 1303 is submitted for certification, the device's private signature key 1305 will be used to countersign 1306 the data 1307 of the Certification request, which has already been signed by the user's newly generated private key 1309.

Also, if the government requires that all 10 decryption keys be deposited in a sealed envelope, the card should be able to certify that it cannot be decrypted. This signature certification can only be implemented through the same mechanism described above, thus allowing the user's signature key to be exempt from sealed envelope deposit requirements. Since it is doubtful whether a key deposited in a sealed envelope retains any value for non-rejection services, this certification is vital to prevent the discovery of the signature key due to²⁰ possible mishandling during the sealed deposit process.

Smart cards must also be required to protect against the unauthorized use of personal identification numbers (PINs). Typically, a smart card is protected against unauthorized use by a PIN, which is equivalent to a password. Typically, a PIN can only be modified by the user, and must have a certain length, but also, typically nothing can prevent the user from setting a trivial number 5 for the PIN, for example just ones or 121212.

Smart card vendors should be required to implement PIN modification routines that ensure non-trivial PINs without repeating digits or obvious patterns. Making the PIN relatively long (when 2Q minus 6 digits) and non-trivial reduces the possibility of the card being manipulated by someone who finds or steals it. Support for the requirement of a 6-digit PIN can be found in X9.26: Financial Institution SignOn Authentication for Wholesale Financial Transactions.₁₅ ANSI, 1990, which is well known in the art and for this reason is incorporated by reference in the present descriptive memorandum, and which sets forth the one-in-a-million standard stating that an internal hosting mechanism can be considered secure if, among other things, an attacker does not 20^has There is a greater than one-in-a-million chance of guessing the correct password, and the system must take preventative measures to avoid repeated guessing attempts. Furthermore, smart cards should be required to take preventative measures, such as blocking access for a period of time or even deleting private keys, if too many incorrect PINs are entered by an unauthorized user.

It could also be established as a requirement that smart card manufacturers use biometrics as more secure identification methods. Extensive research is currently underway in the fields of voice and digital identification as a supplement to PINs. However, even though false positive and false negative rates still need to be reduced, the main problem lies in securing the biometric input device and its data channel so that they are immune to the capture and reproduction of biometric data. This isn't a problem when the biometric device is embedded in a concrete wall, for example in an ATM or door access system, but it remains a problem in typical commercial office environments. Ideally, both the card and the biometric device would each be tamper-proof cryptographic modules that can self-certify and establish secure channels between them.

Smart cards should also be able to maintain an audit trail or internal log of recent actions, containing at least a date and time stamp, the transaction amount, the character code, and the message digest. This information can be compressed to occupy approximately 40 bytes, so a circular log of 400 entries would consume approximately 16 KB. This record will only be uploaded and verified if a signed request is received from the card issuer through a secure channel. Furthermore, the card will not delete the previous record until it receives a signed confirmation from the issuer, stating that the uploaded record was received intact. This control mechanism will curb counterfeiting, reduce the damage a counterfeiter can cause, and allow any unauthorized or questionable transactions to be investigated more quickly and easily. Since most transactions occur offline from the issuer, the cardholder is the best witness to their own actions.

Control of Access to the Root Certification Authority Public Key, and Cost Recovery

As shown in FIGURE 3, in a particular cryptographic system there may exist a hierarchy of₂₀ Certification authorities (31-33) that issue certificates 34, 35. In a larger system, the number of certification authorities and the depth of the hierarchy would be much greater. In the structure shown in FIGURE 3, certification authority A (31) is the root certification authority, with all other certification authorities below it. As explained in the description of FIGURE 3, the public key of certification authority A is well known. In a system where certificate authority A accepts responsibility for any transactions in the system based on information in certificates issued by A, it would be useful and desirable for certificate authority A (since it is the root certificate authority) to control access to its public key. By doing so, certificate authority A could enforce rules in the system that would ensure the integrity of the system structure. Several methods for controlling access to a certification authority's public key are now described.

Referring to FIGURE 14, in a cryptographic system, the certificate authority (CA) 1402 issues 15 user identity certificates 1404 to users (for example, user 1438) of the cryptographic system. The certificate authority 1402 has a private key 1406 and a public key 1408. The private key 1406 is used to digitally sign the certificates 1404 with the certificate authority's digital signature 1410. The 1402 certification authority can be any certification authority in a hierarchy of certification authorities, such as, for example, the one shown in Figure 3.

The 1402 certification authority determines information about system users and, based on this information, issues 1404 certificates to those users. A 1404 certificate issued by a 1402 certification authority to a 1438 user contains 1410 information about the user, including the 1412 user's public key and 1414 information about the certification authority's policy regarding that user. In order for other users of the system to verify the information contained in the 1404 certificates, these other users must have access to the 1408 public key of the 1402 certification authority.

Indeed, 1404 certificates issued by certification authorities are used by system users to identify themselves to other system users, in order to facilitate transactions within the system. A receiver (a system user) who receives a 1440 transaction from another 1438 system user, where the transaction is accompanied by a 1404 certificate issued by certification authority 1402, can trust the information in the 1404 certificate, essentially because the certification authority 1402 that issued the 1404 certificate is responsible for the information contained in the certificate. and accepts responsibility for certain transactions that depend on the information in the certificate, if the certificate 1404 includes information 1414 about the certification authority's policies, this responsibility is only accepted by the certification authority 1402 if the recipient had a valid copy of the certification authority's public key 1406, and if the recipient followed the policy 1414 described in the certificate 1404.

Thus, for example, suppose that after successfully verifying the identity of user A (1438), the certification authority 1402 issues a certificate 1404 to user A (1438). The certificate includes the public key 1416 of user A (1438), a policy 1414 of certification authority 1402 with respect to user A, and is digitally signed by certification authority 1402. Suppose, for example, that certificate policy 1414 specifies that user A only has access to transactions on business days, from nine in the morning to five in the afternoon. A receiver 1424 of a transaction 1440 made by user A 1438 and certificate 1404, can make the transaction with the certainty that the certification authority 1402 will accept responsibility for the transaction if (a) the receiver verified policy 1414 for the transaction, i.e., if the receiver verified that the transaction is carried out within the allowed time limits, and (b) if the receiver had a valid copy of the public key 1408 of the certifying authority 1402. In other words, if the receiver does not compare the transaction with respect to the policy, then the transaction will be invalid. Furthermore, even if a receiver confronts user A's transaction, and it turns out that the transaction is permitted by the certification authority with respect to user A (as specified in the certificate), the certification authority 1402 is not responsible for the transaction if the receiver did not have possession of a valid copy of the certification authority's public key 1408.

The cryptographic system also includes several sponsors (1418), who also issue certificates to users. These certificates issued by sponsors are also known as authorization certificates (1420). These certificates serve, among other things, to specify the rules or policies (1422) of the sponsor that issued them. These 1420 authorization certificates can be separate and different from the 1404 identity certificates issued by the certification authorities (even though the identity certificates may contain certification authority policy requirements). A user can only have one 1404 identity certificate issued by a 1402 certification authority. However, a user may have numerous 1420 authorization certificates, issued by one or more sponsors.

1419.

When a receiver receives a transaction from another user in the system, the receiver should also verify all sponsor policies included in the authorization certificates accompanying that user's transaction. In this way, in this cryptographic system, users are required to enforce the rules (policies) of the certification authorities and system sponsors.

As mentioned previously, in order for the information contained in the various certificates to be verified by system users, these users need to have access to the public key 1408 of the certification authority 1402 or sponsor 1418, who issued the various certificates. To enforce the rules of each certification authority and sponsor within the system, it is necessary to restrict access to the public key 1408 of certain certification authorities. Specifically, it is necessary to restrict access to the public key of the highest-level (root) certification authority 1402.

Accordingly, the root certification authority 1402 maintains its public key as a trade secret, and in order to obtain the public key from the root certification authority 1402, a user (potential recipient) 1424 who wishes to 25 carry out transactions on the system, must obtain the certification authority rules 1426, issued by the root certification authority. The receiver 1424 has to shred (make an arbitrary selection of elements) these rules, to form partial (shredded) rules 1428, which it must then digitally sign to produce a signed copy of the partial (shredded) rules 1430. This digitally signed copy of the partial rules must be returned to the root certification authority 1402. Through these actions, the recipient 1424 agrees to abide by the rules of the root certification authority 1402 that it has just signed. The root certification authority 1402 may also require the recipient 1424 to obtain, sign, and return rules from other certification authorities in the system, as well as from sponsors in the system. For example, receiver 1424 may be required to obtain rules 1432 from sponsor 1418, and return a signed copy of these rules 1434 to sponsor 1418.

q Once the root certification authority 1402 is satisfied that it has received a valid copy of the system rules signed by the recipient 1424, the root certification authority 1402 issues its public key 1408 to the recipient 1424.

The public key 1424 of the certification authority can be issued to a recipient in several ways. In the preferred methods, the recipient is provided with a security device 1436, for example, a smart card. In a preferred mode, the certifying authority's public key 1408 is immediately available on the security device, so that by the time receiver 1424 obtains the device, it possesses the root certifying authority's public key 1408. In another preferred mode, the public key 1408 of the certification authority is located within the device 1436 in a disabled form, and the root certification authority 1402 enables key 1408 on the device after receiving and verifying the signed rules 1430.

In some cases, it is useful for the public key 1406 on the root certificate authority's device 1436 to expire or become inaccessible after a certain period. In these cases, for the root certificate authority to reactivate key 1406, the recipient needs to obtain, sign, and return the root certificate authority's rules 1402 again. These rules may differ from the rules previously signed.

Different certification authorities, including the root authority, may also require potential recipients to meet other conditions before granting them access to those certification authorities' public keys. However, the system rules include an agreement to keep these keys secret by anyone who signs the rules.

Cost Recovery

The rules may also include an agreement to pay for system usage. Thus, when a user obtains a valid key (by agreeing to follow the system's root CA rules), these rules may impose an agreement to comply with the system's payment schedule.

A cryptographic system can link system operation to associated payments made by system users for transactions they conduct or accept. Payment for a transaction can be made, for example, through a prepaid account, an acceptance of charges to the user's account, or a concurrent digital cash payment to various parties within the system. For example, a particular operation, such as digitally signing a transaction, may cost the user a certain amount that must be paid to the certification authority that issued the certificate guaranteeing the identity of that user.

Some digital payment functions can be built into the devices that hold the public keys. Since users' private keys are typically kept within security devices (e.g., smart cards), these security devices can be used to maintain an up-to-date digital balance for each user. This digital balance can be a debit or credit amount. Each time a user digitally signs a transaction using their security device, a certain amount is deducted from the user's digital balance. If the security device is a debit device, then when the user's digital balance reaches zero, the device would be disabled and could no longer sign for the user. The user would then have to obtain additional digital credit from a certificate authority or some other sponsor in the system. If, on the other hand, the security device is a credit device, then the user could be required to make a payment transaction to the certifying authority at certain regular intervals, for example, daily, weekly.

2q or monthly. Since the digital credit amount is available through the security device, the certifying authority can be assured that the transaction is for the correct amount. A user who does not make the required payment transaction would be listed in a CRL as suspended or revoked, and would no longer be able to transact in the system.

Digital payment on a pay-per-transaction basis is also achieved using a confirm transaction. The user's authorization certificate lists the recipient's address, which must be confirmed. Once the transaction occurs, the recipient is notified and can deduct the payment from the user's account. Pricing Information

Since a user has agreed to pay fees and royalties associated with the system, the user can also be provided with flexible information on pricing and billing.

Pricing policies tailored specifically to the user can be implemented through the use of certificates. Certificates issued by sponsors and certification authorities can include payment and pricing policies for individual users. For example, a certificate may contain a price list for certain transactions (which includes, for example, signing using a particular private key, verifying using a particular public key, or confronting the revocation status of a particular certificate), a discount rate for particular users, a discount rate for transactions with certain recipients, and fees for wholesale transactions. Some charges or billing are made by iOS user security devices, while other events that cause charges or billing may result from actions made by the recipients of the transactions.

To implement certain pricing policies, a certificate may contain several digital fields. For some policies, these fields include a revocation service address, a revocation service fee, and a transaction confirmation fee. The revocation service address is similar to the confirm-to address, but it is used solely to verify the validity of certificates. In other words, the revocation service searches for transactions that were attempted using certificates that had been revoked. The revocation service fee is the charge for this service.

Examples of these fields are:

(a) Private key signing fee = $0.50 (b) Public key verification fee = $0.50 (c) Revocation service address = rev-check@btec.com (d) Revocation service fee = $0.50 (e) Confirmation service fee = $0.50

All fees can be set as flat fees or as fees based on the basic transaction amount. For example, a fee might be specified as $0.50 or as $0.50 for every $1,000 of basic transaction amount.

Given the preceding examples, a receiver that receives a transaction can send the associated certificates to the revocation service address and would be billed at the rate specified by the service fee.

To bill a confirmation transaction, a certificate may also contain a transaction confirmation fee, such as,

Transaction confirmation fee = ($0.50 per $1000 of transaction amount)

In this case, each confirmed transaction would cost the recipient the appropriate fee.

Occasionally, a recipient might receive a transaction that is too expensive and therefore reject it. Accordingly, a digital field is also included indicating authorization to bill the sender, and this field is signed by the sender. This field could include the sender's account number and other information, such as a maximum acceptable billing rate, etc. This "billing-to-sender" field would appear as an attribute in the sender's signature block.

Granting of Intellectual Property Licenses

The rules may also include an agreement to pay for all intellectual property used by a user. For example, a system might offer a user transactions, services, algorithms, copyrighted materials, and similar proprietary content. To obtain a public key that grants access to this intellectual property, the user must sign the user rules, agreeing to pay for its use.

For example, in one mode, the security device contains many non-activated services (for which payment is required). Each use of one of these services requires payment in the form of, for example, digital cash, either through an internal transaction on the device or through a transaction with another user of the system. To obtain the device, the user must digitally sign a set of rules (using a private key on the device that is unique to the device and therefore also to the user). By signing these rules, the user agrees to make payments as required.

Policies and Rules Imposed by the Signatory

A user of a cryptographic system may have an identification certificate (issued by a CA) and one or more authorization certificates (issued by CAs or sponsors of that user). Each of these certificates contains policies of the issuing party, and the recipient of a transaction involving any of these certificates should verify that the transaction complies with all the rules specified in the certificate. However, it's possible that for a particular transaction, a user might want more restrictive rules applied than those permitted by the certificates. For example, a user might be allowed to approve all transactions of $1 million or less, but would prefer to approve a certain transaction only if its value is less than $1,000. Alternatively, a user may be authorized to approve certain transactions alone, but for a specific transaction, the user may require one or more joint signatories. In support of this feature, the cryptographic system, in accordance with the following invention, provides users with the ability to add user rules, attributes, and restrictions to transactions.

User rules cannot allow transactions to be approved that would otherwise be prohibited. Therefore, the recipient must always apply the most restrictive rules to each transaction. For example, if a user certificate allows transactions up to $1,000, and the user rules specify transactions up to $1 million, the $1,000 limit must be applied. This can be achieved, for example, if the receiver first applies all the rules in the certificate and then, if the transaction is still valid, applies all the user rules. Applying the user rules first and then the certificate rules will also produce a correct result. However, because Boolean combinations of rules and constraints are supported, interleaving user and certificate rules can produce an incorrect result if care is not taken.

Figure 15 shows the verification of a user transaction that includes user-supplied rules. A user transaction 1502 includes a transaction text 1506, which describes the transaction to be performed by a receiver. The user adds to the transaction text 1506 a set of user-supplied rules 1504, which the user wants to be verified by any receiver of transaction 1502. Next, the user digitally signs the combination of transaction text 1506 and rules 1504 to form transaction 1502, forming a user signature 1510 that is added to the transaction.

The transaction 1506 is then sent, along with any required sponsor/CA certificates (for example, the CA certificate 1508 and the sponsor certificate 1509), to a receiver who must then verify the transaction. To do this, the receiver verifies the user's signature 1510 using the user's public key 1514 from the CA certificate 1508. If the user's signature is accepted, the verification continues; otherwise, the transaction is rejected (1514). If the verification continues, the receiver verifies (1516) the CA's signature (1518) using the CA's public key (1520). If the CA's signature is accepted, the verification (15) continues (1522) by comparing the rules in all certificates and those supplied by the user, including the sponsor's certificate (1509). Otherwise, the transaction is rejected 1514. If verification continues, the receiver verifies 1522 the transaction against 2Q the rules in the CA certificate 1508, in the sponsor certificate 1509 (and in any other certificates that are associated with this transaction). If any of these rules are not satisfied, the transaction is rejected 1514; otherwise, the verification of the₂₅ The transaction continues with verification against the rules 1504 supplied by the user. Only if the transaction satisfies the rules 1504 provided by the user is it accepted 1526; otherwise, it is rejected 1514.

The user-provided 1504 rules can be any combination of rules known to the system and include, but are not limited to, joint signature requirements, time limits, transaction amount limits, confirmation-a requirements, and the like.

In some environments, users can create rule sets or override rules themselves for use with particular types of users or transactions. These rule sets or overrides can be automatically added to all transactions of those user or transaction types. For example, a user who is a bank manager may determine (based on experience) that for all transactions carried out by new tellers and co-signed by her, she will apply stricter rules than those required by the bank. She will then

2Q would store these rules in its system as a breach for those types of transactions that it signs or countersigns.

A person skilled in the art will appreciate that the present invention is typically practiced using electronic devices, such as digital electronic computers and the like, and that certificates, transactions, messages, signatures and the like are electronic digital signals generated by the electronic devices and transmitted between the electronic devices.

This provides a method for securely using digital signatures in a commercial cryptographic system. A person skilled in the art will appreciate that the present invention can be implemented by means other than those described, which are presented for illustrative purposes only and not to limit its scope, and the present invention is limited only by the following claims.

It is hereby stated that, as of this date, the best method known to the applicant for carrying out the aforementioned invention is the one that is clear from the present description of the invention.

Having described the invention as above, it is claimed as