|Numéro de publication||WO2002046861 A2|
|Type de publication||Demande|
|Numéro de demande||PCT/US2001/044078|
|Date de publication||13 juin 2002|
|Date de dépôt||26 nov. 2001|
|Date de priorité||27 nov. 2000|
|Autre référence de publication||WO2002046861A3|
|Numéro de publication||PCT/2001/44078, PCT/US/1/044078, PCT/US/1/44078, PCT/US/2001/044078, PCT/US/2001/44078, PCT/US1/044078, PCT/US1/44078, PCT/US1044078, PCT/US144078, PCT/US2001/044078, PCT/US2001/44078, PCT/US2001044078, PCT/US200144078, WO 0246861 A2, WO 0246861A2, WO 2002/046861 A2, WO 2002046861 A2, WO 2002046861A2, WO-A2-0246861, WO-A2-2002046861, WO0246861 A2, WO0246861A2, WO2002/046861A2, WO2002046861 A2, WO2002046861A2|
|Inventeurs||Gregory J. Meffert, Paul R. Ii Hastings, Mark C. Kurt, Donovan Mouriz|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Citations de brevets (4), Référencé par (6), Classifications (32), Événements juridiques (7)|
|Liens externes: Patentscope, Espacenet|
SYSTEMS AND METHODS FOR COMMUNICATING IN A BUSINESS ENVIRONMENT
BACKGROUND OF AN EXEMPLARY SYSTEM This Application claims the benefit of U.S. Application Serial No. 60/252,897 of Greg Meffert and Paul Hastings filed September November 27, 2000 for BUSINESS-TO- BUSINESS EXCHANGES WITH ENCRYPTED XML, the contents of which are herein incorporated by reference. This Application is a Continuation-in-Part of copending U.S. Application Serial No. 09/816,255 of Gregory J. Meffert, Donovan Mouriz, Paul R. Hastings II, Rick W. Wise and Douglas A. Laine filed March 26, 2001 for SECURED CONTENT DELIVERY SYSTEM AND METHOD.
A portion of this patent document contains material subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent document, or of the patent disclosure, as it appears in government files or records, but otherwise reserves all copyrights.
Field of the Invention
This invention relates generally to protection of information and, more particularly, systems and methods for communicating in a business environment.
Description of Related Art
Electronic commerce has grown and supplanted, in part, traditional methods of doing business with paper documents. These traditional paper methods include the use of physical "wet-ink" signatures, paper delivery systems and manual data entry. Electronic commerce has grown due to its efficiencies and speed compared to conducting business with paper. Conducting business with paper, however, can offer several advantages over conventional electronic commerce. These advantages include security and authentication.
A transaction with the paper process is slow, costly and laborious due, in part, to reliance on the delivery of physical paper and envelope. Although some conventional electronic commerce systems solve many of these problems, such systems have their own limitations and deficiencies as described below. For example, a method of security with electronic systems is to encrypt the entire file, deliver it to the recipient and allow the recipient to decrypt the file. A problem with this basic method is that the recipient may access the entire file, including portions of the file to which the recipient should not have access, and the sender may lose control over the digital content after it is sent to the recipient. One who obtains access to the recipient's private key may access the file.
SUMMARY OF INVENTION
It is an object of the present invention to provide systems and methods of communicating in a business environment.
To achieve this and other objects of the present invention, there is a method for a system having a first program executing in a first address space and a second program executing in a second address space. The method comprises receiving, in the first program, a first rule identifier, a first signal, and a second signal; sending the first rule identifier from the first program to the second program; receiving, in the second program, the first rule identifier sent in the previous step; conditionally sending a third signal to the first program, responsive to the received first rule identifier; and using the second signal and the third signal to decrypt the first signal.
According to another aspect of the present invention, a system comprises a first program executing in a first address space and a second program executing in a second address space, the first program including logic that receives a first rule identifier, a first signal, and a second signal; and logic that sends the first rule identifier from the first program to the second program. The second program includes logic that receives the first rule identifier, logic that conditionally sends a third signal to the first program, responsive to the received first rule identifier; and wherein the first program further includes logic that decrypts the first signal, responsive to the second signal and the third signal.
According to yet another aspect of the present invention, a system comprises means for receiving a data structure having a first rule identifier, a first signal, and a second signal; means for conditionally generating a third signal, responsive to the received first rule identifier; and means for decrypting the first signal, responsive to the second signal and the third signal.
According to yet another aspect of the present invention, there is a system for implementing encryption, decryption, authentication and digital signing of electronic data over an electronic system. The system comprises (a) an application program interface serving as a local agent that provides calls to subcomponents included within the Acme
Security API to perform certain requested functions; (b) an application program interface serving as a local agent that facilitates the transfer of electronic data through the store-and- forward technique using the Diffie-Hellman key agreement; (c) an application program interface serving as a local agent that provides encryption/decryption services at the file- level and tag-level, inclusive of an XML document parser; (d) an application that encrypts, decrypts, digitally signs and verifies an electronic message that is sent or received either directly from a similar application operating on an electronic device or with an intermediary program on an electronic device communicating with both applications; (e) DTDs, inclusive of an XML Schema, that facilitates the processing and mapping of data from an XML document for encrypting, decrypting, authenticating and digitally signing such XML document at the file-level and at the tag-level; (f) an electronic device connected to an electronic network that facilitates the creation, modification and compliance with rules related to the communication, authentication, encryption/decryption, digital signing and access at the file level and at the event-tag level; (g) an electronic device connected to an electronic network that facilitates generating, distribution, management, revocation and access to key-pairs and digital certificates used in a PKI- environment for encrypting, decrypting, authenticating and digitally signing an XML document at the file-level and at the tag-level; or (h) a pre-built XML-based syntax that facilitates the request of certain functions based on a one-to-one mapping between an XML tag and the Acme Security API referenced above.
According to yet another aspect of the present invention, a system comprising a local agent that stores, manages, uses or deletes public or private keys in a PKI-based encryption process in connection with functions requested by an application program interface or other local agent used for encrypting, decrypting, authenticating and digitally signing an XML document at the file-level and at the tag-level.
According to yet another aspect of the present invention, a system for implementing the exchange of encrypted data between multiple applications residing on an electronic network comprises (a) a program residing as a local agent at the sender application that sends encrypted HTTP requests either directly to a program residing as a local agent at the intended recipient application or indirectly through an intermediary program residing on an electronic device outside the firewall of the sender application and the recipient application; (b) an intermediary program residing on an electronic device outside the firewall for the sender application and the recipient application that converts an HTTP request to an HTTP response and forwards it to a program residing as a local agent at the recipient application; or (c) a program residing as a local agent at the recipient application that receives HTTP requests directly from the program residing locally at the sender application or HTTP responses from the intermediary program residing on an electronic device outside the firewall of the sender application and the recipient application.
According to yet another aspect of the present invention, there is a system maintained on a control server for creating, storing, managing, modifying and implementing content management and digital rights management rules on a file-by-file level or at a tag level.
According to yet another aspect of the present invention, there is a system for implementing encryption, decryption, authentication and digital signing of electronic data communicated via a wireless transmission by assigning x.509 credentials to such data.
According to yet another aspect of the present invention, there is method to control access to data transmitted to a recipient. The method comprises generating multiple symmetric keys; splitting a symmetric key into a first part and a second part; storing the first part into a document file, or an XML tag; storing the second in a server; and issuing the second part from the server, in accordance with pre-established rules.
According to yet another aspect of the present invention, there is a method for handling encryption, decryption, authentication and digital signing of electronic data over an electronic network through a distributed system of local agents and local application program interfaces that make calls to other software to perform functions used for encrypting, decrypting, authenticating and digitally signing an XML document at the file- level and at the tag-level.
According to yet another aspect of the present invention, there is method for exchanging encrypted data between multiple applications residing on an electronic network wherein (a) a local agent resides at the sending application for encryption and digital signing of the requested function at the file or the tag level; (b) an intermediary program resides on an electronic device outside of the firewall of the sending application and the recipient application to reconfigure a request sent by the sending application to a format that can traverse the firewall of the recipient application; and (c) a local agent resides at the recipient application for decryption and confirmation of the digital signature of the message originated by the sending application.
According to yet another aspect of the present invention, there is a method for handling specific functions requested by a local agent utilizing XML-based syntax and one-to-one mapping between an XML tag and an application program interface command to facilitate faster, more efficient deployment of a process to encrypt, decrypt, authenticate and digitally sign electronic data over an electronic network at the file and event tag levels. According to yet another aspect of the present invention, there is a method for handling the encryption, decryption, authentication and digital signing of messages originating from a wireless device and sent to an electronic device connected to an electronic network through the association of public and private keys to the sending wireless device.
BRIEF DESCRIPTION OF THE DRAWINGS
References are made to the following description taken in connection with the accompanying drawings, in which:
Fig. 1 is a diagram showing a first exemplary system.
Fig. 2 is a diagram showing a portion of the system shown in Fig. 1.
Fig. 3 is a diagram showing a data structure within a file shown in Fig. 2.
Fig. 4 is a diagram showing a portion of the data structure of Fig. 3 in more detail and in a decrypted format.
Fig. 5 is a diagram showing another portion of the data structure shown in Fig. 3 in more detail and in a decrypted format.
Fig. 6 is a screen display on an output device of the system of Fig. 2.
Fig. 7 is a diagram of a data structure in a server shown in Fig. 1.
Fig. 8 is a diagram of a second exemplary system.
Fig. 9 is a diagram of a third exemplary system.
Fig. 10 includes of Fig. 10A, which is a diagram of the encryption process of an exemplary system for streaming media, and Fig. 10B, which is a diagram of the decryption process of an exemplary system for streaming media.
Fig. 11 includes of two diagrams (Fig. 11 A and Fig. 1 IB) displaying the process utilized by an exemplary system to provide the Acme Secure Application Exchange.
Fig. 12 shows a flow chart of the processes performed by the Broker in the Acme Secure Application Exchange.
Fig. 13 shows a flow chart of the processes performed by the Proxy in the Acme Secure Application Exchange. Fig. 14 shows a flow chart of the processes performed by the Router in the Acme Secure Application Exchange.
Fig. 15 shows a diagram of how certain components of an exemplary system would be used in connection with wireless communication and the transfer of wireless messages.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS First Exemplary Embodiment
Fig. 1 shows a system that communicates information in a business environment, in accordance with a first preferred embodiment of the present invention. System 5 sends file 7 to system 10, via communications link 15. Link 15 may be through a computer network, or through a system of computer networks such as the Internet.
System 10 receives the file, and processes the file by using a message received from server 20, via communications link 17. More specifically, file 7 contains an Extensible Markup Language (XML) structure enclosing encrypted data 11, and decryption data 8. XML is a system for defining markup languages to transmit formatted data. Various XML-related standards are available from the World Wide Web Consortium (W3C), at www.w3.org.
When system 10 encounters the encrypted data, system 10 sends a message to server 20. Depending upon whether certain conditions are satisfied, server 20 may send a positive reply message back to system 10. The positive reply message contains decryption data 9.
Software processes data 8 with data 9 to decrypt data 11. More specifically, software 138 (Fig. 2) performs a bitwise exclusive OR (XOR) of data 8 with data 9, resulting in a decryption key for decrypting data 11. The resultant decryption key is symmetric in this example.
In other words, system 10 XORs bit 0 of data 8 with bit 0 of data 9, resulting in bit 0 of the result; system 10 XORs bit 1 of data 8 with bit 1 of data 9, resulting in bit 1 of the result; system 10 XORs bit 2 of data 8 with bit 2 of data 9, resulting in bit 2 of the result; etc.
Data 8 alone is insufficient to decrypt data 11. Data 9 alone is insufficient to decrypt data 11.
Fig.2 shows system 10 in more detail. System 10 includes a personal computer (PC) having CPU 135, and memory 153 for storing programs and data. Memory 153 includes random access memory (RAM) and disk memory. Various parts of programs and data in RAM may be transferred between RAM and disk memory using a virtual memory mapping scheme, as is well known in the art.
System 10 also includes CRT display 158, mouse input device 159, keyboard input device 161, and telecommunications hardware 157, which may include a modem, PSTN interface circuitry, TI interface circuitry, or wireless transceiver, for example.
Software 138 includes the functionality of conventional Web browser, such as Netscape Communicator™. Software 138 can download files from the Internet and interpret HTML for display on CRT 158, or some other output device. Software 138 receives file 8 via hardware 157.
Software 138 also includes logic to decrypt data 11 and otherwise process the contents of file 7.
Fig. 3 shows a simplified view of file 7 in more detail. File 7 includes an XML "Encrypt" tag structure delimited by tags 130 and 132. An element of "Encrypt" structures is the structure "EncryptedData" containing data that has been encrypted. "Encrypt" structures also include other elements. To enhance clarity of description, these other elements do not explicitly appear in Fig. 3. These other elements include information about the method used to encrypt the data within the "EncryptedData" structure. When software 138 encounters "Encrypt" tag 130, software 138 decrypts the data within the "EncryptedData" tag structure, using a private key, resulting in the data shown in Fig. 4.
In Fig. 4, the "Event" tag 140 and the "/Event" tag 142 delimit a rule. A rule identifier, authorized_to_view_sales_data, is embedded within the "Rule_Name" structure. When program 138 detects event tag 140, program 138 sends the rule name authorized_to_yiew_sales_data, to server 20. Program 138 also sends a public key infrastructure (PKI) Distinguished Name currently associated with the user of software 138. PKI provides a secure method for exchanging information. PKI includes cryptography and digital certificates.
When server 20 receives the message that contains the rule name authorized_to_view_sales_data and the Distinguished Name from system 10, server 20 returns decryption data 9 only if the Distinguished Name is in a table of persons who are actually authorized to view sales data at the present time.
The communication from the user of software 138 with server 20 is digitally signed with the private signing key corresponding to the digital certificate containing the
Distinguished Name sent to rules server 20. If the signature is not valid when received by server 20, server 20 considers the user to be unauthorized.
If system 10 does receive decryption data 9 in a reply from server 20, system performs the XOR operation data 9 with data 8, generating a key for decrypting data 11, and subsequently generating text 11' shown in Fig. 6.
Referring again to Fig. 3, file 7 includes another XML "Encrypt" tag structure, delimited by tags 158 and 159. When software 138 encounters "Encrypt" tag 158, software 138 decrypts the data within the "EncryptedData" tag structure, using the private key, resulting in the data shown in Fig. 5.
In Fig. 5, the "Event" tag 156 and the "/Event" tag 157 delimit another rule. A rule identifier, authorized_to_view_salaries, is embedded within the "RuleJSfame" structure. When program 138 detects event tag 156, program 138 sends the rule name authorized_to_view_salaries, to server 20. Program 138 also sends the PKI Distinguished Name currently associated with the user of software 138, via a digitally signed request to server 20.
When server 20 receives the message contain the rule name authorized_to_view_salaries and the Distinguished Name from system 10, server 20 returns decryption data only if the Distinguished Name is in a table of persons who are actually authorized to view salaries at the present time and only if the digital signature of the rule request is valid and the Distinguished Name of the signing certificate matches the Distinguished Name sent in with the rules request.
If system 10 does receive decryption data in a reply from server 20, system 10 performs the XOR operation, of the received decrypted data with data 152, generating a key for decrypting data 154, and subsequently generating text 154' shown in Fig. 6.
Fig. 7 shows a data structure in server 20. The data structure associates each rule name with respective decryption data. For example, authorized_to_view_sales_data is associated with decryption data 9, and authorized_to_view_salaries is associated with decryption data 181.
In summary, software 138 is a program that runs in an address space, and server 20 is another program that runs in another address space. Authorized_to_view_sales_data is a type of name that acts to identify a rule. Software 138 receives the rule delimited by tags 140 and 142; software 138 receives authorized_to_view_sales_data, encrypted data 11, and decryption data 8. Software 138 sends the rule name authorized_to_view_sales_data to server 20.
Server 20 executes a sub-program to determine whether the conditions for authorized_to_view_sales_data are satisfied for the user with the Distinguished Name. If the rule conditions are satisfied, server 20 sends decryption data 9 as a positive reply message to software 138. Otherwise, server 20 sends a negative reply message to software 148.
If software 138 received the positive reply message containing decryption data 9, software 138 performs an exclusive OR (XOR) operation of decryption data 9 with decryption data 8, resulting in a decryption key. Software 138 then decrypts data 11 with the decryption key.
As described above in connection with Figs. 3 and 4, system 5 generates file 7 by encrypting the rule delimited by tags 140 and 142, using an asymmetric public key of the user of system 10. System 5 envelopes the thus encrypted data in the enciypt tag structure delimited by tags 130 and 132 shown in Fig.3.
System 5 generates file 7 to include a second rule having a second rule name, authorized_to_yiew_salaries. This second rule is delimited by tags 156 and 157, having a common name (Event) with tags 140 and 142, respectively, used to delimit the first rule.
System 5 uses a symmetric key to encrypt data 11. In addition to the encrypt operation, system 5 splits the symmetric key into decryption data 8 and decryption data 9. System 5 performs this split by performing an XOR operation of the symmetric key with a bit pattern generated by a cryptographically secure random number generator. Decryption data 8 includes the bit pattern, and does not include the result of the XOR. Decryption data 9 includes the result of the XOR, and does not include the bit pattern.
System 5 inserts decryption data 8 into file 7. System 5 sends decryption data 9 to server 20 via communication path 16.
In addition to distributing parts of a single key as described above, there are other methods of distributing decryption data between a location in a file and a location outside the file. For example, one alternative is to doubly encrypt certain file-resident data, using a first key followed by a second key. In this alternative, the first key may be stored in the file, and the second key may be stored outside the file.
According to a more specific example of this alternative, data is first encrypted using a key (A), that is stored outside the file, to produce encrypted content B. Key (A) may be stored on a server. Then, the encrypted content B is encrypted again, this time using a symmetric key (C) to produce encrypted content D. Symmetric key C is then encrypted with the recipient's public key to produce encrypted data E (E is commonly referred to as a digital envelope for C). Both encrypted data D and encrypted data E are stored in the XML Document.
To decrypt the "doubly encrypted" data, the recipient first decrypts encrypted data E using his private decryption key to retrieve symmetric key C. Symmetric key C is then used to decrypt encrypted content D to produce encrypted content B. Then, a rules server is contacted to retrieve key A. If the key is retrieved, then encrypted content B is decrypted to produce the original content.
Second Exemplary System
Fig. 8 shows a second exemplary system. The second exemplary system provides a secure, robust method for transferring data from one business to another over the Internet, an Intranet or LAN. The preferred embodiment of an exemplary system takes XML data that is extracted from one business application (e.g., an Enterprise Resource Planning application or ERP) and sends it to another business application. This scenario might exist when a financial transaction from the first business is sent for processing to another business, as when a purchase order from one company is sent to another and the other company fills the order.
Application Server EC.01 facilitates communication between the business partners EC.02 and EC.03 via network EC.09, which may be the Internet, an intranet, or other type of network system. Server EC.01 listens for connections over standard Http protocol (typically using the standard Http Port- Port 80) and provides access to backend components such as the Store-And-Forward database EC.05, LDAP server EC.04 that stores digital certificates, the roaming private key storage database EC.06, the logging database EC.07, and the Rules Server EC.08.
Business partner EC.02 (A) includes logic to transmit data to another business (B).
Business partner EC.03 (B) includes logic to receive data from another business
LDAP Directory Server EC.04 stores digital certificates for trading partners.
Store-And-Forward database EC.05 stores packages sent prior to their retrieval.
Roaming private key database that can be used to distribute private keys to authorized clients who login to the Acme Application Server (EC.01). The term "Acme" refers to a hypothetical company and instead of any specific company or company product.
Logging database EC.07 stores audit information for the transaction. Examples of audit record entries include the time a package was sent, the time it was received, the Distinguished Name of the entity that received it, the data/time when a package was opened, etc.
Rules server EC.08 includes the functionality of server 20 described in connection with the first exemplary system. Server EC.08 processes Acme EVENT tag elements embedded within an XML document. The rules server is sent the rule data that is contained in clear-text within the event tag. Upon successful evaluation of the rule, the server sends the client (the entity processing the Event tag) the second half of a symmetric key needed to unlock the protected content.
ERP system EC.10 is the source for the XML data. The data extracted from this system is encoded using an industry-specific XML DTD, such as FpML for the financial market. The Acme XML Security application program interface (API) then transforms the DTD to include the industry-specific tags plus the Acme-specific XML tags, such as Encrypt, Signature, Event, and Log. This transformed data is available to the receiving application, or it may be removed when secure-processing (decryption, signature verification, etc.) is complete. In this manner, the receiving application can choose its level of integration with the Acme XML Security API.
An ERP system EC.11 is the destination for the data transfer.
The combination of ERP system EC.10 and business partner EC.02 includes the functionality system 5 described in connection with the first exemplary system above.
The combination of ERP system ECU and business partner EC.03 includes the functionality of system 10 described above in connection with the first exemplary system.
To obtain the public key of business partner B, business partner EC.02 sends a signed HTTP request to Application Server EC.01 requesting the digital certificate of the recipient. Next, business partnerEC.02 extracts data from ERP application EC.10 to produce an XML document using an industry-standard DTD.
Business partner EC.02 digitally signs the contents of the document and then encrypts the sensitive data contained within the document using the public key of business partner EC.03. Business partner EC.02 then sends this encrypted data, in file 7, to Application server EC.01. Application server EC.01 stores file 7 in store-and-forward database EC.05. Subsequently, upon receiving a request from business partnerEC.03, Application server EC.01 retrieves file 7 from store-and-forward database EC.05 and sends file 7 to business partner EC.03.
When business partner EC.03 receives file 7, business partner EC.03 decrypts document tags and verifies signatures within file 7. Business partner EC.03 processes any event tags in file 7 in the manner described above in connection with the first exemplary system.
In addition, either business partner EC.02 or EC.03 or Application Server EC.01 may include functionality to add signed XML log entries to the document itself, or to a log database EC.07.
Application server EC.01 may itself invoke rule processing from rules server EC.08, as represented by the dotted line between server EC.01 and server EC.08 in Fig. 8, when server EC.01 is itself a recipient of a package. This may occur in a business-to-business architecture where a company wishes an Event to be processed every time a particular document (or package of data) is transferred through the application server. For example, for audit trail information, one might have an Event tag insert a record into a database whenever the document is forwarded through the Application Server to another person or entity on the exchange.
Business partner EC.02 uses Diffie-Hellman key agreement to encrypt all communication with application server EC.01 ensuring the security of information passed between business partner EC.02 and application server EC.01. Business partner EC.03 uses Diffie-Hellman key agreement to encrypt all communication with application server EC.01 ensuring the security of information passed between business partner EC.03 and application server EC.01.
Using standard HTTP protocol, server EC.01 allows partner EC.02 to communicate with partner EC.03 despite a firewall that may exist between partner EC.02 and server EC.01, or between partner EC.03 and server EC.01.
Server EC.01 has a store and forward architecture, including database EC.05, for transmitting data from partner EC.02 to partner EC.03. Partner EC.03 polls the server EC.01 to see if any packages are waiting. In this manner, even receipt of encrypted documents can be done via standard firewall-compliant HTTP request-response mechanisms.
Thus, the second exemplary system may be applied to implement a virtual private network (VPN), for example.
Third Exemplary System
Fig. 9 shows a third exemplary system.
Server 401 facilitates communication between servers 410 and 411. Server 401 listens for connections over standard Http protocol (typically using the standard Http Port- Port 80) and provides access to database 407 for Store-And-Forward and logging.
Server 410 includes logic to transmit data to server 411.
Server 411 includes logic to receive data from server 410.
Database 407 stores audit information for the transaction. Examples of audit record entries include the time a package was sent, the time it was received, the Distinguished Name of the entity that received it, the data/time when a package was opened, etc.
PMI (Permission Management Infrastructure) server 408 includes the functionality of server 20 described in connection with the first exemplary system. Server 408 processes Acme EVENT tag elements embedded within an XML document. Server 411 sends rule data that is contained in clear-text within the event tag. Upon successful evaluation of the rule, server 408 sends server 411 (the entity processing the Event tag) the second half of a split symmetric key needed to unlock the protected content.
Server 410 is the source for the XML data. The data extracted from this system is encoded using an industry-specific XML DTD. The Acme XML Security API then transforms the DTD to include the industry-specific tags plus the Acme-specific XML tags, such as Encrypt, Signature, Event, and Log.
Server 411 is the destination for the data transfer.
Server 410 includes the functionality system 5 described in connection with the first exemplary system above. Preferably, server 410 employs the X.509 certificate standard.
Server 411 includes the functionality of system 10 described above in connection with the first exemplary system.
Server 410 extracts data from an application to produce an XML document using an industry-standard DTD.
Server 410 digitally signs the contents of the document and then encrypts the sensitive data contained within the document using the public key of Server 410 then sends this encrypted data, in file 7, to Server 411. Server 411 stores file 7 in store-and-forward database 407. Subsequently, upon receiving a request from Server 411, Server 401 retrieves file 7 from store-and-forward database 407 and sends file 7 to Server 411.
When Server 411 receives file 7, Server 411 decrypts document tags and verifies signatures within file 7. Server 411 processes any event tags in file 7 in the manner described above in connection with the first exemplary system.
In summary, because Server 410 uses PKI for encryption and signatures, and provides only part of the decryption key used for rule-processing, server 410 maintains data secrecy even from PMI rule server 408, which is processing the document and its rules.
Server 410 has functionality for signing or encrypting any XML content. However, in order for a 3rd party validating parser to accept the output of server 410, the DTD of the original document must support W3C Signature tags at any sub-document level that is to be signed, and it must support Acme encryption tags at any sub-document level that is to be encrypted. If the Acme XML security API is first used to parse the document, this limitation does not exist, as the resulting content will be decrypted for later handling by the 3rd party parser. In addition, encryption of an entire document does not have these same restrictions because the Acme DTD is used in the document header. More specifically, the document type is now that of AcmeSecurityDTD. When decrypted, the document is then transformed back to its original format when the "Encrypt" tag is removed.
Server 410 uses Diffie-Hellman key agreement to encrypt all communication with application server 401 ensuring the security of information passed between business server 410 and application server 401. Server 411 uses Diffie-Hellman key agreement to encrypt all communication with application server 401 ensuring the security of information passed between server 411 and application server 401.
Using standard HTTP protocol, server 401 allows server 410 to communicate with server 411 despite a firewall that may exist between server 410 and server 401, or between server 411 and server 401.
Server 401 has a store and forward architecture, including database 407, for transmitting data from partner server 410 to server 411. Server 411 polls the server 401 to see if any packages are waiting. In this manner, even receipt of encrypted documents can be done via standard firewall-compliant HTTP request-response mechanisms.
Thus, the third exemplary system may be applied to implement a virtual private network (VPN), for example.
Servers 410 and 411 include components of a package, "com.Acme.xmlsecurity," containing the Java classes described below.
Cert is a class that holds a certificate and the length of that certificate.
CertList is a class that maintains a list of certs (class = Cert).
CertProfile is a class that holds the profile information needed to generate a certificate.
Key is a class that holds various types of keys. XMLAttr is a class that holds an XML attribute-name/attribute-value pair to encapsulate element attributes.
XMLAttrList is a class that holds a list of Tags Attributes, stored in an array of XMLAttr classes.
XMLProxylnfo is a class that contains the XMLSecurity APIs proxy settings.
XMLSecretSplit is a class that encapsulates the two data objects generated when encrypting data and key splitting for use in secure, rule-based processing.
XMLSecurity is a class that implements the Acme XML tag-level security, allowing for signing, encrypting, verifying, and rule processing of individual XML tags.
XMLSecurityLog is a class that holds an XML business partner security log as a list security log entries.
XMLSecurityLogEntry is a class that holds the data for a security log entry including both the log text and the signature of the user who added the log entry.
XML tag is a class that encapsulates the data representing an XML tag.
XMLTagSearchData is a class that holds the data needed to find a tag or tags within an XML document for use by the encryption, signing, verification, and rule- processing engines.
The XML security class includes the following methods. EnableLog public abstract void EnableLog(boolean bLogAHSecureOps) Enable AUTOMATIC logging of security transactions (i.e. encryption, decryption, verification, signing, etc.) Parameters: bLogAHSecureOps - boolean
encryptSplitTag public abstract XMLSecretSplit encryptSplitTag(XMLTaQSearchData tag)
This method employs a key splitting technique to encrypt data such that two pieces are generated, neither one of them can alone decrypt. One copy is sent to the rule-processing server, and one is encoded in the XML document, typically within a PKI encrypted block.
Upon server rule validation, the client receives the missing piece of the data and can unlock the file. This method has the added benefit that the server is not storing a key that can alone unlock a file, and it can remove its copy of the "key" should the transaction ever become invalid.
Parameters: tag - com.Acme.xmlsecurity .XMLTagSearchData
EncryptTag public abstract boolean EncryptTag(XMLTagSearchData tag,
This method encrypts a given tag. The certlist parameter contains a list of all the recipients certificates
Parameters: tag - XMLTagSearchData certlist - CertList
OpenXML public abstract boolean OpenXML(java.net.URL uriDocument)
This method opens an XML document for processing
Parameters: uriDocument - java.net.URL
Returns: boolean (true if success, false otherwise)
ReadLog public abstract XMLSecurityLog ReadLogQ
Returns the security log for the open document
SignTag public abstract boolean SignTag(XMLTaciSearchData tag, java.lang.String szUserlD, java.lang.String szPassword) This method will sign a tag by looking up the users private signing key in a password- protected key database. Parameters: tag - XMLTagSearchData szUserlD - String szPassword - String Returns: boolean
VerifyCertSecurityLevel protected boolean VerifyCertSecurityLevel(Cert cert,
This method can be overridden by extending this class in order to provide Red/Green/Blue type of cert validation. The default implementation return 'true for all conditions. This function is called by the 'VerifyTag method
Parameters: cert - Cert tagSecurity - XMLTagSecurity
VerifyTag public abstract boolean VerifyTag(XMLTagSearchData tag) Return true if certificate used to sign tag is valid
Parameters: tag - XMLTagSearchData
WriteToLog public abstract boolean WriteToLog(java.lang. String szLogText, cert cert, byte[j password)
This method allows the developer to manually create a log entry. All log entries must be signed.!
Parameters: szLogText - String cert - Cert password - byte [j
Fourth Exemplary System
The fourth exemplary system relates to a system of distributed application program interfaces residing as local agents on an electronic network and communicating either directly with each other or communicating through an intermediary program residing on an electronic device that could be within or outside of the firewalls of the sending application and recipient application. The fourth system addresses encryption, decryption, authorization and validation at the file and tag levels and also allows encrypted messages to traverse firewalls using HTTP protocol. These two features are integrated and dependent in an end-to-end secure business communication solution by combining the ability to control access to data and content and also deliver such data and content to various electronic devices despite firewall restrictions. The fourth system is unique in numerous ways, including the ability to (a) facilitate encryption, decryption, authentication and digital signing of XML documents at the file level and at the tag-level, and (b) traverse firewalls to deliver such encrypted messages.
The local agents were referred to as BATS in U.S. Application Serial No. 60/252,897, the contents of which are herein incorporated by reference, and are now referred to herein as a specific application program interface residing on a local agent with a particular function (e.g., Acme Security API, CagentX Transport API, CagentX XML Security API, Proxy and Router). The intermediary programs residing on an electronic device were referred to as BASS, CLINK, or PMI in the U.S. Application Serial No. 60/252,897, the contents of which are herein incorporated by reference, and are now referred to as Acme Application Server, Broker or Acme Rules-Based Server.
A. Elements of Fourth Exemplary System
Issues regarding security, authentication, authorization and ultimately, non- repudiation are addressed by the fourth exemplary system. The fourth exemplary system includes of the following components: (i) Acme Security API; (ii) CagentX Transport API; (iii) CagentX XML Security API; (iv) Acme Secure Application Exchange; (v) Acme XML DTDs; (vi) Acme Rules-Based Server; and (vii) Acme Roaming Credential Server. The three subcomponents of the Acme Security API are (A) CagentX Security; (B) CagentX IO; and (C) CagentX Exceptions. The Acme Secure Application Exchange (which is also used to facilitate secure remote management) may include the following subcomponents: (1) Acme Secure Proxy; (2) Acme Secure Router; and (3) Acme Secure
1. Acme Security API: The Acme Security API provides support for digital signatures, including signing and verifying of the user, and encryption and decryption. It includes multiple algorithm selections, support for streaming input and output, operating system-independent, lightweight database storage, secret-key cryptographic support (including password-based encryption) and message-digest support. The software is written in Java and employs a Java, SOAP, Corba, or COM interface for ease-of-use in Microsoft-windows or Unix based systems. It includes, algorithms and encryption/decryption methods from RSA Security, Inc. that have been modified and applied by Applicants as described below.
The first subcomponent of the Acme Security API is CagentX Security. This package of software includes the objects used for key storage, certificate storage and serialization and basic security operations. The CagentX Security allows other applications ("base applications") to become PKI-enabled with very minimal customization/modification by including in the base applications commands that request the CagentX Security to perform a function. The benefit of using the Acme Security API to the developer of the base applications is that the developer does not need to have significant expertise in encryption/decryption, digital signing or verification to enable virtually any type of application to perform such functions.
CagentX Security includes certain Java classes such as (a) Security (basic support for encryption, decryption, digital signing and verification of digital signing together with a message digest and interfaces with the Acme Transport API); (b) SecurityDB (a platform-independent lightweight storage and retrieval mechanism for digital certificates and their corresponding private keys); (c) Key Agree (implementation of Diffie-Hellman key agreement that encrypts all communication between the TransportClient class and the Acme Application Server); (d) Base64 (static methods to Base-64 to encode binary data and Base-64 decode text data); (e) Cert (storage for a digital certificate); (f) CertList (storage for a list of Cert objects); (g) Key (provides for cryptographic key); (h) KeyList (storage for a list of Key objects); (i) CertProfile (certificate request information storage); (j) AcmeDBIndex (supports SecurityDB); and (k) AcmeData (serializes data in a cross- platform manner and transports multiple fields of data to/from the Acme Application Server). The second subcomponent of the Acme Security API is the CagentX IO. This package of software provides the streaming cryptographic functions of the Acme Security API. One limitation with CagentX Security package is that it requires the entire blob of data to be stored in memory during the encryption, decryption, signing or other functional process. This is inefficient and/or may not be possible for large files or streaming data. The CagentX IO performs the requested function as data flows from one data stream to the next data stream allowing arbitrarily large files to be encrypted, decrypted, signed, etc... as it is read. This process eliminates the current file-size limitations of a document to be encrypted, decrypted, signed, etc... and provides a much more efficient method to perform these functions. Fig. 10 includes a diagram illustrating the streaming encryption and decryption flow using CagentX IO.
The third subcomponent of the Acme Security API is the CagentX Exceptions. This package of software includes all of the various exceptions that can be thrown by the Acme Security API. Some of Java classes of the CagentX Exceptions includes the following classes: (a) Algorithm Not Supported Exception; (b) Buffer Initialization Exception; (c) Acme Security Exception; (d) Integer Conversion Exception; and (e) Number Out Of Bounds Exception.
2. CagentX Transport API: The second component is the CagentX Transport API that provides the communication mechanism between client-side applications and server applications. It allows for secure communication through the store- and-forward technique. It also provides for user and certificate authority/registration authority management functionality that allows administrators, among other things, to create and delete users, create user-groups, create and revoke user certificates and register digital certificates from other certificate authorities. After the user submits his or her proper login, the CagentX Transport API assists in the secure delivery of digital certificates and private keys via a secure connection created with Diffie-Hellman key agreement. All communication to/from the Acme application server using the CagentX Transport API meets HTTP 1.0 and HTTP 1.1 specifications. In addition, all administrative method calls (create user, delete user, delete Certificate, etc.) are digitally signed with the private signing key of the currently logged-in user for added protection against unauthorized transactions.
3. CagentX XML Security API: The third component is the CagentX XML Security API. This package of software contains all of the core cryptographic functionality of the Acme Security API plus the added feature of an XML Document parser capable of performing cryptographic functions on individual XMLTags. This component provides methods for tag-level encryption, decryption, signing, and verification. The uses for this component cover a wide range of applications from B2B exchanges to Digital Rights Management and rule-based encryption/decryption. While a standard for XML Signatures has been released by W3C, a similar standard for encrypted tags has not even reached the proposal stage within the organization. As a result, the Applicants have developed its own DTDs for encrypted tags, disclosed in Table 1 below:
<!-- DTD for XML Encryption http://www.acme.eom/xmlencrypt# — > <!-- These entity declarations permit the flexible parts of Signature content model to be easily expanded and changed — > <!ENTITY % Dsig.Signature SYSTEM 'xmldsig-core-schema.dtd'> %Dsig.Signature;
<!ENTITY % SecurePCDATA '(#PCDATA|Encrypt)*'> <!ELEMENT Encrypt (Encryptlnfo, EncryptedData, AcmeEncrypt.KeyInfo*)> <!ATTLIST Encrypt xmlns CDATA #FIXED "http://www.acme.eom/xmlencrypt#"
Id ID #IMPLIED >
<!ELEMENT EncryptedData (#PCDATA)> <!ELEMENT Encryptlnfo (EncryptionMethod)> <!ATTLIST Encryptlnfo
Id ID #IMPLIED >
<!ELEMENT EncryptionMethod (#PCDATA)> <!ATTLIST EncryptionMethod
Algorithm CDATA #REQUIRED
Id ID #IMPLIED
Encoding CDATA #REQUIRED >
<!-- This is BASE64 for now --> <!ELEMENT AcmeEncrypt.Keylnfo %Key.ANY;>
<!ATTLIST AcmeEncryptKeylnfo Id ID #IMPLIED
<!-- Key Information — >
<!ELEMENT AcmeEncryptKeyName (#PCDATA)>
<!ELEMENT AcmeEncryptKeyValue (#PCDATA)>
<!-- Key Information — >
<!-- Logging -->
<!ELEMENT Log (LogEntry | Encrypt | Signature)*>
Id ID #IMPLIED >
<!ELEMENT LogEntry (#PCDATA | Signature | Encrypt)*> <!ATTLIST LogEntry
Id ID #REQUIRED
Type CDATA #ιMPLIED
Date CDATA #IMPLIED >
The various classes of the CagentX XML Security API include (a) XML Security; (b) XML Document; (c) XML Tag Search Data; (d) XML Tag; (e) XML Attribution; and (f) XML Attribution List.
As to greater detail, the CagentX XML Security API parses through XML and other documents according to a known format (a "DTD") for communicating information regarding keys to use, encryption algorithms, location of LDAP or other public key storage, and any information related to tag-specific encryption or signing.
4. Acme Secure Application Exchange: The fourth component is the Acme Secure Application Exchange ("SAE"). The SAE includes of Acme Secure Proxy ("Proxy"), Acme Secure Router ("Router"), and Acme Secure Broker ("Broker"). The SAE facilitates the exchange of encrypted data and digital signatures between and among applications residing on the same network or on remote servers and computers. It provides automatic firewall/proxy negotiation and supports multiple proxy protocols (HTTP, FTP,
WML, etc.). It is written in Java and facilitates a scalable architecture. The Proxy secures HTTP requests, and decrypts and verifies HTTP responses from the requesting application, through the SAE. The Proxy is also Java-based with a small size of less than 500 kilobytes to facilitate speed of installation and to optimize minimal storage capacity. The Router decrypts and verifies secure HTTP requests, and encrypts HTTP responses from the responding application, through the SAE. The Broker configures, directs and brokers traffic and traverses firewalls between the Proxy and the Router and is installed in a DMZ environment with HTTP accessibility to both the Proxy and Router. To illustrate the process, the sending application generates a message that is formatted by the Proxy as an HTTP request and is sent through the Proxy residing on such application. The Proxy encrypts the request using the recipient's public key and sends such encrypted request through the sending application's network firewall to the Broker as an HTTP request with the HTTP header in clear text and the message encrypted. The Broker changes the clear text HTTP header information on the HTTP request to an HTTP response associated with the encrypted message. The recipient application periodically "pings" (e.g., sends a message every 10 seconds or immediately after the recipient's prior request is timed-out by the recipient application's firewall) the Broker with an HTTP request allowing the reconfigured HTTP response with the encrypted message to traverse the recipient application's network firewall as an HTTP response linked to the "ping" HTTP request. The Router that resides on the recipient application receives the reconfigured HTTP response (formerly the HTTP request sent by the sender application). The Router then decrypts the message associated with the reconfigured HTTP response with the recipient application's private key. The clear text message now causes the recipient application to perform some function.
For greater security and authentication, the sending application digitally signs the encrypted message prior to sending it to the Broker. As with other digital signature processes, the Proxy residing on the sending application creates a one-way hash value of the message and encrypts such message with the sending application's private key. The Broker reconfigures the HTTP request to an HTTP response as referenced above and forwards the message (inclusive of the encrypted hash value) to the recipient application. The Router at the recipient application decrypts the message with its private key as referenced above. It also decrypts the encrypted hash value with the sending application's public key (which authenticates the message as being sent by the sender application) and rehashes the decrypted message. This new hash value is compared to the decrypted hash value to confirm that no changes were made to the message after it was digitally signed by the sending application. This digital signature, authentication and confirmation process is similar to other commonly used digital signature processes.
The Broker is typically deployed in a DMZ environment in cases where a firewall exists between the applications and the Internet. It maintains session and IP information for appropriate brokering of secure messages. In cases where there is no firewall between sending and receiving application, the Proxy and Router communicate directly without use of the Broker in a "peer-to-peer" environment. A diagram of how the SAE works is set forth in Fig.il.
5. Acme XML DTDs: The fifth component is the Acme XML DTDs, described in connection with Table 1 above. A DTD is a document type definition that defines the valid syntax for a particular XML document. The Acme XML DTDs relate to encrypted tags of XML documents.
6. Acme Rules-Based Server: The sixth component is the Acme Rules-Based Server. This server application allows the administrators and other users to establish, modify and eliminate rules related to communication, authentication, encryption/decryption, digital signing and other functions. It employs multiple protocols (HTTP, SSL, FTP, etc...). It passes a unique identifier that identifies the rule being verified and the parameters that are used in the verification to the Acme Security API. Each rule has its own pair of secret-split keys that are explained in greater detail in the succeeding paragraph. If the rule is validated, then the Acme Rules-Based Server sends one-half of the secret-key split to the Acme Security API. In that each rule has its own key pair, several keys could be transmitted to the Acme Security API at one time if several rules are established to accomplish a particular function. Rules may optionally be stored or imbedded into the header of the protected document.
The other half of the key resides within the XML document. An exemplary system incorporates a "secret-splitting" process that splits a single symmetric key into two pieces of equal length. The complete key cannot be reconstructed without the combination of both halves of the split-secret. The complete key is necessary to perform a function related to the data or document being transmitted to the Acme Security API. For example, if the recipient is only entitled to view certain data in an XML document, the Rules-Based Server will only release half of the appropriate keys to the recipient allowing the recipient, automatically through the Acme Security API, to view certain data while other data remains encrypted.
By storing one-half of the key on the Rules-Based Server and the other half of the key within the XML document and then separating the XML document (residing at client's server or computer utilizing the Acme Security API) from the Rules-Based Server, the creator of the event is assured that third parties, including administrators of the Rules- Based Server, cannot perform the applicable function associated with the XML document (e.g., decrypting certain data). Also, the recipient cannot retrieve the content if the rules server does not allow him to retrieve the second part of the key. Third-party attackers or those with access to the Rule-Based Server itself (i.e., people who are not intended recipients) cannot open the message content because (1) they do not possess the private key to decrypt the first half of the secret-split symmetric key (assuming that 1 of the particular key pair is encrypted with the recipient's public key), and (2) they will not have the login credentials to retrieve the second part of the key from the Rules-Based Server. To the extent that the XML document resides at the Rules-Based Server prior to delivery to the recipient, greater security and control can be implemented by encrypting the XML document with the recipient's public key. The document can only be decrypted with the recipient's private key that resides with the recipient (and not on the Rules-Based Server). As stated previously, rules can be established at the XML event tag-level. This process facilitates decrypting individual content contained within an XML document based on one or more designated rules for the recipient, or controlling more complicated workflow applications that launch a process (that is identified in the encrypted content of XML event tag) when a recipient processes the XML event tag. For example, this more complicated workflow process could be a notification (email, HTTP post, etc.), an external application, or anything that a developer wants his program to do in response to the event. An exemplary system offers the flexibility of event processing without enforcing constraint over what an application developer is allowed to do with the events. An exemplary system splits the symmetric key in the following manner. The original key is Exclusive OR'd with a random bit pattern (which is generated by a cryptographically secure random number generator). An Exclusive OR is a binary operation that results in a logical true (1) if two inputs are of opposite polarity. So, the output is true only if the two inputs are different. The random bit pattern is the first part of the "split" and the result of the Exclusive OR is the second part of the split. When the two pieces are once again Exclusive OR'd together, the result is the original key that facilitates the performance of the particular function.
7. Acme Roaming Credentials Server: The seventh component is the Acme Roaming Credentials Server. This server is described in detail in the utility United States Patent Application entitled "Secure Content Delivery System and Method," S/N
09/816,255, and filed on March 26, 2001, the contents of which are incorporated herein by reference in their entirety.
8. XML Messaging Extension: The final component is the XML Messaging Extension to CagentX for the Acme Security API. The Acme Security API may need programming prior to implementation at the client side in order to handle specific functions. The XML Messaging Extension is an XML-based syntax that facilitates the request of certain functions performed by the Acme Security API without the need of a developer to configure, customize or program the Acme Security API Java-code. This messaging system can work both with XML data and with data of an arbitrary text or binary format. In the case with original XML data, additional flexibility can be gained by combining the XML Messaging Extension with the W3C standard XSLT. By doing this, any DTD can be used as the source of encryption and signing instructions for the XML Messaging Extension engine, thus minimizing integration efforts into existing processes. The basic structure of the XML Messaging Extension is a one-to-one mapping between an XML tag and an Acme Security API call, with some higher-level tags provided for convenience. So, an <ENCRYPT> tag would map to a com.Acme.cagentx.security.Security.Encrypt() method, and so forth. The tags are organized according to targets (identified by the <TARGET> tag), and are processed sequentially.
For example, the XML script necessary for the XML Messaging Extension to request a function by the Acme Security API is as follows: <TARGET id="Samplel" destination=file://samplel .out> <ENCRYPT id=Encl>
<RETRIEVAL method=LDAP, base="c=US", host="ldap.cerita.com">
<TRANSPORT protocoHHTTP method=post uri=HTTP://responder .Acme.com> <SOURCE id=Tranl refid=Encl transform=base64/>
The foregoing example would take the input file "sample Lin", encrypt it with the public key for "cn=JoeTest" and post it to the HTTP server "responder.Acme.com". In this way, several operations can be linked together to allow complicated workflow processing to take place without having to understand any specific programming language. Encryption algorithms can also be specified along with LDAP locations and tag level encryption and signing instructions. A GUI XML script creation tool provides ease of use and implementation for non-programmers.
For the case where some programming expertise is available, such as is the case of web development, the XML Messaging Extension processing engine is optionally packaged into a Java applet that takes, as its parameters, an input file location and script file location. This enables the web developer to collect data from the user, perform cryptographic operations via the XML Messaging Extension, and submit the result. All of the processing is done at the client-side so that digital signature operations can be deemed non-reputable if executed in the proper environment, and encryption operations can utilize maximum protection with user data.
Fig. 10A represents an encryption system that utilizes Acme's streaming security API to streamline data processing.
The items shown in Fig. 10A are as follows:
The streaming encryption process works in the following manner. Data from an application (#200) is sent in stream form (#201) to a Compression Stream (#202) where it is reduced in size. The compressed data stream is then written to a PKEncryptOutputStream (#203) where it is encrypted and then routed to another Output Stream (#204) where it is formatted for sending across whatever medium is necessary (such as the internet). The result is the compressed, encrypted, output-formatted data #205.
The process described above is only an example as to what can be done with the streaming architecture presented in this patent. The Acme Streaming Security API offers many Output Streams that can encrypt/decrypt using symmetric and asymmetric ciphers, sign/verify using various Public Key signature algorithms, and encode/decode data using the binary-to-ASCII Base64 Encoding/Decoding algorithm. Any of these streams can be "chained" together as has been done in this example (where a compression stream was chained with a Public-Key Encryption stream) to form a complicated, single-pass, data processing chain.
Fig. 10B represents a decryption system that utilizes Acme's streaming security API to streamline data processing.
The items shown in Fig. 10B are as follows:
The streaming decryption process works like this. Data from the Internet #300 (or some other transport medium) is read in as a stream (#301). The transport input stream (#301) removes whatever headers and formatting were added to facilitate the transportation of the data, and the stream is passed the decryption input stream #302. The particular decryption input stream selected for this example is the PKDecryptlnputStream from Acme's CagentX IO library. This stream decrypts data that was encrypted using the PKEncryptOutputStream class. The decrypted data is then passed to a decompression stream (#303), and the resulting decompressed data is passed to the application input stream (#304). At the end of the process, the final application data #305 has been read from the transport medium, decrypted, decompressed, and delivered into the application in a single-pass, efficient, data-processing technique made possible by the layered streaming architecture of the CagentX streaming library.
The process described above is only an example as to what can be done with the streaming architecture presented in this patent. The Acme Streaming Security API offers many Input Streams that can encrypt/decrypt using symmetric and asymmetric ciphers, sign/verify digital signatures using various Public Key signature algorithms, and encode/decode data using the Base64 Encoding/Decoding algorithm. Any of these streams can be "chained" together as has been done in this example (where a compression stream was chained with a Public-Key Decryption stream) to form a complicated, single-pass, data processing chain.
Fig. 11 shows an exemplary system utilizing Acme's Secure Application Exchange
(SAE) components, which are in turn built from Acme's CagentX API. In this embodiment, an end-user (items #100 and #101) has the ability to manage a remote database (item #130) in a secure, authorized manner not previously possible in a practical application environment. Fig. 11A depicts the overall system, while Fig lb emphasizes the communications mechanisms employed by Acme's SAE design.
The items shown in Fig. 11 are as follows:
This embodiment represents the typical case in which the resources at both ends of the communication channel (the database administrator and the database) are behind separate firewalls and typically are not allowed to communicate directly. Acme's SAE architecture does allow the secured communication to take place, despite the firewall restrictions; and it provides a level of security and authentication over and above what the firewall and end-user/server applications currently provide.
The process begins with the SAE Router (#113) "registering" with the SAE Broker (#112). To facilitate firewall-friendly communication, this registration (and all communication between the router/proxy and the broker for that matter) is formulated into HTTP Requests as per RFC2068 and RFC2616. The router will automatically "reregister" with the Broker any time it has not received a remote connection within a configurable timeout period, or whenever a remote connection is made. This allows the Router to accept multiple remote connections, as is a typical requirement for server-based applications. This registration includes the server application's IP address, the server application's communications port, and the server application's Distinguished Name from its X509 digital certificate. The registration data (as well as all communication between SAE components) is digitally signed for subsequent verification by the remote application. A client application may connect to this Router (and hence, to the server application "connected" to the Router) by specifying either the application's IP Address, or the application's Distinguished Name.
Next, when the client (#100 or #101) launches an application that needs to connect with the remote database #130, the SAE Secure Proxy connects to the Broker and tries to establish the communication. The Secure Proxy (like its router counterpart) includes its Distinguished Name in the connection request, and it digitally signs the connection request. The request is formatted into an HTTP request so that it is allowed to pass through the corporate firewall (#120). Once the Broker receives the connection request and finds a matching registration, it reformats the request (simply by changing the HTTP headers) into an HTTP Response that is sent to the SAE Router (#113). The Router then decrypts the message received, verifies its digital signature, verifies the validity of the signer's (#110 or #111) certificate, and passes the application data to the server if validation succeeds. This connection is assigned a unique identifier, and all subsequent communications between this Proxy and Router through the Broker reference this identifier to allow for continuous HTTPRequest/HTTPResponse pairs to be associated with the same connection. Once connection is established, the client (#100 or #101) can communicate with the server (#130) as it would in a normal, non- Acme-enabled, manner. The difference now is that the communication is digitally signed and encrypted for authentication and privacy.
Fig. 12 shows a flow chart of the processes performed by the Broker in the Acme Secure Application Exchange. The Broker is an application that resides outside both Proxy-side and Router-side firewalls. Its purpose is to route communication between the two end-entities (Proxy and Router) in a firewall-friendly manner. It does not perform any security operations (encryption, decryption, signing, or verifying), and it does not store any data other than connection-related data. As a result of its simplicity, it is highly efficient and scalable.
Broker communication begins when an incoming HTTP Request is made. The Broker reads the command encapsulated within the HTTP request's "post" data and determines whether the request is coming from a client-side Proxy, or a server-side Router. If the command is a "Connect" command, the requestor is a Proxy and the communication begins at step B.Ol on the Broker Communications flowchart. If the command is a "Register" command, the requestor is a Router and communication begins at step B.20 on the flowchart.
Proxy connection to Broker: After receiving the Connect request [B.02], the broker extracts the DN and/or IP Address identifying the requested Server. If the requestor is currently in the pool of servers accepting client connections, the broker sends the Connect command to the server [B.06] as an HTTP Response.
The reason the Connect command is sent as an HTTP Response is that firewalls will typically block inbound TCP/IP traffic that is not a direct response to a request coming from behind the firewall. In this case, the HTTP Response is actually a response to the Router's Register command (described below). During the transformation of the inbound Connect command from an HTTP Request (sent by the Proxy) to an outbound HTTP Response (as sent to the Router), only the HTTP headers are altered; specifically, the HTTP command line itself is changed from the Request format to the HTTP Response format.
Next, in step B.07, the Router verifies the signature of the Proxy's Connect command. If the signature is valid and the client is authorized to connect to the server attached to the router, the Ack flag on the Router is set to Success (B.08) and the Router sends the digitally signed Acknowledgement to the Broker (B.10) in an HTTP Request. If the signature is invalid, or if the client is not authorized to connect to the server attached to the router, the Router set the Ack flag to Failed (B.09) and the Router sends the digitally signed Acknowledgement to the Broker (B.10). The Broker then sends the acknowledgement to the Proxy as an HTTP Response (B.l 1).
This HTTP Response is in response to the HTTP Request the Proxy used to issue the Connect command.
If the acknowledgement received by the Proxy indicates a connection failure (test in B.12), then the Proxy (B.13) closes the connection. If the connection is successful (test in B.12), then communication between the Proxy and the Router begins in B.14. In steps B.14 - B.l 7, the Broker (as with previous connection-protocol-related communications) merely acts as a relay, transforming HTTP Requests to HTTP Responses and routing the data from one side of the communications channel to another. In step B.14, the Proxy digitally signs and encrypts data sent from the application attached to the Proxy and sends it to the Broker as an HTTP Request. In step B.l 5, the Broker transforms the HTTP' Request into an HTTP Response and sends the data to the Router. In step B.l 6, the Router signs and encrypts data from the server attached to the router and sends it to the Broker as an HTTP Request. In step B.l 7, the Broker transforms the HTTP Request into an HTTP Response and sends the data to the Proxy. Steps B.14 through B.l 7 repeat until the Proxy or the Router terminates the communication.
Router connection to Broker: After receiving the Register request [B.20] from the router, the broker extracts the DN and/or IP Address identifying the Server connected to the router. It then checks to see if any clients (proxies) are waiting for a connection to the new registered server(router) [B.l 8]. If no clients are waiting for a connection to the router, the router connection is placed in a pool of available server connections [B.19]. If there is client waiting to connect with this server the flowchart continues as with the case outlined in the "Proxy Connect to Broker" section. Specifically, the broker sends the Connect command received from the proxy to the Router [B.06] as an HTTP Response. Next, in step B.07, the Router verifies the signature of the Proxy's Connect command. If the signature is valid and the client is authorized to connect to the server attached to the Router, the Ack flag on the Router is set to Success (B.08) and the Router sends the digitally signed Acknowledgement to the Broker (B.10) in an HTTP Request. If the signature is invalid, or if the client is not authorized to connect to the server attached to the router, the Router set the Ack flag to Failed (B.09) and the Router sends the digitally signed Acknowledgement to the Broker (B.10). The Broker then sends the acknowledgement to the Proxy as an HTTP Response (B.ll). If the acknowledgement received by the Proxy indicates a connection failure (test in B.12), then Proxy (B.13) closes the connection. If the connection is successful (test in B.12), then communication between the Proxy and the Router begins in B.14. In steps B.14 - B.l 7, the Broker (as with previous connection-protocol-related communications) merely acts as a relay, transforming HTTP Requests to HTTP Responses and routing the data from one side of the communications channel to another. In step B.14, the Proxy digitally signs and encrypts data sent from the application attached to the Proxy and sends it to the Broker as an HTTP
Request. In step B.l 5, the Broker transforms the HTTP Request into an HTTP Response and sends the data to the Router. In step B.l 6, the Router signs and encrypts data from the server attached to the router and sends it to the Broker as an HTTP Request. In step B.l 7, the Broker transforms the HTTP Request into an HTTP Response and sends the data to the Proxy. Steps B.14 through B.l 7 repeat until either the Proxy or the Router terminates the communication.
Fig. 13 shows a flow chart of the processes performed by the Proxy in the Acme Secure Application Exchange. Communication from the Proxy begins with the Proxy sending a signed HTTP Request containing an SAE Connect command to the Broker [P.01]. This connect command contains the Distinguished Name of the Server with whom a connection is desired and/or the IP Address of the same server.
Next, the proxy waits for an acknowledgement from the Broker indicating whether the connection was successful [P.02]. If an Ack was received [P.03], the signature is then verified [P.06]. If an Ack was not received, and the connection timeout (which is configurable) has not expired, the proxy continues to wait [continues to P.02]. If no acknowledgement was received and the timeout has expired, an IO Exception is thrown and the proxy notifies the client application that the connection is unavailable [P.05]. Assuming the acknowledgement was received, the signature is verified in step P.06 as indicated above. If the signature is not valid, or is not trusted; an IO Exception is thrown and the client application that the connection is unavailable [P.05]. If the signature is valid and trusted, control passes to step P.08 and the connection is considered established. To help keep connections that originate behind a firewall alive, a Write Socket Timeout is set in both the Proxy and Router configuration files. This timeout tells the proxy (or router) to send a "ping" command over the socket output stream if a certain period of time has elapsed and no data has been written by the application connected to the proxy (or router). This logic is illustrated beginning at P.08 where the "write timeout timer" is cleared and restarted.
If the client connected to the proxy has data to send [P.09] (i.e. it has sent data to the proxy), control passed to P.l 1 where the Write Timeout Timer is stopped. The client's data is digitally signed with the local proxy's private signing key, and then the signed data is encrypted with the router's public encryption key (obtained from a configurable key store such as an LDAP), and the resulting data is sent to the Broker as an HTTP Request [P-12].
If the client connected to the proxy does not have data to send [P.10], control passed to P.22 where the Write Timeout Timer is stopped. The proxy then generates a "ping" command that is digitally signed with the local proxy's private signing key, and then encrypted with the router's public encryption key. The resulting data is sent to the Broker as an HTTP Request [P.23].
Regardless of whether branch PI 1 or branch P22 was taken, execution of Proxy communication logic continue with step P.13 where a "Read Timeout Timer" is cleared and started [P.14]. The purpose of the Read Timeout Timer is to make sure that the connection is still alive. Because of the "ping" functionality built into both the Proxy and the Router, data is guaranteed to arrive at the receiving end with a configurable amount of time.
Step P.15 monitors the input stream for a response, and step P.18 makes sure that the timeout period has not lapsed before the response has arrived. If a response is not received before the timeout has expired, an IO Exception is thrown in P.19 and the client is notified that the connection was broken.
If a response was received, the signature is verified in step P.16 and the result is tested in P.17. If the signature is not valid, or it is not trusted, an IO Exception is thrown [P.19] and the client is notified that the connection was broken.
If the response was not and Acknowledgement or a Ping command [P.20], the data from the signed and encrypted HTTP Response is extracted and placed in an output buffer where the client can retrieve it [P.21].
The program flow then loops and continues with step P.08 until the connection is closed by either the client (proxy) or the server (router).
Fig. 14 shows a flow chart of the processes performed by the Router in the Acme Secure Application Exchange. Communication from the Router begins with the Router sending a signed HTTP Request containing an SAE Register command to the Broker [R.01]. This register command contains the Distinguished Name of the Server attached to the router and/or the IP Address of the same server.
Next, the router waits for a client connection from the Broker [R.02]. If a connection was received [R.03], the signature is then verified [R.05]. If a connection was not received, and the connection timeout (which is configurable) has not expired, the router continues to wait [continues to R.02]. If no connection was received and the timeout has expired, the router loops back to step R.01 where it "re-registers" with the Broker.
Assuming a connect command was received, the signature is verified in step R.05 as indicated above and is tested in step R.06. If the signature is not valid, or is not trusted, the router sends a signed Acknowledgement to the broker indicating that the client is not authorized to connect with the server [R.07] and the connection is closed [R.09]. If the signature is valid and trusted, the router generates a signed and encrypted acknowledgement indicating that the connection was successfully established and sends the acknowledgement as an HTTP Request to the broker [R.08]. The connection is now considered established.
Similar to the Proxy, the router clears and starts the read socket timeout to monitor connections for "staleness." [R.10]. The router then waits for client data received via the Broker [R.11]. If data is received [R.12], control is passed to R.13 where the data is decrypted and the signature is verified. If data is not received and the timeout has not expired, the router continues to wait, passing control to the beginning of the "read loop" at step R.11]. If no data is received and the timeout has expired, an IO Exception is thrown and the server application connected to the router is notified that the connection was broker.
If data was received, the signature is tested in step R.14. If the signature is not valid, or the signing certificate is not trusted, an IO Exception is thrown and the connection is closed.
If the data received was a "Ping" command [R.17], control is passed to step R.08 where a signed and encrypted acknowledgement is sent to the proxy via the broker; otherwise, the data is placed in an output buffer where the server application connected locally to the router can retrieve the data via a standard socket "read."
Once the data was received and made available to the server application, the write timeout timer is cleared and started [R.19]. If the server has data to write [R.20], the write timeout timer is stopped [R.22], and the data is sent via a signed and encrypted HTTP Request to the Broker [R.23]. Control then passes to step R.10 where the router starts its read loop again.
If no data is available from the server [R.20] and the timeout has not expired [R.21], the router continues to wait until the server does have data to write or until the write timeout timer has expired. If no data is available from the server [R.20] and the timeout has expired [R.21], the router generates a signed and encrypted "ping" command • and sends it to the Broker via an HTTP Request [R.25]. Control then passes to step R.10 where the router starts its read loop again. B. Benefits of Fourth Exemplary System
1. Improved Security: An exemplary system addresses the inefficiencies of current electronic commerce security systems by encrypting data at the document and/or XML tag level. This process allows certain data to be displayed to designated recipients based upon rules established and stored within the Acme Rules- Based Server (as explained below). Also, unlike SSL transmissions, an exemplary system facilitates digital content management. For example, data can be presented to the recipient once and the recipient can be prevented from forwarding or saving the data based on rules maintained at the Acme Rules-Based Server. Another example is that an exemplary system allows time-sensitive data that "expires" based on rules established at the Rules-Based Server to not be displayed to the recipient allowing the sender to control the data (i.e., digital content management) and potentially minimize exposure related to "stale" data. Further, authorization can be granted, modified or revoked dynamically on a per tag-level rather than a file level with an exemplary system. Because the data remains encrypted and is only decrypted upon proper requests from authorized users, the data displayed to the user does not need to be encrypted again for secure storage as with the SSL transmission. The "secret-splitting" process incorporated into an exemplary system addresses the deficiencies of other PKI systems. As stated above, because both the public and private key reside on the recipient's computer, these keys are subject to being "hijacked" by an unauthorized third party that gains access to the recipient's computer. An exemplary system eliminates this issue by storing separate halves of a split symmetric key in different systems - one in the Rules-Based Server and the other within the XML document. This process also allows for "one-time" use symmetric keys preventing anybody (the recipient or third parties) from gaining access to the data after its initial review.
2. Improved Authentication: An exemplary system automatically combines something you know (a shared secret) with something you have (a user certificate and the XML document with Vz of the split symmetric key). With the Rules- Based Server and "one-time" use keys, the receiving or signing party cannot claim unauthorized access following initial access to the document because subsequent access is prevented. Further, each rule can be associated with a separate password increasing the level of authentication by the recipient.
3. Improved Authorization: With the Rules-Based Server, separate rules are maintained and can be modified from time to time as the recipient's authorization is modified. An exemplary system eliminates the problems of revoking and reissuing a certificate as with other PKI-based systems when the authorization of the recipient has been modified or eliminated.
C. Problems/Advantages with Remote Application Management: There is a • significant need for an exemplary system to provide secure communication for remote management of applications because other existing secure communication alternatives are inefficient or expensive. For example, as referenced above, an SSL transmission only provides point-to-point encryption of the entire pipe (i.e., all content) versus an exemplary system that provides encryption and decryption for specific functions at the document and tag-level. Combined with the Rules-Based Server, an exemplary system also provides for rules-based access and auditing of remote administration not available with an SSL transmission. An exemplary system provides end-to-end encryption/decryption and does not require multiple encryption/decryption as does an SSL transmission that passes through several servers/computers before reaching the intended server/computer with the particular application (e.g., through a router, web server and application server to a database server). Because an exemplary system facilitates the sending and receipt of encrypted messages in a dynamically deployable fashion, customized programming and integration is avoided as with other secure communication alternatives.
Another secure communication alternative is a virtual private network ("VPN"). A VPN is costly and provides only network security. Application communications outside of the secure network are vulnerable. An exemplary system combines efficient and inexpensive HTTP communication combined with a flexible, rules-based encryption at the tag-level. The "secret-splitting" key system of an exemplary system provides further security. The Acme Secure Application Exchange (as explained below) also provides secure and continuous communication with the ability to traverse firewalls otherwise closed to outside traffic (no open ports for incoming traffic).
D. Problems with Electronic Exchanges: Electronic commerce has grown significantly and supplanted, in part, traditional methods of doing business grounded in paper documents. These traditional paper methods include the use of physical "wet-ink" signatures, paper delivery systems and manual data entry. Electronic commerce has grown due to its efficiencies and speed compared to conducting business in paper. However, conducting business in paper offers several advantages over electronic commerce. These advantages include security, authentication, authorization and non-repudiation. 1. The Paper Process: Specifically, with a paper process, the sender can elect to send the paper document in a sealed envelop. The recipient will know if security has been compromised if the envelope has been opened prior to delivery to the recipient. The sender can physically sign the document and the recipient can compare the physical signature to other documents previously signed by the sender. For greater security, the sender can mark through or "black-out" portions of a document for which the recipient is not authorized to view.
To facilitate authentication in the paper process, the sender or signer of a document needs to physically present himself to a trusted third party (e.g., a notary) or the recipient in order for the recipient to know who sent or signed the document received by the recipient. To confirm authorization, the recipient must contact others within the sender or signer's organization to confirm if the sender has the proper capacity and/or authority to send or sign the particular paper document. Non-repudiation of a document is the culmination and reliability of the sending, signing, authentication and authorization processes.
The problems with the traditional paper method are apparent. A transaction utilizing the paper process is slow, costly and laborious due, in part, to reliance on (a) the delivery of physical paper and envelope; (b) authentication based upon the recipient having a copy of the signature of the sender/signer and/or the sender/signer presenting himself to a trusted third party or the recipient; and (c) third party confirmation of authority of the sender/signer. Although existing electronic commerce systems solve many of these problems, such systems have their own limitations and deficiencies as described below.
2. Deficiencies with Current Electronic Exchanges : a. Security Problems: Electronic commerce has attempted to address and incorporate processes to satisfy the security, authentication, authorization and non-repudiation of paper processes. However, existing electronic commerce applications have failed to provide the same level of security, authentication, authorization and non- repudiation as paper processes. For example, with security, many electronic commercial systems rely on a secure socket-layer transmission ("SSL"). The SSL communication encrypts all transmissions between the server and client-side browser. In other words, the transmission pipe used to transport data provides the encryption from point-to-point, but once the data has been received, the SSL communication no longer provides any security. To illustrate, after a trading partner receives financial data from the electronic exchange, the information is received and stored unencrypted (or cached) in a temporary file on his computer and is easily accessible to anyone who obtains access to his computer.
Additionally, a partner must open a port for the SSL traffic, leaving them vulnerable to outside port attacks (e.g., denial of service attacks). For the electronic exchange, data received at the SSL originating server (e.g., a web server or application server in a multi- tier environment) needs to be further encrypted for such data to be routed to other servers within such network (e.g., database server) either via multiple SSL transmissions or file encryption. This multiple encryption process requires processing power from the originating server and/or facilitates additional transaction requests by the originating server (to extent that encryption/decryption is "off-loaded" to another server) - either of which is inefficient, slows the process and creates a drain of processing power on the electronic exchange system.
Another method of security with electronic systems is to encrypt the entire file, deliver it to the recipient and allow the recipient to decrypt the file. Security is maintained through an asymmetric process in which the sender uses the recipient's public key to encrypt the file and the recipient uses his private key to decrypt the file. The public and private keys are mathematically associated and only a file encrypted with the recipient's public key can be decrypted with the recipient's private key. This is generally referred to as a public-key infrastructure system or PKI. The problem with this method is that the recipient gains access to the entire file (including portions of the file to which the recipient should not have access) and the sender loses control over the digital content after it is sent to the recipient. For example, the sender cannot limit the recipient from forwarding the file to a third party or providing that the file is only accessible for the next 10 days (e.g., the file may contain data that becomes "stale" and creates liability for the sender after such 10 day period). Also, again, anyone who obtains access to the recipient's computer on which the recipient's private key is stored can gain access to the file. Finally, integration of a system to a PKI platform can often be difficult or otherwise cumbersome to implement. b. Authentication Problems: The authentication process with electronic exchanges relies on the use of something you know, or a shared secret (e.g., passwords or PINs), something you have with digital certificates and/or something you are with biometrics, or a combination of two or more processes. Each process has its limitations. With something you know (the "shared secret solution"), the user must remember the shared secret and the shared secret is stored within the authenticating server (and may also be stored in the sending computer). Therefore, third parties may have unauthorized access by obtaining such shared secret which compromises the authentication scheme or the user fails to remember his password which prevents the user from properly accessing the electronic exchange. Also, the user could avoid legal liability to the electronic exchange or its participants by claiming that his password was compromised and used by a third party. With something you have (the "digital certificate solution"), the user's access to the electronic exchange may be limited to the computer on which the private key resides. Also, again, if a third party obtains access to the computer on which the private key resides, the third party may have unauthorized access to the exchange. With something you are (the "biometric solution"), the user must have access to hardware that can retrieve and forward the biometric data to the electronic exchange for authentication. Since this biometric hardware is not widely distributed or used, is not 100% reliable and is costly, the use of biometrics currently has significant issues with wide-scale adoption. c. Authorization Problems: There are also significant challenges with authorization by participants in electronic exchanges. Authorization is generally tied to the method of authentication. The shared secret solution and the biometric solution are not the preferable methods due to the concerns addressed in the foregoing paragraph, particularly with high risk or high value transactions. With the digital certificates, authorization is typically embedded within information that resides on the certificate. If authorization is modified, then the certificate needs to be eliminated, purged and reissued. Because many digital certificate providers charge on the number of certificates issued, this method of updating authorization is inefficient and costly.
The fifth exemplary system relates to transmissions of data to and from cellular phones, PDAs and other wireless devices to provide secure end-to-end transmission. To illustrate, an exemplary system resides at the wireless gateway and retrieves user credentials from the authentication mechanism already present on the gateway. The exemplary system assigns corresponding x.509 credentials and digitally signs the credentials and transmitted message by creating a one-way hash value of such contents and encrypting such hash value with the private signing key of the gateway or corresponding private key of the wireless user. An exemplary system then encrypts the contents and encrypted hash value with the public key of the receiving application or server. The receiving application or server decrypts the package, verifies the digital signature of the gateway or sender (by using the public key of the gateway or sender to decrypt the oneway hash value) and compares the prior hash value with a new hash value of the contents to ensure data integrity. After this process is completed by an exemplary system, the decrypted request is delivered to the recipient application or server to process the request or perform the designated function. An exemplary system sends a response back to the wireless gateway to notify the initiating wireless device that the requested function/message has been received. Fig. 15 attached hereto and incorporated herein sets forth a diagram of the use of an exemplary system to facilitate secure end-to-end communication with wireless devices.
Fig. 15 shows an exemplary system utilizing certain components of an exemplary system in connection with wireless communication. The items shown in Fig. 15 are as follows:
In Fig. 15, an Acme-enabled application  runs on the wireless gateway  to retrieve user credentials from the authentication mechanism already present on the gateway. These credentials are then added to the data retrieved from the cell phone . Next, the entire transaction is digitally signed (with a private signing key issued to the gateway), and then encrypted (with the public key of the destination application or application server).
The application server then decrypts the package, verifies the gateway's signature, and finally processes the request. Since the application trusts the gateway, and since the gateway trusts the cellular user, the application can trust that the request from the cellular user is valid. A response is sent back to the gateway so that a status message can be sent to the cell phone.
Communication between the mobile device (#702) and the wireless gateway (#701) typically uses the industry-standard WTSL specification to encrypt traffic to and from the wireless device. The actual data content is typically WML (Wireless Markup Language), which is similar to HTML. The Acme application that resides on the Wireless gateway converts data that is sent from the wireless device into an encrypted package that can be understood by the receiving application server #700. Because the application server can accept secure connections from both the wireless gateway and any conventional web servers (or any server in general for that matter), it does not have to contain any special logic pertaining to the wireless input received from the wireless gateway. Rather, it only has to be able to decrypt and authenticate the transaction that it receives. The trust relationship derived above makes it possible for the application server to now trust transactions that originated from wireless devices without having to write specific application code to communicate with the wireless gateway.
Benefits, other advantages, and solutions to problems have been described above with regard to specific examples. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not critical, required, or essential feature or element of any of the claims.
Additional advantages and modifications will readily occur to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or the scope of Applicants' general inventive concept. The invention is defined in the following claims. In general, the words "first," "second," etc., employed in the claims do not necessarily denote an order.
|Brevet cité||Date de dépôt||Date de publication||Déposant||Titre|
|US5457746 *||19 déc. 1994||10 oct. 1995||Spyrus, Inc.||System and method for access control for portable data storage media|
|US5542045 *||3 mars 1995||30 juil. 1996||Software Security, Inc.||Method for interposing a security function in a computer program|
|US5784460 *||10 oct. 1996||21 juil. 1998||Protocall Technolgies, Inc.||Secured electronic information delivery system having a three-tier structure|
|US6105012 *||22 avr. 1997||15 août 2000||Sun Microsystems, Inc.||Security system and method for financial institution server and client web browser|
|Brevet citant||Date de dépôt||Date de publication||Déposant||Titre|
|WO2006089584A1 *||21 déc. 2005||31 août 2006||Volkswagen Ag||Method, device, unit and system for protecting a private communications key in a vehicle-environment communication|
|WO2013041394A1 *||7 sept. 2012||28 mars 2013||Koninklijke Kpn N.V.||Secure distribution of content|
|WO2013060695A1 *||24 oct. 2012||2 mai 2013||Koninklijke Kpn N.V.||Secure distribution of content|
|WO2014143786A1 *||14 mars 2014||18 sept. 2014||Informatica Corporation||Data tokenization in an intermediary node|
|US9336256||15 mars 2013||10 mai 2016||Informatica Llc||Method, apparatus, and computer-readable medium for data tokenization|
|US9350539||7 sept. 2012||24 mai 2016||Koninklijke Kpn N.V.||Secure distribution of content|
|Classification internationale||G06Q30/00, G06F21/10, H04L29/06, H04L29/08|
|Classification coopérative||H04L69/329, H04L67/02, H04L63/0823, G06F2221/2137, G06F21/10, H04L63/123, H04N21/4627, H04N21/63345, H04L63/045, H04N21/8113, H04N21/44204, H04N21/8355, G06Q30/06, H04L2463/101, H04N21/2541, H04N21/4405|
|Classification européenne||H04N21/4627, H04N21/4405, H04N21/8355, H04N21/254R, H04N21/6334K, H04N21/442C, H04N21/81A1, G06Q30/06, G06F21/10, H04L63/04B4, H04L29/08A7, H04L29/08N1|
|13 juin 2002||AL||Designated countries for regional patents|
Kind code of ref document: A2
Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR
|13 juin 2002||AK||Designated states|
Kind code of ref document: A2
Designated state(s): AU CA IL JP MX RU US
|7 août 2002||121||Ep: the epo has been informed by wipo that ep was designated in this application|
|13 févr. 2003||DFPE||Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)|
|7 avr. 2004||122||Ep: pct application non-entry in european phase|
|17 janv. 2006||WWW||Wipo information: withdrawn in national office|
Country of ref document: JP
|17 janv. 2006||NENP||Non-entry into the national phase in:|
Ref country code: JP