Abstract:
A method of establishing a multiplicity of shared secrets at two mutually authenticated end points in a network. The method includes authenticating a first end point in the network based on an asymmetric key pair and authenticating a second end point based on an asymmetric key pair. Upon successful authentication of the first and second end points, the end points negotiate a shared secret. Multiple shared secret keys are generated from the negotiated shared secret and session keys are computed from the multiple shared secret keys.

Description:
FIELD OF THE INVENTION 
       [0001]    The present disclosure relates to providing voice and other real-time communications of digital data over networks that are bandwidth-limited and between resource-constrained devices such as mobile phones. In particular, the present disclosure relates to providing secure real-time communication over a network in a bandwidth efficient manner. 
       BACKGROUND OF THE INVENTION 
       [0002]    In bandwidth and power constrained environments, such as mobile telephony, it is important to minimize the data and complexity of processing that is required by protocols that establish secure real-time communication of data over a network. 
         [0003]    There is an established field of real-time communications over Internet Protocol (IP) networks, which underpins widespread applications such as Voice over IP (VoIP). There are standard protocols such as Session Initiation Protocol (SIP) and Real-Time Transport Protocol (RTP) which support unencrypted real-time traffic. Secure RTP (SRTP) has been extended to encrypt real-time traffic. However, none of these protocols are well suited for bandwidth limited environments. 
         [0004]      FIG. 1  shows a conventional system using the above-mentioned protocols. A mobile end point (. 110 ) communicates over a wireless network ( 100 ) with an IP network ( 200 ). The IP network contains a SIP stateful proxy ( 210 ), a second SIP stateful proxy ( 211 ) and a SIP stateless proxy ( 220 ). A mobile end point ( 110 ) invites another end point ( 120 ) to establish a call, using the SIP protocol, by passing messages to ( 210 ), ( 220 ) and ( 211 ). The SIP stateful servers exchange the final call-setup SIP messages by communicating directly between each other. When the call is set-up, each end point communicates directly with the other and the end points send the real-time data to each other without encryption using RTP, or encrypted using SRTP. 
         [0005]    SRTP supports symmetric VoIP data encryption with Advanced Encryption Standard (AES). To encrypt a call using SRTP, the end points must first obtain a shared secret encryption key. Then they each use that key to encrypt the voice data that passes between them. 
         [0006]    In some conventional systems, each end point selects the session key from a list of keys that have previously been loaded into each end point using a secure method, which often involves physical delivery to the end point or each end point securely obtains the session key over the network from a key server. Both scenarios are bandwidth intensive. Moreover, use of a key server constitutes an aggregated risk. 
         [0007]    The present disclosure is directed toward, but not limited to, improving the above noted problems by providing minimal protocol messages to provide secure real-time communication in a bandwidth limited network environment. 
       SUMMARY OF THE INVENTION 
       [0008]    Exemplary embodiments disclosed herein provide a method of establishing a multiplicity of shared secrets at two mutually authenticated end points in a network. The method, for example, includes generating a first public key (AA 1 pub), and a first private key (AA 1 priv) for a first algorithm (AA 1 ), a second public key (AA 2 pub) and a second private key (AA 2 priv) for a second algorithm (AA 2 ), a DeviceID and a PeerID. 
         [0009]    For each call, or part of a call, exemplary embodiments provide a method to create a random number value, and calculating a first authentication value (AA 1 -Auth) corresponding to the first public key and the first private key and a second authentication value (AA 2 -Auth) corresponding to the second public key and the second private key. A receiver end point is authenticated based on the first authentication value of the receiver end point and an initiator end point is authenticated based on the first authentication value of the initiator end point, if the authentication of the receiver end point verifies. 
         [0010]    In another exemplary embodiment, the system creates the authentication value AAn-Auth only when the user has been successfully validated using a biometric method, such as, for example, a fingerprint scan. 
         [0011]    After the initial authentication process is performed, a key exchange function (DHeph) is generated by the receiver end point using a second algorithm (AA 2 ), if the authentication performed by the receiver end point is successful, and a shared secret (DHssec) is calculated by the initiator end point from the key exchange function (Dheph) generated by the receiver end point. The initiator end point generates a key exchange function (Deph) using the second algorithm (AA 2 ) and the receiver end point calculates a shared secret (DHssec) from the key exchange function generated by the initiator end point. 
         [0012]    A second authentication of the initiator end point and the receiver end point is performed using the second authentication values calculated by the initiator end point and the receiver end point. Upon successful authentication, session keys are generated from the calculated shared secrets. 
         [0013]    AA 1 -Auth and AA 2 -Auth can be used to establish mutual trust of different aspects of an end-point, for example, the device, user, device software, software origination or system operation. AA 1 -Auth can be used to authenticate the user and AA 2 -Auth can be used to authenticate the device. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]      FIG. 1  is a block diagram illustrating a conventional communication system. 
           [0015]      FIG. 2  is a block diagram illustrating an exemplary embodiment of a communication system as disclosed herein. 
           [0016]      FIG. 3  ( 3 A and  3 B) is a flow chart illustrating an exemplary representation of mutual authentication and negotiating a shared secret. 
           [0017]      FIG. 4  is a flow chart illustrating an exemplary representation of a verification process of an authentication value. 
           [0018]      FIG. 5  is a block diagram illustrating secure calling from a Code Division Multiple Access (CDMA) enabled end point. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    The present disclosure describes a communication protocol for providing secure real-time communications in a network system. The protocol is bandwidth efficient and uses minimal data and messages to effectuate secure real time communications in the network. The protocol performs mutual authentication and generates multiple shared secrets for encrypted communications. 
         [0020]      FIG. 2  is a diagram illustrating an exemplary embodiment of a communication system. The system includes end point  2010  communicating over wireless network  2000  with network system  2200 , and end point  2110  communicating with the network system over wireless network  2100 . The network system interconnects two end points in the communication system, and the communication system may include two or more end points. 
         [0021]    End point  2010  can be, for example, a mobile end point which includes mobile equipment (e.g., mobile phone) equipped with encryption modules. The encryption modules provide encryption and decryption functions for voice data in real time and establish a secure communication link with another end point in the communication system. The encryption modules can be processors embedded with computer readable instructions that when executed perform encryption and decryption functions. 
         [0022]    End point  2110  can be, for example, another mobile end point, such as end point  2010 , or a gateway device, such as gateway  2111 . Gateway  2111  connects a traditional phone system, such as, for example, Public Switched Telephone Network (PSTN) and Private Branch Exchange (PBX) to network system  2200 . The gateway converts the PSTN or PBX telephone traffic into an IP format for transmission over an IP network. Gateway  2111  is equipped with an encryption module to facilitate encryption and decryption functions. Transparent point to point encryption is provided between end point  2010  and end point  2110 , and between end point  2010  and gateway  2111 . 
         [0023]    The encryption modules may use redundant encryption schemes for session, authentication, digesting and/or key exchange. Preferred embodiments use two strong algorithms at the same time in series. The encryption of the data may be performed using any known cryptography algorithm, such as, for example, Elliptic curve Diffie-Hellman (ECDH), Rivest, Shamir and Adleman (RSA), Advanced Encryption Standard (AES), Digital Signature Algorithm (DSA), etc. 
         [0024]    Networks  2000  and  2100  are wireless network systems, such as, for example, Global Systems for Mobile Communication (GSM), Enhanced Data Rates for GSM Evolution (EDGE), General Packet Radio Service (GPRS), 3G GSM, HSPA, UMTS, CDMA and Wi-Fi. 
         [0025]    Network system  2200  is a wired network system, such as, for example, an Internet Protocol (IP) system. The network system may include one or more signaling servers and one or more media servers. An end point sends a request to the signaling server to make a call or send a message to another end point. The signaling server sets up the call, telling each end point to contact the same media server. The end points send the real-time data to each other through the media server. The media server uses media protocols for receiving voice data and sending it across the network. 
         [0026]    Storage device  2240  can be implemented with a variety of components or subsystems including, for example, a magnetic disk drive, an optical drive, flash memory, or any other devices capable of persistently storing information. Storage device includes device database  2215 , which contains a list of all the DeviceIDs known to the system. 
         [0027]    The architecture shown in  FIG. 2  allows for communication (e.g., data transmission, phone call, and video) between two end points or between an end point and a gateway in the system. Communications are encrypted using the protocols described below and illustrated in  FIG. 3  and  FIG. 4 . The real-time communications between two end points or between an end point and a gateway are encrypted using one or more session keys that are derived from a shared secret known only to the end points. 
         [0028]    As illustrated in  FIG. 3 , at step  3500   a,  each end point and/or gateway (e.g., an initiator end point/gateway and a receiver end point/gateway) generates, at a predetermined time, such as, for example, at installation, a first public key (AA 1 pub), and a first private key (AA 1 priv) for a first algorithm (AA 1 ), a second public key (AA 2 pub) and a second private key (AA 2 priv) for a second algorithm (AA 2 ), a DeviceID and a PeerID. The first public key (AA 1 pub), first private key (AA 1 priv), second public key (AA 2 pub) and second private key (AA 2 priv) can be generated by any method well known in the art. 
         [0029]    In another exemplary embodiment, the first public key is a corresponding digital certificate (Cert-AA 1 (x)) for an asymmetric cryptographic algorithm (AA 1 ) and the second public key is a corresponding digital certificate (Cert-AA 2 (x)) for a different asymmetric cryptographic algorithm (AA 2 ). The digital certificates Cert-AA 1 (x) and Cert-AA 2 (x) can each be a X509 certificate that contains one or more attributes, such as, for example, DeviceID, PeerID, ID, software ID, software originator ID, system operation ID, and name, for a corresponding end point. 
         [0030]    The first algorithm (AA 1 ) and the second algorithm (AA 2 ) are cryptographic algorithms. In one embodiment, the first algorithm (AA 1 ) and the second algorithm (AA 2 ) are used to authenticate a same parameter. In this embodiment, the first algorithm (AA 1 ) and the second algorithm (AA 2 ) use different cryptographic algorithms. For example, the first algorithm (AA 1 ) can be Rivest, Shamir and Adleman (RSA) and the second algorithm (AA 2 ) can be Digital Signature Algorithm (DSA). 
         [0031]    In another exemplary embodiment, the first algorithm (AA 1 ) and the second algorithm (AA 2 ) are used to authenticate different parameters. In this embodiment, the first algorithm (AA 1 ) and the second algorithm (AA 2 ) use the same cryptographic algorithm. 
         [0032]    In another exemplary embodiment, the first algorithm (AA 1 ) is replaced by a null algorithm such that encryption with any key gives the same encrypted text as a plain text input and encryption gives the same decrypted text as the input text, and the signatures always verify. 
         [0033]    The DeviceID of an end point is used to identify the device only to the signaling server and is created by its corresponding end point. The end point can derive the DeviceID from a hardware identifier in the end-point, such as the GSM International Mobile Equipment Identity (IMEI). Alternatively, the end point can create the DeviceID, for example using a random number generator. The DeviceID can be delivered to the device database  2215  by an out-of-band channel. 
         [0034]    In another exemplary embodiment, another system component generates the DeviceID and delivers it to the associated end-point and the device database  2215  by out-of-band channel. 
         [0035]    The PeerID identifies the device to the media server and is generated using a random number generator. In another exemplary embodiment, the PeerID is derived from a public key of an asymmetric cryptographic key pair that an end point generates when it is created. The PeerID of an end point is independent of the IP address and is used to identify media messages from a corresponding end point in the communication system. 
         [0036]    At step  3500   b,  a random number value (N) is generated for each call or part of a call. The random number value (N) is generated from a random number generator. 
         [0037]    At step  3510 , each end point (e.g., an initiator end point and a receiver end point) calculates a first authentication value (AA 1 -Auth) corresponding to the first public key and the first private key and a second authentication value (AA 2 -Auth) corresponding to the second public key and the second private key. 
         [0038]    The first authentication value (AA 1 -Auth) is calculated, for example, as AA 1 -Auth(x)=AA 1 _encrypt(Nx, AA 1 puby) concatenated with AA 1 _sign_withH 1  (messages, AA 1 priv(x)). Messages=all sent messages(x) concatenated with all received messages(x). The subscript x identifies the protocol message sender and the subscript y identifies the protocol message receiver. AA 1 _encrypt is the encryption algorithm using the public key. AA 1 _sign_withH 1  is a signature algorithm (e.g., DSA) using the private key and a digest algorithm (H 1 ) (e.g., SHA-384). 
         [0039]    The second authentication value (AA 2 -Auth) is calculated, for example, as AA 2 -Auth(x)=AA 2 -SIG(x)_withH 2  (all sent messages(x) concatenated with all received messages(x)). AA 2 -SIG(x)_withH 2  is a signature algorithm using the private key and a digest algorithm (H 2 ). Digest algorithms H 1  and H 2  are different from one another. 
         [0040]    If any of the sent messages(x) are lost, the messages are resent from a buffer. Lost messages are not recalculated. 
         [0041]    At step  3520 , an initiator end point (e.g., end point  2010 ) initiates a mutual authentication process by generating a message and sending the generated message to a receiver end point (e.g., end point  2110 ) in the communication system. The message format is, for example, [PeerID ( 2010 ), N ( 2010 ), AA 1   pub  ( 2010 )], wherein PeerID ( 2010 ) is the PeerID of end point  2010 , N ( 2010 ) is the random number value generated by end point  2010  and AA 1 pub ( 2010 ) is the initiator&#39;s public key or corresponding digital certificate for the first algorithm (AA 1 ). 
         [0042]    Upon receiving the message, the receiver end point sends a message to the initiator end point, at step  3530 . The message format is, for example, [PeerID( 2110 ), N( 2110 ), AA 1   pub  ( 2110 ), AA 1 -Auth ( 2110 )]. PeerID ( 2110 ) is the PeerID of end point  2110 , N ( 2110 ) is the random number value generated by end point  2110  and AA 1 pub ( 2110 ) is the initiator&#39;s public key or corresponding digital certificate for the first algorithm (AA 1 ). AA 1 -Auth ( 2110 ) is the first authentication value calculated by end point  2110 . 
         [0043]    At step  3540 , initiator end point  2010  verifies the authentication value of end point  2110 . 
         [0044]    Each end point contains a trusted contact database (not shown) of trusted contacts. Each trusted contact contains for a given end point a name, CallingID, PeerID, Credential 1  and optionally Credential 2 , where name is a user-defined string to identify the contact, CallingID can be used as a CallerID or CalleeID, and CredentialZ is AAZpub, or Cert-AAZ, and Z=1 or 2. 
         [0045]    When a call is initiated, the caller end point ( 2010 ) (i.e., the initiator end point) generates a SetupID that identities the request to make a call to an end point in the network (e.g.  2110 ) (i.e., the receiver end point), and sends a call request 1  message to a signaling server (not shown) that must contain the SetupID, SessionID, CalleeID and CallerID. CalleeID is a number to identify end point ( 2010 ) and CallerID is a number to identify end point ( 2110 ). 
         [0046]    On receiving the call request 1  message, the signaling server maps the CalleeID to a DeviceID using a database and checks whether the end point has a SessionID to show that it has registered. If so, the signaling server generates a CAllID which identifies the call, selects a media server and sends a call request 2  message to end-point ( 2110 ) that must contain CalleeID, CallerID, MS address, where MS address is the IP address of the media server that will carry the call. 
         [0047]    The authentication value is verified using an algorithm, which utilizes information from the call request messages. The algorithm, as illustrated in  FIG. 4 , includes, for example, the following: 
         [0048]    At step  401 , if end point  2010  is the Caller (A) (i.e., the initiator end point), find the trusted contact that matches the CalleeID corresponding to end point  2010 . If end point  2110  is the Callee (B) (i.e., the receiver end point), find the trusted contact that matches the CallerID corresponding to end point  2110 , which is obtained from the call request 2  message. 
         [0049]    At step  402 , determine if a match is found. 
         [0050]    If a match is found, at step  403 , compute the verification results as follows: 
         [0051]    a. If a match is found for end point B ( 2110 ),
       ResultA=(CallerID from call request 2  message matches CalleeID from the trusted contact)       
 
         [0053]    b. if a match is found for end point A ( 2010 ),
       ResultA=(CalleeID matches CallerID from the trusted contact)       
 
         [0055]    c. ResultB=verify AAZ-Auth (e.g., AA 1 -Auth ( 2110 )) using the CredentialZ from the trusted contact, using a standard cryptographic verification algorithm for AAZ (e.g. AA 1 ) 
         [0056]    d. VerificationResultZ=ResultA AND ResultB 
         [0057]    e. If VerificationResultZ is TRUE, set TrustedCallZ to TRUE 
         [0058]    If no match is found, at step  404 , set the verification result to TRUE and the TrustedCallX to False. 
         [0059]    ResultX and TrustedCallX (X=A or B), VerificationResultZ (Z=1 or 2) are logical values, with values TRUE or FALSE. 
         [0060]    If the first authentication value is verified successfully, end point  2010  sends its first authentication value to end point  2110  for verification. Otherwise the process terminates. 
         [0061]    At step  3550 , receiver end point  2110  verifies the authentication value of end point  2010  in the manner illustrated in  FIG. 4 . If the first authentication value is verified successfully, end point  2110  generates a key exchange function (DHeph) (e.g., diffie-hellman key exchange) using the second algorithm (AA 2 ) and generates a message to send to end point  2010 . The message format is, for example, [AA 2 pub ( 2110 ), Dheph( 2110 )]. AA 2 pub ( 2110 ) is the receiver&#39;s ( 2110 ) public key or corresponding digital certificate for the second algorithm (AA 2 ). If the first authentication value does not verify successfully, the process terminates. 
         [0062]    Upon receiving the message, end point  2010  calculates a variable DHssec from the Diffie-Hellman key exchange Dheph ( 2110 ), and generates a key exchange function (DHeph) ( 2010 ) (e.g., Diffie-Hellman key exchange) using the second algorithm (AA 2 ), at step  3560 . End point  2010  generates a message to send to end point  2110 . The message format is, for example, [AA 2 pub ( 2010 ), Dheph( 2010 )]. AA 2 pub ( 2010 ) is the initiator&#39;s ( 2010 ) public key or corresponding digital certificate for the second algorithm (AA 2 ). 
         [0063]    At step  3570 , end point  2110  calculates a variable DHssec from the Diffie-Hellman key exchange Dheph ( 2010 ), and sends end point  2010  its second authentication value (AA 2 -Auth( 2010 )). 
         [0064]    The Diffie-Hellman key exchange provides forward secrecy, i.e., it ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future. Incidentally, if the key is obtained by a hacker, any corresponding messages will not be compromised. 
         [0065]    At step  3580 , end point  2010  verifies the second authentication value of end point  2110  in the manner illustrated in  FIG. 4 . If the authentication value does not verify, an authentication failure occurs and the process terminates. If the authentication value does verify, end point  2010  sends end point  2110  its second authentication value (AA 2 -Auth( 2010 )) and computes sessions keys as described below. 
         [0066]    Upon receiving the second authentication value of end point  2010 , at step  3590 , end point  2110  verifies the second authentication value in the manner illustrated in  FIG. 4 . If the authentication value does not verify, an authentication failure occurs and the process terminates. If the authentication value does verify, end point  2110  computes sessions keys as described below. 
         [0067]    The real-time data stream is encrypted with a key stream (i.e., session keys), generated using a first symmetric algorithm (SA 1 ) and then a second symmetric algorithm (SA 2 ). For example SA 1  can be RC4 and SA 2  can be AES in CTR mode. 
         [0068]    In one embodiment of the invention, SA 1  is replaced by a null algorithm, such that encryption with any key gives that same encrypted text as the plaintext input, and encryption gives the same decrypted text as the input. 
         [0069]    The key stream is initialized, as follows, for example, for a 248 bit key: 
         [0000]    A&#39;s downlink and B&#39;s uplink:
   K SA1 =Bytes  0  to  31  from PRF(SSEC 2 )   K SA2 =Bytes  0  to  31  from PRF(SSEC 1 )   IV SA2 =Bytes  32  to  47  from PRF(SSEC 1 )
 
A&#39;s downlink and B&#39;s uplink:
   K SA1 =Bytes  32  to  63  from PRF(SSEC 2 )   K SA2 =Bytes  48  to  79  from PRF(SSEC 1 )   IV SA2 =Bytes  80  to  95  from PRF(SSEC 1 )   
 
         [0076]    PRF denotes a pseudorandom function. The shared secrets, SSEC 1  and SSEC 2  are computed, as follows:
   SSEC 1 =H 2 (N A  concatenated with N B ),   SSEC 2 =Double_hash(SSEC 1  concatenated with Double_hash(DH ssec )),
 
where Double_hash(X)=Cyclic-XOR (H 2  (X), H 3  (X))) and H 2  and H 3  are different digest algorithms, for example SHA-512 and MD5. N A  is the random number generated by the initiator end point and N B  is the random number generated by the receiver end point.
   
 
         [0079]    In another exemplary embodiment, SSEC 1 =NULL, and only 1 secret key is used to initialize a key stream. 
         [0080]    In other embodiments of the invention, the approach is generalized to create more than two shared secrets. 
         [0081]    The communications between end points  2010  and  2110  are encrypted using the computed sessions keys. 
         [0082]    When end point  2110  is a gateway, the gateway uses the same asymmetric keys (A pub, A priv) to authenticate itself in all calls. 
         [0083]    In another exemplary embodiment, the gateway has a database that stores a set of asymmetric key pairs associated with each secure phone number or trusted range that it serves. When the gateway receives or makes a call using a secure phone number, it finds the corresponding asymmetric key pairs from the database and uses them in the protocol illustrated in  FIG. 3 . 
         [0084]    Furthermore, before an encrypted path between two end points or between an end point and gateway (e.g., end point  2010  and gateway  2111 ) in the communication system can be established, mutual authentication must occur (e.g., between the device of end point  2010  and gateway  2111 ) as described in  FIG. 3 . 
         [0085]    In another exemplary embodiment, the communication system provides distributed and 2-factor authentication, for example, to a telephony service, such as a conference bridge, in the telephony infrastructure. The telephony service has a database that contains a white list of the CallerIDs who may use the service. When setting up a call to the service, the gateway  2111  sends the CallerID to a PBX, which sends the CallerID to the telephony service. The service only allows access if the CallerID is in the database. 
         [0086]    In another exemplary embodiment, the database could contain a black list of the CallerIDs that may not use the service. 
         [0087]    Once the call is established, the telephony service can also use voice prompts to request additional authentication data, such as a PIN, from the caller. When the caller enters the PIN, the system sends it as a dual-tone multi-frequency (DTMF) signal, and the telephony service verifies the PIN. The DTMF tones are encrypted between the end points. If verification fails, the telephony service terminates the call, otherwise, an end point (e.g., end point  2010 ) can communicate with another end point (e.g., end point  2110 ) in the communication system using DTMF. 
         [0088]    End point  2010  can call a conference service, and respond to voice prompts from the conference service using DTMF signals to select a conference room and input a pin to authenticate the caller. In this case, the end point encodes DTMF signals in the media traffic and the gateway decodes them and transmits them in a standard way to a PBX. 
         [0089]    The system encodes DTMF signals in frames that replace standard codec frames (as described below). In this way, encrypted DTMF signals can be mixed arbitrarily with encrypted voice traffic. 
         [0090]    An end point encodes voice data using a modification to a standard rate-adaptive codec, such as Adaptive Multi-Rate audio codec (AMR). The modification reduces the bandwidth required to transmit the data from the standard codec. The system negotiates the codec rate on a per-call basis and uses this knowledge to reduce the data transmitted in each codec frame. 
         [0091]    When an end point registers, the registration message contains a protocol version field, which contains an encoding of the codec rate or rates that the end point can use. The signaling server determines which codec rate the end points on a call can use and notifies each end point of the choice in protocol messages. 
         [0092]    In another exemplary embodiment, the end points negotiate the codec end-to-end rate at the beginning of the session. In this case, both end points know the rate of a multi-rate adaptive codec to use in a call between them without the signaling server being involved, and therefore, the end points can remove the header component from ail of the frames. 
         [0093]    To reduce the bandwidth used, an end point (e.g., end point  2010 ) removes the header data from a standard codec frame that contains the rate information before sending the frame to the other party on a call. The other end point of the call (e.g., end point  2110 ) adds the equivalent standard codec data to each modified frame when it receives it. 
         [0094]    In an exemplary embodiment, end point  2010  forms a packet that comprises multiple modified frames concatenated and transmits the concatenated frames to the other party on the call. 
         [0095]    In another exemplary embodiment, the standard codec rate is determined by run length encoding. This method reduces bandwidth since an end point is only notified when the speed changes. 
         [0096]    The authentication process to access a telephony service can be distributed in more than one place (e.g., the gateway, PBX and the service). If these functions are physically separated, then it would be necessary to compromise all of them to compromise the authentication process. 
         [0097]    In another exemplary embodiment, when a call is established, an end point can compute a code that is unique to that call. In the case that both end points on the call are mobile phones, each can display the code to the user. One caller can read the code to the other, who can confirm it is the same code that displayed on his phone. 
         [0098]    The code can be derived from the computed session keys, for example, using a digest function. 
         [0099]    In the case when one end point is a gateway, the gateway can compute the code and pass it to a PBX, which can relay the code to an end point in the communication system, such as a phone. The phone could display the code, thereby allowing the callers to confirm their codes. 
         [0100]    In a similar manner, the gateway could transfer a non-verbal message that it had received securely from a mobile end point to communication system. 
         [0101]      FIG. 5  illustrates secure calling from Code Division Multiple Access (CDMA) enabled end points. End point  500  is a CDMA mobile end point which includes mobile equipment (e.g., mobile phone equipped with encryption modules). The mobile equipment includes a speaker  530 , a microphone  540 , a button  510  and a secure telephony application  520 . The secure telephony application  520  uses simplex audio communications, where the user presses button  520  on the handset to speak. 
         [0102]    When button  510  is depressed, the application  520  ceases to playback received audio over secure communication channel  550  to an end point  570  in a secure calling network  560  and transmits recorded audio from the microphone  540 . 
         [0103]    When the button  510  is not depressed, the application  520  plays to the speaker  530  the received audio from the secure communication channel  550  to an end point  570  in the secure calling network  560  and ignores audio from the microphone  540 . 
         [0104]    In another exemplary embodiment, when the button  510  is depressed, application  520  sends a message down the encrypted call channel to end point  570 . When end point  570  receives this message, it does not transmit audio to end point  500  and application  520  transmits recorded audio from microphone  540  to end point  570 . 
         [0105]    In another exemplary embodiment, it is possible to depress one of a set of buttons where each button sends a different message down the encrypted call channel. When receiving the message, end point  570  displays text or an icon depending on which button is depressed. For example, end point  570  displays the text, for example, “in duress” in response a message received from a button programmed to indicate duress. 
         [0106]    As disclosed herein, embodiments and features of the invention can be implemented through computer hardware and/or software. Such embodiments can be implemented in various environments, such as networked and computing-based environments. The present invention is not limited to such examples, and embodiments of the invention can be implemented with other platforms and in other environments. 
         [0107]    Moreover, while illustrative embodiments of the invention have been described herein, further embodiments can include equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments) adaptations and/or alterations as would be appreciated by those skilled in the art based on the present disclosure.