JP2012053918A - System and method for providing certificate validation and other services - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system and method for facilitating electronic commerce by securely providing certificate-related and others services including certificate validation and warranty.SOLUTION: Services are provided in a four-corner trust model. The four-corner model comprises a buyer (106), or subscribing customer, and a seller (108), or relying customer, who engage in an on-line transaction. The buyer is a customer of a first financial institution (102), or issuing participant. The issuing participant is a certificate authority which issues a hardware key and related private key and a signed digital certificate. The seller is a customer of a second financial institution (104), or relying participant. The relying participant is also a certificate authority which issues a hardware key and related private key and a signed digital certificate.

Description

(Description of related applications)
The present invention relates to US Provisional Patent Application No. 60 / 153,726, filed September 13, 1999, “Transaction Coordinator for Certificate Status and Other Services”, US Provisional Patent Application No. 60/153, filed September 13, 1999. No. 153,724 “Transaction Coordinator Requirements and High Level Design” and US Provisional Patent Application No. 60 / 153,203, filed September 10, 1999, “System and Process for Certification in Electrotechnical Rights” The disclosures of which are incorporated herein by reference.

  The present invention relates generally to the technical field of facilitating electronic commerce by providing services over a public key infrastructure.

In the world of electronic commerce, new attempts have been made to prove the relationship between contracting parties. These attempts are made because the parties cannot face each other or hear about the transaction, or cannot easily verify each other's identity or transaction authority.
One solution to this problem is to give each contracting party a private key to sign outgoing messages. The signing party can use the associated public key to decrypt the message that signed the party's private key so that the receiving party can verify the identity of the sender.

However, the sender's public key may not be known a priori by the receiver. In this case, the sender can send the digital certificate issued by the certification authority together with the signed message. A certificate is itself a signed electronic document (signed by a certification authority's private key) that proves that the particular public key is the sender's public key.
Occasionally, the recipient may not be familiar with the certification authority's public key, or the recipient may not know whether the certificate is still valid. In this case, the recipient tries to check the authenticity and validity of the certificate using the entity that performs the trust. One known protocol is the Online Certificate Status Protocol (OCSP) for checking certificate status.

  The present invention discloses systems and methods that facilitate electronic commerce by securely providing certificate-related services and other services, including certificate validation and assurance. In the preferred embodiment, this service is provided within the context of a four corner trust model. The four-corner model includes buyers called subscribing customers and sellers called relying customers who engage in online transactions. The buyer is a customer of the first financial institution called an issuing participant. The issuing party functions as a buyer's certification authority, and issues a hardware token including a private key and a digital certificate signed by the issuing party to the buyer. The seller is a trading partner of a second financial institution called a relying participant. The trusted party acts as a certification authority for the seller and issues a hardware token that includes a private key and a digital certificate signed by the trusted party to the buyer.

  During the transaction, the buyer generates a transaction data hash, signs the hash, and sends the transaction data, signature, and its digital certificate to the seller. Next, the seller can request a system service through communication with a financial institution or a credit-related party.

  In a preferred embodiment, the system service can include a certificate status verification service and a guarantee service. The certificate status verification service enables the credit partner to verify the signature supplier's certificate. With the guarantee service, the credit partner receives a collateral endorsement guarantee that the signature of the signing partner is valid. The detailed message flow for providing these services is set forth in the detailed description below.

  In the preferred embodiment, each participant and root entity is a transaction that combines services and operations with a single transaction that has the characteristics of atomicity, consistency, independence, and durability. Provided to the coordinator (transaction coordinator). The transaction coordinator provides a single, consistent interface for certificate status messages and requests simultaneously with messages and requests related to other services. As a result, the present invention provides the necessary flexibility and enables centralized and consistent acquisition of transaction information related to multiple presentation services for inspection and non-repudiation purposes. Furthermore, the present invention facilitates the integration of additional services and providing those services to business partners.

  The transaction coordinator of the present invention comprises a single interface and facilitates electronic commerce between banks or other financial institutions, or between banks or financial institutions and business partners. In addition, the transaction coordinator provides a single point of entry for a business partner to obtain a certificate verification service, providing further flexibility, providing a single entry point, a warranty service, New business uses such as payment services or certified mail services are added. It is preferably designed to be easily extendable to support the generated additional services.

  The transaction coordinator of the present invention provides analysis, flow control, error handling for the current message infrastructure and serves as a message switch to direct message component procedures for appropriate system services (eg, OCSP response). System, warranty engine, etc.). In addition, the transaction coordinator orders the responses from these services into an integrated response and sends the response to the requesting client.

  In addition, the transaction coordinator of the present invention records billing data relating to certificate verification services or other services in a centralized general manner. All banks and other financial institutions have a requirement for invoicing, so the invoicing data can be extracted and modified to meet the needs of individual financial institutions with a simple write extraction function. .

  Also, with the transaction coordinator of the present invention, banks or other financial institutions can charge each other for different types of transactions as needed. Furthermore, the transaction coordinator of the present invention can incorporate commercial standard software applications and can provide a single electronic signature service for electronically signing and certifying documents.

In addition, the transaction coordinator of the present invention separates all major services, thus facilitating component reuse and simplifying the maintenance and enhancement of these services. The transaction coordinator of the present invention does not require the exchange of online certificate verification functionality, which may make it non-standard, resulting in vendor fixation and execution delays.
The foregoing and other objects, features, and advantages of the present invention can be understood by reference to the following detailed description and accompanying drawings.

It is a block diagram of suitable embodiment of the 4 corner model used by this invention. FIG. 6 is a block diagram illustrating components that are preferably provided for each entity of a four corner model. FIG. 2 is a block diagram of a preferred embodiment of a transaction coordinator. FIG. 5 is a combined block diagram / flow chart illustrating certain aspects of the transaction coordinator in the preferred embodiment. FIG. 4 is a combined block diagram / flow chart illustrating the preferred operation of the signature component of the transaction coordinator. FIG. 5 is a combined block diagram / flow chart illustrating a preferred embodiment of the steps performed by the transaction coordinator when performing certificate status verification. FIG. 5 is a combined block diagram / flow chart illustrating a preferred embodiment of a transaction flow for validating a certificate. FIG. 4 is a combined block / flow chart illustrating a transaction flow for one preferred embodiment of a warranty service. FIG. 4 is a combination block diagram / flow chart of a preferred embodiment of server-side authentication. Fig. 4 is a combination block / flow chart of a preferred embodiment of client-side authentication. It is a combination of a block diagram / flow chart showing message authentication processing. FIG. 5 is a combined block diagram / flow chart of a preferred embodiment of a security-related flow associated with a transaction coordinator component. FIG. 5 is a combined block diagram / flow chart showing the size (estimation) of messages sent and received between system entities in the preferred embodiment. FIG. 3 is a combined block / flow diagram illustrating a transaction flow for an OCSP proxy-centric embodiment of the system.

The present invention relates to a system that facilitates a financial institution to securely perform electronic certificate status verification and other services for business partners. In a preferred embodiment, the system of the present invention uses a corner trust model to provide these services. FIG. 1 illustrates a preferred embodiment of a four corner trust model for use with the present invention.
As shown in FIG. 1, the four-corner model includes a first engine 102 and a second engine 104. The first institution 102 is a related party of this system, and is hereinafter referred to as “issue related party” because it issues a smart card to a business partner. The second institution 104 is a related party of this system, and the business partner trusts the display made by the issuing related business 102 and the business partner of the issuing related business 102, and henceforth referred to as “trusted business partner”. .

  Further, FIG. 1 shows a first customer 106 and a second customer 108. The first business partner 106 and the second business partner 108 are preferably business partners of the issuance related party 102 and the credit related party 104, respectively. The first business partner 106 is referred to as a “signature business partner” because it signs the service provided by the issuing party 102. The second business partner 108 is referred to as a “credit business partner” because it trusts the display made by the issuing business partner 102 and the signature business partner 106.

  Also shown in FIG. 1 is a root entity 110. The root entity 110 is typically an organization that establishes and enforces a common set of operational rules to facilitate electronic commerce and electronic communication. The root entity 110 can be jointly owned by multiple banks and / or other financial institutions that have agreed to follow operational rules. One exemplary embodiment of such a root entity is described in pending US patent application Ser. No. 09 / 502,450 “Method for Certification-Related and Other Services” filed on Feb. 11, 2000. And the disclosure of which is incorporated herein by reference.

  FIG. 2 is a block diagram illustrating components that are preferably provided in an entity of a four corner model. As shown in FIG. 2, each of the participants 102, 104 and the root entity 110 acts as a gateway for sending and receiving messages between all entities related to the services provided by the system, and the transaction coordinator 202. It has. As will be described in more detail below, the transaction coordinator 202 provides a single interface to the online service of the issuing party 102 and the trusted party 104 and the security between the transaction coordinator 202 and other entities in the four corner model. It is equipped with the safety functions for devices necessary for guaranteeing proper electronic communication. One preferred embodiment of the transaction coordinator 202 is described in detail below with reference to FIGS.

  Each of the parties 102, 104 and the trusted party 104 preferably further comprises an OCSP responder 204 and a hardware security module (HSM) 206. Exemplary requirements for the OCSP responder 204 are described below. The HSM 206 signs the message and proves the signature for the message, as will be described below with reference to FIG.

  In addition, each of the parties 102, 104 and the credit party 104 includes an invoicing data database 208 (in the case of the parties 102, 104, connected to the bank invoicing application 210), an open transaction log. 212, an account data database 214, a risk manager 216 (connected to the account data database 214), and a second hardware security module 218, each preferably connected to the transaction coordinator 202. Yes.

  As shown in FIG. 2, it is preferable that the trusted customer 108 further includes a Web server 220 configured to transmit and receive information via the Internet. The credit account 108 preferably further comprises a bank interface 222 for communicating with the credit partner 104, as will be described in detail below. One preferred embodiment of the bank interface 222 (as well as additional components that are preferably located at a credit partner) is described in pending US patent application Ser. for Fiscalizing Access By Sellers to Certificate-Related and Other Services, the disclosure of which is incorporated herein by reference. The trusted customer 108 preferably further comprises a hardware security module 230 for signing and certifying system messages.

As shown in FIG. 2, signature supplier 106 includes a web browser 224 for viewing the Internet and a smart card 226 (and associated reader) for signing digital messages, as described below. Is preferred.
In a preferred embodiment, each system entity has an identity certificate (sometimes called a warranty certificate) and two digital certificates (and associated secrets) that are utility certificates to facilitate authentication. Key). Further, in a preferred embodiment, each transaction coordinator 202 preferably includes its own identity certificate, utility certificate, and associated private key.

  The identity secret key is used to generate an electronic signature requested by the root entity 110 as evidence of the entity's contractual obligations for the contents of the electronic commerce. A certificate chain is necessary to support operations that use this key. As described below, the status of the identity certificate may be obtained by the authenticating entity.

  The utility private key is used to generate an electronic signature that provides additional transaction security. Typically, utility private keys are used to support Secure Sockets Layer (SSL), to sign S / MIME messages, and for other utility applications. An authentication chain is also necessary to support operations that use utility private keys. However, the utility certificate status may not be available to the requester. Throughout this document, the term “certificate” refers to an identity certificate unless otherwise noted.

  In a preferred embodiment, the signature supplier 106's digital certificate and associated private key are provided from the issuing party 102 to the signature supplier. The issuer 102 preferably issues a smart card or other suitable means to the signature supplier 106 that includes at least a private key associated with the signature supplier's identity certificate. If desired, the smart card may also include a signature supplier identity certificate. Preferred specifications for smart cards, their manufacturing methods, and their contents are described in pending US Provisional Application No. 60 / 224,994, “Signing Interface Requirements, Smart Card Compliance Requirements,” filed on August 14, 2000. and Additional Disclosure ", the disclosure of which is incorporated herein by reference.

  FIG. 3 is a block diagram illustrating a preferred embodiment of transaction coordinator 202. As shown in FIG. 3, the transaction coordinator 202 includes an interface 302 having two components: a TC request manager 304 and a transfer service component 306. The interface 302 performs transmission / reception between the plurality of service modules 308 and the core component 310. The service module 308 preferably includes a certificate status verification module 312, a guarantee module 314, a payment guarantee service 316, and other services 318. The core component 310 preferably includes a logging component 320, a billing component 322, and a signature component 324.

  The transfer service component 306 provides a single entry point to the transaction coordinator and serves as a separation layer between the requester, the transaction coordinator service module, and the core components. The TC request manager 304 receives a service request from the transfer service component 306 and forwards it to the appropriate service module and / or core component, as described in detail below.

  The function of the certificate status verification module 312 is to verify the certificate of the entity in the system in FIG. The function of the assurance module 314 is to ensure the identity of the entity that signs the electronic communication associated with a particular business transaction. In the preferred embodiment, the party that is typically the issuing party 102 that makes the guarantee, finds that the signing party 106 did not fulfill the digital signature generated by the private key of the signing party Undertake financial responsibilities for some or all transaction amounts.

  The function of the payment guarantee service 316 is to further reduce the risks associated with the transaction by providing the credit customer 108 with immediate confirmation regarding the ability of the signing customer 106 to fulfill the financial obligation. Further, the issuer 102 may issue a payment guarantee for some or all of the transaction amount if the signing customer 106 is delinquent to the credit customer 108 for any reason. The payment service may also be performed as described in pending US patent application Ser. No. 09 / 657,622, “System and Method for Providing Payment Services in Electronic Commerce” filed on the same day as this application. This disclosure is often incorporated herein by reference.

  The function of the certified mail service 318 supports offline transactions. An offline transaction occurs when the receiving entity places a request in a processing queue instead of serving the request immediately. Typically, a receipt confirmation notification is sent to the requester. This scenario is preferably performed when the transaction volume is very high and an online response cannot be made for every request. The certified mail service 318 is used to satisfy requests between the trusted customer 108 and the trusted party 104, between the trusted party 104 and the issuing party 102, and between any root entities 110. Is preferred.

The function of the logging component 320 is to record all service requests and OCSP responses in the outstanding transaction log 58 (see FIG. 5) for non-repudiation and security checks.
Invoice issue component 322 is to generate and store an invoice issue history for messages (responses and requests) received by transaction coordinator 202. The preferred operation of this module and component is described in detail below.

  FIG. 4 is a combined block diagram / flow chart illustrating the transaction coordinator operation in the preferred embodiment. As shown in FIG. 4, at step 4002, transfer service component 306 of transaction coordinator 202 receives a service request from another system entity and transfers the service to request manager 304. In step 4002, the request manager 304 checks whether the service request format is valid. If the service request format is valid, the message verification module 404 is called to request information about the requester, billing data, and service request format. The message verification module 404 calls the analysis module 406 to extract relevant information from the outstanding service request.

In step 4006, the request manager 304 calls the authentication module 408 to authenticate the requester. The authentication module 408 is described in detail below.
At step 4008, the authentication module 408 calls the signature component 324 of the transaction coordinator 202, ie, calls the hardware 218 to authenticate the requester. The preferred structure and operation of the signature component 324 is described in detail below.
In step 4010, the authentication module 408 calls the certificate status verification module 414 and then calls the OCSP responder 204 to perform certificate status verification on the requester. A preferred structure and operation of the certificate status verification module 414 is described in detail below.

In step 4012, the authentication module 408 calls the supplier authentication verification module 418, verifies that the requester is authorized, and issues a service request. A preferred configuration and operation of the supplier authentication verification module 418 will be described in detail below.
At step 4014, the request manager 304 sends any billing data required for the appropriate billing for the service provided to the billing component 322 and records it in the billing log.

In step 4018, request manager 304 sends a service request to service request router 426. At step 4020, service request router 426 invokes the appropriate service module 308 to execute the request.
In step 4022, the service request router 426 receives a service response from the service module called in step 4020. The service request router 426 returns the service response to the request manager 304 and then sends the service response to the forwarding service component 306. The transfer service component 306 sends a service response to the entity making the service request.

FIG. 5 is a combined block diagram / flow chart illustrating the preferred operation of the signature component 324. The signature component 324 preferably includes a single interface to various signing means such as smart cards and hardware security modules and uses a cryptographic process to verify the signature.
In FIG. 5, at step 5002, upon receiving a request, the signature component 324 determines whether it is a signature request or a verification request. In the case of a verification request, the signature component 324 sends a verification request to the hardware security module 218 (step 5004). At step 5008, the hardware security module 218 performs verification in response to the request and returns a signature verification response to the signature component 324.

  If the request is a signature on a document, the signature component 324 sends a request for signature (which should include the document to be signed) to the hardware security module 218 (step 5006). At step 5010, hardware security module 218 signs the document in response to this request and returns the signed document to signature component 324. Finally, in step 5012, the signature component 324 returns a signature-verify response or signed document to the requesting component.

  FIG. 6 is a combined block diagram / flow chart illustrating the preferred operations of the steps performed by transaction coordinator 202 when performing certificate status verification. In step 6002, the certificate verification service module 312 receives an unparsed certificate status verification request from the service request router 426, and extracts related business partner information (including a certificate to be verified) in response to the request. To the analysis component 406. In step 6004, the certificate verification service module 312 acquires arbitrary additional service specification execution information from the supplier database 606.

In step 6006, if the certificate to be verified belongs to the related business partner that the transaction coordinator 202 received the request, the certificate verification service module 312 passes the request to the local business partner handler 602. Otherwise, the certificate verification service module 312 passes the request to the non-local customer handler 620.
If the local account handler 602 delivers the request, the system executes step 6008 and the local account handler 602 sends a certificate verification request to the certificate verification service module 312. The certificate status verification component 312 then obtains the certificate status for the certificate to be verified from the associated OCSP responder 204 (ie, belonging to the same transaction coordinator 202 as the certificate status verification component 312). The flow in this case proceeds to step 6032 below.

In contrast, if the certificate to be verified does not belong to the counterparty that received the request, at step 6010, the non-local counterparty handler 605 looks up the IP address of the issuer, The issuer is configured to issue a certificate that is the target of the request in the static DNS lookup table 604. The transaction coordinator 202 _RP is preferably adapted to identify the location of the issuer 102 using an AIA extension for the certificate. At step 6012, non-local customer handler 610 sends the subject certificate to OCSP request formulation module 608. In step 6014, the OCSP request formulation module 608 formulates an OCSP request for the certificate and sends the request to the signature component 324. At step 6016, the signature component 324 returns a signed request.

In step 6018, the OCSP request formulation module 608 sends a signed request to the issuer 102 that issued the target certificate. In step 6020, the issuing party 102 returns an OCSP response to the request to the OCSP request formulation module 608.
At step 6022, OCSP request formulation module 608 sends a response to non-local customer handler 610. At step 6024, the non-local supplier handler 610 records the raw response data in the raw transaction log 212 for non-repudiation purposes.

At step 6026, the non-local customer handler 610 sends the raw response data to the participant component 406 and extracts the issue participant 102 certificate and its transaction coordinator 202 _IP in response to the response.
In step 6028, the non-local customer handler 610 verifies the transaction coordinator certificate of the issuing party 102 by repeating steps 6012 to 6024, but the OCSP request generated in step 6014 is not the issuing party 102. Send to root entity 110.

Similarly, in step 6030, the non-local customer handler 610 verifies the certificate of the issuing party 102 by repeating steps 6012 to 6024. However, the OCSP request generated in step 6014 is received by the issuing party 102. To the root entity 110 instead.
At step 6032, the certificate verification response data received by the non-local account handler 610 or generated by the local account handler 602 is sent to the signature component 324 that signs the response. At step 6034, the signed response is returned to the certificate verification service module 312, which then sends the response to the service request router 426.

  FIG. 7 is a combined block / flow diagram illustrating a preferred embodiment of a transaction flow within system 200 for validating a certificate. As shown in FIG. 7, in step 7002, the signing customer 106 generates a data hash indicating the transaction between the signing customer 106 and the trusted customer 108 and sends the hash to the signature smart card 226. . In step 7004, the smart card 226 signs the data and returns the signed data along with the signature supplier 106 and issuer 102 certificates.

  In step 7006, the signature customer 106 sends the signed data and two certificates to the trusted customer 108. In step 7008, the trusted customer 108 verifies the signature regarding the data sent from the signature customer 106. This verification preferably includes verification of the expiration date of the received certificate. Alternatively, the verification may be provided as a service to the credit customer 108 by the credit partner 104. Next, the trusted customer 108 generates an OSCP request including the signature customer and the related party's certificate, and sends this request to the signature hardware security module 230. In step 7010, hardware security module 230 returns a signed request.

In step 7012, the trusted customer 108 sends a signed OCSP request along with its certificate to the trusted party 104. At step 7014, the transaction coordinator 202 _RP of the credit partner 104 receives the signed OCSP request, checks the customer database, and processes the request before the request is signed by a real credit customer. Confirm. In the preferred embodiment, the trusted party 104 does not process requests received from different related business partners. At step 7016, the transaction coordinator 202 _RP stores the outstanding transaction data (ie, the unparsed request, signature, and accompanying credit account certificate) in the outstanding transaction log 212 _RP . At step 7018, any billing data required to properly bill for the service provided is stored in billing log 208 _RP . Alternatively, the invoice issue data may be extracted from an unprocessed transaction log by offline processing to improve system performance.

In step 7020, the transaction coordinator 202 _RP verifies the trusted customer's signature for the service request using the trusted customer's certificate, the trusted party certificate, and the public key. The trusted supplier's certificate and public key are preferably stored in the hardware security module 218 _RP .
In step 7022, the transaction coordinator 202 _RP generates an OCSP request including the certificate of the trusted customer, signs it, and sends it to the OCSP responder 204. Alternatively, if the transaction coordinator and OCSP responder are co-located, a signature on the request may not be required. At step 7024, OCSP responder 204 verifies the signature of the request, checks the local repository to determine the validity of the trusted partner's certificate, and returns a response related to the status of the certificate to transaction coordinator 202 _RP . .

It should be noted that as part of the system operation, the trusted customer 108 often needs to verify the certificate of the signing customer 106, which is a customer partner other than the credit partner 104. In this case, since the trusted party 104 is not an issuing party that issues a certificate to be verified, the trusted party does not have direct knowledge of the certificate status.
In a preferred embodiment, the system solves this problem by having each party that receives an OCSP request for a certificate issued by another party send the request to the issuing party for the certificate. To do. In particular, in step 7026, the credit relationship partner 104 determines the issue relationship destination of the signature business partner. If the signing business partner is another business partner, the trusted business partner 104 generates a signed verification request for the signature business partner's certificate and sends it to the confirmed issuing business partner 102 along with its own certificate. send. Alternatively, instead of signing the verification request, the trusted party may include a client-side authentication unit for the issuing party 102, for example, an OCSP proxy-centric model described below.

When both the signing business partner and the credit business partner are business partners of the same related party, the above-mentioned local handler module 602 verifies the signature business partner's certificate.
At step 7028, issuer 102 verifies its transaction coordinator 202 _RP to confirm that the entity authorized to make the request has signed the request. In step 7030, the issuer 102 stores the received raw data (ie, unparsed request, signature, and associated credit supplier certificate) in the raw transaction log 212 _RP . In step 7032, the issue party 102 stores the related invoice issue data for the request in the invoice issue log 208. Alternatively, the invoice issue data may be extracted from an unprocessed transaction log by offline processing to improve system performance.

At step 7034, the issuing party 102 uses the trusted party's transaction coordinator certificate (sent with the request) and the root public key (which can be stored in the hardware security module 218 _IP ) to process the transaction for the request. Coordinator 202 Verify signature of _RP . In step 7036, the issuing transaction coordinator 202 _IP generates a signed OCSP request for the trusted transaction coordinator certificate and sends the request to the root entity 110.

In step 7038, the transaction coordinator 202 _R of the root entity 110 receives the request, and stores the outstanding requests to the untreated transaction log 212 _R. In step 7040, the transaction coordinator 202 _R stores the billing data for the request to billing data log 208 _R. In step 7042, the transaction coordinator 202 _R verifies the signature of the request, then sends the request to the OCSP responder 204 _R. In step 7044, OCSP responder 204 _R collates the local repository to determine the status of the target certificate and returns the related status to the transaction coordinator 202 _R. In step 7056, the transaction coordinator 202 _R indicates the status of the trust the merchant coordinator certificate, send a signed reply to the transaction coordinator 202 _IP.

At step 7048, the transaction coordinator 202 _IP of the issuing party 102 stores the OCSP response from the root entity 110 in the raw transaction log 212 _IP for non-repudiation purposes. At step 7050, transaction coordinator 202 _IP generates an OCSP request for the signing supplier's certificate, signs it, and sends it to its local OCSP responder 204 _IP along with its certificate. Alternatively, if the transaction coordinator 202 _IP and the OCSP responder 204 _IP are co-located, the request signature may not be required. Also, if the two are co-located, the transaction coordinator functions as a simple pass-through as opposed to a resignature request and response.

At step 7052, the OCSP responder 204 _IP verifies the signature on the request, generates a response, signs it, and returns the signed response to the transaction coordinator 202 _IP . At step 7054, transaction coordinator 202 _IP verifies the OCSP responder's certificate, re-signs the response, and returns it to transaction coordinator 202 _RP along with its own certificate.
In step 7056, the transaction coordinator 202 _RP of the credit relationship partner 104 stores the unprocessed response data received from the issue relationship partner 102 in the unprocessed transaction log 212 _RP for non-repudiation purposes. At step 7058, the transaction coordinator 202 _RP uses the trusted transaction coordinator certificate (sent with the request) and the root public key (which can be stored in the hardware security module 218 _RP ) to determine the transaction coordinator. 202 Verify signature on _IP response. At step 7060, the transaction coordinator 202 _RP generates a signed OCSP request for the trusted transaction coordinator certificate and sends it to the root entity 110.

At step 7062, the transaction coordinator 202 _R of the root entity 110 stores the unprocessed request data in the unprocessed transaction log 212 _R. In step 7064, the transaction coordinator 202 _R stores the related invoicing data to billing log 208 _R. At step 7066, transaction coordinator 202 _R verifies the signature for the request and sends the request to OCSP responder 204 _R. In step 7068, OCSP responder 204 _R determines the status of the issuing participant transaction coordinator certificate against a local repository, returns a response regarding the status to the transaction coordinator 202 _R. In step 7070, the transaction coordinator 202 _R sends the signed response regarding the status of the certificate subject to the transaction coordinator 202 _RP.

At step 7072, the transaction coordinator 202 _RP of the credit partner 104 stores the response in the raw transaction log 212 _RP for non-repudiation purposes. At this point, the processing of the signature supplier certificate is completed.
At step 7074, the transaction coordinator 202 _{RP now} processes the response, ie the second half of the signing supplier's certificate, by generating a signed OCSP request and sending it to the root entity 110.

At step 7076, the transaction coordinator 202 _R of the root entity 110 stores the raw request data in the raw transaction log 212. At step 7078, transaction coordinator 202 _R stores the relevant invoice issue data in invoice issue log 208.
In step 7080, the transaction coordinator 202 _R verifies the signature about the request and sends the request to the OCSP responder 204 _R. In step 7082, OCSP responder 204 _R determines the status of the target of the certificate against a local repository, returns a response to the transaction coordinator 202 _R. At step 7084, transaction coordinator 202 _R sends a signed response to transaction coordinator 202 _RP .

At step 7086, the transaction coordinator 202 _RP of the trusted party 104 stores the response from the root entity 110 in the raw transaction log 212 _RP for non-repudiation purposes. In step 7088, the transaction coordinator 202 _RP generates an OCSP response from the response from the transaction coordinator 202 _RP and its local cache issues participant 102 performs sign it, sent with its certificate to credit suppliers 108.

In step 7090, the trusted customer 108 verifies the response using the root public key certificate stored in the hardware security module 230. In step 7094, the credit suppliers 108 to the certificate to determine whether not disabled, send a request for credit participant transaction coordinator certificate to the transaction coordinator 202 _R. At step 7094, the transaction coordinator 202 _RP verifies the signature on the request and sends the request to the local OCSP responder 204 _RP to ensure that the trusted transaction coordinator certificate has not been revoked. At step 7096, the local OCSP responder 204 _RP responds to this request from the transaction coordinator 202 _RP .

At step 7098, the transaction coordinator 202 _RP sends an OCSP request for the trusted transaction coordinator certificate to the transaction coordinator 202 _R of the root entity 110. In step 7100, the transaction coordinator 202 _R is to verify the signature on the request, to determine the status of credit related parties of the transaction coordinator certificate. In step 7102, the transaction coordinator 202R sends the response received from the local OCSP responder 204 _R to the transaction coordinator 202 _RP.

At step 7104, transaction coordinator 202 _RP sends the response received from root entity 110 to trusted customer 108. In step 7106, the trusted customer 108 provides a confirmation notice to the signature customer 106.
In connection with steps 7092 through 7104 above, it is noted that as part of the system operation, the credit account 108 typically needs to obtain the status of the credit coordinator certificate of the credit partner. I want. Within the four corner model, the transaction coordinator and OCSP responder certificates of issuer 102 and creditor 104 are signed by root entity 110. The root entity 110 operates the OCSP responder, but this service is only available to interested parties. As a result, the trusted customer 108 cannot request the root entity 110 to verify the certificate of the trusted party.

  In the preferred embodiment, the system solves this problem by having each participant 102, 104 operate a route responder proxy. This proxy typically accepts requests from trading partners on behalf of the route via another similar resource locator, sends the request over the authenticated secure socket layer path, and returns it to the requesting party .

  The four-corner model described above may also be used to provide a guarantee service that guarantees the identity of a particular entity (eg, a signing customer) who has signed the transaction. One embodiment for providing such a warranty service is described below. Another embodiment for providing warranty service is a pending US Provisional Application No. 60 / 224,994 filed Aug. 14, 2000, “Signing Interface Requirements Requirements, Smart Card Compliance Requirements, and Additional Disclosure”. And the disclosure of which is incorporated herein by reference.

  FIG. 8 is a transaction flowchart of one preferred embodiment of a warranty service. As shown in FIG. 8, at step 8002, the signing customer 106 generates a data hash between the signing customer 106 and the trusted customer 108 and sends this hash to the signature smart card 226. At step 8004, the smart card 226 signs the data and returns the signature along with the trusted certificate and the trusted certificate. Optionally, the message may include a card and signature security data (CSSD), providing additional security such as protection against duplicate messages.

  In step 8006, the signature supplier 106 sends the signed data, the signature, the signature supplier certificate, and the issuer's certificate (optionally CSSD) to the trusted customer 108. In step 8008, the trusted customer 108 verifies the signature on the data sent by the signature customer 106. Alternatively, the verification may be provided as a service to the credit customer 108 by the credit partner 104. Next, the trusted customer 108 generates a guarantee request and sends the request to the hardware security module 230 for signing. At step 8010, hardware security module 230 returns the signed request with a copy of the trusted partner's certificate.

In step 8012, the trusted customer 108 sends the signed guarantee request and the trusted customer certificate to the trusted party 104.
At step 8014, the transaction coordinator 202 _RP of the credit partner 104 checks the customer data database 214 _RP to confirm that the real customer has signed the request before processing the request. At step 8016, the transaction coordinator 202 _RP stores the raw transaction data related to the transaction (ie, “unparsed request, signature, and accompanying certificate) in the raw transaction log 212 _RP . At step 8018, transaction coordinator 202 _RP stores the relevant invoice issue data in invoice issue log 208 _RP . Alternatively, the invoice issue data may be extracted from an unprocessed transaction log by offline processing to improve system performance.

At step 8020, the transaction coordinator 202 _RP uses the trusted supplier certificate (sent with the request), the trusted party certificate, and the root public key (both can be stored in the hardware security module 218 _RP ). To verify the signature of the relevant business partner for the request. Next, the transaction coordinator 202 _RP generates an OCSP request including a trusted customer certificate, signs it, and sends it to the local OCSP responder 204 _RP . Alternatively, if the transaction coordinator or OCSP responder is co-located, it may not be necessary to sign the request.

At step 8022, the OCSP responder 204 _RP verifies the signature for the request, checks the local repository for the status of the trusted customer certificate, and returns a status response to the transaction coordinator 202 _RP .
At step 8024, the transaction coordinator 202 _RP calls the risk manager 216 _RP to determine whether the credit account 108 is financially authorized to make a guarantee request. If so, then at step 8026, the transaction coordinator 202 _RP determines the party's responsibility for responding to the assurance request for the signing customer 106. In this embodiment, this entity is the issue relationship destination 102. Next, the transaction coordinator 202 _RP generates a guarantee request for the signature supplier 106, signs it, and sends it to the issuer 102 with its own certificate. It should be noted that if both the signing business partner and the credit business partner are business partners of the same related party, the guarantee request may be processed locally at the related party instead.

At step 8028, the transaction coordinator 202 _IP verifies the customer data database 214 _IP to verify that the request is signed by an entity authorized to make the request. At step 8030, transaction coordinator 202 _IP stores raw transaction data (ie, “unparsed” request, signature, and accompanying certificate) in raw transaction log 212. At step 8032, transaction coordinator 202 _IP stores the associated invoicing data for the request in invoicing log 208 _IP . Alternatively, the invoice issue data may be extracted from an unprocessed transaction log by offline processing to improve system performance. In step 8034, the transaction coordinator 202 _IP uses the transaction coordinator 202 _RP 's certificate (sent with the request) and the root public key (which can be stored in the hardware security module 218 _IP ) for the transaction coordinator for the request. 202 Verify _RP certificate. Next, the transaction coordinator 202 _IP generates an OCSP request for the trusted transaction coordinator 202 certificate, signs it, and sends it to the root entity 110.

In step 8036, the transaction coordinator 202R root entity 110 stores the outstanding requests to the untreated transaction log 212 _R. In step 8038, the transaction coordinator 202 _R stores the related invoicing data for the request to billing log 208 _R. In step 8040, the transaction coordinator 202 _R verifies the signature about the request, then sends a request to the OCSP responder 204 _R. The OCSP responder 204 _R checks the local repository to determine the status of the trusted transaction coordinator certificate and returns a response related to that status to the transaction coordinator 202 _R. Transaction coordinator 202 _R then returns the signed response to transaction coordinator 202 _IP .

At step 8042, the transaction coordinator 202 _IP of the issuing party 102 stores the unprocessed response in the unprocessed transaction log 212 _IP for non-repudiation purposes. In step 8044, the transaction coordinator 202 _IP then generates an OCSP request containing the signed supplier certificate from the received request, signs it, and sends it along with its certificate to the local OCSP responder 204 _IP . Alternatively, if the transaction coordinator and the OCSP responder are co-located, the request signature may not be required. Also, if the two are co-located, the transaction coordinator functions as a simple pass-through as opposed to a resignature request and response.

At step 8046, the OCSP responder 204 _IP verifies the signature on the request, generates a response, signs it, and returns the signed response to the transaction coordinator 202 _IP . At step 8048, transaction coordinator 202 _IP calls risk manager 216 _IP to determine whether to issue a guarantee for signing customer 106. In step 8050, the risk manager 216 _IP returns a signed message to the transaction coordinator 202 _IP indicating whether or not a guarantee needs to be issued. At step 8052, transaction coordinator 202 _IP stores the signed response in raw transaction log 212 _IP .

At step 8054, the transaction coordinator 202 _IP sends a signed response to the transaction coordinator 202 _RP of the root entity 110 to determine whether the issuing party 102 has sufficient collateral to issue a guarantee. In step 8056, the transaction coordinator 202 _R interacts with risk manager 216 _R, to determine whether issuance participant 102 is guaranteed by proper collateral when warranted, collateral issued participant 102 The level is reduced by an amount appropriate for the issued guarantee, and the response is returned to the issuing party 102.

At step 8058, transaction coordinator 202 _IP verifies transaction coordinator 202 _R 's signature, generates a guarantee response, and returns it to transaction coordinator 202 _RP along with its certificate.
At step 8060, the transaction coordinator 202 _RP of the credit partner 104 stores the unprocessed response in the unprocessed transaction log 212 for non-repudiation purposes. At step 8062, the transaction coordinator 202 _RP uses the transaction coordinator 202 _IP certificate (sent with the request) and the root public key (which can be stored in the hardware security module 218 _RP ) to respond to the transaction coordinator. Verify the signature of 202 IP. Next, the transaction coordinator 202 _RP generates a signed OCSP request for the issuing transaction coordinator certificate and sends it to the root entity 110.

At step 8064, the transaction coordinator 202 _R of the root entity 110 stores the outstanding request in the outstanding transaction log 212 _R. In step 8066, the transaction coordinator 202 _R stores the related invoicing data to billing log 208 _R. In step 8068, the transaction coordinator 202 _R verifies the signature about the request. Next, the transaction coordinator 202 _R stores the request in the OCSP responder 204 _R. The OCSP responder 204 _R checks its local repository to determine the status of the subject certificate and returns a response to the transaction coordinator 202 _R. Transaction coordinator 202 _R then sends a signed response to transaction coordinator 202 _RP .

At step 8070, the transaction coordinator 202 _RP of the credit partner 104 stores the outstanding response in the outstanding transaction log 212 _RP for non-repudiation purposes. In step 8072, the transaction coordinator 202 _RP checks whether issuing participant examines the transaction coordinator 202 _R of the root entity 110 owns sufficient collateral only have to issue a warranty.

In step 8074, the transaction coordinator 202 _R stores the outstanding requests to the untreated transaction log 212 _R. In step 8076, the transaction coordinator 202 _R stores the related invoicing data to billing log 208 _R. In step 8078, transaction coordinator 202 _R sends a “yes” or “no” response to credit partner 104, relating to whether issuer 102 has sufficient collateral to issue a guarantee. Send to Transaction Coordinator 202 _RP .

At step 8080, transaction coordinator 202 _RP stores the unprocessed request in unprocessed transaction log 212 _RP for non-repudiation purposes. At step 8082, the transaction coordinator 202 _RP generates a guarantee request from the request received from the transaction coordinator 202 _IP , signs it, and sends it to the trusted customer 108 along with the transaction coordinator 202 _RP certificate.

At step 8084, the trusted customer 108 verifies the response using the root public key stored in the hardware security module 230. In step 8086, the credit suppliers 108, in order to examine whether disabled, send a request for certificate of transaction coordinator 202 _RP to the transaction coordinator 202 _RP.
At step 8088, the transaction coordinator 202 _RP verifies the signature on the request and sends a response to the OCSP responder 204 _RP to ensure that the transaction coordinator certificate of the trusted customer 108 has not been revoked. In step 8090, the local OCSP responder 204 _RP sends an OCSP request for the certificate to the transaction coordinator 202 _R.

In step 8094, the transaction coordinator 202 _R verifies the signature about the request, determines the status of the certificate of the transaction coordinator 202 _RP examines the local OCSP responder 204 _R. Next, transaction coordinator 202 _R sends the response received from local OCSP responder 204 _R to transaction coordinator 202 _RP .
At step 8096, transaction coordinator 202 _RP sends the response received from transaction coordinator 202 _R to trusted customer 108. In step 8098, the trusted customer 108 sends a confirmation notification to the signature customer 106.

  In a preferred embodiment, each transaction coordinator 202 provides the transaction with atomicity, consistency, independence, and durability that is coordinated by the transaction coordinator. Atomicity means that all actions necessary to close a transaction succeed or all fail, i.e. the transaction is a unit of work that cannot be divided. Consistency means that after a transaction is executed, the system returns to a state in which it remains in the correct state, in a stable state, or initiating a transaction. Independence means that each transaction is not affected by other transactions that can be executed simultaneously. Durability means that the effect of each transaction is unchanged after the transaction is committed. The combination of atomicity, consistency, independence, and durability is sometimes referred to as an ACID property.

  The transaction coordinator 202 preferably has ACID characteristics in a distributed computing environment by incorporating a transaction processing procedure monitor or component transaction monitor. Suitable transaction processing procedure monitors may include BER System's BER TUXEDO, Microsoft's MSMQ, NCR's Top End, and IBM Transarc's Encina. Suitable component transaction monitors may include Orbix OTM from Iona Technologies and BEA WebLogic BER from BER System.

  Any combination of transaction steps coordinated by the transaction coordinator can be combined to form a transaction having ACID characteristics. One or more predefined transactions are provided for each step shown in FIGS. That is, for example, the steps that occur between the request and response shown in FIG. 5 can be combined to form a transaction with ACID characteristics.

  In the preferred embodiment, the transaction coordinator component interacts with the transaction processing procedure monitor via the transaction processing library. In order to facilitate the implementation of a flexible architecture that can replace the executed transaction processing monitor with another transaction processing procedure monitor, the library can handle transaction processing even if it uses a specific brand transaction processing monitor. It may be written to access the procedure monitor functionality.

Each of the aforementioned transaction processing procedure monitors has specific functions relating to the suitability of the system for the transaction coordinator for the company. For example, the TUXEDO transaction processing procedure monitor is designed as follows.
(1) High performance message passing engine.
(2) Distributed transaction management that allows clients and servers to participate in distributed transactions and manage the two-way commit process without the application being aware of it.
(3) A transaction manager interface application that allows a developer to write a BEA TUXEDO application regardless of the hardware hosting program.
(4) Dynamic workload balancing that automatically generates and manages parallel copies of applications and ensures that they are used equally.
(5) Transaction queuing, which allows distributed applications to operate simultaneously in an asynchronous, unbound manner and prioritizes queues based on message context, content, and date and time.
(6) Data dependent routines that allow transactions to be processed where the most data is available.
(7) Automatic recovery from application abnormality, transaction abnormality, network abnormality, and node abnormality, in which the server manager restarts the abnormality process and rolls back the transaction that was in progress.

Microsoft's MSMQ transaction processing procedure monitor is designed as follows.
(1) Full COM component support.
(2) Access from various programming languages (eg Visual C ++, Visual J ++).
(3) Five APIs (open, close, send, receive, locate) that provide advanced message queuing benefits.
(4) Sliding window protocol, recoverable storage, dynamic routing for message delivery, regular and in-order message delivery.
(5) Ability to be included in transactions with other actions such as database updates.
(6) Ability to delegate or cancel operations on other resources to maintain data integrity during transactions.
(7) Built-in message encryption, integrity, and signature support.
(8) An administrator with the ability to indicate which MSMQ events need to generate Windows NT® security log inspection records.

  Typically, MSMQ includes the functions of MS Windows NT® Server, Standard Edition 4.0, and MS Windows NT® Server, Enterprise Edition 4.0. MSMQ preferably runs on NT Server, Enterprise Edition 4.0 if more than 24 clients support, cost based routines, and MSMQ Connector are required. Note that MSMQ is a high performance message passing engine, but it is not suitable for use in this system because it does not have the necessary functions for transaction processing procedure monitoring.

IBM Ecina is available from Transarc for a number of hardware platforms including Sun, IBM, Digital Equipment Corp, Hewlett Packard, and Windows®. The IBM Ecina transaction processing procedure monitor is designed as follows.
(1) Interoperability that enables distributed transaction processing procedure applications that integrate a wide variety of systems.
(2) Oracle providing simultaneous use of mainframe LU6.2 including sync-level0, 1, 2 services via the X / OpenXA application program interface without requiring additional software on the mainframe. Simultaneous use of multiple XA compliant databases or resource managers such as Ingres, Infomix, or Sybase.
(3) Performance and reliability required by transaction processing procedure application.
(4) An effective fully distributed two-way commit mechanism.
(5) Automatic load balancing and application replication services that enhance performance and eliminate single point failures.
(6) A basic DCE genetic security mechanism that allows both the client and server to verify the identity and authority of the parties involved in the transaction.
(7) An additional security mechanism that includes automatic authentication verification and facilitates providing an inspection record structure.
(8) Enterprise extensibility to support a large number of users and large amounts of data.
(9) Centralized management that facilitates effective management.

The Top End transaction processing procedure monitor is designed as follows.
(1) Robust middleware (2) Distributed transaction management (3) Client / server interaction (4) Reliable file transfer (5) Dynamic workload balancing (6) Recoverable transaction queuing (7) Applications Parallelization (8) Dual commit processing procedure (9) Automatic recovery (10) Message dependent routine (11) Multiple database support (Microsoft SQL Server, Oracle, and Sybase)
(12) Extensibility and usefulness of Internet applications

In a preferred embodiment, each transaction coordinator of the system has a plurality of transactions including authentication, authorization, session security, message security, non-repudiation, and auditing. Service is to be provided.
In the preferred embodiment, the transaction coordinator utilizes PKIX authentication based on the PKI defined by the root entity 110. Other authentication mechanisms for services other than the present system can be supported as determined by the entity operating the transaction coordinator.

In a preferred embodiment, authentication is provided using digital certificates. Authentication occurs at the session level, message level, or both levels.
In the preferred embodiment, the Secure Sockets Layer (SSL) protocol provides session level authentication. The secure socket layer protocol consists of two phases. Service-side authentication and optional client-side authentication. The predetermined transaction coordinator 202 functions as a server when receiving a request from a business partner or another transaction coordinator, and as a client when sending a request to another transaction coordinator.

  FIG. 9 shows server-side authentication. The server 90 receives the request from the client 95 (step 9002) and sends the utility certificate to the client (step 9004). In step 9006, the client 95 generates a public key, encrypts it using the public key of the server, and sends it to the server 90 (step 9006). In step 9008, the server 90 authenticates itself to the client 95 by decrypting the public key sent by the client 95 using the private key and returning an authenticated message using the public key received from the client. . The subsequent data is encrypted and authenticated using a client-generated public key.

  With the secure socket layer server side authentication, the client 95 can know who is communicating. Server-side authentication is preferably required for all sessions in which network transactions occur. In order to authenticate the server 90, the client 95 needs to possess a public key certificate for root certificate authority in the server 90 utility certificate chain.

  FIG. 10 illustrates optional client-side authentication. In step 10002, server 90 sends a challenge to client 95. The client 95 signs the challenge using its private key and authenticates itself to the server 90 by returning the signed challenge along with its public key (step 10004).

Secure socket layer client-side authentication ensures that client 95 possesses a valid utility certificate and accompanying private key. In the preferred embodiment, secure socket layer client-side authentication is optional, but is employed when the issuing party 102 and the trusted party 104 do not request a digitally signed request from the client 95. The transaction coordinator 202 _IP , 202 _RP , 202 _R determines the public key certificate for the root certificate authority in the client's utility certificate chain to determine that the client 95 has a valid root certificate. Need to own.

In the preferred embodiment, at the session level, the issuing party 102 and the trusted party 104 authenticate themselves with the client. In addition, the issue party 102 and the credit party 104 can request the client to authenticate itself to the transaction coordinators 202 _IP , 202 _RP , 202 _R when the session is established. That is, if the client 95 is not a verified partner of the party with which it is communicating, the transaction coordinator for that party can cancel the session before processing the message. Further, the related party can request client side authentication of the business partner at the session level instead of requesting message level authentication.

Authentication between the transaction coordinators 202 _IP , 202 _RP , 202 _R may occur at either the session level or the message level or both. In contrast, it is desirable that a credit account be required to provide message level authentication by digitally signing all requests sent to transaction coordinator 202RP. However, as described above, the party may require the credit trading partner to provide client-side authentication at the session level.

  FIG. 11 is a combined block diagram / flow chart illustrating the preferred embodiment. As described below, this method operates to authenticate a message sent to transaction coordinator 202 by adding a digital signature to the data contained in the message.

  At step 1102, the authentication module 408 invokes the hardware security module 218 to verify the signature on the received message, typically using the caller's public key certificate sent with the message. In step 1104, the authentication module 408 invokes the hardware security module 206 to validate the caller's certificate chain by originating the root certificate in the caller's chain and enabling the caller's certificate chain. Make sure you have a good root assurance certificate. Several parts of the caller chain, such as the caller's public key certificate, are sent with the message. Other parts of the chain, such as the root certificate, are already stored in the HSM 206 and / or customer database 214.

In step 1106, the authentication module 408 calls the time source 11, obtains the latest time, and verifies that none of the certificates containing the caller's chain has expired. All participants and the root entity 110 preferably have a synchronized time source.
In step 1108, the authentication module 408 calls the OCSP responder 204 to confirm that the certificate of the caller's chain other than the certificate stored in the hardware security module 218 has not been revoked.

  Message authentication provides a higher level of authentication than session authentication. Session authentication uses a utility key. In general, since OCSP verification is not performed on utility keys, neither the client nor the server can verify during the authentication process if the SSL certificate is invalid. Furthermore, since utility keys are stored without protection, anyone who owns the token in which the key is stored can impersonate an authorized user. On the other hand, the guaranteed key used to provide message authentication is protected, so even if you simply own the token, you are not eligible to approach the key and impersonate an authorized user.

  In the preferred embodiment, the supplier authentication verification module 418 (see FIG. 5) verifies that the service requester is authorized to receive the service. To determine authentication, the requester's identity can be determined from session level authentication or message level authentication. The supplier authentication verification module 418 extracts the authenticated identity of the user, or a distinguished name from a given utility, or a warranty certificate and compares it to the authorized user list in the supplier data database 214. It is preferable to perform authentication verification. In a preferred embodiment, the customer authentication verification may be based on a portion of the distinguished name, such as any user with a distinguished name that is subordinate to the distinguished name of the financial institution's certification authority, or only certain users It may be based on the full distinguished name to be certified.

The supplier authentication verification module 418 can perform authentication verification at multiple levels. For example, you may have the capability to permit or deny the service in a user level, or you may have the capability to permit or deny based on the detailed standard of the security which a user holds.
In a preferred embodiment, transaction coordinator 202 provides session security using a secure socket layer (SSL). SSL typically provides three levels of session security. That is, confidentiality, data integrity, and session authentication. Communications from or to the transaction coordinator 202 are preferably encrypted using SSL.

The message security of the system is preferably provided using a digital signature. Digital signatures provide two levels of message security. Authentication and data integrity. Digital signatures typically authenticate using a protected private key, which is used for the signature message.
As mentioned above, digital signatures preferably provide data integrity using a hash or message digest generated during the signing process. The message digest gives a “fingerprint” of data that, when any bit of the signed data is changed, creates another “fingerprint” that prevents the data recipient from verifying the signature.

In the preferred embodiment, confidentiality is provided for all route communications at the session level. The transaction coordinator preferably follows the confidentiality rules defined by the root entity 110.
In a preferred embodiment, each transaction coordinator 202 records all data necessary to ensure non-repudiation of execution services in the logs and to ensure the integrity of these logs. For example, the credit partner 104 preferably provides such non-repudiation for all services performed on the credit partner 108. That is, for each execution service, the transaction coordinator 202RP not only responds to the trusted customer 108, but also all the necessary to ensure that no party involved in the execution of the service can reject the provided service. Retain data.

  In a preferred embodiment, digitally signed messages provide this non-repudiation criterion. For example, in the context of the aforementioned verification service, transaction coordinator 202 maintains a log of all received data for non-repudiation purposes. Transaction coordinator 202 preferably records the message as it is received and does not parse it, do not change it, or store it in a format other than the received format. Changing the received message makes it impossible to prove the digital signature of the message, making the message inappropriate for non-repudiation purposes.

  In the preferred embodiment, each received message is time stamped as part of the non-repudiation service. The response is associated with an authentication verification that is performed at a specific time. The authentication verification time is a signed attribute in the response, and is preferably acquired by the unprocessed transaction log 212.

  In the preferred embodiment, the transaction coordinator 202 also records information for inspection purposes. Security inspection logs can be used to detect potential attacks on the system, such as numerous suspicious requests from non-parties and numerous suspicious invalid signatures. The security inspection log is useful when a key leak occurs. The reason is that the key can be compromised before it is recorded and the associated certificate becomes invalid. The security inspection log is preferably usable to confirm that processing has occurred using the leaked key.

  Inspection records are maintained for dispute resolution, non-repudiation, and billing purposes. In the preferred embodiment, the transaction coordinator records all messages sent and received and records the entire message. Messages can be recorded in “raw” format. Alternatively, the transaction coordinator can break the message into component parts and store it as a schema, and the entire message can be reconstructed with the signature preserved. In the preferred embodiment, the log is such a property, so log entries cannot be counterfeited (added, deleted, or changed) without being detected. Furthermore, if the transaction coordinator is recorded in a raw format, it preferably includes the ability to convert the raw data into a format readable by the COTS solution. This may be a loosely coupled utility or may be part of the transaction coordinator functionality and run as a separate, possibly low priority background process. This may also be performed on a completely separate system. The log may include other data related to transfers and sessions. Examples include sender / receiver IP addresses, post URLs, SMTP headers, and the like.

  The transfer service component 306 (see FIG. 3) preferably comprises a secure communication component that establishes a secure socket layer session between the transaction coordinator 202 and the communicating entity. In a preferred embodiment, the secure communication component performs session authentication as described above. That is, if the transaction coordinator 202 serves as the server 90, the secure communication component can provide server-side session authentication and request client-side session authentication. In contrast, when transaction coordinator 202 serves as client 95, the secure communication component is responsible for authentication of server 90.

  As a client, transaction coordinator 202 is also preferably responsible for establishing session security by generating a session key and sending the key to the transaction coordinator attempting to communicate, and the key is encrypted with the server's public key. Is done. Subsequent communication between the two parties is encrypted using the session key.

  FIG. 12 combines a block diagram / flow chart of a preferred embodiment of a security-related flow associated with the components of transaction coordinator 202. As shown in FIG. 12, at step 1202, the forwarding service component 306 receives the request. In step 1204, transfer service component 306 sends the request to request manager 304. Request manager 304 preferably performs all security-related functionality on incoming messages prior to processing the message.

In step 1206, the request manager calls the logging component 320 to record raw data. The logging component 320 collects data that requires non-repudiation and inspection support. As mentioned above, all requests and responses are preferably recorded in a received format.
In step 1208, the request manager 304 determines whether a signature for the request is requested. In step 1210, when the request manager 304 confirms that the request does not need to be signed, the request manager 304 invokes the supplier authentication verification module 54 using the client's utility certificate.

In step 1212, when the request manager 304 confirms that the signature needs to be signed, the request manager 304 calls the supplier authentication module 408. At step 1214, the supplier authentication module 408 verifies the signature for the request and invokes the signature component 324 to verify the certificate chain.
The signature component 324 preferably provides message security and supports session and message authentication services. The signature component 324 interacts with the hardware security module 218 to perform cryptographic functions. The root entity 110 preferably defines the digital signature method used for all transactions. The signature component 324 preferably interacts with the hardware security module 218 to perform cryptographic functions included in the signature verification process.

In step 1216, the supplier authentication module 408 checks the status of the guarantee certificate of the supplier by sending a request to the OCSP responder 204 via the certificate status check module 414 as described above.
In step 1218, the supplier authentication module 110 calls the supplier authentication verification module 418 using the guarantee certificate of the supplier. In step 1220, the supplier authentication verification module 418 checks the supplier database 214 to confirm that the request from the supplier is certified to obtain the requested service. At step 1222, the request for authorization is returned to the request manager 304, and processing of the system provided service as described above continues.

  Describe preferred security requirements for network communications between the transaction coordinator and the following entities: Entities are trading partners, OCSP responders, and other trading coordinators. A preferred requirement will be described as an example where the trusted customer 108 has made a request to the trusted party 104.

If the transaction coordinator 202 _RP of the credit partner 104 receives a request from the credit partner 108, the transaction coordinator 202 _RP authenticates the request. Typically, a signature is required for all messages sent from the trusted customer 108 to the transaction coordinator 202 _RP . Further, the transaction coordinator 202 _RP may require the trusted customer 108 to provide a secure socket layer client side session certificate.

The transaction coordinator 202 _RP preferably provides authentication for all messages sent to the trusted customer 108. Furthermore, the transaction coordinator 202 _RP provides a secure socket layer server side session certificate if any session is established using the trusted customer 108.

In the preferred embodiment, the transaction coordinator 202 _RP performs an authorization to determine whether the trusted customer 108 is a real customer for the trusted party 104. The transaction coordinator 202 _RP can also perform an authorization to verify whether it is authorized to receive the type or level of service being requested. The trusted trading partner 108 preferably has an entry point for the trading partner database 214 _RP that lists eligible services. When secure socket layer server-side session authentication is adopted, the trusted customer 108 can confirm that it exists in the guarantee certificate by the distinguished name, and can exist in the utility certificate by the distinguished name. It is preferable that it can be confirmed. This transaction coordinator aspect may be integrated with the COTS access control / authentication package.

In the preferred embodiment, communications between the trusted customer 108 and the transaction coordinator 202 _RP are encrypted based on specifications defined by the root entity 110 and require server-side authentication.
Typically, messages exchanged between the trusted customer 108 and the transaction coordinator 202 _RP are digitally signed. The transaction coordinator 202 _RP preferably verifies all signed messages received, validates the certificate chain, and ensures that the certificates in the chain have not been revoked. In addition, transaction coordinator 202 _RP signs all messages sent to trusted customer 108.

In the preferred embodiment, the transaction coordinator 202 _RP provides a non-repudiation service for the credit account 108. Typically, the transaction coordinator 202 _RP records all requests related to requests for services received from any route component. This includes other components of the transaction coordinator 202 _RP as well as other related and root entity 110 components. The credit partner 104 preferably records all requests for services from the credit partner 108 and all confirmation notifications received from the credit partner 108 to protect itself from denials from the counterparty. .

In the preferred embodiment, the transaction coordinator 202 _RP records all requests for services from the credit trading partner 108 for inspection purposes. Accordingly, the system administrator can detect a potential attack on the system and can confirm whether or not a request for service has been received after a key leak has occurred. Request inspection can also be used to support any possible billing dispute.

In the preferred embodiment, the transaction coordinator 202 _IP , 202 _RP , 202 _R communicates with only the OCSP responder 204 _IP , 204 _RP , 204 _R respectively, that is, with an OCSP responder at the same financial institution. If a response from an OCSP responder at another financial institution is required, preferably the communication should pass through the other financial institution's transaction coordinator 202.

Preferably, the OCSP responders 204 _IP , 204 _RP , 204 _R can identify the identity of the entity receiving the request, and the transaction coordinators 202 _IP , 202 _RP , 202 _R can identify the identity of the entity receiving the OCSP response. . Co-located coordinators 202 _IP , 202 _RP , 202 _R and OCSP responders 204 _IP , 204 _RP , 204 _R can identify that they are receiving messages from local processes without any explicit authentication Is preferred. In this case, neither secure socket layer authentication nor signed requests are required. However, the OCSP responders 204 _IP , 204 _RP , 204 _R typically sign all requests, and the transaction coordinators 202 _IP , 202 _RP , 202 _R typically sign signed requests based on the Internet PKI OCSP specification. receive.

If the transaction coordinator 202 _IP , 202 _RP , 202 _R and the OCSP responder 204 _IP , 204 _RP , 204 _R are not co-located and it is not clear who they are communicating with, Authentication is necessary. The authentication for the request is preferably at the message level and may be at the session level. Similarly, authentication for responses is preferably message level and may be session level.

It should be understood that the transaction coordinator 202 _IP , 202 _RP , 202 _R typically does not perform an authentication match for the OCSP responder 204 _IP , 204 _RP , 204 _R. The reason is that the OCSP responders 204 _IP , 204 _RP , 204 _R typically do not request services from the transaction coordinators 202 _IP , 202 _RP , 202 _R.

Since the OCSP responder 204 is preferably located at the same location as each transaction coordinator 202, it is typically not necessary to provide a communication security mechanism for communication therebetween. Since the two components are housed in a physical environment that is completely under the control of one financial institution, protection can be provided by policy as opposed to implementing security mechanisms.
However, if these components are not co-located, it is preferable to protect the communication against network attacks that compromise the confidentiality or integrity of the communication. It is preferred to utilize SSL that provides this protection.

  In the preferred embodiment, each OCSP responder 204 is co-located with the respective transaction coordinator 202 so that the transaction coordinator 202 need not sign the OCS request. However, the OCSP responder 204 can sign the request if the specifications defined by the root entity 110 require it.

  If the OCSP response is signed, it is preferable to record the complete responder signature, especially if the response is directly related to the provided service. However, if the transaction coordinator 202 requests an OCSP response as part of an authentication match for a request for a service, the OCSP response is typically not recorded for non-repudiation purposes. The reason is that the OCSP verification is executed to confirm whether or not to process an incoming request, and is not part of the processing of the request itself. Only information related to request processing needs to be retained for non-repudiation purposes. In the preferred embodiment, the local OCSP response is that the trusted party 104 is also the issuing party 102 of the corresponding certificate, and the OCSP request verifies the certificate of the supplier certificate, for example during a verification request for the certificate. Recorded only when it is part of the service provision process.

  In the preferred embodiment, the OCSP responder 204 does not require the services of the transaction coordinator 202, so it is not necessary to record an OCSP response for security check purposes. Further, since the transaction coordinator 202 cannot inspect itself, there is no need to record the OCSP request generated by the transaction coordinator 202 for security inspection purposes.

  The transaction coordinator authenticates all requests from other transaction coordinators. This is typically accomplished either with a secure socket layer client certificate or with a financial institution that has set up a transaction coordinator to request a signature on all requests from other transaction coordinators. Is done.

In a preferred embodiment, a first transaction coordinator receiving a request from a second transaction coordinator performs an authentication match to determine whether the requesting transaction coordinator is authorized to make the request. This authentication verification is facilitated by providing all certified transaction coordinators 202 _IP , 202 _RP , 202 _R with an entrance to the transaction coordinator's customer database from which services are to be obtained. If the transaction coordinator 202 that has received a service request requires a signature, the requester is preferably able to confirm by the distinguished name that it exists in the guarantee certificate. Otherwise, verification from the utility certificate is preferably allowed only if secure socket layer client side authentication is required.

Communication between the trusted customer 108 and the transaction coordinator 202 _RP is preferably encrypted and requires server-side session authentication.
Participants may require that all requests sent from other transaction coordinators to that transaction coordinator be signed. Instead, the participant may require a secure socket layer client-side session certificate. The transaction coordinator 202 _IP , 202 _RP , 202 _R preferably signs all responses sent to other transaction coordinators.

Transaction coordinators 202 _IP , 202 _RP , 202 _R provide non-repudiation services. To that end, transaction coordinators 202 _IP , 202 _RP , 202 _R preferably record all responses regarding requests for requests received from other transaction coordinators.
Preferably, transaction coordinators 202 _IP , 202 _RP , 202 _R can record requests for services received. This allows the system administrator to detect potential attacks on the system, and allows the system administrator to check whether a request for service has been received after a key leak has occurred. Request inspection can also be used to support any possible billing dispute.

The preferred architectural components of the transaction coordinator are described in detail below.
The transaction coordinator component is preferably implemented as dedicated software code, although other software products may be utilized as described herein. In addition to this code, participants can write and execute their own business specification rules for the aforementioned certificate status verification service and other services provided by the four corner model.

  In the preferred embodiment, the supplier software development kit is utilized as a tool set to facilitate the interface between the transaction coordinator 202 and an account or other transaction coordinator. The software development kit is preferably integral with the transfer service component 306. The software development kit is preferably adapted to block all hypertext transfer protocol requests for the application's original web server at the website owned by the credit account 108. The software development kit preferably verifies whether the message requires a signature based on the definition rule set. The software development kit also authenticates the signature and public key certificate with the help of the hardware security module 230. A preferred embodiment of such an SDK is described in co-pending US patent application Ser. No. 09 / 657,604, “System and Method for Capacitating Access by Certificate to Related and Other Services”. The disclosure of which is incorporated herein by reference.

  Depending on the breadth of functionality provided by the software development kit, this usage can preferably be extended to other areas of transaction coordinator operations. Typically, certain changes and functionality additions are required to enable software development kits to be used by a transaction coordinator.

  The Microsoft® SQL server can be used as a database for storing billing data. Transaction coordinator 202 is preferably adapted to interact with the server via a database library. Alternatively, the interaction with the server may be performed using JAVA (registered trademark) Database Connectivity if the transaction coordinator is developed on JAVA (registered trademark). In addition, the database library may be written to other servers, which allows the Microsoft SQL server to be replaced with other databases without affecting the transaction coordinator 202.

The Microsoft SQL server preferably has the following functions.
(1) Online analysis processing (OLAP) to effectively analyze multiple information essential for reports, data analysis, decision making, and data modeling
(2) Disk storage architecture (3) Multi-phase query optimizer (4) Automatic statistics that enable the query optimizer to use the latest information to improve query efficiency (5) Minimal impact on operational system Active backups that provide high performance online backups in the state (6) merge replication that allows users to work alone and merge later (7) built-in priority based conflict resolution to resolve merge conflicts (8) Ability to publish data to the web (9) A data conversion service that captures and transforms data from multiple disparate sources (10) Ability to collate physical and logical databases (11) Fixed dynamic column level ( 12) Query optimizer that manages statistical collection and guarantees efficient method (13) Improves performance Intra-query parallel execution of a single query across multiple processors (14) decision support, data warehousing, and online analytical processing applications, where each step of a single query is executed in parallel to provide optimal response time Redesigned query processor (15) sort speed (16) multiple triggers per table and direct iteration of triggers (17) for optimal memory allocation and use Dynamic memory and dynamic memory management (18) parallel backup and utility scale restoration at device speed (19) smart read-ahead logic without the need for performance improvement and manual adjustment (20) runtime check of critical configurations

  Preferably, sufficient data is collected and stored to allow the entity that maintains the transaction coordinator to generate a bill for each transaction. For this purpose, in the preferred embodiment, all incoming and outgoing messages generated by the transaction coordinator are all stored in consecutive records in the database. Such messages include all requests received, all requests made, all responses generated, and all responses received. This confirms the availability of all the data necessary to generate a per transaction bill.

  Preferably, transaction coordinator 202 records bill data in a centralized and general manner. Participants may obtain records by writing their routines to extract bill data related to the parties from the centralized bill data. In addition to supplying data to the database, the data may be supplied in EXCEL® spreadsheets.

  In the preferred embodiment, as the time stamp component of the transaction coordinator, the Data Inc. The TimeServer Network Time Server ("TYMSYNC") registered trademark is used. TYMSYNC is a time-synchronized package managed by the United States Naval Observatory that reads time from the satellite positioning of the Nabster Global Positioning System with full accuracy to the nearest microsecond to Coordinated Universal Time. This product may be adapted to synchronize workstations with TCP / IP (transmission control protocol over internet protocol) and local area network (LAN) networks. Preferably, time is allocated within the network using a Network Time Protocol. TYMSYNC may be configured to continuously synchronize the computer system clock to Coordinated Universal Time. The times when requests and responses are generated and messages are received and transmitted are preferably stored for non-repudiation and auditing purposes.

  In the preferred embodiment, all communication with the trunk transaction coordinator 202 is performed over secure connections. Preferably, a secure socket layer encryption scheme for synchronous communication is used. The secure socket layer is used in a manner that is compatible with commercial / web server implementations and provides security and privacy over electronic networks such as the Internet. The secure socket layer is application independent so that the protocols are transparently layered on top of them.

  The secure socket layer provides confidentiality, data integrity, and authentication for all network communications. The secure socket layer typically ensures confidentiality by encrypting all data passing between communicating entities. When secure socket layer enabled client 95 and server 90 communicate for the first time, they agree on the protocol version and select the encryption algorithm. Preferably, the network approved encryption algorithm and key length are specified by the root entity 110.

  The secure socket layer also verifies data integrity, usually through the use of cryptography. If the message is not decoded correctly, the recipient can tell that someone has interfered with the message.

  The secure socket layer also supports server and client authentication, negotiates encryption keys, and authenticates the server before data is exchanged by higher level applications. Authentication is preferably provided through the use of digital signatures and public key certificates, which are exchanged when an electronic communication session is first established.

In a preferred embodiment, each transaction coordinator communicates using SMTP for sending S / MIME messages and over the HTTP protocol over an SSLv3 connection (HTTPS), receiving messages on the public Internet, and Can be sent. That is, each transaction coordinator is preferably adapted to support the following two communication modes:
• For HTTP-synchronous communication (ie HTTPS) via secure socket layer (SSLv3). HTTPS is a hypertext transfer protocol that integrates a secure socket layer between a web server and a web browser to securely transfer web pages. The use of HTTP keep alive is recommended.
• For asynchronous communication using S / MIMEv2-SMTP.

  In the preferred embodiment, each transaction coordinator behaves as an HTTPS server during communication with a relying customer and as an HTTPS client when making requests to the transaction coordinator at other financial institutions. Either way, all SSL communications for credential status checking may employ only one server authentication.

  In a preferred embodiment, each transaction coordinator may receive messages delivered via other transport protocols (eg, IIOP) approved by the root entity 110. Further, the participant may execute other transport protocols locally depending on the configuration. However, if there is no prior agreement, only HTTPS support should be tasked.

  In the preferred embodiment, a Valicert® registered OCSP responder is used for the certificate status check service 312. However, access to the OCSP responder 204 may be achieved using a library. Thus, a new OCSP responder vendor may be implemented by writing a new library.

  Preferably, the OCSP responder 204 determines the certificate status without using a certificate revocation list. The OCSP responder 204 may run most of the processing involved with certificate authorities and components that issue, verify, and revoke certificates, and may eliminate the need to download potentially large certificate revocation lists. Absent. Alternatively, these functions may be distributed among various components that may be given separate signature keys. For example, the function of issuing a certificate may be separated from the revocation function, and the component that performs these functions may comprise a separate signing key.

  In the preferred embodiment, a hardware security module is used as the signature component. The hardware security module is preferably a high speed device for signing and verifying signatures. A hardware security module is typically a networked hardware device that provides cryptographic services to an authenticated entity. A suitable hardware security module is manufactured by NCipher.

  In the preferred embodiment, the transaction coordinator 202 is always available for processing requests during its normal operating hours, which may be 24 hours a day, 7 days a week. A detailed requirements analysis of system availability should be performed to ensure that the system meets availability requirements. Since different parties may have different requirements, many different types of failures may occur. As is known, many different hardware and software vendors offer various options for high availability systems. However, these options may or may not be available for hardware and software selected by certain financial institutions.

  There are a number of known and potential hardware failures that may affect the transaction coordinator. For example, the power supply to the server may fail. Preferably, a plurality of redundant hot-swap power supplies are automatically converted to redundant power supplies. In the event of a server failure or crash, the transaction coordinator preferably comprises high availability clustering for automatic fail over. In addition, the transaction coordinator preferably includes a self-restart function to automatically reboot the server in the event of a network operating system (NOS) hang.

  The transaction coordinator also preferably includes a plurality of redundant hot-swap disk drives and a disk array controller for handling disk failures or crashes. The transaction coordinator also includes a network interface to provide support for redundant network interface cards (NICs) in case of NIC failure. In the event of a cooling system failure, the transaction coordinator preferably uses a redundant hot swap cooling system with hot swappable redundant fans that can be individually removed. The transaction coordinator also preferably includes an Intelligent Platform Management Interface to detect hardware and software failures. The intelligent platform management interface is an open specification that simplifies and standardizes communication for device management. In the case of memory corruption, the transaction preferably uses self-modifying memory. The self-correcting memory is preferably managed error checking and correction system memory and cache memory.

  In the case of an application crash, the transaction coordinator 202 preferably uses transaction processing monitoring to restart the application. The transaction coordinator may also run a redundant copy of the application, and the transaction processing monitor may transfer the transaction to the redundant copy. Certain application availability characteristics may require the application to be coded in a specific way that may also support address application crashes.

In the case of an operating system crash, the transaction is preferably forwarded to a standby machine supported by the network. Directory services including middleware such as CORBA may also be used to redirect new transaction requests to a new machine.
In addition to hardware and software availability products, a monitoring infrastructure is preferably used to monitor applications and networks.

  In a preferred embodiment, a software monitoring tool (such as Trivoli) is used to monitor the application. The tool is preferably configured to call an administrator in the event of an application failure. Network monitoring systems (such as those made with NetView) may also be used to allow an administrator to monitor the network.

  Preferably, custom written application daemons are used to simulate transactions. If these transactions fail, the system administrator may be notified. Database vendor tools may also be used for database monitoring. Most databases provide database monitoring tools that detect deadlocks and other database problems.

  The allocation approach for the transaction coordinator is preferably defined as a function of what the root entity 110 wishes to allocate to the parties involved. Application allocation may typically be performed via web download from the root entity 110. The web download mechanism may comprise selective download, authentication, and tracking.

  In preferred embodiments, the transaction coordinator may be adapted to support integration with existing operational systems, such as CICS, IMS, and other legacy systems.

  Participants may choose to use the overall transaction coordinator architecture and functionality described above, or instead use the transaction coordinator component and add their implementation to the component. You may choose. The web download approach is preferably configured to meet the various requirements of the parties involved. The download mechanism preferably includes at least three download options: (1) download transaction coordinator executable option (2) transaction coordinator source code and binary options and ( 3) Supply the transaction coordinator class source code option.

  The first option preferably corresponds to a participant who chooses to use the entire transaction coordinator. This option provides options for different platforms. The second option preferably corresponds to a participant who chooses to plug the above-described transaction coordinator component into his implementation. This download mechanism also provides options for different platforms. The third option preferably corresponds to a financial institution that chooses high endurance development and chooses only to use certain parts of the transaction coordinator implementation described above.

  Preferably, the download mechanism allows the financial institution to download not only the executable but also the source code. Since the downloaded executable may be used on its own and the source code may be used to develop other custom applications, the root entity 110 is preferably the root entity. Provide download access only to institutions that are trusted partners with 110 and are therefore authorized to use the transaction coordinator. Preferably this is accomplished via an authentication / authorization process.

  The root entity 110 may preferably keep track of which participants download a particular component of the transaction coordinator. Thus, the root entity 110 may determine the version of the transaction coordinator and / or its components that are being used at a certain time. The root entity 110 uses this information to track the version of the transaction coordinator (1) to charge the downloaded component from the financial institution and (2) for maintenance purposes. May be.

  Preferably, the transaction coordinator is adapted to be scalable to handle increasing users without significantly degrading performance. One step in meeting the scalability requirements for an application is to predict the potential growth of the user base. In general, an application with a distributed architecture facilitates higher scalability by allowing multiple distributed instances of a heavily loaded component to run at a certain time. The transaction coordinator architecture is preferably distributed and therefore supports scalability. Furthermore, the load capacity of the transaction coordinator is preferably aligned with the selected development machine. This information is used to select the appropriate hardware to support the expected number of transactions. Preferably, the transaction coordinator (and OCSP responder) is adapted to reliably handle up to 1000 confirmation transactions per minute.

  As described above, the OCSP check is usually not performed for utility certificates. If a signature is not required in the request, there is no appropriate mechanism to ensure that the secure socket layer client-side certificate has not been revoked. Preferably, if the secure socket layer certificate is revoked, the financial institution will be informed out of band (eg, a broadcast message) and the affected user will be removed from the relevant supplier database. The

  Each transaction coordinator typically trusts a set of certificates that are stored in its hardware security module. No OCSP check is performed for these certificates. If a revoked certificate is present in the hardware security module, it will not be detected during online processing. Preferably, the financial institution is notified that the certificate stored in the hardware security module has been revoked so that they can delete the certificate from the hardware security module.

  When a transaction coordinator acts as a client, it authenticates the server with which it is communicating. However, this check usually only ensures that the server is a certificate issued by a certificate authority trusted by the transaction coordinator. There is no check on the identity and status of the server itself. In the preferred embodiment, the transaction coordinator checks the server against a list of trusted servers and performs an OCSP check of the server's certificate. However, since little is gained by server intercepting requests, performance degradation due to these additional checks is usually not justified.

  Typically, the transaction coordinator does not have an automated process to detect potential attacks. Preferably, the system and security administrator inspection audit logs periodically to identify such potential attacks.

  Normally, requests that do not pass the client-side authentication check of the secure socket layer are not logged. If an attack (eg, denial of service attack) occurs at this level, there is no log to reference.

  In the preferred embodiment, the transaction coordinator is protected by a firewall. Preferably, the firewall component maintains a log of incoming requests.

  The transaction coordinator preferably comprises an automatic intrusion detection mechanism. These processes typically monitor incoming traffic or look for suspicious activity, scan the audit log, and take appropriate action if necessary.

  Transaction coordinators typically maintain logs for non-repudiation purposes. Often, however, the system does not include functionality to assist the user in retrieving the data necessary to support non-repudiation. The user manually searches through the log to find all supported data. In other embodiments, an automatic non-repudiation tool may be used to assist the user in this process.

  In the preferred embodiment, the transaction coordinator and OCSP responder employ a normal Internet timeout value for the certificate status check request. For other services, the timeout value may be set as appropriate for that service. In a preferred embodiment, the timeout value can be configured at the transaction coordinator.

  The following description outlines possible hardware and software implementations for the transaction coordinator.

  The main server used for the transaction coordinator may be a Hewlett Packard Netserver LH4. Preferably, the server has the following specifications: 4P2-450 MHZ processor, 512-768 MB RAM, 40-60 GB HD, RAID5 array, UPS, and external DLT40E DLT4000 tape drive for tape backup. Preferably, at least five workstations are used, each having the following uses: a P2400 MHz processor, 128 MB RAM, and 6 GB HD.

  The transaction coordinator is preferably platform independent so that it can be supported on the server based on Microsoft Windows NT® 4.0 / 2000, Sun Solaris, and Hewlett Packard HP-UX. . The implementation is preferably done in JAVA, but the coding may be done in C / C ++ as well.

  Windows NT Server w / Service Pack 3 may be used as the operating system. Microsoft Visual SourceSafe 6.0 may be used for source control. Symtec's Visual Cafe Professional Edition 3.0 (Java (R) Version 1.2) may be used for development. RSA Security Systems' SSL / J SDK may be used for secure socket layer implementation and is also required by XITI's JKIX.

  For signature verification, nCipher's hardware security module may be used. A Datakey smart card may be used for signatures from signature suppliers. Preferably, the OCSP responder is responsible for cryptographic functions and ASN. A toolkit is provided that provides an interface for one communication. In a preferred embodiment, XITI JKIX may be used for this purpose.

  For digital time stamps, Datum's TYMSYNC or other reliable time source may be used. An MS SQL server may be used for the database described above. A Metro Works Code Warrior may be used for development of portable C / C ++ development. CodeIntegrity may be used to perform a code integrity check to check code portability.

  Usually, the size of the data passing between the various entities helps with the performance of the public key infrastructure system. Messages submitted between entities are therefore preferably analyzed to estimate the size of the data to be transmitted. The analysis may be performed based on a certificate field defined in RFC 2459 with specific route extensions.

  The exact data length of the certificate field has a fixed length and is preferably considered during estimation. However, there are many fields that vary in length. For these fields, a free estimate of the size is preferably made (ie larger than small). Also, all message size estimates preferably include sizes for all extensions. That is, if the message allows five different extensions, the size is preferably calculated on the assumption that all five extensions have been sent with the request.

  FIG. 13 represents various message (estimated) sizes passing between system entities in the preferred embodiment. As shown in FIG. 13, the total estimated message size of the message passed from the subscribing customer 106 to the relying customer 108 is 2610 bytes. The message typically comprises two certificates, each of which is 1146 bytes, the certificate of the issuing participant signed by the root entity is 128 bytes, and the signature of the issuing party is 128 bytes and the HTTP header is 62 bytes.

  The total estimated message size of the message passed from the credit partner 108 to the credit partner 104 is 2022 bytes. The message typically comprises two requests, one for the signing party certificate, one for the issuer's certificate, each 55 bytes, and the message extension 210 bytes, The version number is 4 bytes, the name of the trusted party is 132 bytes, the signature of the trusted party is 128 bytes, the certificate of the trusted party is 1146 bytes, and the HTTP header is 62 bytes.

  The total estimated message size of a message passed from the trusted party 104 to the issuing party 102 is 1601 bytes. The message typically comprises a request for the signing party's certificate or the issuing party's certificate, which is 55 bytes, the message extension is 210 bytes, the root entity in the trusted party's transaction coordinator certificate The signature is 128 bytes, the trusted transaction coordinator certificate is 1146 bytes, and the HTTP header is 62 bytes.

  The total estimated message size of the message passed from the issuing party 102 to the trusted party 104 is 2086 bytes. The message typically comprises a response for either the signing party's certificate or the issuing party's certificate, which is 456 bytes, the message extension is 294 bytes, and the issuing party's certificate is 1146 bytes. The signature of the root entity is 128 bytes and the HTTP header is 62 bytes.

  The total estimated message size of the message passed from the credit partner 104 to the credit partner 108 is 2213 bytes. The message typically comprises a response regarding the signing party's certificate or the issuing party's certificate, which is 55 bytes, the message extension is 210 bytes, and the response from the trusted transaction coordinator is 127 bytes. The trusted transaction coordinator certificate has 1146 bytes, the trusted entity transaction coordinator certificate has 128 bytes for the root entity signature, and the HTTP header is 62 bytes.

  Details of the message size estimation for the different fields are given in the table below. Usually, the size of messages passed between entities is between 2K and 3K. Once the transaction volume is calculated, this information is preferably used to estimate the network load.

Certificate size-no extension or route specific instructions

Certificate extension-with root instruction and extension

OCSP request-with root instruction and extension

OCSP response-with root command and extension

  Valid request and response times for OCSP transactions and guaranteed transactions, and confirmation times for all transactions are preferably specified by the root entity 110. The following sections describe preferred performance targets for the transaction coordinator. The described response time specifically represents the system response time. Preferably, an elapsed time frame is also established at which manual processing (referring to the request for confirmation, requesting it, filing a claim, etc.) is completed.

  Preferably, the valid request and response time (ie, OCSP) is 10 seconds or less for all response time transactions within the route control infrastructure. Authorization outside the root infrastructure (from customer to customer or from customer to root) preferably does not exceed 60 seconds. The total round trip time preferably does not exceed 70 seconds. Preferably, the response time includes a waiting time on the Internet. The end-to-end response time is preferably the longest valid path (i.e., from the signing counterparty to the credit counterparty, to the credit counterparty, to the issuing counterparty, and to the root entity). Including.

  An example performance requirement would be: only 6 seconds between the certificate status check notification to the trusted transaction coordinator and receipt of the response, and caching is enabled The certificate of freshness (ie, including the status of the participant certificate in the message sent by the participant) is valid, the certificate chain of the two certificates is authorized, and the transaction Is a four-corner transaction, and the system entity goes to a certificate status check where response data is locally available when connected to a 10 Mbps LAN (not the Internet) It takes only 3 seconds to get a response.

  The warranty request response time includes an offline transaction. Preferably, these offline transactions do not exceed the eight hour window starting at the end of the business day.

  Response times for responses to lost, damaged or invalid certificate notifications preferably include offline transactions. Preferably, these offline transactions do not exceed one hour.

  Certificate revocation also preferably includes offline transactions. Preferably, these offline transactions do not exceed one hour.

  The transaction coordinator also preferably provides transaction confirmation. The online transaction request preferably receives a status confirmation including an incomplete request or response within 70 seconds. The transaction coordinator also preferably receives receipt of request status, incomplete request response, and transaction queuing for incomplete transactions for the search for incomplete transaction requests or responses. A method for storing is provided.

  The transaction coordinator also preferably has transaction recovery requirements. Proper system resource allocation preferably takes into account transaction roll-back.

  The transaction coordinator also preferably provides fail over requirements. In the preferred embodiment, the transaction coordinator provides system redundancy, system / hot backup, and redundancy within the public Internet.

  During development of the transaction coordinator, a performance baseline in the development environment is preferably established. This baseline information is used to improve the performance of application components on the development machine itself. However, to achieve the desired target performance, the appropriate production hardware that can support the expected number of transactions and the appropriate bandwidth network are usually placed in the correct location.

  The following section describes a preferred tuning method for higher performance of the transaction coordinator.

  The size of messages passing between entities may be able to be reduced by eliminating some or all of the certificates sent with each message. Typically, the message recipient knows the sender's identity (ie, the sender's distinguished name as it appears on the warranty certificate) and has access to his complete certification path. Many of the required certificates are also available from the local repository.

  The OCSP check that is performed as part of the authentication process is designed so that the supplier database reflects the revoked certificate, and the authentication check, as opposed to its distinguished name, and the user's distinguished name and Omitted when matching with certificate.

  In the preferred embodiment described above, the transaction coordinator stores raw transaction data and then parses the data to separately store a subset of the data for billing purposes. Alternatively, however, this functionality may be offloaded to offline processing that monitors the raw transactional database and extracts relevant billing data from the data stored in the database.

  Placing the transaction coordinator and OCSP responder in the same location eliminates the need to sign and verify requests and to establish a secure socket layer connection between these components.

  The use of a secure socket layer between financial institutions and during communication with the root entity 110 typically eliminates the need to digitally sign each request message. However, digitally signed requests provide greater security. Each participant preferably assesses the risks associated with redeeming performance and safety.

  Caching OCSP responses typically improves round trip time by reducing the time it takes to send and receive OCSP requests to the root entity. In the preferred embodiment, confirmation of the OCSP response is performed when the data is cached, as opposed to performing confirmation as part of online transaction processing.

  In a preferred embodiment, the transaction coordinator may use the cached response to cache the validity response and to validate the certificate. The period during which responses are cached is preferably set as policy matter by the root entity 110. This period will preferably be in the range of 4 to 5 minutes.

  When transaction coordinators implement the performance of using cached responses, they are preferably adapted to log their use for billing and auditing, as well as for non-repudiation purposes. The logged information preferably indicates that the cached response was used to authorize the certificate rather than the newly obtained response.

  For high value transactions, the client application may prefer to use a new response over a cached response. Thus, in a preferred embodiment, the transaction coordinator preferably obtains and uses a newly obtained validity response for an explicit request that uses a new response rather than a cached response.

  In a preferred embodiment, the responding recipient examines the status of the responder's certificate. Alternatively, to eliminate this second request, whenever the transaction coordinator sends a response to a trusted counterparty or other transaction coordinator, its proof (signed by the root) The status of the document may be included automatically.

  The following sections describe the transaction coordinator tests. Preferably, the transaction coordinator is tested for the items listed in this section.

  To provide structural flexibility, the transaction coordinator preferably has one or more hardware platforms (e.g., Microsoft Windows NT® 4.0 / 2000, Sun Solaris and Hewlett Packard HP-UX). Ported). This allows participants to select their hardware platform from a list of supported platforms. Preferably, a test is performed to ensure that the transaction coordinator is installed smoothly on each of the supported platforms. It is usually required to be able to test such suitable hardware.

  Preferably, a test is performed to verify that the transaction coordinator is installed and uninstalled on a clean Windows NT® machine.

  If the transaction coordinator is extended to support other operating systems, it is preferable to ensure that executables from the same source code can be installed on all supported operating systems. A test is performed to Appropriate hardware with an appropriate operating system may be required to perform these tests.

  Preferably, the transaction coordinator works with other third party vendor software tools. Interfaces to these software tools are preferably tested at the development site during the development and system testing phases. In addition, complex tests are typically performed at the trading partner site to ensure that the transaction coordinator interface with these tools is stable. This is done during the supplier / functionality test as described below.

  The function of the transaction coordinator is preferably tested during the development and system testing phases. Appropriate tools are used during these tests to ensure that all of the custom reton code is executed at least once. In another preferred test phase, the customer tests the function of the transaction coordinator.

  Security is an important part of the transaction coordinator. Preferably, a test is performed to ensure that data is securely transferred from one point to another. Preferably, a test case is created for comprehensively testing the safety aspects of the public key infrastructure.

  The messaging protocol definition for messages sent in system 200 and the certificate status protocol definition for system 200 are described in pending US Provisional Patent Application No. 60 / 231,319, filed on the same day as this application. It is described in the above application entitled Certificate Status Check (CSC) Protocol Definition, Transaction Coordinator Messaging Protocol Definition, and Transaction Coordinator Requirements, which is hereby incorporated by reference. In the preferred embodiment, each transaction coordinator supports this messaging protocol definition. Specifically, each transaction coordinator receives and sends all valid XML messages, logs and reports malformed messages, and responds to requests as defined in the messaging protocol definition. Thus, a valid XML message can be generated.

In an alternative embodiment, the system is instead implemented as an OCSP-centric model that does not employ the transaction coordinator 202. This alternative embodiment typically employs an enhanced OCSP responder that is adapted to provide significantly more functionality than that provided by a typical OCSP responder. In particular, the improved OCSP responder is adapted to provide the following additional features:
• Cryptographic communication using SSL • Logging of raw transactions for both requests and responses • Supplying a certificate chain with responses • Verifying the signature of the request, preferably using HSM • With requests Certificate chain authorization (some of which may be stored in a local database or HSM)
-Creation of a new request based on:-The value of the received request in the service lacator request extension-Authority information access extension in the certificate with the response-The response is new to these other Postponing processing on a request until it is received on a created request. That is, the function to synchronize the response to the request.
Transfer response when appropriate This alternative embodiment provides only a portion of the certificate status check service without the flexibility of adding new services. Nor is the claim executed in this alternative embodiment. Further, this alternative embodiment may cause vendor locking. Details of the pros and cons of this alternative embodiment are listed below.

FIG. 14 shows the transaction flow for this alternative embodiment. The message flow in FIG. 14 is summarized in the following table:

1. The signing customer (subscribing customer, SC) sends the signed data, signature, SC and IP certificate (optionally CSSD) to the relying customer (relying customer, RC).
2 The RC verifies the signature of the data sent by the SC, authorizes the SC's certificate chain, and then creates an OCSP request that includes the SC certificate number. This data is sent to the HSM for signature.
3 The OCSP request for the SC certificate signed by the RC is sent along with the RC certificate chain to the relying participant (RP) OCSP responder (OR). The entire certificate chain must be passed with the message.
4 The RP OCSP responder logs the request in its OCSP log.
The RP OCSP responder verifies the signature in the request and authorizes the RC certificate chain. All verification is performed in software. The entire chain (including the root) must be passed with the message so that signature / certificate chain verification can be performed. No checks are performed to confirm that the RC certificate has not been revoked.
5 RP OCSP responder creates a new request, including a single request received from the RC, and signs it with its HSM. Signed requests between financial institutions are not required. Instead, the root entity (ROOT) may require SSL client-side authentication, where confirmation / authorization / partner lookup is based on a certificate associated with the SSL connection.
6 The RP OCSP responder sends a signed OCSP request to the appropriate issuing related OCSP responder based on the value of the received request in the service locator request extension.
7 The IP OCSP responder logs the request in its OCSP log. The IP OCSP responder verifies the signature in the request and authorizes the RP OR certificate chain. All tests are performed in software. The entire chain (including the root) must be passed with the message in order for the signature / certificate chain verification to be performed.
8 The IP OCSP responder creates an OCSP request containing the certificate number of the RP OCSP responder and signs it using its HSM.
9 The IP OCSP responder then sends a request to the ROOT OCSP responder based on the authority information access extension in the certificate associated with the signature in the request received in step 4. IP
The OCSP responder waits for a response from the ROOT regarding the RP OCSP responder's certificate before issuing a response in the SC's certificate. This step may not be necessary if the IP requires only SSL client-side authentication and not a signed OCSP request.
10 ROOT OCSP responder logs request in its OCSP log. The ROOT OCSP responder verifies the signature in the request and authorizes the IP OCSP responder's certificate chain. Requests signed between financial institutions are not required. Instead, ROOT is where the confirmation / authorization / partner search is based on the certificate associated with the SSL connection.
May require SSL client side authentication.
11 The ROOT OCSP responder consults its local database to determine the status of the RP OCSP responder's certificate, then generates a response and signs it using its HSM.
12 ROOT OCSP responder then returns a response to the IP OCSP responder.
13 IP OCSP responder logs response to its OCSP log. The IP OCSP responder verifies the signature in the request and authorizes the root OCSP responder certificate chain. It is noted, however, that sufficient information to support non-repudiation may not be maintained in the log.
The entire certificate chain must be passed with the message.
The 14 IP OCSP responder then consults its local database to determine the status of the SC's certificate. The IP OCSP responder generates a response and signs it with its HSM.
15 IP OCSP responder sends signed response to RP OCSP responder.
The 16 RP OCSP responder logs the OCSP response in the OCSP log. The RP OCSP responder verifies the signature in the response and authorizes the IP OCSP responder certificate chain. The entire certificate chain must be passed with the message.
The 17 RP OCSP responder creates an OCSP request containing the number of the IP OCSP responder's certificate and signs it using its HSM.
The 18 RP OCSP responder then sends a request to the ROOT OCSP responder based on the authority information access extension in the certificate associated with the signature in the response received in step 14.
19 ROOT OCSP responder logs unprocessed requests in its OCSP log. The ROOT OCSP responder verifies the signature in the request and authorizes the entire certificate chain of the RP OCSP responder. The entire certificate chain must be passed with the message.
The 20 ROOT OCSP responder consults its local database to determine the status of the IP OCSP responder's certificate, then generates a response and signs it with its HSM.
21 ROOT OCSP responder sends a signed response to the OCSP responder.
The 22 RP OCSP responder logs the response in its OCSP log. The RP OCSP responder verifies the signature in the response and authorizes the root OCSP responder certificate chain. The certificate chain may be sent with the message, or part of the chain may be in the HSM or in a certificate verification database.
The 23 RP OCSP responder creates a response for the RC that contains the information it received in step 2 (eg, only once), and the status information about the certificate of the SC it received in step 14, and the HSM Use it to sign it.
The 24 RP OCSP responder returns a response to the RC.
25 The RC uses its HSM to verify the signature in the response and to authorize the RP's OCSP responder certificate chain. The certificate chain may be passed with the message or part of the chain may be in the HSM.
26 The RC creates an OCSP request that includes the IP certificate number. This data is sent to the HSM for signature.
27 The OCSP request for the IP certificate signed by the RC is accompanied by the trusted party (RP) along with the RC certificate chain.
Sent to the OCSP responder (OR). The entire certificate chain needs to be passed along with the message.
The 28 RP OCSP responder logs the request in its OCSP log. The RP OCSP responder verifies the signature in the request and authorizes the RC certificate chain. All verification is performed in software. The entire chain (including the root) must be passed with the message in order for the signature / certificate chain verification to be performed.
No check is performed to confirm that the RC certificate has not been revoked.
The 29 RP OCSP responder creates a new request, including a single request received from the RC, and signs it with its HSM. Requests signed between financial institutions are not required. Instead, ROOT may require SSL client-side authentication, where confirmation / authorization / partner lookup is based on a certificate associated with the SSL connection.
The 30 RP OCSP responder sends a signed OCSP request to the ROOT based on the value in the service locator request extension of the received request.
Send to the OCSP responder.
31 ROOT OCSP responder logs request to its OCSP log. The ROOT OCSP responder verifies the signature in the request and authorizes the RP OR's certificate chain. All verifications are performed in software. The entire chain (including the root) must be passed with the message in order for the signature / certificate chain verification to be performed.
The 32 ROOT OCSP responder examines its local database, then generates a response and signs it using its HSM to determine the status of the RP OCSP responder's certificate.
33 The ROOT OCSP responder then returns a response to the RP OCSP responder.
The 34 RP OCSP responder logs the response in its OCSP log. The RP OCSP responder verifies the signature in the response and authorizes the ROOT OCSP responder certificate chain. It is noted that there may not be enough information in the log to support non-repudiation. The entire certificate chain must be passed with the message.

This OCSP proxy-centric model has advantages and disadvantages compared to the transaction coordinator model described above. The pros and cons of this alternative embodiment are summarized in the following table:

  Technical and security requirements for the OCSP responder 204 are preferably specified by the root entity 110. An illustrative example of the requirement is described below.

Technical Requirements In the preferred embodiment, each OCSP responder 204 operates according to an Online Certificate Status Protocol (OCSP).

  In a preferred embodiment, when the OCSP responder 204 receives an OCSP request, it authorizes the requestor's certificate, authenticates the requester, and the requester performs a local status check on the requester's certificate to request Confirm whether you are a contracted system user with the recipient of the Requestor authentication may be accomplished using a signed OCSP request for inter-agency requests or through secure socket layer client authentication for supplier requests. Furthermore, the secure socket layer may be required to ensure the confidentiality of all requests.

  In the preferred embodiment, each OCSP responder 204 selects a peer server when making inter-agency requests based on the locator extension and local table of the requested service. In an alternative embodiment, this information may be obtained by a Lightweight Directory Access Protocol (LDAP) search.

  In the preferred embodiment, each OCSP responder 204 may cache a certificate according to the rules specified by the root entity 110.

  In the preferred embodiment, each OCSP responder 204 verifies that the inter-agency response is signed by an approved responder certificate. For inter-agency OCSP requests, the OCSP responder of the trusted party 204 preferably re-signs the response from, for example, the issuing party 102 before sending it to the requestor.

  In the preferred embodiment, each OCSP responder supports the following responses: “Cancel”, “Good”, and “Unknown”. If the client OCSP responder receives a “revoked” response for the particular certificate created at time t, the client OCSP responder will either have the certificate, or some certificate in the certificate chain of the certificate, Consider canceled before time t. As such, the client OCSP responder uses the private key corresponding to the checked certificate to transfer sufficient responsibility for the digitally signed document after time t to the server OCSP responder. Does not have.

  If the client OCSP responder receives a “good” response for a particular certificate made at time t, then the client OCSP responder receives the certificate and every other certificate in its certificate chain at time t. , All considered in good standing. As such, the client OCSP responder has sufficient ground to transfer responsibility for documents digitally signed before time t to the server OCSP responder.

  If the client OCSP responder receives an “unknown” response for a particular certificate created at time t, then the client OCSP responder has all of the certificate or one certificate in the certificate chain of the certificate Consider paid or unknown. As such, the client OCSP responder does not have sufficient grounds to transfer responsibility for documents digitally signed using the private key corresponding to the checked certificate to the server OCSP responder.

Security Requirements In the preferred embodiment, each OCSP responder 204 stores its private key in a hardware security module that meets the requirements established by the root entity 110.

In the preferred embodiment, each OCSP responder 204 uses separate keys for the server secure socket layer, the client secure socket layer, and the OCSP response.
In a preferred embodiment, each OCSP responder 204 can operate with a platform configuration that has been strengthened by the institution. Institution-enhanced platforms are approved and tested platforms for use within the institution's firewall.
In the preferred embodiment, each OCSP responder 204 maintains a detailed log of all signed requests and responses, all exceptions or errors, and all administrative and configuration operations.
In the preferred embodiment, each OCSP responder 204 uses strong authentication, such as secure socket layer client authentication, to authenticate the entity for all management transactions.
In the preferred embodiment, each OCSP responder 204 meets the minimum security requirements established by the root entity 110. In addition, the agency that maintains the OCSP responder may specify additional OCSP responder security rules.
In the preferred embodiment, each OCSP responder 204 is configured to be highly available and adoptable in an iterative manner. In addition, each OCSP responder preferably responds to all requests in less than a second.
An OCSP responder is usually not required to perform a utility certificate check. However, the OCSP responder may be configured to allow the requester unauthenticated access to the status of the utility certificate.
In the preferred embodiment, each OCSP responder may be required to function as an authenticated interface to the institutional repository. The implementation details of this preferred embodiment may be left to the entity that maintains the OCSP responder.

  In a preferred embodiment, each OCSP responder includes an additional interface to support additional functions. In particular, each OCSP responder preferably comprises an additional interface to make the information available to support the relevant customer service requirements. In addition, each OCSP responder may preferably include a standard interface defined by the agency for exposing system and event logs to the outside. Each OCSP responder may also include an interface for exposing information for the billing application. The billing data may be externalized in any form including a log, but preferably allows the requester to determine the type and volume of the request.

  In the preferred embodiment, the parties 102, 104 described in FIG. 1 are referred to as level 1 parties because they are issued digital certificates directly by the root entity 110. Thus, each participant's certificate chain starts at the root entity 110. Each level 1 participant relies on the root entity 110 to obtain the status of the certificates of other level 1 participants.

  In a further preferred embodiment, the system may include additional participants, referred to as level 2 participants. Each level 2 participant is preferably issued a digital certificate by the level 1 participant associated with it. These Level 2 parties may act as certificate authorities for their separate business partners and provide system services to the business partners.

  Level 1 participants preferably give the highest point of trust to Level 2 participants. As such, level 2 parties preferably report directly to the level 1 parties that they guarantee. Level 2 participants must also rely on the Level 1 parties they guarantee to obtain the status of other parties' certificates. Preferred embodiments including Level 1 and Level 2 partners further include systems and methods for providing pending United States Patent Application No. 09 / 502,450, filed February 11, 2000, certification related and other services, and Which is described in that application, which is hereby incorporated by reference.

  In a preferred embodiment, each participant collectively implements and maintains a hardware and software configuration baseline that identifies the operating environment of each participant's hardware and software components. As such, the configuration baseline serves as a configuration reference that facilitates day-to-day operation and management of the system. The baseline facilitates control of configuration changes made by one or more parties at a system-wide level. In addition, the baseline facilitates system-wide service recovery in the event of one or more certificate authority hardware or software failures.

  In the preferred embodiment, a master copy of the configuration baseline of the system is maintained by the root entity 110. Typically, the master copy is held by an executive of the root entity 110, such as a business vice president.

  In the preferred embodiment, the root entity 110 maintains a true and accurate record of the hardware and software configuration of the root entity 110. At least three copies of the root certificate authority's configuration baseline are maintained by the root entity 110 in the following three locations: (1) the same physical location as the root certificate authority, thereby operationally (2) A secure location outside the physical location of the root certificate authority but a controlled container; and (3) the root Offsite location with backup and archive records of entity 110. Other copies of this hardware and software configuration may be provided to the level 1 certificate authority at the discretion of the root entity 110.

In the preferred embodiment, each level 1 participant maintains a true and accurate record of the hardware and software configuration of its certificate authority architecture. Each Level 1 participant preferably prepares, maintains, and maintains at least three copies of its configuration baseline document in the following three locations: (1) Same for Level 1 Certificate Authority Physical location, so that operational changes are recorded as they occur; (2) a secure location that is external to the physical location of a Level 1 Certificate Authority, but in a controlled container And (3) an off-site location with level 1 certificate authority backup and archive records. In addition, each level 1 participant preferably provides a copy of its configuration baseline to the root entity 110.
In the preferred embodiment, Level 2 participants also maintain a true and accurate record of the hardware and software configuration of their certificate authority architecture. Each Level 2 participant prepares, maintains, and maintains at least three copies of its configuration document at the following three locations: (1) The same physical location as the Level 2 Certificate Authority , Thereby allowing them to be recorded when operational changes occur; (2) A secure location outside the physical location of a level 2 certificate authority but a controlled container And (3) off-site location with level 2 certificate authority backup and archive records. In addition, each Level 2 participant preferably provides its configuration baseline to its guaranteed Level 1 Certificate Authority.

  A format may be provided to facilitate documentation of hardware and software configurations. In the preferred embodiment, the hardware and software configuration of the root entity 110 and each participating certificate authority directory, OCSP responder, and Internet firewall are also documented.

  In the preferred embodiment, the root entity 110 has an important responsibility for configuration management at the system wide level. This responsibility is typically delegated to officers of the root entity 110, such as a business vice president. Each certificate authority preferably has technical operations staff with operational responsibility for maintaining an accurate record of the certificate authority's hardware and software configuration.

  In the preferred embodiment, each CA's initial configuration baseline is created by committing each subordinate CA's configuration baseline.

  In a preferred embodiment, configuration changes must comply with the following criteria: (1) Configuration changes must be required to address defined system requirements; (2) Configuration changes are (3) Operational platform configuration changes, in the case of root entities, by executives, such as business vice presidents, and Level 1 or Level 2 Certification Authorities. In this case, it must be approved by the highest executive responsible for the integrity of the certification authority; (4) Notification of configuration changes must be made to the affected party; (5 ) Configuration change Shall take into account the relevant configuration change criteria as set forth by the governing or standards setting body; and (6) Configuration changes shall be made public by announcing the date of change and the respective period of the previous configuration. Must be recorded. Each certificate authority typically stores configuration changes along with other stored materials such as backup tapes.

  In the preferred embodiment, the configuration baseline is implemented in conjunction with the root entity's system security policy and is an audited component of each certificate authority.

  While the invention has been described in connection with specific embodiments, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art in light of the foregoing description.

Claims (36)

A logging component;
A billing component;
A signature component;
At least one of a warranty service, a certificate status check service, or a payment compensation service; and a transaction processing monitor for linking the operation of the component and at least one service to one or more transactions;
A transaction processing system comprising: the one or more transactions having attributes of atomicity, consistency, isolation, and durability. A secure method for performing a certificate status check over an electronic network, comprising at least one electronic network, at least one signing counterparty, at least one credit counterparty, at least one issuing party, The method comprising at least one trusted party and at least one route comprising:
(A) issuing a smart card to the at least one signing partner; the signing partner sends data to be signed to the smart card; and the smart card includes: Generating a signature and returning the signature together with the signature supplier's certificate and the issuer's certificate; and (b) the signed data, the signature supplier's certificate, and the Sending an issuer's certificate to the at least one trusted customer; the at least one trusted customer confirms the signature of the signed data; and Creating an Online Certificate Status Protocol (OCSP) request including a certificate and the certificate of the issuer; and the OCSP request is signed Including the signature supplier's certificate and the issuer's certificate being sent to the hardware security module for; and the hardware security module includes the signature and the credit partner's certificate Said step of returning the certificate;
(C) transmitting the OCSP request including the certificate of the signing business partner and the certificate of the issuing business partner to the transaction coordinator of the credit business partner together with the certificate of the credit business partner;
The trusted party transaction coordinator checks a counterparty database to verify that the request has been signed by an existing trusted counterparty before processing the request; and The transaction coordinator stores raw transaction data in a raw transaction log, and stores billing data in a billing log; and the trusted transaction coordinator is sent with the service request; Using the trusted customer's certificate to verify the trusted customer's signature in the service request; and the trusted party's certificate and a root public key, both of which are the hardware Stored in a security module; and said The transaction coordinator for the business generates an OCSP request including the certificate of the trusted customer, signs it, and sends it to the co-located OCSP responder; and the OCSP responder sends the request Verifying the signature of the trusted counterparty, checking its local repository, and returning a response to the trusted transaction coordinator; and the trusted OCSP responder certifying the signed counterparty Generating a request for a certificate, signing it, and sending it to the issuing party along with the certificate of the trusted party;
(D) receiving the request for the signature supplier certificate by the transaction coordinator of the issuing party;
The issuing transaction coordinator checks its customer database to verify that an existing signing customer has signed the service request before processing the request; and The transaction coordinator stores the raw transaction data in its raw transaction log; and the issuing transaction coordinator stores billing data for the request in its charge log; and The issuing transaction coordinator includes a certificate of the trusted transaction coordinator sent with the request, and a hardware security module of the issuing transaction coordinator of the issuing party. Verifying the signature of the trusted transaction coordinator in the request by using the root public key stored in the request; and the issuing transaction coordinator confirming the trusted party proof Generating a signed OCSP request for the certificate and sending it to the root transaction coordinator;
(E) receiving the request for the trusted party's certificate by the root transaction coordinator, wherein the root transaction coordination includes processing the raw transaction data into the raw transaction Storing in a log and storing billing data in the billing log; and the root transaction coordinator verifies the signature in the request and sends the request to the OCSP responder. And the root OCSP responder checks its local repository and returns a response to the root transaction coordinator; and the root transaction coordinator sends a signed response, And wherein said step of transmitting to the transaction coordinator of the serial issuing participant;
(F) receiving the response by the transaction coordinator of the issuing party, and the transaction coordinator of the issuing party stores the response in its unprocessed transaction log for the purpose of non-repudiation And the issuing transaction coordinator generates an OCSP request from the request it received, including the signature supplier's certificate, signs it, and with its own certificate, Send it to the issuing OCSP responder; and the issuing OCSP responder verifies the signature in the request, generates a response, signs it, and sends the signed response to the Return to the transaction coordinator of the issue relationship; and the issue relationship The transaction coordinator checks the signature of the OCSP responder, and re-signing the response, and it its certificate and thighs, it, and said step of returning to the transaction coordinator of the trust relationship destination;
(G) receiving a response from the transaction coordinator of the credit-related party, wherein the transaction coordinator of the credit-related party sends the unprocessed response data to the unprocessed transaction log for the purpose of preventing non-repudiation. And the trusted transaction coordinator uses the issuing participant transaction coordinator's certificate and the root public key stored in its hardware security module, Verifying the signature in the response; and the trusted transaction coordinator generates an OCSP request for the issuer's certificate and sends it to the root transaction coordinator. Tsu and up;
(H) receiving a request by a transaction coordinator of the route, the transaction coordinator of the route storing the outstanding request data in its outstanding transaction log; and Storing in a billing log; and the root transaction coordinator verifies the signature in the request; and the root transaction coordinator sends the request to its OCSP responder; and the root OCSP responder Checks its local repository and returns a response to the root transaction coordinator; and the root transaction coordinator sends the response to the trusted transaction. Said step of sending to the zuction coordinator;
(I) receiving the response by the trusted transaction coordinator, the trusted transaction coordinator storing the response in its outstanding transaction log for non-repudiation purposes; And the trusted transaction coordinator generates a signed OCSP request for the issuer's certificate and sends it to the root transaction coordinator;
(J) receiving the request by the root transaction coordinator, the root transaction coordinator storing the outstanding request data in its outstanding transaction log; and the root transaction The coordinator stores relevant billing data in its billing log; and the root transaction coordinator verifies the signature in the request and sends the request to the OCSP responder; and the route The OCSP responder checks its local repository and returns a response to the root transaction coordinator; and the root transaction coordinator sends the signed response Said step of sending to the transaction coordinator of the associated party;
(K) receiving the response by the trusted transaction coordinator, the trusted transaction coordinator storing the response in its outstanding transaction log for non-repudiation purposes; And; and
The trusted party transaction coordinator generates an OCSP response from the response received from the issuing party transaction coordinator, signs it, and combines it with the trusted party certificate. Said step of transmitting first;
(L) receiving the response from the trusted customer, wherein the trusted customer uses the root public key certificate stored in its hardware security module to send the response Confirming; and to determine whether the certificate has been revoked, the trusted customer sends a request for the trusted party's certificate; and
(M) receiving the request by the trusted transaction coordinator, wherein the trusted transaction coordinator verifies the signature in the request, and the trusted supplier's certificate is Send a request to its local OCSP responder to verify that it was not revoked; and the trusted local OCSP responder returns a response to the trusted transaction coordinator; and the trusted The involved transaction coordinator sends a request in the trusted party certificate to the root transaction coordinator;
(N) receiving the request by the root transaction coordinator, wherein the root transaction coordinator verifies the signature in the request and determines the status of the trusted party's certificate; Checking the local OCSP responder; and the root transaction coordinator forwards the response received from the local OCSP responder to the trusted transaction coordinator; and (o) the trust Receiving the response by a related transaction coordinator, wherein the trusted transaction coordinator forwards the response to the trusted customer; (p) the credit Comprising the steps of: receiving the response by suppliers, the credit transaction destination, said method comprising the step of an acknowledgment to the signature suppliers. A system for supplying one or more services over a network:
A root entity, operating a root entity certificate authority and maintaining a root entity configuration baseline for the root entity certificate authority, wherein the root entity configuration baseline is The root entity, including the operating environment of the entity certificate authority;
At least one level 1 participant, operating a level 1 certificate authority and maintaining a configuration baseline for the level 1 certificate authority, wherein the configuration baseline for the level 1 certificate authority is the level Said Level 1 participants, including the operating environment of one certificate authority
At least one level 2 participant, operating a level 2 certificate authority and maintaining a configuration baseline for the level 2 certificate authority, wherein the configuration baseline for the level 2 certificate authority is the level 2 Level 2 parties, including the operating environment of 2 certificate authorities
The system comprising:   The system of claim 3, wherein the configuration baseline of each entity's certificate authority is recorded in a form.   The system of claim 3, wherein a copy of each entity's configuration baseline is maintained by the root entity.   4. The system of claim 3, further comprising a configuration manager, wherein the configuration manager is an officer of the root entity and further responsible for configuration management within the system. The system.   The certificate authority according to claim 3, wherein each certificate authority comprises a technical operations staff, the technical operations staff having a primary responsibility for managing records of the configuration of the entity certificate authority. System.   The system of claim 3, wherein the configuration baseline for each entity's certificate authority is maintained at the same physical location of the entity's certificate authority.   The system of claim 3, wherein the configuration baseline for each entity's certificate authority is maintained at a secure location outside the physical location of the entity's certificate authority.   The system of claim 3, wherein the configuration baseline for each entity's certificate authority is maintained at an off-site location.   The system of claim 3, wherein changes are made to the configuration baseline of an entity's certificate authority to address system requirements.   The system of claim 3, wherein affected parties are notified of changes to the configuration baseline of an entity's certificate authority.   4. The system of claim 3, wherein changes to an entity's certificate authority configuration baseline take into account configuration change criteria set forth by a governing body.   4. The system of claim 3, wherein changes to an entity's certificate authority configuration baseline take into account configuration change criteria set forth by a standards setting authority. Providing a certificate status check via a network including a plurality of entities including at least one root entity, at least one issuing party, and at least one trusted party, wherein each entity:
With the transaction coordinator;
An online certificate status protocol responder that checks the status of the certificate, receives an online certificate status request from the transaction coordinator, and sends an online certificate status response to the transaction coordinator; Said system comprising: said online certificate status protocol responder; and at least one hardware security module.   16. The system of claim 15, wherein the online certificate status protocol responder sends a revoked response associated with a checked certificate. The system, indicating that the certificate, ie one certificate in the certificate chain of the certificate, has been revoked before a certain time.   The system of claim 16, wherein the issuing party does not accept responsibility for documents signed after the specified time using a private key corresponding to the checked certificate. .   16. The system of claim 15, wherein the online certificate status protocol responder sends a good response related to a checked certificate, wherein the good response is the certificate and The system indicating that every other certificate in the certificate chain of the certificate has already been paid at a particular time.   The system of claim 18, wherein the issuer accepts responsibility for documents signed before the specified time using a private key corresponding to the checked certificate. .   16. The system of claim 15, wherein the online certificate status protocol responder sends an unknown response for a certificate, wherein the unknown response is the certificate, i.e., the certificate. The system indicating that one certificate in the certificate chain is unknown to have been paid at a particular time.   21. The issuer of claim 20, wherein the issuing party does not accept responsibility for documents signed prior to the specified time using a private key corresponding to the checked certificate. system.   The system of claim 15, wherein the online certificate status protocol responder stores its private key in a hardware security module.   The system of claim 15, wherein the online certificate status protocol responder meets a set of minimum security requirements established by the root entity. A system comprising a first customer, a second customer, a first customer, and a second customer, wherein the first customer is a customer of the first customer The second business partner is the second business partner, and each entity is authorized to authorize a certificate in the system provided with a digital certificate and an associated private key. The method is:
a) the first customer signs the data with its private key;
b) the first customer sends the signed data to the second customer;
c) the second customer generates an authorization request for the certificate of the first customer;
d) the second customer sends the authorization request for the certificate of the first customer to the second party;
e) the second party forwards the authorization request to the first party;
f) the first party sends a response to the authorization request to the second party; and g) the second party sends the response to the second customer. Said method comprising.   The method of claim 24, wherein the second business partner uses a hardware security module to sign the authorization request.   25. The method of claim 24, wherein each party stores data regarding the authorization request for non-repudiation.   The method of claim 24, wherein each party stores data regarding the authorization request for billing.   25. The partner of claim 24, wherein each participant checks a supplier database to verify that the authorization request has been received from an authorized entity before processing the request. the method of.   The method of claim 24, wherein each participant uses an online certificate status protocol responder to generate the authorization request. A system comprising a first customer, a second customer, a first customer, and a second customer, wherein the first customer is a customer of the first customer And wherein the second trading partner is the trading partner of the second partner and each entity is provided with a digital certificate and an associated private key.
a) the first customer signs the data with its private key;
b) the first customer sends the signed data and its certificate to the second customer;
c) the second customer generates a warranty request for the certificate of the first customer;
d) the second customer sends the guarantee request to the second party;
e) the second party forwards the guarantee request to the first party;
f) the first party determines whether a guarantee should be issued;
g) the first party sends the decision to the second party; and h) the second party sends the decision to the second customer. Said method comprising.   The method of claim 30, wherein the second customer uses a hardware security module to sign the warranty request.   31. The method of claim 30, wherein each participant stores data relating to the warranty request for non-repudiation prevention.   The method of claim 30, wherein each participant stores data relating to the warranty request for billing.   32. The method of claim 30, wherein each participant checks a trading partner database to verify that the request has been received from an authorized entity before processing the request. A system comprising a root entity, a first party, a second party, a first business partner, and a second business partner, wherein the first business partner is the first business partner The second business partner is the second business partner, and each entity receives a certificate in the system that is supplied with a digital certificate and an associated private key. The way to authorize is:
a) the second business partner generates an authorization request including the second party certificate; b) the second business partner includes the second party certificate. Sending a request to the second party;
c) the second party generates an authorization request for the certificate of the second party;
d) the second party sends the authorization request including the certificate of the second party to the root entity;
e) the root entity sends a response to the authorization request to the second party; and f) the second party sends the response to the second business partner. The method comprising:   36. The method of claim 35, wherein the second party uses an online certificate status protocol responder to generate the authorization request.

Images