WO2002046861A2 - Systemes et procedes permettant de communiquer dans un environnement commercial - Google Patents

Systemes et procedes permettant de communiquer dans un environnement commercial Download PDF

Info

Publication number
WO2002046861A2
WO2002046861A2 PCT/US2001/044078 US0144078W WO0246861A2 WO 2002046861 A2 WO2002046861 A2 WO 2002046861A2 US 0144078 W US0144078 W US 0144078W WO 0246861 A2 WO0246861 A2 WO 0246861A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
data
level
recipient
tag
Prior art date
Application number
PCT/US2001/044078
Other languages
English (en)
Other versions
WO2002046861A3 (fr
Inventor
Gregory J. Meffert
Paul R. Ii Hastings
Mark C. Kurt
Donovan Mouriz
Original Assignee
Certia, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/816,255 external-priority patent/US20020059144A1/en
Application filed by Certia, Inc. filed Critical Certia, Inc.
Priority to AU2002241514A priority Critical patent/AU2002241514A1/en
Publication of WO2002046861A2 publication Critical patent/WO2002046861A2/fr
Publication of WO2002046861A3 publication Critical patent/WO2002046861A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video stream decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44204—Monitoring of content usage, e.g. the number of times a movie has been viewed, copied or the amount which has been watched
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4627—Rights management associated to the content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8106—Monomedia components thereof involving special audio data, e.g. different tracks for different languages
    • H04N21/8113—Monomedia components thereof involving special audio data, e.g. different tracks for different languages comprising music, e.g. song in MP3 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8355—Generation of protective data, e.g. certificates involving usage data, e.g. number of copies or viewings allowed
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2137—Time limited access, e.g. to a computer or data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity

Definitions

  • This invention relates generally to protection of information and, more particularly, systems and methods for communicating in a business environment.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the system comprises (a) an application program interface serving as a local agent that provides calls to subcomponents included within the Acme
  • 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;
  • 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;
  • 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;
  • 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;
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • a local agent resides at the sending application for encryption and digital signing of the requested function at the file or the tag level
  • 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
  • a local agent resides at the recipient application for decryption and confirmation of the digital signature of the message originated by the sending application.
  • 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.
  • 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.
  • W3C World Wide Web Consortium
  • W3C World Wide Web Consortium
  • system 10 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.
  • the resultant decryption key is symmetric in this example.
  • 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.
  • RAM random access 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 CommunicatorTM. 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.
  • 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.
  • 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.
  • 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.
  • server 20 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.
  • system 10 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.
  • file 7 includes another XML "Encrypt” tag structure, delimited by tags 158 and 159.
  • 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.
  • 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.
  • 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.
  • 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.
  • system 10 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.
  • 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.
  • software 138 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.
  • XOR exclusive OR
  • system 5 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.
  • 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.
  • one alternative is to doubly encrypt certain file-resident data, using a first key followed by a second key.
  • the first key may be stored in the file
  • the second key may be stored outside the file.
  • 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.
  • 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).
  • 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.
  • the recipient 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.
  • 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.
  • ERP Enterprise Resource Planning
  • 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.
  • Http protocol typically using the standard Http Port- Port 80
  • 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 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.
  • the server 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 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.
  • ERP system EC.10 and business partner EC.02 includes the functionality system 5 described in connection with the first exemplary system above.
  • ERP system ECU and business partner EC.03 includes the functionality of system 10 described above in connection with the first exemplary system.
  • business partner EC.02 sends a signed HTTP request to Application Server EC.01 requesting the digital certificate of the recipient.
  • 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.
  • Application server EC.01 retrieves file 7 from store-and-forward database EC.05 and sends file 7 to business partner EC.03.
  • 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.
  • 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.
  • 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.
  • the second exemplary system may be applied to implement a virtual private network (VPN), for example.
  • VPN virtual private network
  • 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.
  • standard Http protocol typically using the standard Http Port- Port 80
  • 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.
  • 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.
  • the Data 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the third exemplary system may be applied to implement a virtual private network (VPN), for example.
  • VPN virtual private network
  • 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.
  • CertProfile is a class that holds the profile information needed to generate a certificate.
  • 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
  • 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.
  • the client 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.
  • the certlist parameter contains a list of all the recipients certificates
  • This method opens an XML document for processing
  • 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
  • VerifyTag public abstract boolean VerifyTag(XMLTagSearchData tag) Return true if certificate used to sign tag is valid
  • 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.
  • 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
  • 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.
  • base applications applications
  • 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
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • DTD a known format
  • 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,
  • 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.
  • 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.
  • the sending application digitally signs the encrypted message prior to sending it to the Broker.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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).
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • Fig. 10A 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 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).
  • 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 SAE components, which are in turn built from Acme's CagentX API.
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • the client 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.
  • the HTTP Response is actually a response to the Router's Register command (described below).
  • the HTTP headers are altered; specifically, the HTTP command line itself is changed from the Request format to the HTTP Response format.
  • 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.
  • the Proxy (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.
  • 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.
  • the Broker transforms the HTTP' Request into an HTTP Response and sends the data to the Router.
  • 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.
  • 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.
  • 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.
  • step B.14 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.
  • 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
  • step B.l 5 the Broker transforms the HTTP Request into an HTTP Response and sends the data to the Router.
  • 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.
  • 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.
  • 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].
  • step P.08 If the signature is valid and trusted, control passes to step P.08 and the connection is considered established.
  • 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.
  • 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].
  • step P.13 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.
  • step P.16 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step R.14 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.
  • step R.08 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.”
  • step R.10 the router starts its read loop again.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • VPN virtual private network
  • 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).
  • 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.
  • 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.
  • a trusted third party e.g., a notary
  • 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.
  • 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.
  • existing electronic commerce systems solve many of these problems, such systems have their own limitations and deficiencies as described below.
  • SSL secure socket-layer transmission
  • a partner must open a port for the SSL traffic, leaving them vulnerable to outside port attacks (e.g., denial of service attacks).
  • data received at the SSL originating server e.g., a web server or application server in a multi- tier environment
  • data 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.
  • PKI public-key infrastructure system
  • 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).
  • the recipient's computer on which the recipient's private key is stored can gain access to the file.
  • integration of a system to a PKI platform can often be difficult or otherwise cumbersome to implement.
  • 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.
  • biometric solution 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • an Acme-enabled application [700] runs on the wireless gateway [701] 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 [702]. 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.
  • WML Wireless Markup Language
  • 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.

Abstract

L'invention concerne des systèmes et procédés permettant de communiquer dans un environnement commercial.
PCT/US2001/044078 2000-11-27 2001-11-26 Systemes et procedes permettant de communiquer dans un environnement commercial WO2002046861A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002241514A AU2002241514A1 (en) 2000-11-27 2001-11-26 Systems and methods for communicating in a business environment

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US25289700P 2000-11-27 2000-11-27
US60/252,897 2000-11-27
US09/816,255 US20020059144A1 (en) 2000-04-28 2001-03-26 Secured content delivery system and method
US09/816,255 2001-03-26

Publications (2)

Publication Number Publication Date
WO2002046861A2 true WO2002046861A2 (fr) 2002-06-13
WO2002046861A3 WO2002046861A3 (fr) 2003-06-12

Family

ID=26942773

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/044078 WO2002046861A2 (fr) 2000-11-27 2001-11-26 Systemes et procedes permettant de communiquer dans un environnement commercial

Country Status (2)

Country Link
AU (1) AU2002241514A1 (fr)
WO (1) WO2002046861A2 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006089584A1 (fr) * 2005-02-24 2006-08-31 Volkswagen Ag Procede, dispositif, appareil et systeme pour proteger une clef de communication privee dans le cadre d'une communication vehicule-environnement
WO2013041394A1 (fr) * 2011-09-23 2013-03-28 Koninklijke Kpn N.V. Distribution sécurisée de contenu
WO2013060695A1 (fr) * 2011-10-24 2013-05-02 Koninklijke Kpn N.V. Distribution sécurisée de contenu
WO2014143786A1 (fr) * 2013-03-15 2014-09-18 Informatica Corporation Tokénisation de données dans un noeud intermédiaire
US10693531B2 (en) 2002-01-08 2020-06-23 Seven Networks, Llc Secure end-to-end transport through intermediary nodes

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5457746A (en) * 1993-09-14 1995-10-10 Spyrus, Inc. System and method for access control for portable data storage media
US5542045A (en) * 1993-10-15 1996-07-30 Software Security, Inc. Method for interposing a security function in a computer program
US5784460A (en) * 1996-10-10 1998-07-21 Protocall Technolgies, Inc. Secured electronic information delivery system having a three-tier structure
US6105012A (en) * 1997-04-22 2000-08-15 Sun Microsystems, Inc. Security system and method for financial institution server and client web browser

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5457746A (en) * 1993-09-14 1995-10-10 Spyrus, Inc. System and method for access control for portable data storage media
US5542045A (en) * 1993-10-15 1996-07-30 Software Security, Inc. Method for interposing a security function in a computer program
US5784460A (en) * 1996-10-10 1998-07-21 Protocall Technolgies, Inc. Secured electronic information delivery system having a three-tier structure
US6105012A (en) * 1997-04-22 2000-08-15 Sun Microsystems, Inc. Security system and method for financial institution server and client web browser

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10693531B2 (en) 2002-01-08 2020-06-23 Seven Networks, Llc Secure end-to-end transport through intermediary nodes
WO2006089584A1 (fr) * 2005-02-24 2006-08-31 Volkswagen Ag Procede, dispositif, appareil et systeme pour proteger une clef de communication privee dans le cadre d'une communication vehicule-environnement
WO2013041394A1 (fr) * 2011-09-23 2013-03-28 Koninklijke Kpn N.V. Distribution sécurisée de contenu
US9350539B2 (en) 2011-09-23 2016-05-24 Koninklijke Kpn N.V. Secure distribution of content
WO2013060695A1 (fr) * 2011-10-24 2013-05-02 Koninklijke Kpn N.V. Distribution sécurisée de contenu
KR101620246B1 (ko) 2011-10-24 2016-05-23 코닌클리즈케 케이피엔 엔.브이. 콘텐츠의 보안 배포
WO2014143786A1 (fr) * 2013-03-15 2014-09-18 Informatica Corporation Tokénisation de données dans un noeud intermédiaire
GB2528203A (en) * 2013-03-15 2016-01-13 Informatica Corp Data tokenization in an intermediary node
US9336256B2 (en) 2013-03-15 2016-05-10 Informatica Llc Method, apparatus, and computer-readable medium for data tokenization
GB2528203B (en) * 2013-03-15 2020-09-09 Informatica Llc Data tokenization in an intermediary node

Also Published As

Publication number Publication date
WO2002046861A3 (fr) 2003-06-12
AU2002241514A1 (en) 2002-06-18

Similar Documents

Publication Publication Date Title
US6952768B2 (en) Security protocol
US6941459B1 (en) Selective data encryption using style sheet processing for decryption by a key recovery agent
US7360079B2 (en) System and method for processing digital documents utilizing secure communications over a network
US6931532B1 (en) Selective data encryption using style sheet processing
US9619632B2 (en) System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
US6961849B1 (en) Selective data encryption using style sheet processing for decryption by a group clerk
US7036010B2 (en) Method and apparatus for a secure communications session with a remote system via an access-controlling intermediate system
US6978367B1 (en) Selective data encryption using style sheet processing for decryption by a client proxy
US9509681B2 (en) Secure instant messaging system
CA2527718C (fr) Systeme, procede et programme informatique permettant d'envoyer des messages cryptes a des destinataires, l'emetteur ne possedant pas les justificatifs du destinataire
JP4632315B2 (ja) グリッド・アクセス及びネットワーク・アクセスを提供するシングル・サインオン操作のための方法及びシステム
US6993651B2 (en) Security protocol
JP5021215B2 (ja) Ｗｅｂサービス用の信頼できる第三者認証
CA2394451C (fr) Systeme, methode et produit informatique pour l'envoi et la reception de donnees cryptees s/mime
US20030084292A1 (en) Using atomic messaging to increase the security of transferring data across a network
JP2005517348A (ja) 復号化鍵を引き出すための鍵検索を必要とする安全な電子メッセージングシステム
JP2004501547A (ja) 安全なコラボレーティブ・トランザクションを管理する方法及び装置
TW200307439A (en) Mechanism for supporting wired and wireless methods for client and server side authentication
Farrell et al. AAA authorization requirements
KR20070109040A (ko) 사용자 인증의 이중 강화를 위한 보안 관리 웹 서비스시스템 및 방법
WO2002046861A2 (fr) Systemes et procedes permettant de communiquer dans un environnement commercial
WO2002021793A2 (fr) Systeme et procede permettant l'echange de messages chiffres
Kadir RewritingHealer: An approach for securing web service communication
Farrell et al. RFC2906: AAA Authorization Requirements
Van Eeden A SOAP-based Model for secure messaging in a global context

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AU CA IL JP MX RU US

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP