Abstract:
The present invention provides a method and apparatus for a trusted service provider (TSP) which assists with the secure exchange of data across the public switched telephone network. Communications are routed via a TSP, which uses cryptographic techniques to conceal the identities (e.g., telephone numbers) of the call initiator and call recipient, thereby preventing traffic analysis attacks. The TSP also performs cryptographic handshakes with the call initiator and call recipient to authenticate callers. The TSP further provides cryptographic keying material which communicants may use to help protect communications and to directly authenticate and identify each other. Although the TSP is trusted to negotiate the connection and is involved in the process, the communicants can perform their own key agreement and authentication for protecting data routed via the TSP.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 08/908,994 filed on Aug. 8, 1997, now U.S. Pat. No. 7,743,247, incorporated herein by reference in its entirety. 
    
    
     STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
     Not Applicable 
     INCORPORATION-BY-REFERENCE OF MATERIAL SUBMITTED ON A COMPACT DISC 
     Not Applicable 
     FIELD OF THE INVENTION 
     The invention relates to methods and apparatus for the secure communication of data, and more specifically to methods and apparatus for the delivery of encrypted data across publicly-accessible networks. 
     BACKGROUND OF THE INVENTION 
     Nearly every modern industry and profession requires the rapid delivery of a variety of types of communications. In many instances, an additional requirement is that the documents be maintained confidential during the delivery process. A still further complication is the ability of the recipient to verify the authenticity of the received document. 
     To respond to such requirements, the entire courier industry has been developed. Thus, a courier service arranges to pick up an original document from the sender and to deliver it, as promptly as possible within the charging structure, to a recipient. Because the document is maintained in a sealed envelope, confidential communications are frequently entrusted to such courier services. Since the documents can bear original signatures, their authenticity is generally presumed. 
     However, the operation of a courier service is labor intensive and the cost structure of the industry reflects its dependence on extensive manual effort. In addition, the responsiveness of the industry is generally dependent on the sender and recipient both being in either dose proximity or near a major airport. Thus, a recipient located in a remote portion of a foreign country may encounter significant delays in receiving a communication by courier simply because delivery requires extensive manual handling of the communication. 
     In addition, while a document delivered by courier is generally presumed to be maintained confidential, in fact it is apparent the confidentiality of the communication may be compromised with exceptional ease. As a result, some industries have taken to using specialized couriers which offer particular assurances of confidentiality. 
     Still further, the reliability of a courier service is equally limited, since it depends upon each link in a potentially extensive chain operating with substantial success. While such success occurs in the great majority of cases, there are numerous instances where increased reliability would be greatly desirable. 
     While modem telecommunications offers a response to some of the concerns about couriers, existing systems have generally proven inadequate to provide a suitable replacement for courier services. Thus, while a telephone call offers immediacy and access virtually to the farthest reaches of the globe, conventional telephone communications are not especially secure and do not provide communication of documents. 
     Fax machines, including fax machines with provision for confidential faxing, likewise suffer from numerous limitations, which include in most instances a lack of data encryption and substantial manual involvement in ensuring that the document is properly entered into the fax machine. Fax modems incorporated into personal computers offer some improvement on the document-loading scheme, but offer little or no encryption of the data, and typically do not verify destination. The result is little security for potentially quite valuable communications. 
     As a result, there has been a need for a secure communications technique which offers reliable high speed access to virtually anywhere a telephone or other network connection exists, while at the same time offering a high degree of confidentiality and security to the communications. 
     The security of data sent over telecommunications networks, including telephone networks, is important for many computer applications and systems. With a large network or a network that involves access via a public utility such as the telephone company, it is impractical to assure the physical security of the communications channel. Even with a single location, the size and configuration of most networks (e.g., wires, fiber optic cables, switching hardware, etc.) make it expensive or impossible to assure that communications are not being monitored. 
     An ideal data communications system would be easy to operate, inexpensive, reliable, widely available, fast, and secure. Existing networks, such as the public switched telephone network (PSTN), may be used to obtain some of these characteristics. In particular, the PSTN is relatively inexpensive, widely available, and reliable. The PSTN can be used to exchange digital data with reasonable speed (e.g., 28.8 kilobits per second using a modem implementing the V.34 protocol defined in International Telecommunications Union, “Recommendation V.34—A modem operating at data signaling rates of up to 28800 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits,” September 1994.) Higher speed modems, such as those operating at 33.6 or 56 kilobits per second, ISDN lines operating at up to 128 k-bits, or ADSL lines operating at even higher rates offer improved performance through the PSTN. 
     However, the PSTN is often not sufficiently secure for exchanging sensitive information. Specifically, communications may be monitored by tapping a telephone line or by recording a call at the telephone switch. Additional privacy protection is thus desirable. 
     Some kinds of protection may be added by users of the network to protect their own communications. For example, encryption may be used to ensure that eavesdroppers cannot determine the content of communications. Encryption algorithms, including the Data Encryption Standard (DES), are well known in the background art and may be used in scrambling and security systems to protect the privacy of data. (DES is defined in National Bureau of Standards, NBS FIPS PUB 46-1, “Data Encryption Standard,” U.S. Department of Commerce, January 1988.) 
     End users can also use cryptography to protect their data exchanges against accidental or malicious modification. (Such tampering can occur even if data is encrypted, since changes made to the ciphertext data stream will generally result in changes to the Plaintext data produced by the decryption process.) To protect against tampering, keyed MAC functions such as HMAC are often used. (HMAC is defined in M. Bellare, R. Canetti, and H. Krawczyk, “Keying Hash Functions for Message Authentication,”  Advances in Cryptology—Crypto &#39; 96  Proceedings , Springer-Verlag, 1996, pp. 1-15.) Alternatively, data may be digitally signed, for example using the RSA algorithm of U.S. Pat. No. 4,405,829 to Rivest et al. or using the Digital Signature Standard (National Institute of Standards and Technology, NIST FIPS PUB 186, “Digital Signature Standard,” U.S. Department of Commerce, May 1994). Protocols and techniques usable by communicants to encrypt data and to protect data against tampering are well known in the background art. For example, the SSL protocol, used widely to protect transactions on the world wide web and in other applications, combines asymmetric (public-key) cryptography, symmetric (secret-key) cryptography, and MACs to securely select which cryptographic algorithms to use, authenticate communicants, negotiate shared keys, encrypt and decrypt data for privacy, and protect data against modification. 
     Encrypting modems (and other network interfaces) which use DES and other encryption algorithms to protect communications sent over the public switched telephone network (and other communications systems) are also known. Secure modems using encryption algorithms such as DES are commercially available, and modems running more sophisticated cryptographic protocols (such as SSL) are also known. Such modems can, if used properly, provide users with good cryptographic assurance of data privacy and integrity. 
     However, such encrypting modems cannot solve many applications&#39; security and business requirements, and consequently they have failed to gain widespread acceptance in the marketplace. For example, existing encrypting modems used over the PSTN cannot protect the identities of communicating parties. In many cases it is as important to conceal from eavesdroppers the identities of the communicants as it is to protect the actual content of their communication. This problem cannot be solved by an end-user device since, for example, an eavesdropper can identify the recipient of a modem connection simply by observing the telephone number dialed by the party originating the call (e.g., by monitoring the DTMF tones generated by the transmitting telephone or modem). Other networking protocols suffer from the same limitation that eavesdroppers can determine at least identity of the intended recipient of data, even if the data is encrypted. Although Internet-based systems for protecting users&#39; anonymity are known (e.g., remailers for PGP-encrypted e-mail and anonymizers for world wide web communications), the techniques they employ do not work with public switched telephone networks, and companies generally do not wish to send their private communications over the Internet. 
     A second problem with systems known in the background art is that the cost of the development and manufacture of the secure modem hardware and software must be recovered when users purchase the equipment. Since no after-purchase revenue is available to device manufacturers and vendors, customers are forced to make a substantial initial investment, often of several hundred dollars per user, to purchase the hardware and/or software. Many potential customers, such as companies with a large number of users who would all need to be equipped with the hardware, are deterred by this initial cost and ultimately end up using cheaper, less secure systems. 
     There has therefore been a long felt need for a data communications system which is easy to use, reliable, fast, secure and economical for transmitting confidential or sensitive information expeditiously even to remote points. 
     SUMMARY OF THE INVENTION 
     The present invention describes method and apparatus for delivering highly secure communications between authorized parties who may be remotely located with access available only over publicly accessible networks. Although the preferred embodiment of the invention protects standard modem communications exchanged via the PSTN, alternate embodiments may be used to protect other communications sent via ISDN or using other means. In general, the present invention may be thought of as an integrated network of dedicated hardware, communications software and telecommunications technology providing a secure private network for the delivery of electronic information. 
     The hardware layer of the present invention comprises at least a sender and recipient personal computer system, a device (typically a modem) at both the sender&#39;s and recipient&#39;s ends for accessing a telecommunications service, and a telephony server (typically a single device, but may be comprised of two or more servers, each of which could have one or more clients, networked to achieve greater efficiency and/or capacity), for managing connections between the respective computer/modem of the sender and recipient. 
     A variety of personal computers or workstations may be connected to the network of the present invention; in general, the invention is equally applicable on any available operating system and their associated platform, including Apple Macintosh™, IBM PC™, Sun™ or other Unix platforms, and so on. 
     Each personal computer system includes a modem device which, in at least some embodiments of the present invention, will be a secure modem device (“SMD”.) In a presently preferred embodiment, the sender initiates a telephone call via the PSTN to a telephony server (“TS”). The TS serves as an intermediary between the sender and the receiver, thus protecting their identities from eavesdroppers, and additionally helps communicants negotiate key material and authenticate each other. In addition, the TS maintains appropriate record-keeping to track usage and thereby provide a source of revenue to manufacturers and vendors other than from the sale of security devices to end users. 
     In addition to the hardware layer, at the PC the present invention includes a software transport layer which may be thought of as including, at the top level, an operator interface, and behind the operator interface a communications module for managing communications with either a sender or recipient, key management, and enciphering and deciphering of messages. The Communications Module may reside in either the PC or the modem. 
     Documents selected for transmission are selected from a listing of available files; similarly, the destination is selected from a list of authorized destinations or, if not currently on the list, added as appropriate. The selection of files to be transmitted and their destination is particularly intended to be intuitive to the user, to permit successful operation of the system without the need for extensive training. 
     In operation, the call from the sender is routed to the TS in a conventional manner; that is, the sender initiates a call to the TS with the number encoded as a sequence of DTMF signals. The PSTN switch decodes the initial DTMF signals and routes the sender&#39;s call to the TS. After the TS answers the call, the TS and calling SMD follow a cryptographic protocol in which the caller authenticates the TS, the TS authenticates the caller, the TS receives an identifier of the call recipient&#39;s identity in encrypted form, and the caller receives encrypted key material from the TS. The TS can therefore be seen to verify the trust relationship between the sender and the recipient; the TS can therefore be seen to be a trusted service provider, or “TSP.” 
     After receiving the cryptographically-protected representation of the call recipient&#39;s identity from the calling SMD, the TS attempts to establish a data connection with the specified destination party, first checking to determine whether or not the recipient is an authorized destination. If successful, the call recipient&#39;s SMD answers the call from the TS and performs a cryptographic handshake with the TS. In the handshake, the TS and the recipient&#39;s SMD cryptographically authenticate each other. In some embodiments the TS provides, in encrypted form, identification of the calling party. In addition, the same key material provided during the initial (TS/call initiator) handshake may also be sent, in cryptographically-protected form, to the call recipient. 
     When the handshakes are complete, the TS connects the incoming connection (from the call initiator&#39;s SMD) with the outgoing connection (to the call recipient&#39;s SMD), thereby allowing the SMDs to communicate directly with each other. At this point the TS may be effectively disconnected from the call. In a presently preferred embodiment, the SMDs establish a secure communications channel keyed using information derived either from the TSP-supplied keying material or negotiated directly between the SMDs; alternatively, information previously shared between the SMDs may also be used. No information which could be used by an attacker to identify the communicants needs to be exchanged in plaintext, or unencrypted, form. Once the SMDs have established, via the TSP, a secured communications channel, they exchange data, which may take the form of messages, files, images, programs, and so on, or may in some embodiments include video or audio information. 
     Because the recipient identification information is encrypted, it is protected from eavesdroppers. Cryptographic protocols and handshakes protect the system from other forms of attack. In addition, for added security, telephonic verification may be added as an authentication step to ensure that attackers cannot spoof the operation of the TS. 
     In addition to routing the telephone call, in a typical embodiment the switch collects information for auditing and billing purposes. For example, users may be billed on a per-call and/or per-minute basis for using the service. Such billing may be performed by any means, but in the preferred embodiment is accomplished by submitting charges to appear on the telephone bill of the call initiator, call recipient, or a third party. 
     Note that the TSP need not play any active role in the data exchange between the SMDs; it can simply serve as a portion of the communication network connecting the devices. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates in block diagram form a secure communications system according to the present invention. 
         FIG. 2  illustrates a communications transport layer in accordance with the present invention. 
         FIG. 3A  illustrates a first alternative of a screen in accordance with the present invention for selection of files for transfer. 
         FIG. 3B  illustrates a second alternative of a screen for selection of files for transfer in accordance with the present invention. 
         FIG. 4  illustrates in flow diagram form the Call Manager protocol of the present invention. 
         FIGS. 5A-5C  illustrate in flow diagram form the Key Exchange protocol by which keys are exchanged between sender and receiver. 
         FIG. 6A  illustrates a first authentication screen for one stage of a file transfer. 
         FIG. 6B  illustrates a second authentication screen for a second stage of a file transfer. 
         FIGS. 7A-7D  illustrate in flow diagram form the Data Exchange protocol by which a file transfer is made between sender and receiver. 
         FIG. 8A  illustrates a first alternative of a send log screen in accordance with the present invention. 
         FIG. 8B  illustrates a second alternative of a send log screen in accordance with the present invention. 
         FIG. 8C  illustrates an embodiment of a receive log screen in accordance with the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Referring first to  FIG. 1 , the overall system of the present invention can be better appreciated. In simplest terms and without describing the software transport discussed at length below, a secure communications system indicated generally at  10  comprises a first personal computer or other workstation  15  operating in conjunction with a modem or other device  20  to access a local exchange carrier  25  of the PSTN or other communications link such as ISDN. A person seeking to make a secure exchange of data with a recipient selects the recipient on an appropriate menu, discussed hereinafter, which causes the workstation  15  to dial, through the modem  20 , a single telephone number which connects the workstation  15  through the Sender&#39;s local exchange carrier  25 . The local exchange carrier  25  then connects the call, either through the local carrier or a long distance carrier  30 , to a local exchange carrier  35  at the point of presence of a telephony switch  40 . In this manner, the call is connected to the telephony switch  40 . 
     The telephony switch  40  cooperates with a telephony server  45  to which it is linked, and the telephony server both validates the identity of the recipient&#39;s account and authorizes a telephone connection to the recipient via the telephony switch  40 . The telephony switch  40  then dials the recipient&#39;s modem number, again through the local exchange carrier  35  and also (possibly) through a receiver-side long distance carrier  50  as well as a Receivers local exchange carrier  55  located near the recipient. The Receiver&#39;s local exchange carrier  55  relays the call in a completely conventional manner to the recipient&#39;s modem  60  (or other similar device) and the recipient&#39;s associated workstation  65 . After appropriate handshaking and authentication, discussed in greater detail hereinafter, the telephony server is effectively disconnected from the call and the data is transferred from the sender workstation  15  to the recipient workstation  65 . 
     An additional but important feature of the system of the present invention is the capture of sufficient data to base billings on use of the system, similar to the manner in which conventional telephone calls are billed. To achieve this goal, a billing tape  70  captures the connection data for the authorized call initiated by the sender, and forwards it to an appropriate billing function. In a preferred embodiment, the captured data is provided to a billing system  75  of a conventional local exchange carrier who incorporates the billing into the conventional local phone bill. The bills  80  may then be sent to the user. 
     Although the hardware comprising the system has been described generally, above, many of the critical functions of the system are performed in software. In particular, software functions are critical at the PC layer for both the sender and the receiver, and separately at the telephony server. At the PC level, including the modem, the software function comprises a communications transport layer, shown in  FIG. 2 . In particular, the communications transport layer comprises an operator interface  85  which communicates bidirectionally with a communications module  90  comprising three sub-modules  95 A- 95 C to perform communications, key management and encipher/decipher functions. The communications sub-module provides a connection between a PC and a modem and the private network of the invention. The key management sub-module manages the enciphering/deciphering keys required for data transfers, while the enciphering/deciphering sub-module coordinates the encryption and decryption, as appropriate, of the data being transferred. 
     Referring next to  FIGS. 3A-3B , which are alternative embodiments of a screen for selection of files to be transferred in accordance with the present invention, the operation of the system of the present invention may be appreciated in greater detail.  FIG. 3A  uses the Windows 95® version of the operator interface  85  by example, but alternately may comport to the look and feel of Java, UNIX, Macintosh® or other standards, as appropriate, and for example the Java screen may be as shown in  FIG. 3B  where like elements with  FIG. 3A  are shown with like reference numerals. To initiate a data transfer in accordance with the invention, a caller must have a valid account number stored in the system, typically at the telephony server. In addition, the recipient must have a valid account number stored in the same manner. The user seeking to initiate a data transfer opens the program, which brings up the window shown at  200  in  FIG. 3 . The window  200  may be seen to replicate closely the intuitive paradigm of an envelope: the left portion  205  of the window  200  includes a drop-down list of callers  210 , which brings up, for example, the sender&#39;s account number and other appropriate identifying information. Similarly, the right portion  215  of the window  200  includes a drop-down list of recipients  220 , with identifying information comparable to that shown in the left portion  205  and status information relative to authentication. Thus, the sender simply selects from the drop down lists the appropriate caller and recipient account information, in a manner intuitive to anyone who has ever addressed an envelope. 
     In addition to selecting a caller and a recipient, it is also necessary for the sender to select the data to be transferred. Although the data can take any form, including audio information, video information, or other data, for purposes of simplicity the information transferred in this example will be assumed to be conventional data or program files. 
     To select the files to be transferred, the user selects a “Send Files” tab  225  from a lower portion  230  of the window  200 . The “Send Files” tab opens a drive window  235  which may, for example, list the directories in the selected drive. In an adjacent window  240  the files in a selected drive or directory(s) is displayed. The user selects files to be transferred from the files displayed in the window  240 , which causes the selected files to be displayed in a selected files window  245 . The user can select as many files as desired. 
     By clicking on the SEND icon  250 , the files are aggregated, compressed and encrypted, forming a single session. At that point the call is automatically initiated. As previously noted, in a presently preferred configuration the modem is permitted to dial only the number of the telephony switch  40 , although in some embodiments it may be desirable to use a conventional modem. This begins the process of actually exchanging data between the two systems. 
     Successful completion of a data transfer between two systems requires the completion of three protocols: the Call Manager protocol, the Key Exchange protocol, and the Data Exchange protocol. In general, the Call Manager protocol manages the process by which a caller (via a PC and modem) is identified to the telephony server  45 , and identifies the recipient of the call—by account number in the exemplary embodiment described here. The PC  15  causes the modem  20  to generate DTMF codes to connect to the telephony server, identifying itself and the recipient. If both account numbers are valid, the caller and recipient are connected through the telephony switch to permit the respective PCs  15  and  65  to exchange data. At the same time, the telephony switch logs the call and captures the information necessary to track the call and handle time and billing. 
     The Call Manager protocol may be better appreciated from  FIG. 4 . The protocol begins at step  275  with the telephony switch detecting a ring on one of its numerous ports. Once a ring has been detected, the time and date are captured at step  280  for billing and other purposes. The protocol advances to step  285  where a tracking ID is generated, and at step  290  ANI information about the sender is captured by the telephony server. At this point the sender&#39;s call is answered as step  295 , followed at step  300  by sending a signal to the sender PC that the telephony server is now ready to receive from the sender the DTMF tones representative of the account number of the sender and the account number of the recipient. The sender PC then sends the appropriate account numbers at step  305 . 
     At step  310 , the account numbers are compared to a database of valid account numbers maintained in the system, typically in the telephony server. If one or both account numbers fails to match, a negative acknowledge is sent at step  315 . However, if both numbers match valid account numbers in the database, the process advances to step  320 . At step  320 , the caller&#39;s ANI data and phone number are compared to the system database, to further confirm the validity of the sender. In particular, this compares the caller&#39;s telephone number, modem number, and other selected information. If any of this additional information does not match that in the database, the process branches to a negative acknowledge at step  315 . However, if all of the requisite data matches, the processes advances to step  325  where the telephony server sends a “call OK” message. The call is then transferred to the recipient phone number at step  330 , and the call is logged for billing purposes at step  335 . 
     Once the call has transferred to the recipient, the sender and recipient must exchange keys through a handshaking process. This is managed by the Key Exchange protocol, described in  FIGS. 5A-5C . Those skilled in the art will recognize that the steps in  FIGS. 5A-5C  have been simplified somewhat for clarity, including the elimination of time outs and other internal testing for data integrity. Data flow between the sender and recipient is shown by a dashed line. 
     The protocol of  FIGS. 5A-5C  begins at step  350  with the sender generating an appropriately secure key, for example a Diffie-Hellman random exponent eA and computing the related value g eA  mod n, where g and n are fixed system-wide parameters. The sender also generates a 20-byte pseudorandom value, RandomA. Then, at step  355 , the sender modem contacts the recipient modem. The recipient modem answers the modem call at step  360 , which causes the sender to initiate a handshake session at step  365  by sending a first handshake packet, Handshake Packet A 1 . The first handshake packet sent by the sender includes the sender&#39;s version information, account number, g eA  mod n, and a hash of RandomA. The data structure may be, for example: 
     
       
         
               
               
               
               
             
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Field 
                 Comments 
                 Size (bytes) 
               
               
                   
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 STX 
                 Framing 
                 1 
               
               
                   
                 Low Version 
                 Lowest version supported 
                 1 
               
               
                   
                 Hi Version 
                 Highest version supported 
                 1 
               
               
                   
                 AccountA 
                 Sender&#39;s account number 
                 12 
               
               
                   
                 DH_result_A 
                 g eA  mod n 
                 128 
               
               
                   
                 Hash_RandomA 
                 SHA(RandomA) 
                 20 
               
               
                   
                 EM 
                 Framing 
                 1 
               
               
                   
                   
               
             
          
         
       
     
     Once the handshake session has started, the key exchange must be completed before data can be transferred. If, as tested at step  370 , the recipient cannot support the version transmitted by the sender, a negative acknowledge results and the system branches to step  375  to transmit the message to the sender as well as causing a hangup and exit at the recipient end at step  380 . In each case, the message associated with the hangup contains housekeeping information which is entered into the Send Log and the Receive Log. The sender then tests the negative acknowledge (NAK) signal at step  385 , and if so, executes a hang up and exit at step  390 . 
     In most instances, however, the version will check as valid at step  370 . In this circumstance, the recipient develops its responsive handshake packet, Handshake Packet B, at step  395  in a data structure similar of the sort shown below: 
                                                                   Field   Comments   Size (bytes)                                        STX   Framing   1           Version   version being spoken   1           AccountB   Recipient&#39;s account number   12           DH_result_B   g eA  mod n   128           ProofB   SHA(“KEY_ID”|g eB  mod n)   20           EM   Framing   1                        
The KEY_ID string represents, in an exemplary embodiment, a six-byte string, typically with no terminating byte.
 
     The recipient handshake packet is then transmitted to the sender at step  400 . The version specified by the recipient handshake packet is checked at step  405 , and if not supported by a negative acknowledge and hangup are generated at steps  410  and  415 , respectively. In most cases the version will be supported such that the check at step  405  will be affirmative, and the process will advance with the sender performing a proof step at step  420 . At step  425 , the result of the proof step is then compared to the ProofB portion of the recipient handshake packet, Handshake Packet B. A negative result forwards to step  410  for hangup and exit, while a successful check causes the sender to generate a second handshake packet, Handshake Packet A 2 , at step  430  and transmit it to the recipient. If a negative acknowledge is sent at step  410 , it is detected at step  435  and a hangup and exit executes at step  440 . 
     Then, at step  445 , a comparison is then done at the recipient end to compare the RandomA value received in the second handshake packet with the RandomA value received in the first handshake packet. A negative compare results in the generation of a negative acknowledgment at step  435  and a hangup and exit at step  455 , while a positive compare continues the process. On the sender&#39;s side, a negative acknowledgment detected at step  460  results in a hangup and exit at step  465 . The process continues with both the sender and the recipient computing, at steps  470 A and  470 B, respectively, a check of the password. The result is the generation of an ordered string of words which are then reduced to form a five character string X, together with the generation of a long term key at both the sender and recipient sides. 
     The string X is then displayed as a pop-up window at the sender side, as shown in  FIG. 6A , and the sender is instructed to telephone the recipient to provide the string X. On the recipient side, shown in  FIG. 6B , the recipient is instructed to await a call from the sender and to insert the string X. These steps are shown in  FIGS. 5A-5C  as steps  475  and  480 , respectively. If the ID is confirmed, as checked at step  485  on the sender side and step  490  on the recipient side, the long term key LTK is saved at steps  495  and  500 , respectively, followed by an exit. If the check at steps  485  and  490  results in a negative compare, the long term key is not saved and the process simply exits. 
     At this point, if the protocol has executed successfully, both the sender and receiver have saved the Long Term Key and have established in their respective account listings that the sender/recipient pair is authorized to transfer data. This concludes the Key Exchange protocol. 
     Once the Key Exchange protocol of  FIGS. 5A-5C  is completed, the system moves on to the Data Exchange protocol shown in  FIGS. 7A-7D . As with  FIGS. 5A-5C , the flow diagram of  FIGS. 7A-7D  is idealized and simplified, and data flow between the sender and recipient processes is shown with a dashed line. 
     The process begins at step  600  with the sender generating a random Session Key, or SKey, which may, for example, be on the order of 20 bytes, followed by generating a random challenge which may also be on the order of 20 bytes. The process then moves on to step  605  with the compression of the files to be transferred, selected as shown in connection with  FIG. 3 . At step  610 , a FileHash is calculated in accordance with HMAC{SKey}(“File_Check”|file) and appended to the compressed file, after which the compressed file with the appended hash is encrypted. In an exemplary embodiment, the encryption is performed using triple DES in encrypt-decrypt-encrypt mode. Block chaining using CBC mode is then performed, external to the DES operations. The first, second and third 56-bit DES keys are taken as the left-hand 64 bits of HMAC{SKey}(“KEY 1 ”, MAC{SKey}(“KEY 22 ”) and HMAC{SKey}(“KEY 333 ”), respectively. Each 64-bit DES key typically contains fifty-six effective key bits, with the rest ignored as parity. The HMAC and encryption are typically performed as a single pass, and date and time of the file are preferably preserved. 
     Once the encryption is complete, the sender establishes a data connection with the recipient, as shown in  FIGS. 7A-7D  at step  615 . The sender then transmits to the recipient, at step  620 . Transfer Packet A 1  having a data structure as follows: 
     
       
         
               
               
               
               
             
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Field 
                 Comments 
                 Size (bytes) 
               
               
                   
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 STX 
                 Framing 
                 1 
               
               
                   
                 Low Version 
                 Lowest version supported 
                 1 
               
               
                   
                 Hi Version 
                 Highest version supported 
                 1 
               
               
                   
                 Account A   
                 Sender&#39;s account number 
                 12 
               
               
                   
                 Challenge A   
                 Random Challenge from Sender 
                 20 
               
               
                   
                 ETX 
                 Framing 
                 1 
               
               
                   
                   
               
             
          
         
       
     
     At step  625 , the recipient answers the call from the sender and then, at step  630 , checks the sender&#39;s account number in its authorization file. If the account number is not found, a negative acknowledge is transmitted at step  635  back to the sender and a hangup and exit is executed at the recipient side at step  640 . On the sender side, a check for a NAK is made at step  645 , and if a negative acknowledge was generated at step  635  the process executes a hangup and exit at step  650 . 
     However, if the version and account number checked as valid at step  630 , the recipient gets the LTK for the account at step  655 . At step  660 , the recipient generates its own random Challenge B  and, in addition, calculates ProofB=HMAC{LTK}(ChallengeA|ChallengeB|“Verify”). The recipient then sends its own transfer packet, Transfer Packet B, to the sender at step  665 . This transfer packet has the following data structure in an exemplary embodiment: 
                                                   Field   Comments   Size (bytes)                                STX   Framing   1       Version   Version being spoken   1       Account B     Recipient&#39;s account number   12       Challenge B     Random Challenge from Recipient   20       Proof B     Proof of B&#39;s Identity   20       ETX   Framing   1                    
The sender receives the transfer packet from the recipient and, at step  670 , checks to verify version and account number. If not, a negative acknowledge is sent to the recipient at step  675  and a hangup and exit are executed on the sender side at step  680 . If a negative acknowledge is transmitted at step  675 , it is detected on the recipient side at step  685 , which likewise causes a hangup and exit at step  690 .
 
     However, if the versions and account numbers are verified, the sender side moves on to step  695  and the sender computes CompareProof B  which it compares with Proof B  from the recipient side. If the proofs do not match, as determined at step  700 , the process aborts by jumping back to step  675 . However, as will most often be the case, the proofs will match and the process will advance to step  705 . 
     At step  705 , the sender side transmits to the recipient a second transfer packet, Transfer Packet A 2 , having, in at least an exemplary embodiment, the following data structure: 
                                                                   Field   Comments   Size (bytes)                                        STX   Framing   1           Account B     Recipient&#39;s account number   12           Proof A     Proof of A&#39;s Identity   20           DeltaKey A     Delta of session key from A   20           KeyProof A     Proof of session key from A   20           FileProof A     Proof of encrypted file from A   20           ETB   Framing   1                        
In response, the recipient calculates, at step  710 , a CompareProof A  value based on HMAC{LTK}(Challenge A |Challenge B |“Verify 2 ”). The recipient also calculates a session key SKey and, as well, a proof of the session key, or KeyProof B . Then, at step  715 , CompareProof A  is compared to Proof A  and KeyProof A  is compared with KeyProof B .
 
     If either proof fails, a compare at step  715  fails and a negative acknowledge is sent to the sender at  720 . On the recipient side, a NAK causes a hangup and exit at  725 . On the sender side, the NAK is checked for at step  730 , and if found, causes the sender to hangup and exit at step  735 . 
     However, if the proofs match, the process advances on the recipient side by sending an Acknowledge to the sender at step  740 . The sender side then advances to step  745  where the sender transmits the compressed and encrypted file to the recipient, after which the sender side of the process completes by hangup and exit at step  750 . The recipient side receives the compressed and encrypted file at step  760 , and the computes a FileHash and also calculates at step  765  a FileProof B  based on HMAC{SKey}(Challenge A  |Challenge B |FileHash|“Verify 3 ”). FileProof B  is then compared to FileProof A  at step  770  and, if the proofs match, the file is decrypted at step  775  using the SKey and then uncompressed at step  780  into individual files. If the proofs do not match after decompression, a hangup and exit is executed at step  785 . 
     Referring next to  FIGS. 8A-8C , the manner in which the transfer of files is recorded by the sender and recipient can be better appreciated. Assuming the files were successfully decompressed at the receiver side, the session is then displayed in the recipient&#39;s inbox, as shown in  FIG. 8A , the number of files within a session being noted in the column entitled “Files”. Those file names can, in turn, be viewed individually in a related screen overlay. As seen in  FIGS. 8B-8C , which show the general arrangement of a send log but is very similar to the receive log of  FIG. 8A , the transferred files are listed by the recipient or sender, depending on which fog is examined, the company, account, the date/time, and other related information. It will be appreciated that in each of  FIG. 8A-8C , the upper portion  800  of the screen maintains the “envelope” paradigm discussed previously, while the lower portion  805  of the screen maintains a file arrangement which identifies the directories in a left window  810  and files within the directories in a second window  815  to the right of the directories window. 
     At this point the transaction is completed and the telephony server completes the log of the call duration and related data for purposes of generating billing. As previously noted, the billing is processed, in a presently preferred embodiment, through a local telephone service provider. 
     Although a presently preferred embodiment has been described in detail in the foregoing, numerous alternatives exist which do not depart from the invention. One particularly attractive alternative is to cache communications at the telephony server  45  ( FIG. 1 ), and forward them later to the destination system  65 . This additional delay can be used to complicate attempts by attackers to use traffic analysis at the TSP to identify communicants. (For example, an attacker might try to correlate incoming calls to the TSP with outgoing calls from the TSP.) Caching can also be used to reduce communication costs (e.g., by delaying connections until nighttime to take advantage of reduced telephone rates). This approach has the negative of a lack of immediacy and thus will have some restrictions on its application. 
     Also, and as previously noted, the software portion of the present system may be implemented to eliminate any code resident on the modems, thus placing all user code at the PC level and permitting the use of general purpose moderns. Additionally, although the presently preferred embodiment is implemented using standard communications protocols such as v.34, other encoding methods are also acceptable in many embodiments. Likewise, dual-mode approaches may be desirable in at least some embodiments, in which slower DTMF codes are used for some functions while faster v.34 protocols are used for file transfer. 
     In addition, various elements of the cryptographic engine or related databases may be implemented on a removable cryptographic token, such as a smart card. The smart card may connect directly to the TSP, or may be accessed via a smart card reader or other device connected to the TSP. Likewise, particular sequences for handshaking and encryption as described above may be rearranged or modified to comply with local laws or otherwise facilitate better implementation. In addition, other cryptographic functions may be used. For example, DES-based MAC functions may be used instead of HMAC, elliptic-curve public key cryptographic functions may be used instead of RSA and Diffie-Hellman, stream ciphers such as RC4 may be used instead of block ciphers, DSS may be used instead of RSA for digital signatures, etc. 
     It can therefore be appreciated that a new and novel system and method for secure communications of a wide variety of types of data has been described. It will be appreciated by those skilled in the art that, given the teachings herein, numerous alternatives and equivalents will be seen to exist which incorporate the invention disclosed hereby. As a result, the invention is not to be limited by the foregoing exemplary embodiments, but only by the following claims.