US20110145584A1 - Translating Information between Computing Devices Having Different Security Management - Google Patents
Translating Information between Computing Devices Having Different Security Management Download PDFInfo
- Publication number
- US20110145584A1 US20110145584A1 US12/790,723 US79072310A US2011145584A1 US 20110145584 A1 US20110145584 A1 US 20110145584A1 US 79072310 A US79072310 A US 79072310A US 2011145584 A1 US2011145584 A1 US 2011145584A1
- Authority
- US
- United States
- Prior art keywords
- computing device
- document
- portions
- signing
- packets
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Images
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/0464—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 using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
-
- 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/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
Definitions
- a method and apparatus for translating portions of documents containing secured information between computing devices is disclosed.
- Communicating with computers requires that to transmit documents from one computer to another, certain security measures are present.
- Example of such secure documents include text documents in a word processing format, PDF documents, graphics document or a photograph of a document.
- the document being sent must be signed and encrypted in accordance with the rules of the corporation.
- the protocol to transfer the file must be authenticated per the corporation's specifications.
- one corporation When one corporation needs to transfer information to another corporation having different authentication and encryption requirements, one corporation must change its authentication methodology. Alternatively, one of the corporations may be required to adopt a special authentication methodology to enable communication. These changes can significantly increase the cost to the institution as it typically has specific authentication and encryption methods as part of its infrastructure.
- a method and apparatus for transferring documents with an intermediate computing device coupled between a first computing device disposed at a first location and a second computing device disposed at a second location is disclosed.
- the method and device includes partitioning the document into portions with the first computing device and then individually signing and encrypting in accordance with a first signing and a first encryption methodology each of the portions.
- the multiple portions are separately and individually transmitted as data packets along with a trailer manifest via a network from the first computing device to an intermediate computing device where the individual packets are decrypted and the signatures of the packets are verified using the first signing and encrypting methodology.
- the trailer manifest will be signed and encrypted by the first computing device.
- the trailer manifest includes information indicating an order to assemble the portions at a destination computing device and may include a hash of the entire document.
- the data packets are re-signed and re-encrypted by the intermediate computing device with a second signing and a second encryption methodology/algorithm such that the individual packets can be decrypted and validated at a second location.
- These methodologies/algorithms may be previously provided to the intermediate device from a computing device at the second location.
- the re-signed and re-encrypted individual packets along with the trailer manifest are transmitted separately and individually to the second computing device via a network for decryption and validation so that the second computing device can decrypt and verify the packets and separate the portions from the packets.
- the individual packets can be transmitted out of order because the trailer manifest will include sufficient information for the receiving computing device (e.g. an intermediate or 2 nd computing device) to reassemble the document correctly.
- the manifest may be provided from the first computing device to the second computing device so that the portions at the second computing device may then be aggregated into the document in a specific order using information contained in the manifest. Also the intermediate computing device may validate the integrity of the aggregated document by first computing a hash value of the aggregated document using the hash algorithm indicated inside the manifest. The intermediate computing device may then compare the computed hash value against the hash value contained in the manifest.
- a trailer manifest is always provided to the intermediate computing device.
- the intermediate computing device may decide to re-assemble the document or the intermediate computing device could also transmit the re-signed and re-encrypted packet individually to the second computing device followed by a newly signed and encrypted trailer manifest.
- the intermediate computing device if the intermediate computing device is re-assembling the packet, then the intermediate computing device must validate the aggregated document using the hash provided in the trailer manifest. However, if the intermediate computing device is not re-assembling the packet, it will simply pass the trailer manifest “as is” to the second computing device.
- the intermediate computing device decides whether or not to re-assemble or not to re-assemble the packets using pre-determined data or by analyzing data provided by the first computing device when the first computing device connects and authenticates its data with the intermediate computing device
- FIG. 1 is a simplified schematic diagram of a communication system for transferring information between computing devices.
- FIG. 2 is a simplified schematic diagram of an exemplary computing device used in the communications system.
- FIGS. 3-5 are flow charts disclosing a method for transferring secure documents between multiple computing devices, where FIG. 3 is a method executed using a first computing device shown in the translation communications system, where FIG. 4 is the method executed using an intermediate computing device shown in the communications system and where FIG. 5 is the method executed using a second or host computing device shown in the communications system.
- FIG. 6 is a data diagram illustrating the contents of document and of a data packet.
- FIG. 7 is a data diagram illustrating an exemplary trailer manifest.
- system 100 having a first electronic device or first computing device 102 a at a first location coupled via network 104 and intermediate computing device 102 b to host or second computing device 102 n .
- Computing devices 102 b and 102 n are preferably located remotely from each other and computing device 102 a .
- First computing device 102 a , intermediate computing device 102 b and second computing device 102 n may be constructed using materials, processes and techniques generally known in the art, and may include conventional components.
- An example of one of computing devices 102 a - 102 n (Device 200 ) is described in more detail in FIG. 2 .
- Computing devices 102 a - 102 n may communicate with each other via an ISO (International Standard Organization), ITU (International Telecommunications Union) or IEEE (Institute for Electrical and Electronic Engineers) standards based network 104 or any proprietary network using structures, protocols and layouts including but not limited to TCP, Ethernet, cellular, microwave, fiber, broadband, baseband, wireless, IEEE 802.11, etc.
- Network 104 may be an Internet, World Wide Web, intranet, or any combination thereof.
- system 100 is shown with computing device 102 b being coupled to computing devices 102 a and 102 n , computing device 102 b may be coupled with many other computing devices (not shown), or coupled via network 104 to other computer networks.
- Computing device 102 a communicates with an intermediate computing device 102 b coupled with a first computing device 102 a disposed at a first location and a second computing device 102 n disposed at a second location.
- a document 110 is provided to computing device 102 a from a user (e.g. the document may be generated on the computing device) or from another computing device (not shown).
- document may include one or more documents, any type of information, including text, algorithms, audio/video data, symbolic, animation, financial and numerical information.
- the document may various formats including, but not limited to, Microsoft® Word, PDF, TIFF, GIFF, Visio, Excel, WordPerfect, and JPEG file formats.
- Such document is typically transferred to device 102 a using generally accepted methods, such as being transferred via an I/O device or being transferred from other computing devices (not shown) coupled to network 104 using Hyper Text transfer protocols (HTTP), FTP (File Transfer Protocol), or using any generally known protocol.
- the document 110 may be partitioned and split into portions and inserted into data packets 110 a - 110 n having equal size or unequal size depending on networking requirements by computing device 102 a.
- Computing device 102 a individually signs and encrypts each of the packets at the first location in accordance with a first signing and a first encryption methodology.
- the first computing device 102 a may create a trailer manifest 114 for each document.
- the trailer manifest 114 may contain information indicating a unique ID for each of the multiple portions of the document, a table or listing containing all the unique IDs indicating an order in which the packets or portions of the packets are to be re-assembled, a hash value corresponding to the portion and a hash algorithm of the entire received document to validate the integrity of the document post assembly.
- Computing device 102 a transmits 1) the individually signed and encrypted multiple packets that each includes a portion of the document and 2) trailer manifest 114 , to the intermediate computing device 102 b via network 104 .
- Such multiple data packets 110 may be transmitted on the same channel, in any order or may be transmitted over different channels via network 104 .
- the trailer manifest 114 may or may not be encrypted and/or signed before being transmitted to the intermediate computing device 102 b.
- Intermediate computing device 102 b receives via network 104 multiple data packets 110 a - n and the trailer manifest 114 from the first computing device 102 a .
- Intermediate computing device 102 b decrypts the individual packets and verifies the signatures of the individual portions of the document using the first signing and encrypting methodology.
- Computing device 102 b may be provided keys and the hash algorithm to decrypt, verify and examine the trailer manifest 114 to verify the integrity of the trailer manifest. In another implementation, the computing device 102 b may not be provided the trailer manifest keys and hash algorithm but simply passes the manifests through to computing device 102 n .
- Computing device 102 b may aggregate the decrypted and verified packets 120 .
- computing device 102 b may aggregate the received portions of the verified document in an order specified in the trailer manifest 114 . In another implementation, computing device 102 b does not aggregate the packets/portions of the document and passes them through to another computing device. In another implementation, device 102 b re-signs and re-encrypts individual data packets 120 with a second signing and a second encryption methodology such that the individual packets can be decrypted and validated at a second location by computing device 102 n . Computing device 102 b transmits the re-signed and re-encrypted individual packets 120 a - 120 n to the second computing device 102 n via a network 104 .
- computing device 102 b feeds the received trailer manifest 124 to computing device 102 n .
- computing device 102 b generates the trailer manifest 124 for the decrypted, assembled and verified document before transmitting the document to computing device 102 n .
- the second signing and encryption methodology/algorithm is provided to computing device 102 b by computing device 102 n prior to receipt of the packets from computing device 102 a .
- the methodology/algorithms may be stored in a table in the memory of computing device 102 b.
- Computing device 102 n receives via network 104 multiple packets 120 a ′- 120 n ′ from the intermediate computing device 102 b and the trailer manifest.
- Computing device 102 n decrypts the packets 120 a ′- 120 n ′ and verifies the signatures of the individual packets using the second signing and encrypting methodology.
- Computing device 102 n may be provided keys and the hash algorithm to examine the trailer manifest 124 ′ to verify the integrity of the multiple packets received from computing device 102 b .
- Computing device 102 n then removes the portions of the document from each of the decrypted and verified packets, and aggregates the decrypted and validated portions to form document 130 .
- the order in which the validated portions of the document are assembled/aggregated by device 102 n to form the document is specified in the received trailer manifest 120 n′.
- Computing device 200 includes a processing device 204 and memory 212 , and hardware 222 .
- Computing device 200 may include one or more a microprocessors, microcontrollers or any such devices for accessing memory 212 or hardware 222 .
- Computing device 200 has processing capabilities and memory suitable to store and execute computer-executable instructions.
- Computing device 200 executes instruction stored in memory 212 , and in response thereto, processes signals from hardware 222 .
- Hardware 222 may include a display 224 , and input device 226 and an I/O communications device 228 .
- I/O communications device 228 may include a network and communication circuitry for communicating with network 104 .
- Input device 226 receives inputs from a user of the computing device 200 and may include a keyboard, mouse, track pad, microphone, audio input device, video input device, or touch screen display.
- Display device 224 may include an LED, LCD, CRT or any type of display device to enable the user to preview information being stored or processed by computing device 204 .
- Memory 212 may include volatile and nonvolatile memory, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules or other data.
- Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium which can be used to store the desired information and which can be accessed by a computer system.
- Operating system 214 may be used by application 220 to control hardware and various software components within computing device 200 .
- the operating system 214 may include drivers for device 200 to communicate with I/O communications device 228 .
- a database or library 218 may include preconfigured parameters (or set by the user before or after initial operation) such a server operating parameters, server libraries, HTML libraries, API's and configurations.
- An optional graphic user interface or command line interface 222 may be provided to enable application 220 to communicate with display 224 .
- Application 220 includes an encryptor/decryptor module 217 , a signor/validator module 219 and an assembler/disassembler module 221 .
- Encryptor/decryptor module 217 separately encrypts (and in some instances re-encrypts) and decrypts the individual portions (data packets) of the documents using encryption methodologies.
- Signor/validator module 219 separately verifies and signs (and in some instances re-signs) the signatures of the individual portions (data packets) of the document or the entire document using the signing/hashing methodologies and/or algorithms.
- Assembler/disassembler module 221 separates documents into portions, assigns a unique ID and session ID to the portions, and provides the IDs to generate a trailer manifest indicating the order of the packets.
- the assembler/disassembler module 221 allows aggregates/assembles portions into a document using the unique ID and session ID provided in the trailer manifest. Specifically the assembler/disassembler module 221 uses the session ID provided in the trailer manifest to determine the order the portions are aggregated to construct a document.
- Such exemplary processes 300 , 400 and 500 may be a collection of blocks in a logical flow diagram, which represents a sequence of operations that can be implemented in hardware, software, and a combination thereof.
- the blocks may represent computer-executable instructions that, when executed by one or more processors, perform the recited operations.
- computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types.
- the order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order and/or in parallel to implement the process.
- process 300 executed by a communications application 220 (See FIG. 2 ) (hereafter also referred to as “application 220 ”) is show.
- process 300 is executed in a computing device, such as first computing device 102 a ( FIG. 1 ).
- Application 220 when executed by the processing devices, uses the processor 204 and modules 212 - 228 shown in FIG. 2 .
- application 220 in computing device 102 a connects to and authenticates with intermediate computing device 102 b to establish a session.
- computing device 102 a provides intermediate computing device 102 b with data routing information (i.e. computing device 102 a wants to send data to computing device 102 n ).
- computing device 102 a receives a response from intermediate computing device 102 b indicating unique session information (e.g. a session token) and indicating a public key to be used by computing device 102 a for encryption of data.
- the session information may be used by computing device 102 a to bind computing device 102 a to another computing device, such as computing device 102 n , during a data transfer session.
- computing device 102 a using module 217 partitions the original document into data portions.
- computing device 102 a assigns a unique ID to each data portion of the document, then envelopes (aggregates) the unique ID, the data portion, and session token to form individual packets 110 a - 110 n.
- the individual packets are then signed by module 219 and encrypted by module 217 in computing device 102 a before being fed as a ‘signed/encrypted’ data packet to Intermediate Computing device 102 b .
- a configured key pair that is used to encrypt data packets for the document may be retrieved from memory 212 to sign/encrypt the packets.
- Application module 219 signs each of the individual data packets and creates an ID for each of the data packets and encrypts each of the individual data packets.
- the individual packets for the document may be signed by computing device 102 a using generally known signing digest algorithms, including but not limited to, MD5 hashing algorithm, SHA-1 hashing algorithm, Elliptic Curve Digital Signature Algorithm (ECDSA). Further details of MD5 and SHA-1 digest algorithms are disclosed in IETF RFC 2014, which is hereby incorporated by reference. Further details of ECDSA are disclosed in IETF RFC 3278, which is hereby incorporated by reference. If the data packets are signed, the keys used to sign the packets may have been previously provided to computing device 102 a and stored in memory 212 .
- Signer certificates may contain public keys that correspond to the private keys used during signing may be embedded in the signed document or signed packets.
- the signed packets may be formatted with an encoding scheme including but not limited to standard cryptographic message syntax (CMS).
- CMS standard cryptographic message syntax
- signer certificates When signer certificates are embedded in the document or packets during signing, the signer certificates may not need to be pre-exchanged with computing device 102 a - n as discussed herein. Otherwise, signer certificates used to sign the document or data packets must be pre-exchanged between computing devices 102 a and 102 b (and 102 n ), so that device 102 b can ascertain which certificates to use when verifying the signatures of the documents or data packets.
- the signed document or packets may be encrypted by encryptor/decryptor module 217 using standard encryption algorithms using previously provided public keys stored in memory of computing device 102 a .
- encryption algorithms include but are not limited to Triple DES, AES-128, AES-192, AES-256, CAST128, CAST256, RC2-40, and RC2-128.
- the public keys used by computing device 102 a to encrypt the packets of the data packets are known to computing device 102 b since computing device 102 b has the corresponding private keys, which enables computing device 102 b to decrypt the data packets.
- a list of algorithms to be used by computing device 102 a may be provided by computing device 102 b .
- the encrypted data packets may be formatted with an encoding scheme including but not limited to standard CMS. The encryption and CMS formatting process is described in IETF RFC 3852, which is hereby incorporated by reference.
- each of the individual signed/encrypted data packets 110 a - 110 n are transmitted to the intermediate computing device 102 b .
- a signature for each of the data packets is encrypted and transmitted with its respective individual data packet to computing device 102 b .
- the wire protocol for transferring of the encrypted and/or signed document can be any generally known protocol including but not limited to HTTP, FTP or SMTP (EMAIL). Details of such protocols are described in HTTP 1.1, HTTP1.0, FTP, FTPS, SFTP and SMTP (EMAIL), which are hereby incorporated by reference.
- the cryptographic message syntax scheme defines the manner in which the data packets are signed and encrypted, encrypted and not signed, or signed and not encrypted, the encryption algorithms and key lengths, the signing digest algorithms, signers' information and signer certificates embedment information.
- the packets may be signed or encrypted, signing and encrypting of each and every one of the packets are optional and some of the packets transferred to computing device 102 b may contain any cryptographic message syntax encoding schemes including not being signed and/or encrypted.
- the trailer manifest includes one or more of a session token, a cryptographic hash of the original document, and an ordered list of all unique IDs for each of the packets. The ‘order’ defines the order of the portions in relation to the original document and may not necessarily reflect the actual order that the packets were sent by device 102 a or received by computing device 102 b or 102 n.
- computing device 102 a signs and encrypts the trailer manifest using one or more of the algorithms previously described.
- application 220 using OS 214 and I/O controller 216 , sends the manifest to intermediate computing device 102 b .
- the trailer manifest 114 (which may or may not be encrypted and/or signed) is then transmitted to computing device 102 b via network 104 .
- process 400 executed by a communications application 220 (hereafter also referred to as application 220 ) in computing device 102 b is shown.
- process 400 is executed in computing devices 102 b (See FIG. 1 ) although process 400 may be executed by any of computing devices 102 a - 102 n .
- Application 220 when executed by a computing device uses the processor 204 and modules 212 - 228 shown in FIG. 2 .
- the application 220 in computing device 102 b receives an authentication request from a computing device, such as computing device 102 a ( FIG. 1 ).
- intermediate computing device 102 b when the request to authenticate from computing device 102 a is received, intermediate computing device 102 b creates a session token (also referred to as “session information”) and returns the token along with the public key of the intermediate computing device 102 b to Computing device 102 a .
- the session token is used by intermediate computing device 102 b to determine that computing device 102 a is trying to send data to computing device 102 n .
- Intermediate computing device 102 b needs to store this information so that when the packets arrive from computing device 102 a , Intermediate computing device 102 b knows the computing device to be routed the data packets.
- intermediate computing device 102 b retrieves its public key, and responds to the first computing device 102 a in block 408 .
- application 220 in intermediate computing device 102 b receives from computing device 102 a one or more data packets that comprise the document.
- the data packets are received via network 104 from one of the computing devices (e.g. device 102 a ).
- application 220 decrypts the received data packets using the one or more private keys presorted in memory of intermediate computing device 102 b .
- the received encrypted data packet (if encrypted) may be decrypted using the same cryptographic algorithm used to encrypt the data packet by computing device 102 a .
- the decryption algorithm may be indicated by metadata in CMS format included with the received packet or the algorithm may be previously known by the computing device.
- Intermediate computing device 102 b decrypts and verifies the received data packet to obtain the information contained in the packet (e.g. the Session token, unique IDs of the data portion and the data portion itself).
- computing device authenticates/validates the signatures of the decrypted packet (if the data packet was signed).
- the signatures may be validated using the embedded certificates or certificates containing the public keys provided by computing device 102 a , or a trusted certificate issuing authority.
- the certificates containing the public keys used in validating the signatures may also be checked against one or more Certificate Revocation Lists (CRL). Details of CRL and its format are described in IETF RFC2459, which is hereby incorporated by reference. Alternatively, the certificates may also be verified using Online Certificate Status Protocol (OCSP) against its issuing Certificate Authority. Details of OCSP are described in IETF RFC2560, which is hereby incorporated by reference.
- the data packets may be stored in memory, and intermediate computing device may transmit a process packet acknowledgement indication to computing device 102 a in block 418 . If the packet is determined not to be valid, or contains invalid certificates, an error may be transferred to computing device 102 a and an indication of such error may be logged into memory 18 b within computing device. Such error indication may be provided to another computing device on the network 104 or signaled to a user using conventional means.
- application 220 may transmit the process packet acknowledgment indication via network 104 to the computing device that sent the data packet (e.g. device 102 a ).
- application 220 determines which computing device (e.g. computing device 102 n ) is to receive this data packet.
- Intermediate computing device 102 b retrieves the necessary information from its memory to re-encrypt and re-sign the data packet.
- the data packets could be in the clear, and contain no signing or encryption (after block 416 ).
- Intermediate computing device 102 b retrieves the necessary pre-stored information from its memory to re-encrypt and to re-sign the clear data packets.
- These clear data packets may be processed (by being re-encrypted and re-signed), in block 420 using process 300 ( FIG. 3 ).
- the intermediate computing device (e.g. computing device 102 b ) prepares and transmits the re-signed and re-encrypted data packets to a second computing device (e.g. computing device 102 n ) in block 424 .
- the signing digest algorithms, signer certificates embedding process and encoding scheme format used during re-signing in block 420 by computing device 102 b may be a different process/algorithm than the process/algorithm that were originally used by computing device 102 a.
- the data packets may optionally be re-encrypted using standard encryption algorithms. Examples of such encryption algorithms include but are not limited to Triple DES, AES-128, AES-192, AES-256, CAST128, RC2-40, and RC2-128.
- the public keys used by computing device 102 b to encrypt the packets may be known to computing device 102 n since device 102 n has the corresponding private keys, which enable computing device 102 n to decrypt the document.
- the encrypted packets may be formatted with an encoding scheme including but not limited to standard CMS. The encryption and CMS formatting process is described in IETF RFC 3852, which is hereby incorporated by reference.
- intermediate computing device 102 b determines if an acknowledgement has been received from computing device 102 n .
- the acknowledgement indicates that the data packets were received at computing device 102 n as expected and alternatively may provide an indication of the specific data packets that were successfully received at computing device 102 n . If an acknowledgement is received the process ends.
- intermediate computing device 102 b resends the data packet to computing device 102 n . Transmission retries of the data packets may need to occur as necessary during failed transmissions.
- intermediate computing device 102 b After all the data packets are received from computing device 102 a and processed, intermediate computing device 102 b receives a trailer manifest from computing device 102 a.
- the application 220 receives the trailer manifest received from computing device 102 a and decrypts the manifest if it was encrypted (with module 217 using the decryption method previously described).
- the application 220 using signor/validator module 219 authenticates the signature of the trailer manifest (if the manifest was signed).
- application 220 Upon authentication of the trailer manifest signature, in block 434 , application 220 transmits an indication of trailer manifest acknowledgement via network 104 back to computing device 102 a (the sender of the trailer manifest).
- the session information/token may be examined to determine the computing device destined to receive this manifest.
- Intermediate computing device 102 b also retrieves from its memory the necessary information to re-encrypt and re-sign the manifest.
- intermediate computing device 102 b sends the signed/encrypted manifest to the determined computing device destined to receive the manifest (e.g. computing device 102 n ).
- intermediate computing device 102 b determines if an acknowledgement has been received from computing device 102 n .
- the acknowledgement indicates that the trailer manifest was received at computing device 102 n as expected. If an acknowledgement is received the process ends.
- intermediate computing device 102 b resends the signed and/or encrypted manifest to computing device 102 n . Transmission retries may need to occur as necessary during failed transmissions.
- the re-signed and/or re-encrypted data packets and trailer manifest are received by a second computing device (e.g. computing device 102 n ).
- Computing device 102 n may then execute blocks 502 - 526 shown in process 500 of FIG. 5 .
- second computing device 102 n (also referred to as host or server computing device) receives data packets from the intermediate computing device 102 b via network 104 .
- computing device 102 n decrypts and verifies/authenticates the packet (which contains the session token, unique IDs of the data portions and the data portion itself) in blocks 504 and 506 , respectively, using encryptor/decryptor module 217 and signor/validator module 219 (See FIG. 2 ).
- the received encrypted data packets may be decrypted by computing device 102 n using the same algorithm used to encrypt the data packets by computing device 102 b .
- the decryption algorithm is indicated by metadata in the CMS format included with the received data packets or the algorithm may be previously known by computing device 102 n.
- Computing device 102 n may validate the signature of the decrypted data packets (if signed) with module 219 .
- the signatures may be validated using the embedded certificates or certificates containing the public keys provided by computing device 102 b , or a trusted certificate issuing authority.
- the certificates containing the public keys used in validating the signatures may also be checked against one or more Certificate Revocation Lists (CRL). Details of CRL and its format are described in IETF RFC2459, is hereby incorporated by reference. Alternatively, the certificates may also be verified using Online Certificate Status Protocol (OCSP) against its issuing Certificate Authority. Details of OCSP are described in IETF RFC2560, which is hereby incorporated by reference.
- computing device 102 n stores the decrypted/validated packets in a local storage device, such as memory 212 .
- computing device 102 n provides an acknowledgement to intermediate computing device 102 b via network 104 .
- computing device 102 n receives and decrypts the trailer manifest from intermediate computing device 102 b using encryptor/decryptor module 217 .
- computing device 102 n authenticates the signature of the received trailer manifest.
- Computing device 102 n upon authentication of the signature transmits an ACK indication (acknowledgement) to intermediate computing device 102 b.
- computing device 102 n reads the decrypted/verified manifest to determine the ordered list of unique IDs in the received trailer manifest.
- Computing device 102 n also uses assembler module 221 to reorder and reassemble the portions of the document from the received packets (stored in local storage in block 514 ) into a document to reconstruct the original document as provided from computing device 102 a.
- computing device 102 n using application 220 calculates a crypto hash of the reassembled document.
- computing device 102 n validates reassembled document by comparing the calculated crypto hash with the crypto hash found inside the trailer manifest received from computing device 102 b .
- an error is sent to computing device 102 a and/or 102 b , and an indication of such error may be logged within computing device 102 n in block 524 .
- Such error indication may be provided to another computing device via network 104 or signaled to a user using conventional means. If the reassembled document is determined to be valid, an indication may be provided to other processes in computing device 102 n that the document was received.
- FIG. 1 Although the preferred embodiments describe transferring a data packets from computing device 102 a to 102 n via computing device 102 b ( FIG. 1 ), such data packets may be transferred from computing device 102 n to computing device 102 a using the methods shown in FIGS. 3-5 either directly or via other computing devices, where computing device 102 n implements the methods shown in FIG. 3 , computing device 102 b implements the methods shown in FIG. 4 , and computing device 102 n implements the methods shown in FIG. 5 .
- the process described in this specification discloses translating one data packets between multiple computing devices; the process could further translate multiple data packets, and transmit each of the multiple translated data packets to one or more computing devices from an intermediate computing device such that each of the data packets is translated at the intermediate computing device with a different signing or encryption scheme.
- computing device 102 b is described as the intermediate computing device, any computing device could be substituted for computing device 102 b .
- the processes described with respect to computing devices 102 n and 102 a could be substituted for the processes described with respect to computing devices 102 a and 102 n .
- a document could be transmitted from computing device 102 n via computing device 102 b to computing device 102 a.
- Data packet 604 includes a session token 606 , unique ID of a document portion 608 and a portion 612 of the document 604 .
- Document 604 is comprised of multiple portions 612 a - 612 n which may be of equal or unequal sizes.
- Trailer manifest includes session token, packet information comprising Packet unique IDs portions and the original document hash and hash algorithm. Appendix to the packet ID is an indication of the order in the document of
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Storage Device Security (AREA)
Abstract
Description
- This patent application claims the benefit of U.S. patent application Ser. No. 10/994,921, filed Nov. 22, 2004.
- These claimed embodiments relate to the field of translating and partitioning documents containing secure information when such documents are being transferred between multiple computing devices.
- A method and apparatus for translating portions of documents containing secured information between computing devices is disclosed.
- Communicating with computers, such as those of financial institutions or any entity transferring secure information, requires that to transmit documents from one computer to another, certain security measures are present. Example of such secure documents include text documents in a word processing format, PDF documents, graphics document or a photograph of a document. For example, the document being sent must be signed and encrypted in accordance with the rules of the corporation. Further, the protocol to transfer the file must be authenticated per the corporation's specifications.
- When one corporation needs to transfer information to another corporation having different authentication and encryption requirements, one corporation must change its authentication methodology. Alternatively, one of the corporations may be required to adopt a special authentication methodology to enable communication. These changes can significantly increase the cost to the institution as it typically has specific authentication and encryption methods as part of its infrastructure.
- Further often these secure documents may be very large. Consequently if transmission of the secure documents is interrupted, retransmission of the entire document may be required thereby reducing the efficiency of the transmission.
- A method and apparatus for transferring documents with an intermediate computing device coupled between a first computing device disposed at a first location and a second computing device disposed at a second location is disclosed. The method and device includes partitioning the document into portions with the first computing device and then individually signing and encrypting in accordance with a first signing and a first encryption methodology each of the portions. The multiple portions are separately and individually transmitted as data packets along with a trailer manifest via a network from the first computing device to an intermediate computing device where the individual packets are decrypted and the signatures of the packets are verified using the first signing and encrypting methodology.
- In one implementation, the trailer manifest will be signed and encrypted by the first computing device. The trailer manifest includes information indicating an order to assemble the portions at a destination computing device and may include a hash of the entire document. The data packets are re-signed and re-encrypted by the intermediate computing device with a second signing and a second encryption methodology/algorithm such that the individual packets can be decrypted and validated at a second location.
- These methodologies/algorithms may be previously provided to the intermediate device from a computing device at the second location. The re-signed and re-encrypted individual packets along with the trailer manifest are transmitted separately and individually to the second computing device via a network for decryption and validation so that the second computing device can decrypt and verify the packets and separate the portions from the packets. In another implementation, the individual packets can be transmitted out of order because the trailer manifest will include sufficient information for the receiving computing device (e.g. an intermediate or 2ndcomputing device) to reassemble the document correctly.
- The manifest may be provided from the first computing device to the second computing device so that the portions at the second computing device may then be aggregated into the document in a specific order using information contained in the manifest. Also the intermediate computing device may validate the integrity of the aggregated document by first computing a hash value of the aggregated document using the hash algorithm indicated inside the manifest. The intermediate computing device may then compare the computed hash value against the hash value contained in the manifest.
- In one implementation a trailer manifest is always provided to the intermediate computing device. The intermediate computing device may decide to re-assemble the document or the intermediate computing device could also transmit the re-signed and re-encrypted packet individually to the second computing device followed by a newly signed and encrypted trailer manifest.
- In another implementation, if the intermediate computing device is re-assembling the packet, then the intermediate computing device must validate the aggregated document using the hash provided in the trailer manifest. However, if the intermediate computing device is not re-assembling the packet, it will simply pass the trailer manifest “as is” to the second computing device.
- In a further implementation, the intermediate computing device decides whether or not to re-assemble or not to re-assemble the packets using pre-determined data or by analyzing data provided by the first computing device when the first computing device connects and authenticates its data with the intermediate computing device
-
FIG. 1 is a simplified schematic diagram of a communication system for transferring information between computing devices. -
FIG. 2 is a simplified schematic diagram of an exemplary computing device used in the communications system. -
FIGS. 3-5 are flow charts disclosing a method for transferring secure documents between multiple computing devices, whereFIG. 3 is a method executed using a first computing device shown in the translation communications system, whereFIG. 4 is the method executed using an intermediate computing device shown in the communications system and whereFIG. 5 is the method executed using a second or host computing device shown in the communications system. -
FIG. 6 is a data diagram illustrating the contents of document and of a data packet. -
FIG. 7 is a data diagram illustrating an exemplary trailer manifest. - Referring to
FIG. 1 , there is shownsystem 100 having a first electronic device orfirst computing device 102 a at a first location coupled vianetwork 104 andintermediate computing device 102 b to host orsecond computing device 102 n.Computing devices computing device 102 a.First computing device 102 a,intermediate computing device 102 b andsecond computing device 102 n may be constructed using materials, processes and techniques generally known in the art, and may include conventional components. An example of one of computing devices 102 a-102 n (Device 200) is described in more detail inFIG. 2 . - Computing devices 102 a-102 n may communicate with each other via an ISO (International Standard Organization), ITU (International Telecommunications Union) or IEEE (Institute for Electrical and Electronic Engineers) standards based
network 104 or any proprietary network using structures, protocols and layouts including but not limited to TCP, Ethernet, cellular, microwave, fiber, broadband, baseband, wireless, IEEE 802.11, etc. Network 104 may be an Internet, World Wide Web, intranet, or any combination thereof. Althoughsystem 100 is shown withcomputing device 102 b being coupled tocomputing devices computing device 102 b may be coupled with many other computing devices (not shown), or coupled vianetwork 104 to other computer networks. -
Computing device 102 a communicates with anintermediate computing device 102 b coupled with afirst computing device 102 a disposed at a first location and asecond computing device 102 n disposed at a second location. Adocument 110 is provided to computingdevice 102 a from a user (e.g. the document may be generated on the computing device) or from another computing device (not shown). - Although a document is specifically mentioned in describing the preferred embodiments, it is contemplated that document may include one or more documents, any type of information, including text, algorithms, audio/video data, symbolic, animation, financial and numerical information. The document may various formats including, but not limited to, Microsoft® Word, PDF, TIFF, GIFF, Visio, Excel, WordPerfect, and JPEG file formats. Such document is typically transferred to
device 102 a using generally accepted methods, such as being transferred via an I/O device or being transferred from other computing devices (not shown) coupled tonetwork 104 using Hyper Text transfer protocols (HTTP), FTP (File Transfer Protocol), or using any generally known protocol. Thedocument 110 may be partitioned and split into portions and inserted intodata packets 110 a-110 n having equal size or unequal size depending on networking requirements bycomputing device 102 a. -
Computing device 102 a individually signs and encrypts each of the packets at the first location in accordance with a first signing and a first encryption methodology. Thefirst computing device 102 a may create atrailer manifest 114 for each document. Thetrailer manifest 114 may contain information indicating a unique ID for each of the multiple portions of the document, a table or listing containing all the unique IDs indicating an order in which the packets or portions of the packets are to be re-assembled, a hash value corresponding to the portion and a hash algorithm of the entire received document to validate the integrity of the document post assembly. -
Computing device 102 a transmits 1) the individually signed and encrypted multiple packets that each includes a portion of the document and 2)trailer manifest 114, to theintermediate computing device 102 b vianetwork 104. Suchmultiple data packets 110 may be transmitted on the same channel, in any order or may be transmitted over different channels vianetwork 104. Thetrailer manifest 114 may or may not be encrypted and/or signed before being transmitted to theintermediate computing device 102 b. -
Intermediate computing device 102 b receives vianetwork 104multiple data packets 110 a-n and thetrailer manifest 114 from thefirst computing device 102 a.Intermediate computing device 102 b decrypts the individual packets and verifies the signatures of the individual portions of the document using the first signing and encrypting methodology.Computing device 102 b may be provided keys and the hash algorithm to decrypt, verify and examine thetrailer manifest 114 to verify the integrity of the trailer manifest. In another implementation, thecomputing device 102 b may not be provided the trailer manifest keys and hash algorithm but simply passes the manifests through to computingdevice 102 n.Computing device 102 b may aggregate the decrypted and verifiedpackets 120. - In one implementation,
computing device 102 b may aggregate the received portions of the verified document in an order specified in thetrailer manifest 114. In another implementation,computing device 102 b does not aggregate the packets/portions of the document and passes them through to another computing device. In another implementation,device 102 b re-signs and re-encryptsindividual data packets 120 with a second signing and a second encryption methodology such that the individual packets can be decrypted and validated at a second location by computingdevice 102 n.Computing device 102 b transmits the re-signed and re-encryptedindividual packets 120 a-120 n to thesecond computing device 102 n via anetwork 104. In one implementation,computing device 102 b feeds the receivedtrailer manifest 124 tocomputing device 102 n. In another implementation,computing device 102 b generates thetrailer manifest 124 for the decrypted, assembled and verified document before transmitting the document tocomputing device 102 n. In another implementation the second signing and encryption methodology/algorithm is provided tocomputing device 102 b by computingdevice 102 n prior to receipt of the packets from computingdevice 102 a. The methodology/algorithms may be stored in a table in the memory ofcomputing device 102 b. -
Computing device 102 n receives vianetwork 104multiple packets 120 a′-120 n′ from theintermediate computing device 102 b and the trailer manifest.Computing device 102 n decrypts thepackets 120 a′-120 n′ and verifies the signatures of the individual packets using the second signing and encrypting methodology.Computing device 102 n may be provided keys and the hash algorithm to examine thetrailer manifest 124′ to verify the integrity of the multiple packets received fromcomputing device 102 b.Computing device 102 n then removes the portions of the document from each of the decrypted and verified packets, and aggregates the decrypted and validated portions to formdocument 130. In one implementation, the order in which the validated portions of the document are assembled/aggregated bydevice 102 n to form the document is specified in the receivedtrailer manifest 120 n′. - In
FIG. 2 are illustrated selected modules in computing device 200 (Devices 102 a-102 n ofFIG. 1 ) usingprocesses FIGS. 3-5 respectively.Computing device 200 includes aprocessing device 204 andmemory 212, andhardware 222.Computing device 200 may include one or more a microprocessors, microcontrollers or any such devices for accessingmemory 212 orhardware 222.Computing device 200 has processing capabilities and memory suitable to store and execute computer-executable instructions. -
Computing device 200 executes instruction stored inmemory 212, and in response thereto, processes signals fromhardware 222.Hardware 222 may include adisplay 224, andinput device 226 and an I/O communications device 228. I/O communications device 228 may include a network and communication circuitry for communicating withnetwork 104. -
Input device 226 receives inputs from a user of thecomputing device 200 and may include a keyboard, mouse, track pad, microphone, audio input device, video input device, or touch screen display.Display device 224 may include an LED, LCD, CRT or any type of display device to enable the user to preview information being stored or processed by computingdevice 204. -
Memory 212 may include volatile and nonvolatile memory, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules or other data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium which can be used to store the desired information and which can be accessed by a computer system. - Stored in
memory 212 of thecomputing device 200 may include anoperating system 214, acommunications system application 220 and a library of other applications ordatabase 216.Operating system 214 may be used byapplication 220 to control hardware and various software components withincomputing device 200. Theoperating system 214 may include drivers fordevice 200 to communicate with I/O communications device 228. A database orlibrary 218 may include preconfigured parameters (or set by the user before or after initial operation) such a server operating parameters, server libraries, HTML libraries, API's and configurations. An optional graphic user interface orcommand line interface 222 may be provided to enableapplication 220 to communicate withdisplay 224. -
Application 220 includes an encryptor/decryptor module 217, a signor/validator module 219 and an assembler/disassembler module 221. Encryptor/decryptor module 217 separately encrypts (and in some instances re-encrypts) and decrypts the individual portions (data packets) of the documents using encryption methodologies. Signor/validator module 219 separately verifies and signs (and in some instances re-signs) the signatures of the individual portions (data packets) of the document or the entire document using the signing/hashing methodologies and/or algorithms. Assembler/disassembler module 221 separates documents into portions, assigns a unique ID and session ID to the portions, and provides the IDs to generate a trailer manifest indicating the order of the packets. The assembler/disassembler module 221 allows aggregates/assembles portions into a document using the unique ID and session ID provided in the trailer manifest. Specifically the assembler/disassembler module 221 uses the session ID provided in the trailer manifest to determine the order the portions are aggregated to construct a document. - Application processes are described in
FIGS. 3-5 . Suchexemplary processes - Referring to
FIG. 3 , a flowchart ofprocess 300 executed by a communications application 220 (SeeFIG. 2 ) (hereafter also referred to as “application 220”) is show. In one implementation,process 300 is executed in a computing device, such asfirst computing device 102 a (FIG. 1 ).Application 220, when executed by the processing devices, uses theprocessor 204 and modules 212-228 shown inFIG. 2 . - In
block 302,application 220 incomputing device 102 a connects to and authenticates withintermediate computing device 102 b to establish a session. To establish the session,computing device 102 a providesintermediate computing device 102 b with data routing information (i.e.computing device 102 a wants to send data tocomputing device 102 n). - In
block 303,computing device 102 a receives a response fromintermediate computing device 102 b indicating unique session information (e.g. a session token) and indicating a public key to be used by computingdevice 102 a for encryption of data. The session information may be used by computingdevice 102 a to bindcomputing device 102 a to another computing device, such ascomputing device 102 n, during a data transfer session. - In
bock 304,computing device 102 a, usingmodule 217 partitions the original document into data portions. - In
block 306,computing device 102 a assigns a unique ID to each data portion of the document, then envelopes (aggregates) the unique ID, the data portion, and session token to formindividual packets 110 a-110 n. - In
block 308, the individual packets are then signed bymodule 219 and encrypted bymodule 217 incomputing device 102 a before being fed as a ‘signed/encrypted’ data packet toIntermediate Computing device 102 b. A configured key pair that is used to encrypt data packets for the document may be retrieved frommemory 212 to sign/encrypt the packets. -
Application module 219 signs each of the individual data packets and creates an ID for each of the data packets and encrypts each of the individual data packets. The individual packets for the document may be signed by computingdevice 102 a using generally known signing digest algorithms, including but not limited to, MD5 hashing algorithm, SHA-1 hashing algorithm, Elliptic Curve Digital Signature Algorithm (ECDSA). Further details of MD5 and SHA-1 digest algorithms are disclosed in IETF RFC 2014, which is hereby incorporated by reference. Further details of ECDSA are disclosed in IETF RFC 3278, which is hereby incorporated by reference. If the data packets are signed, the keys used to sign the packets may have been previously provided tocomputing device 102 a and stored inmemory 212. - Signer certificates may contain public keys that correspond to the private keys used during signing may be embedded in the signed document or signed packets. The signed packets may be formatted with an encoding scheme including but not limited to standard cryptographic message syntax (CMS). The process for signing and CMS formatting is described in IETF RFC 3852, which is hereby incorporated by reference.
- When signer certificates are embedded in the document or packets during signing, the signer certificates may not need to be pre-exchanged with computing device 102 a-n as discussed herein. Otherwise, signer certificates used to sign the document or data packets must be pre-exchanged between
computing devices device 102 b can ascertain which certificates to use when verifying the signatures of the documents or data packets. - The signed document or packets may be encrypted by encryptor/
decryptor module 217 using standard encryption algorithms using previously provided public keys stored in memory ofcomputing device 102 a. Examples of encryption algorithms include but are not limited to Triple DES, AES-128, AES-192, AES-256, CAST128, CAST256, RC2-40, and RC2-128. - The public keys used by computing
device 102 a to encrypt the packets of the data packets are known tocomputing device 102 b since computingdevice 102 b has the corresponding private keys, which enablescomputing device 102 b to decrypt the data packets. In one implementation, a list of algorithms to be used by computingdevice 102 a may be provided bycomputing device 102 b. The encrypted data packets may be formatted with an encoding scheme including but not limited to standard CMS. The encryption and CMS formatting process is described in IETF RFC 3852, which is hereby incorporated by reference. - In
block 310, each of the individual signed/encrypted data packets 110 a-110 n are transmitted to theintermediate computing device 102 b. In some implementations, a signature for each of the data packets is encrypted and transmitted with its respective individual data packet tocomputing device 102 b. The wire protocol for transferring of the encrypted and/or signed document can be any generally known protocol including but not limited to HTTP, FTP or SMTP (EMAIL). Details of such protocols are described in HTTP 1.1, HTTP1.0, FTP, FTPS, SFTP and SMTP (EMAIL), which are hereby incorporated by reference. - The cryptographic message syntax scheme defines the manner in which the data packets are signed and encrypted, encrypted and not signed, or signed and not encrypted, the encryption algorithms and key lengths, the signing digest algorithms, signers' information and signer certificates embedment information. Although the packets may be signed or encrypted, signing and encrypting of each and every one of the packets are optional and some of the packets transferred to
computing device 102 b may contain any cryptographic message syntax encoding schemes including not being signed and/or encrypted. - In
block 312, a determination is made whether an acknowledgment signal has been received fromcomputing device 102 b indicating all the individual encrypted data packets have been received. If the acknowledgment is not received within a predetermined time period after transmission, the packets are resent inblock 314. If the acknowledgment is received, thetrailer manifest 114 is created in block 316 (as previously described inFIG. 1 ). The trailer manifest includes one or more of a session token, a cryptographic hash of the original document, and an ordered list of all unique IDs for each of the packets. The ‘order’ defines the order of the portions in relation to the original document and may not necessarily reflect the actual order that the packets were sent bydevice 102 a or received by computingdevice - In
block 317,computing device 102 a signs and encrypts the trailer manifest using one or more of the algorithms previously described. - In
block 318application 220, usingOS 214 and I/O controller 216, sends the manifest tointermediate computing device 102 b. The trailer manifest 114 (which may or may not be encrypted and/or signed) is then transmitted tocomputing device 102 b vianetwork 104. - In
block 320, a determination is made whether an acknowledgment signal has been received fromcomputing device 102 b indicating the trailer manifest has been received. Theprocess 300 then repeats inblock 302. - Referring to
FIG. 4 , a flowchart ofprocess 400 executed by a communications application 220 (hereafter also referred to as application 220) incomputing device 102 b is shown. In one implementation,process 400 is executed incomputing devices 102 b (SeeFIG. 1 ) althoughprocess 400 may be executed by any of computing devices 102 a-102 n.Application 220 when executed by a computing device uses theprocessor 204 and modules 212-228 shown inFIG. 2 . - In
block 402, theapplication 220 incomputing device 102 b receives an authentication request from a computing device, such ascomputing device 102 a (FIG. 1 ). - In
block 404, when the request to authenticate fromcomputing device 102 a is received,intermediate computing device 102 b creates a session token (also referred to as “session information”) and returns the token along with the public key of theintermediate computing device 102 b toComputing device 102 a. The session token is used byintermediate computing device 102 b to determine thatcomputing device 102 a is trying to send data tocomputing device 102 n.Intermediate computing device 102 b needs to store this information so that when the packets arrive fromcomputing device 102 a,Intermediate computing device 102 b knows the computing device to be routed the data packets. - In
block 406,intermediate computing device 102 b retrieves its public key, and responds to thefirst computing device 102 a inblock 408. - In
block 412,application 220 inintermediate computing device 102 b receives fromcomputing device 102 a one or more data packets that comprise the document. The data packets are received vianetwork 104 from one of the computing devices (e.g. device 102 a). - In
block 414,application 220 decrypts the received data packets using the one or more private keys presorted in memory ofintermediate computing device 102 b. The received encrypted data packet (if encrypted) may be decrypted using the same cryptographic algorithm used to encrypt the data packet by computingdevice 102 a. Preferably the decryption algorithm may be indicated by metadata in CMS format included with the received packet or the algorithm may be previously known by the computing device.Intermediate computing device 102 b decrypts and verifies the received data packet to obtain the information contained in the packet (e.g. the Session token, unique IDs of the data portion and the data portion itself). - In
block 416, computing device authenticates/validates the signatures of the decrypted packet (if the data packet was signed). The signatures may be validated using the embedded certificates or certificates containing the public keys provided bycomputing device 102 a, or a trusted certificate issuing authority. The certificates containing the public keys used in validating the signatures may also be checked against one or more Certificate Revocation Lists (CRL). Details of CRL and its format are described in IETF RFC2459, which is hereby incorporated by reference. Alternatively, the certificates may also be verified using Online Certificate Status Protocol (OCSP) against its issuing Certificate Authority. Details of OCSP are described in IETF RFC2560, which is hereby incorporated by reference. - If the certificates are still valid and the data packet has valid signatures, the data packets may be stored in memory, and intermediate computing device may transmit a process packet acknowledgement indication to
computing device 102 a inblock 418. If the packet is determined not to be valid, or contains invalid certificates, an error may be transferred tocomputing device 102 a and an indication of such error may be logged into memory 18 b within computing device. Such error indication may be provided to another computing device on thenetwork 104 or signaled to a user using conventional means. - After authenticating the signature of the data packet, in
block 418,application 220 may transmit the process packet acknowledgment indication vianetwork 104 to the computing device that sent the data packet (e.g. device 102 a). - In
block 420, using the session token received in the data packet,application 220 determines which computing device (e.g. computing device 102 n) is to receive this data packet.Intermediate computing device 102 b retrieves the necessary information from its memory to re-encrypt and re-sign the data packet. - Once the validated data packets are stored in memory of the
computing device 102 b, the data packets could be in the clear, and contain no signing or encryption (after block 416).Intermediate computing device 102 b retrieves the necessary pre-stored information from its memory to re-encrypt and to re-sign the clear data packets. These clear data packets may be processed (by being re-encrypted and re-signed), inblock 420 using process 300 (FIG. 3 ). - Using the information indicating the computing device destined to receive the packets, the intermediate computing device (
e.g. computing device 102 b) prepares and transmits the re-signed and re-encrypted data packets to a second computing device (e.g. computing device 102 n) inblock 424. - The signing digest algorithms, signer certificates embedding process and encoding scheme format used during re-signing in
block 420 by computingdevice 102 b may be a different process/algorithm than the process/algorithm that were originally used by computingdevice 102 a. - The data packets may optionally be re-encrypted using standard encryption algorithms. Examples of such encryption algorithms include but are not limited to Triple DES, AES-128, AES-192, AES-256, CAST128, RC2-40, and RC2-128. The public keys used by computing
device 102 b to encrypt the packets may be known tocomputing device 102 n sincedevice 102 n has the corresponding private keys, which enablecomputing device 102 n to decrypt the document. The encrypted packets may be formatted with an encoding scheme including but not limited to standard CMS. The encryption and CMS formatting process is described in IETF RFC 3852, which is hereby incorporated by reference. - In
block 426,intermediate computing device 102 b determines if an acknowledgement has been received fromcomputing device 102 n. The acknowledgement indicates that the data packets were received atcomputing device 102 n as expected and alternatively may provide an indication of the specific data packets that were successfully received atcomputing device 102 n. If an acknowledgement is received the process ends. - In
block 428, if the acknowledgement was not received within a predetermined time period or an indication of non-receipt of the data packets is received fromcomputing device 102 n,intermediate computing device 102 b resends the data packet tocomputing device 102 n. Transmission retries of the data packets may need to occur as necessary during failed transmissions. - After all the data packets are received from
computing device 102 a and processed,intermediate computing device 102 b receives a trailer manifest fromcomputing device 102 a. - In
block 430, theapplication 220, receives the trailer manifest received fromcomputing device 102 a and decrypts the manifest if it was encrypted (withmodule 217 using the decryption method previously described). - In
block 432, theapplication 220 using signor/validator module 219 authenticates the signature of the trailer manifest (if the manifest was signed). - Upon authentication of the trailer manifest signature, in
block 434,application 220 transmits an indication of trailer manifest acknowledgement vianetwork 104 back tocomputing device 102 a (the sender of the trailer manifest). - In
block 436, the session information/token may be examined to determine the computing device destined to receive this manifest.Intermediate computing device 102 b also retrieves from its memory the necessary information to re-encrypt and re-sign the manifest. - In
block 438,intermediate computing device 102 b sends the signed/encrypted manifest to the determined computing device destined to receive the manifest (e.g. computing device 102 n). - In
block 440,intermediate computing device 102 b determines if an acknowledgement has been received fromcomputing device 102 n. The acknowledgement indicates that the trailer manifest was received atcomputing device 102 n as expected. If an acknowledgement is received the process ends. - In
block 442, if the acknowledgement was not received within a predetermined time period or an indication of non-receipt of the trailer manifest is received fromcomputing device 102 n,intermediate computing device 102 b resends the signed and/or encrypted manifest tocomputing device 102 n. Transmission retries may need to occur as necessary during failed transmissions. - The re-signed and/or re-encrypted data packets and trailer manifest are received by a second computing device (
e.g. computing device 102 n).Computing device 102 n may then execute blocks 502-526 shown inprocess 500 ofFIG. 5 . - In
block 502,second computing device 102 n (also referred to as host or server computing device) receives data packets from theintermediate computing device 102 b vianetwork 104. - When a signed/encrypted data packet arrives from
intermediate computing device 102 b,computing device 102 n decrypts and verifies/authenticates the packet (which contains the session token, unique IDs of the data portions and the data portion itself) inblocks decryptor module 217 and signor/validator module 219 (SeeFIG. 2 ). Generally, the received encrypted data packets (if encrypted) may be decrypted by computingdevice 102 n using the same algorithm used to encrypt the data packets by computingdevice 102 b. Preferably the decryption algorithm is indicated by metadata in the CMS format included with the received data packets or the algorithm may be previously known by computingdevice 102 n. -
Computing device 102 n may validate the signature of the decrypted data packets (if signed) withmodule 219. The signatures may be validated using the embedded certificates or certificates containing the public keys provided bycomputing device 102 b, or a trusted certificate issuing authority. The certificates containing the public keys used in validating the signatures may also be checked against one or more Certificate Revocation Lists (CRL). Details of CRL and its format are described in IETF RFC2459, is hereby incorporated by reference. Alternatively, the certificates may also be verified using Online Certificate Status Protocol (OCSP) against its issuing Certificate Authority. Details of OCSP are described in IETF RFC2560, which is hereby incorporated by reference. - In
block 514,computing device 102 n stores the decrypted/validated packets in a local storage device, such asmemory 212. Inblock 516,computing device 102 n provides an acknowledgement tointermediate computing device 102 b vianetwork 104. - In
block 508,computing device 102 n, receives and decrypts the trailer manifest fromintermediate computing device 102 b using encryptor/decryptor module 217. - In
block 510computing device 102 n, authenticates the signature of the received trailer manifest.Computing device 102 n, upon authentication of the signature transmits an ACK indication (acknowledgement) tointermediate computing device 102 b. - In
block 518,computing device 102 n reads the decrypted/verified manifest to determine the ordered list of unique IDs in the received trailer manifest.Computing device 102 n also usesassembler module 221 to reorder and reassemble the portions of the document from the received packets (stored in local storage in block 514) into a document to reconstruct the original document as provided fromcomputing device 102 a. - In
block 520,computing device 102n using application 220, calculates a crypto hash of the reassembled document. Inblock 522,computing device 102 n validates reassembled document by comparing the calculated crypto hash with the crypto hash found inside the trailer manifest received fromcomputing device 102 b. In one implementation, if the document is determined not to be valid, an error is sent tocomputing device 102 a and/or 102 b, and an indication of such error may be logged withincomputing device 102 n inblock 524. Such error indication may be provided to another computing device vianetwork 104 or signaled to a user using conventional means. If the reassembled document is determined to be valid, an indication may be provided to other processes incomputing device 102 n that the document was received. - Although the preferred embodiments describe transferring a data packets from computing
device 102 a to 102 n viacomputing device 102 b (FIG. 1 ), such data packets may be transferred fromcomputing device 102 n tocomputing device 102 a using the methods shown inFIGS. 3-5 either directly or via other computing devices, wherecomputing device 102 n implements the methods shown inFIG. 3 ,computing device 102 b implements the methods shown inFIG. 4 , andcomputing device 102 n implements the methods shown inFIG. 5 . Also the process described in this specification discloses translating one data packets between multiple computing devices; the process could further translate multiple data packets, and transmit each of the multiple translated data packets to one or more computing devices from an intermediate computing device such that each of the data packets is translated at the intermediate computing device with a different signing or encryption scheme. Also althoughcomputing device 102 b is described as the intermediate computing device, any computing device could be substituted forcomputing device 102 b. Further, the processes described with respect tocomputing devices computing devices computing device 102 n viacomputing device 102 b tocomputing device 102 a. - Referring to
FIG. 6 , there is shown anexemplary data packet 602, and adocument 604.Data packet 604 includes asession token 606, unique ID of adocument portion 608 and aportion 612 of thedocument 604.Document 604 is comprised ofmultiple portions 612 a-612 n which may be of equal or unequal sizes. - An exemplary trailer manifest is shown in
block 700 ofFIG. 7 . Trailer manifest includes session token, packet information comprising Packet unique IDs portions and the original document hash and hash algorithm. Appendix to the packet ID is an indication of the order in the document of - While the above detailed description has shown, described and identified several novel features of the invention as applied to a preferred embodiment, it will be understood that various omissions, substitutions and changes in the form and details of the described embodiments may be made by those skilled in the art without departing from the spirit of the invention. Accordingly, the scope of the invention should not be limited to the foregoing discussion, but should be defined by the appended claims.
Claims (19)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/790,723 US8533479B2 (en) | 2004-11-22 | 2010-05-28 | Translating information between computing devices having different security management |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/994,921 US7730298B2 (en) | 2004-11-22 | 2004-11-22 | Method and apparatus for translating information between computers having different security management |
US12/790,723 US8533479B2 (en) | 2004-11-22 | 2010-05-28 | Translating information between computing devices having different security management |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/994,921 Continuation-In-Part US7730298B2 (en) | 2004-11-22 | 2004-11-22 | Method and apparatus for translating information between computers having different security management |
Publications (2)
Publication Number | Publication Date |
---|---|
US20110145584A1 true US20110145584A1 (en) | 2011-06-16 |
US8533479B2 US8533479B2 (en) | 2013-09-10 |
Family
ID=44144235
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/790,723 Expired - Fee Related US8533479B2 (en) | 2004-11-22 | 2010-05-28 | Translating information between computing devices having different security management |
Country Status (1)
Country | Link |
---|---|
US (1) | US8533479B2 (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060133522A1 (en) * | 2004-12-22 | 2006-06-22 | Arak Sutivong | MC-CDMA multiplexing in an orthogonal uplink |
US20070211790A1 (en) * | 2003-05-12 | 2007-09-13 | Qualcomm Incorporated | Fast Frequency Hopping With a Code Division Multiplexed Pilot in an OFDMA System |
US20080310349A1 (en) * | 2007-06-18 | 2008-12-18 | Qualcomm Incorporated | Multiple bindings having independent forward and reverse link bindings for mobile internet protocols |
US20110001539A1 (en) * | 2009-07-02 | 2011-01-06 | Qualcomm Incorporated | Mixer-transconductance interface |
US20120042018A1 (en) * | 2010-08-12 | 2012-02-16 | Ravi Singh | System and method for message delivery |
US8238923B2 (en) | 2004-12-22 | 2012-08-07 | Qualcomm Incorporated | Method of using shared resources in a communication system |
US8594021B2 (en) | 2010-07-19 | 2013-11-26 | Qualcomm Incorporated | Effective timing measurements by a multi-mode device |
US8611283B2 (en) * | 2004-01-28 | 2013-12-17 | Qualcomm Incorporated | Method and apparatus of using a single channel to provide acknowledgement and assignment messages |
US8724555B2 (en) | 2002-10-29 | 2014-05-13 | Qualcomm Incorporated | Uplink pilot and signaling transmission in wireless communication systems |
US9480074B2 (en) | 2004-07-23 | 2016-10-25 | Qualcomm Incorporated | Enabling quick and easy demodulation |
US9871660B2 (en) * | 2014-12-23 | 2018-01-16 | Banco De Mexico | Method for certifying and authentifying security documents based on a measure of the relative variations of the different processes involved in its manufacture |
US20180060612A1 (en) * | 2010-01-28 | 2018-03-01 | International Business Machines Corporation | Distributed storage with data obfuscation and method for use therewith |
US20180198766A1 (en) * | 2015-07-06 | 2018-07-12 | Samsung Electronics Co., Ltd. | Method, apparatus, and system for monitoring encrypted communication session |
US20190007293A1 (en) * | 2017-06-28 | 2019-01-03 | Cpacket Networks Inc. | Apparatus and method for correlating network traffic on opposite sides of a network address translator |
CN110915161A (en) * | 2017-07-12 | 2020-03-24 | 惠普发展公司,有限责任合伙企业 | Migration of memory devices |
US20230353377A1 (en) * | 2022-05-02 | 2023-11-02 | Unisys Corporation | System and method for file and file system integrity independent of file type or contents |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6185683B1 (en) * | 1995-02-13 | 2001-02-06 | Intertrust Technologies Corp. | Trusted and secure techniques, systems and methods for item delivery and execution |
US6308277B1 (en) * | 1996-12-20 | 2001-10-23 | Gte Cybertrust Solutions Incorporated | Virtual certificate authority |
US6725373B2 (en) * | 1998-03-25 | 2004-04-20 | Intel Corporation | Method and apparatus for verifying the integrity of digital objects using signed manifests |
US6748538B1 (en) * | 1999-11-03 | 2004-06-08 | Intel Corporation | Integrity scanner |
US7159240B2 (en) * | 2001-11-16 | 2007-01-02 | Microsoft Corporation | Operating system upgrades in a trusted operating system environment |
US7478243B2 (en) * | 2001-03-21 | 2009-01-13 | Microsoft Corporation | On-disk file format for serverless distributed file system with signed manifest of file modifications |
US7526645B2 (en) * | 2003-07-15 | 2009-04-28 | Hitachi, Ltd. | Electronic document authenticity assurance method and electronic document disclosure system |
-
2010
- 2010-05-28 US US12/790,723 patent/US8533479B2/en not_active Expired - Fee Related
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6185683B1 (en) * | 1995-02-13 | 2001-02-06 | Intertrust Technologies Corp. | Trusted and secure techniques, systems and methods for item delivery and execution |
US6308277B1 (en) * | 1996-12-20 | 2001-10-23 | Gte Cybertrust Solutions Incorporated | Virtual certificate authority |
US6725373B2 (en) * | 1998-03-25 | 2004-04-20 | Intel Corporation | Method and apparatus for verifying the integrity of digital objects using signed manifests |
US6748538B1 (en) * | 1999-11-03 | 2004-06-08 | Intel Corporation | Integrity scanner |
US7478243B2 (en) * | 2001-03-21 | 2009-01-13 | Microsoft Corporation | On-disk file format for serverless distributed file system with signed manifest of file modifications |
US7159240B2 (en) * | 2001-11-16 | 2007-01-02 | Microsoft Corporation | Operating system upgrades in a trusted operating system environment |
US7526645B2 (en) * | 2003-07-15 | 2009-04-28 | Hitachi, Ltd. | Electronic document authenticity assurance method and electronic document disclosure system |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9155106B2 (en) | 2002-10-29 | 2015-10-06 | Qualcomm Incorporated | Uplink pilot and signaling transmission in wireless communication systems |
US8724555B2 (en) | 2002-10-29 | 2014-05-13 | Qualcomm Incorporated | Uplink pilot and signaling transmission in wireless communication systems |
US20070211790A1 (en) * | 2003-05-12 | 2007-09-13 | Qualcomm Incorporated | Fast Frequency Hopping With a Code Division Multiplexed Pilot in an OFDMA System |
US8102832B2 (en) | 2003-05-12 | 2012-01-24 | Qualcomm Incorporated | Fast frequency hopping with a code division multiplexed pilot in an OFDMA system |
US8611283B2 (en) * | 2004-01-28 | 2013-12-17 | Qualcomm Incorporated | Method and apparatus of using a single channel to provide acknowledgement and assignment messages |
US9871617B2 (en) | 2004-07-23 | 2018-01-16 | Qualcomm Incorporated | Method of optimizing portions of a frame |
US9480074B2 (en) | 2004-07-23 | 2016-10-25 | Qualcomm Incorporated | Enabling quick and easy demodulation |
US8649451B2 (en) | 2004-12-22 | 2014-02-11 | Qualcomm Incorporated | MC-CDMA multiplexing in an orthogonal uplink |
US8638870B2 (en) | 2004-12-22 | 2014-01-28 | Qualcomm Incorporated | MC-CDMA multiplexing in an orthogonal uplink |
US20060133522A1 (en) * | 2004-12-22 | 2006-06-22 | Arak Sutivong | MC-CDMA multiplexing in an orthogonal uplink |
US8238923B2 (en) | 2004-12-22 | 2012-08-07 | Qualcomm Incorporated | Method of using shared resources in a communication system |
US8817897B2 (en) | 2004-12-22 | 2014-08-26 | Qualcomm Incorporated | MC-CDMA multiplexing in an orthogonal uplink |
US8831115B2 (en) | 2004-12-22 | 2014-09-09 | Qualcomm Incorporated | MC-CDMA multiplexing in an orthogonal uplink |
US8559396B2 (en) | 2007-06-18 | 2013-10-15 | Qualcomm Incorporated | Multiple bindings having independent forward and reverse link bindings for mobile internet protocols |
US20080310349A1 (en) * | 2007-06-18 | 2008-12-18 | Qualcomm Incorporated | Multiple bindings having independent forward and reverse link bindings for mobile internet protocols |
US20110001539A1 (en) * | 2009-07-02 | 2011-01-06 | Qualcomm Incorporated | Mixer-transconductance interface |
US8432211B2 (en) | 2009-07-02 | 2013-04-30 | Qualcomm Incorporated | Mixer-transconductance interface |
US20180060612A1 (en) * | 2010-01-28 | 2018-03-01 | International Business Machines Corporation | Distributed storage with data obfuscation and method for use therewith |
US11301592B2 (en) * | 2010-01-28 | 2022-04-12 | Pure Storage, Inc. | Distributed storage with data obfuscation and method for use therewith |
US8594021B2 (en) | 2010-07-19 | 2013-11-26 | Qualcomm Incorporated | Effective timing measurements by a multi-mode device |
US20120042018A1 (en) * | 2010-08-12 | 2012-02-16 | Ravi Singh | System and method for message delivery |
US9871660B2 (en) * | 2014-12-23 | 2018-01-16 | Banco De Mexico | Method for certifying and authentifying security documents based on a measure of the relative variations of the different processes involved in its manufacture |
US20180198766A1 (en) * | 2015-07-06 | 2018-07-12 | Samsung Electronics Co., Ltd. | Method, apparatus, and system for monitoring encrypted communication session |
US11153287B2 (en) * | 2015-07-06 | 2021-10-19 | Samsung Electronics Co., Ltd | Method, apparatus, and system for monitoring encrypted communication session |
US20190007293A1 (en) * | 2017-06-28 | 2019-01-03 | Cpacket Networks Inc. | Apparatus and method for correlating network traffic on opposite sides of a network address translator |
CN110915161A (en) * | 2017-07-12 | 2020-03-24 | 惠普发展公司,有限责任合伙企业 | Migration of memory devices |
US20230353377A1 (en) * | 2022-05-02 | 2023-11-02 | Unisys Corporation | System and method for file and file system integrity independent of file type or contents |
Also Published As
Publication number | Publication date |
---|---|
US8533479B2 (en) | 2013-09-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8533479B2 (en) | Translating information between computing devices having different security management | |
US10652015B2 (en) | Confidential communication management | |
US11089032B2 (en) | Signed envelope encryption | |
US10447674B2 (en) | Key exchange through partially trusted third party | |
US10511579B2 (en) | Confidential mail with tracking and authentication | |
US9800416B2 (en) | Distributed validation of digitally signed electronic documents | |
Ramsdell et al. | Secure/multipurpose internet mail extensions (S/MIME) version 3.2 message specification | |
US9912486B1 (en) | Countersigned certificates | |
Schaad et al. | Secure/multipurpose internet mail extensions (s/mime) version 4.0 message specification | |
US9888037B1 (en) | Cipher suite negotiation | |
US20050228999A1 (en) | Audit records for digitally signed documents | |
KR100965886B1 (en) | Method for managing metadata | |
US20070118735A1 (en) | Systems and methods for trusted information exchange | |
US20200320178A1 (en) | Digital rights management authorization token pairing | |
KR100890720B1 (en) | Method for Selectively Encrypting Web Contents and Computer-Readable Recording Medium Where Program Executing the Same Method | |
US7730298B2 (en) | Method and apparatus for translating information between computers having different security management | |
JP2008118653A (en) | Method for managing metadata | |
Ramsdell et al. | RFC 5751: Secure/multipurpose internet mail extensions (S/MIME) version 3.2 message specification | |
Schaad et al. | RFC 8551: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification | |
Abd El-Aziz | An Overview on XML Security Technologies. | |
CN117499032A (en) | Communication method, device, equipment and storage medium | |
Lloyd | A Framework For Securing Jabber Conversations |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HUBSPAN INC., WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CO BURN, MAX N.;HUYNH, YEN LUONG;REEL/FRAME:024811/0146 Effective date: 20100603 |
|
AS | Assignment |
Owner name: MMV FINANCIAL INC., ONTARIO Free format text: SECURITY AGREEMENT;ASSIGNOR:HUBSPAN, INC.;REEL/FRAME:025586/0070 Effective date: 20101230 |
|
AS | Assignment |
Owner name: HUBSPAN, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MMV CAPITAL PARTNERS, INC.;REEL/FRAME:030504/0603 Effective date: 20120815 |
|
AS | Assignment |
Owner name: LIAISON TECHNOLOGIES, INC., GEORGIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HUBSPAN, INC.;REEL/FRAME:030772/0175 Effective date: 20130710 |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.) |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20170910 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:LIAISON TECHNOLOGIES, INC.;REEL/FRAME:047950/0910 Effective date: 20170329 Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:HUBSPAN, INC.;REEL/FRAME:047951/0744 Effective date: 20130701 Owner name: HUBSPAN, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:047951/0741 Effective date: 20181217 Owner name: LIAISON TECHNOLOGIES, INC., GEORGIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:048043/0532 Effective date: 20181217 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE LISTED PATENTS,NAMELY 5 NOS. LISTED AS PATENT NOS.(9590916,9344182,9650219,9588270,9294701),SHOULD BE LISTED AS APPLICATION NOS. PREVIOUSLY RECORDED ON REEL 047950 FRAME 0910. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY INTEREST;ASSIGNOR:LIAISON TECHNOLOGIES, INC.;REEL/FRAME:051255/0831 Effective date: 20170329 |