CN1905449B - Method and apparatus for processing digitally signed messages to determine address mismatches - Google Patents

Abstract

A method and apparatus for processing digitally signed messages in which an address mismatch is detected. In at least one aspect, by performing at least one predetermined action on the digital signature corresponding to the signed data that appears after the message delimiter, correct incorporation of a message portion signed by someone other than the sender of the message message to minimize the number of address mismatch errors reported to the message user, as is the case if the message contains chat threads. For example, a message delimiter may indicate that the message contains data from an old forwarded message or data from an old message that was replied to. For example, the at least one predetermined action may include: bypassing verification that the digitally signed addresses match; or verifying that the digitally signed addresses match, but refraining from notifying the user of any address mismatch errors.

Description

Method and apparatus for processing digitally signed messages to determine address mismatch

Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to anyone's reproduction of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but all copyright rights are reserved. the

technical field

Embodiments of the invention relate generally to the processing of messages, such as email messages, and more particularly, to the processing of digitally signed messages received by users of computing devices, such as mobile devices. the

Background technique

Electronic mail ("e-mail") messages may typically be encoded using one of several known protocols to facilitate secure message communication. For example, the Secure Multipurpose Internet Mail Extensions ("S/MIME") protocol relies on public and private encryption keys to provide confidentiality and integrity, and relies on a public key infrastructure (PKI) to communicate information providing authentication and authorization. Data encoded using the private key of a private/public key pair can be decoded using only the pair's corresponding public key, and data encoded using the public key of a private/public key pair can be decoded using only the pair's corresponding private key to decode. Other well-known standards and protocols may be employed to facilitate secure messaging, such as Pretty Good Privacy ^™ (PGP) and PGP variants such as OpenPGP. PGP-based systems also use public and secret encryption keys to provide confidentiality and integrity, although in a different manner than S/MIME systems verify the authentication of the public keys used in the encoding of PGP messages. A structure similar to a "certificate" (eg, the same as used in S/MIME) containing a public key and key holder information may be provided in secure messaging standards and protocols. One example of such a structure is known as a "PGP key" based in the PGP system.

Encoded messages can be encrypted, digitally signed (signed), or both encrypted and digitally signed. Consider a signed message received by a user at a computing device (eg, a mobile device). Typically, the message includes a digital signature generated using the signer's private key, although some protocols may allow separate parts of the message to be signed. Where multiple parts of a message are signed, the message may include multiple digital signatures. If a user possesses a public key capable of successfully decoding a given digital signature produced by the signer's private key, the user can authenticate the signer and verify the integrity of the signed data. In some cases, the public key accompanies the received message. the

Although the use of digital signatures provides protection, however, there are still situations where security can be compromised. For example, an individual's private key can be used to sign a message. The user receives the message, and the public key accompanying the message successfully decodes the digital signature in the message. Successful verification of a digital signature indicates that the person signed the message and did not modify the message in transit. However, it is assumed that the user does not know that the private key used to encode the digital signature does not belong to the sender of the message identified in the header of the message. In this example, the user is led to mistakenly believe that the message was signed by the identified sender, even though the identified sender is not actually the individual who signed the message. the

Contents of the invention

According to an aspect of the present invention there is provided a method of processing a signed message received at a computing device, the method comprising the steps of: receiving a message comprising: a header including at least a sender address; at least a portion of signed data ; a digital signature corresponding to each portion of the signed data; and at least one message delimiter indicating that at least one old message has been incorporated into the received message; determining whether the first message delimiter appears in a portion In signed data, where the occurrence of the first message delimiter in the received message indicates that the data in the message that appears before the first message delimiter originates from the sender of the received message, and that the data after the first message delimiter originates from other than said sender; if the first message delimiter does not appear in a portion of the signed data, for each digital signature in the message that appears after the first message delimiter, perform at least one predetermined action such that Informing the user of the computing device that the number of misleading address mismatch errors is minimized; and verifying that the sender address matches the address associated with the key if the first message delimiter appears in a portion of the signed data, said The key is used to generate one digital signature corresponding to the portion of the signed data that appears after the first message delimiter, and for other digital signatures in the message that appear after the first message delimiter For each of these, at least one predetermined action is performed to minimize the number of misleading address mismatch errors that notifications are provided to a user of the computing device. the

According to another aspect of the present invention, there is provided an apparatus for processing signed messages received at a computing device, comprising: means for receiving a message, the message comprising: a header including at least a sender address; at least a portion of signed data; a digital signature corresponding to each part of the signed data; and at least one message delimiter indicating that at least one old message has been incorporated into the received message; determining means for determining the first message delimiter is present in a portion of signed data where the presence of the first message delimiter in the received message indicates that the data in the message that appears before the first message delimiter originates from the sender of the received message, and the first message delimiter the subsequent data originates from someone other than said sender; implementing means for, if the first message delimiter does not appear in the part of the signed data, for each digit in the message that occurs after the first message delimiter signing, performing at least one predetermined action to minimize the number of misleading address mismatch errors notified to a user of the computing device; and if the first message delimiter appears in a portion of the signed data, verification means for if the first message delimiter appears in a portion of the signed data, verify that the sender's address matches the address associated with the key used to generate the message that occurs after and with the first message delimiter and means for performing at least one predetermined action for each of the other digital signatures in the message that appear after the first message delimiter, so that the notification to the computing device user of The number of misleading address mismatch errors is minimized. the

Description of drawings

For a better understanding of embodiments of the systems and methods described herein, and to more clearly show how they may be implemented, reference is made to the accompanying drawings, by way of example, in which:

Figure 1 is a block diagram of a mobile device in an example implementation;

Figure 2 is a block diagram of the communication subsystem components of the mobile device shown in Figure 1;

Fig. 3 is the block diagram of the node of wireless network;

Figure 4 is a block diagram illustrating components of the main system in an example configuration;

Figure 5 is a block diagram illustrating components of an example of an encoded message;

Figures 6A to 6E are examples of messages;

Figure 7A is a flowchart illustrating the steps of a method of processing a signed message in one embodiment;

Figure 7B is a flowchart illustrating the steps of a method of processing a signed message in another embodiment; and

Figure 7C is a flowchart illustrating the steps of a method of processing signed messages in another embodiment. the

Detailed ways

As shown in the above example, despite successful decoding of the data signature in the message, it may be possible for a user receiving a signed message at a computing device to mistakenly believe that the sender identified in the message's header signed the message, even though this is not true . the

To address this problem, computing devices adapted to verify address matches of signed messages may be employed. In particular, the device is adapted to verify that an address (eg, an email address) associated with the key used to generate a given digital signature matches an address associated with the sender identified in a header of the message. If an address mismatch is detected (ie, the two addresses do not match), the user is notified of the address mismatch as, for example, an alert or an error message displayed to the user. Thus, by processing signed messages in which an address mismatch error is detected, the user can be alerted when the signer of the message (or a portion thereof) is not the same person as the sender identified by the message. the

As mentioned above, depending on the secure messaging protocol employed, some messages may contain multiple digital signatures generated by the same private key. For example, an individual can use a private PGP key to sign multiple different parts of the same message. Thus, a message can contain multiple digital signatures generated using that individual's private PGP key. When such a message is received by a user, for each digital signature, a matching of the address associated with the personal private PGP key that generated the respective signature with the sender identified in the header of the message can be performed according to an embodiment of the device described above. Verification that the address matches. the

However, some other messages may contain multiple digital signatures, but contrary to the above example, the same private key cannot produce these other messages. the

For example, while some devices adapted to handle encoded messages will remove digital signatures from old messages before sending new messages composed/incorporated by the user, other devices may not remove digital signatures in this manner. For example, a new message incorporated into an old message may be a reply message sent back to the sender of the old message, or a forward message sent to some other recipient. In this regard, it will be appreciated that most known systems allow the user to incorporate the text of the "original message" (ie, the old message) as the text of a new reply or forward message. If the device is not adapted to remove the digital signature from the old message before sending the new message incorporating the old message, when the message contains conversation threads between two or more individuals, the message may contain Multiple digital signatures. the

When a computing device adapted to verify an address match receives a message containing one or more digital signatures, it may not realize that some of the digital signatures originate from older messages that were already signed, as, for example, part of forwarded text or references to messages that have been correctly incorporated The text of the reply. In fact, even if there is only one digital signature in a message, if the digital signature originates from an old message, then the digital signature was not generated by the sender who received the message. the

If the computing device assumes that any received message containing one or more digital signatures should have been generated by the sender of the received message, and then attempts to verify, for each digital signature, that the key associated with generating each signature is header identified in the sender's header, at least one address mismatch may be detected and the user notified of each address mismatch. In these cases, however, the address mismatch will be detected even if the third-party attacker is not maliciously trying to impersonate the sender. the

Reporting of address mismatch errors hampers the serviceability of computing devices even when messages contain conversation threads or correctly incorporate data that the sender did not sign. the

Embodiments described herein generally relate to an apparatus and method that can minimize the number of address mismatch errors reported to message users, especially for messages that correctly incorporate message parts signed by someone other than the sender, such as The same is true for messages containing conversation threads. This can enhance the usability of the computing device and is especially advantageous when the computing device is a mobile device. the

In one broader aspect, there is provided a method of processing a signed message received at a computing device, the method comprising the steps of: receiving a message including at least a header identifying the sender address of the message, at least a portion of the signed message data, a digital signature corresponding to each portion of the signed data, and at least one message delimiter; determining whether the first message delimiter is present in the portion of the signed data; if the first message delimiter is not present in the portion of the signed data , for each digital signature that appears in the message after the first message delimiter, perform at least one predetermined action; and if the first message delimiter appears in a portion of the signed data, verify the sender address with the same method used to generate the signature that appears after the first message delimiter The address associated with a digitally signed key that follows the first message delimiter and corresponds to the portion of the signed data in which the first message delimiter occurs matches, and for other parts of the message that appear after the first message Each digital signature performs at least one predetermined action. the

In another broader aspect, there is provided a method of processing a signed message received at a computing device, wherein at least one predetermined action for a digital signature that occurs after a first message delimiter includes: bypassing the sender address Verification that matches the address associated with the key used to generate the digital signature. the

In another broader aspect, there is provided a method of processing a signed message received at a computing device, wherein at least one predetermined action for a digital signature that appears after a first message delimiter includes: verifying that the sender address is the same as matching the address associated with the key used to generate the digital signature; and inhibiting notification of the address mismatch to a user of the computing device if the sender address does not match the address associated with the key used to generate the digital signature. the

In another broader aspect, there is provided a method of processing a signed message received at a computing device, wherein at least one predetermined action for a digital signature that occurs after a first message delimiter includes: determining the same as the digital signature the corresponding partial private address associated with that portion of the signed data; verify that the partial private address matches the address associated with the key used to generate the digital signature; and if the partial private address matches the key used to generate the digital signature If the address associated with the key does not match, a user of the computing device is notified of the address mismatch. the

In another broader aspect, there is provided a method of processing a signed message received at a computing device, wherein the step of determining a portion of the private address comprises: starting from the portion of the signed message that appears immediately before the digital signature to which it corresponds. Extract the previous sender's address from the message delimiter before the data and the text of the message between that part. the

In another broader aspect, there is provided a method of processing a signed message received at a computing device, wherein the step of determining a portion of the private address comprises: extracting from the portion of signed data that appears immediately after the digital signature corresponds to From the text of the message between the previous message delimiter and the portion, extract the name of the previous sender; and retrieve the address of the previous sender associated with the name from the address book. the

These and other aspects and attributes of various embodiments are described in more detail below. the

Some embodiments of the systems and methods described herein refer to mobile devices. Mobile devices are two-way communication devices with advanced data communication capabilities to communicate with other computer systems. Mobile devices may also include voice communication capabilities. Depending on the functionality provided by a mobile device, it may be called a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet device, or a data communications device (with or without telephony capabilities). Mobile devices communicate with other devices through a network of transceiver stations. the

To help the reader understand the structure of the mobile device and how it communicates with other devices, reference is made to FIGS. 1 to 3 . the

Referring first to FIG. 1 , a block diagram of a mobile device in an example implementation is shown generally at 100 . The mobile device 100 includes a number of components, the controlling component being the microprocessor 102 . The microprocessor 102 controls the overall operation of the mobile device 100 . Communication functions, including data and voice communications, are performed through the communications subsystem 104 . Communication subsystem 104 receives messages from and sends messages to wireless network 200 . In the example implementation of the mobile device 100, the communication subsystem 104 is configured according to the Global System for Mobile Communications (GSM) and General Packet Radio Service (GPRS) standards. GSM/GPRS wireless networks are used worldwide and it is expected that these standards will eventually be superseded by Enhanced Data GSM Environment (EDGE) and Universal Mobile Telecommunications System (UMTS). New standards are being defined, but we believe they will have similarities to the network behavior described here, and it will be understood by those skilled in the art that the present invention is intended to use any other suitable standards that are developed in the future. The wireless link connecting the communication subsystem 104 with the network 200 represents one or more different radio frequency (RF) channels, operating according to defined protocols specified for GSM/GPRS communications. Using new network protocols, these channels can support both circuit-switched voice communications and packet-switched data communications. the

Although in one example implementation of mobile device 100 the wireless network associated with mobile device 100 is a GSM/GPRS wireless network, other wireless networks may be associated with mobile device 100 in variant implementations. Different kinds of wireless networks that can be employed include, for example, data-centric wireless networks, voice-centric wireless networks, and dual-mode networks that can support both voice and data communications on the same physical base station. Combined dual-mode networks include, but are not limited to: Code Division Multiple Access (CDMA) or CDMA2000 networks, GSM/GPRS networks (as described above), and future third generation (3G) networks such as EDGE and UMTS. Some older examples of data center networks include the Mobitex ^™ radio network and the DataTAC ^™ radio network. Examples of older voice-centric data networks include Personal Communication Systems (PCS) networks (such as GSM) and Time Division Multiple Access (TDMA) systems.

Microprocessor 102 also interacts with other subsystems such as random access memory (RAM) 106, flash memory 108, display 110, auxiliary input/output (I/O) subsystem 112, serial port 114, keyboard 116, speaker 118 , microphone 120 , short range communication 122 and other equipment 124 . the

Some subsystems of the mobile device 100 perform communication-related functions, while other subsystems may provide "resident" or on-device functions. As an example, display 110 and keyboard 116 may be used for communication-related functions, such as entering text messages for transmission over network 200, and for device-native functions, such as a calculator or task list. Operating system software used by microprocessor 102 is typically stored in persistent storage such as flash memory 108, which may alternatively be a read-only memory (ROM) or similar storage unit (not shown). Those skilled in the art will appreciate that an operating system, application-specific programs, or portions thereof, may be temporarily loaded into volatile memory such as RAM 106. the

Mobile device 100 may send and receive communication signals over network 200 after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of the mobile device 100 . In order to identify a subscriber, the mobile device 100 requires a Subscriber Identity Module or "SIM" card 126 to be inserted into a SIM interface 128 in order to communicate with the network. SIM 126 is a conventional "smart card" used to identify the subscriber of mobile device 100 and to personalize mobile device 100. Without the SIM 126, the mobile device 100 cannot be fully operated to communicate with the network 200. By inserting the SIM 126 into the SIM interface 128, the subscriber can access all subscription services. Services may include web browsing and messaging such as email, voicemail, Short Message Service (SMS), and Multimedia Message Service (MMS). More advanced services can include: point of sale, field service, and sales force automation. SIM 126 includes a processor and memory for storing information. Once SIM 126 is inserted into SIM interface 128, it is just connected with microprocessor 102. In order to identify the subscriber, the SIM 126 contains some user parameters, such as the International Mobile Subscriber Identity (IMSI). An advantage of using SIM 126 is that the subscriber need not be bound to a single physical mobile device. SIM 126 may also store additional subscriber information for the mobile device, including data book (or calendar) information and recent call information. the

The mobile device 100 is a battery powered device and includes a battery interface 132 for receiving one or more rechargeable batteries 130 . The battery interface 132 is connected to a regulator (not shown), and the regulator assists the battery 130 to supply power V+ to the mobile device 100 . Although current technologies use batteries, future technologies such as micro fuel cells could also power the mobile device 100 . the

In addition to its operating system functions, microprocessor 102 is also capable of executing software applications on mobile device 100 . A suite of applications that control basic device operations, including data and voice communication applications, is typically installed in mobile device 100 during manufacture. Another application that may be loaded onto mobile device 100 may be a personal information manager (PIM). PIM has functionality to organize and manage data items of interest to subscribers such as but not limited to: emails, calendar events, voicemails, appointments and task items. The PIM application has the capability to send and receive data items via the wireless network 200 . PIM data items can be seamlessly integrated, synchronized and updated via wireless network 200 with corresponding data items of mobile device subscribers stored and/or associated with a host computer system. This function creates a mirrored host computer on the mobile device 100 for the item. This is especially advantageous where the host computer system is the mobile device subscriber's office computer system. the

Other applications may also be loaded onto mobile device 100 via network 200 , auxiliary I/O subsystem 112 , serial port 114 , short-range communication subsystem 122 , or other suitable subsystem 124 . This flexibility in application installation increases the functionality of the mobile device 100 and may provide enhanced on-device functionality, communication-related functionality, or both. For example, a secure communication application can use the mobile device 100 to perform e-commerce functions and other such financial transactions. the

Serial port 114 enables a subscriber to set preferences through an external device or software application and expand the capabilities of mobile device 100 by providing information or software downloads to mobile device 100 in addition to over a wireless communication network. An optional download path may be used to load encryption keys to the mobile device 100, eg, over a direct and thus reliable and trusted connection, to provide secure device communications. the

The short-range communication subsystem 122 provides communication between the mobile device 100 and various systems or devices without using the network 200 . For example, subsystem 122 may include infrared devices and related circuits and components for short-range communications. Examples of short-range communications include Infrared Data Association (IrDA), Bluetooth, and the 802.11 family of standards developed by IEEE. the

In use, received signals such as text messages, e-mail messages or web page downloads are processed by the communication subsystem 104 and input to the microprocessor 102 . Microprocessor 102 then processes the received signal and outputs it to display 110 or alternatively to auxiliary I/O subsystem 11 . Subscribers may also use keyboard 116 in conjunction with display 110 and possibly auxiliary I/O subsystem 112 to compose data items such as e-mail messages. Accessory subsystem 112 may include devices such as a touch screen, mouse, trackball, infrared fingerprint detector, or scroll wheel with dynamic button press capability. Keypad 116 is an alphanumeric keypad and/or a telephone-type keypad. Compiled items may be sent over network 200 via communications subsystem 104 . the

The overall operation of the mobile device 100 is substantially similar for voice communications, except that received signals are output to speaker 118 and signals for transmission are generated by microphone 120 . An optional voice or audio I/O subsystem may also be implemented on mobile device 100, such as a voice message recording subsystem. Although output of voice or audio signals is primarily accomplished through speaker 118, display 110 may also be used to provide additional information, such as the identity of the calling party, the duration of the voice call, or other voice call-related information. the

Referring now to FIG. 2, a block diagram of the communication subsystem component 104 shown in FIG. 1 is shown. The communication subsystem 104 includes: a receiver 150; a transmitter 152; one or more embedded or built-in antenna elements 154, 156; a local oscillator (LO) 158 and a processing module 160 such as a digital signal processor (DSP). the

The specific design of the communication subsystem 104 is based on the network 200 in which the mobile device 100 is intended to operate, and thus it should be understood that the design shown in FIG. 2 is used as an example only. Signals received by antenna 154 over network 200 are input to receiver 150, which performs typical receiver functions such as signal amplification, frequency down conversion, filtering, channel selection, and analog-to-digital (A/D) conversion. A/D conversion of the received signal allows more complex communication functions such as demodulation and decoding to be performed in DSP 160. In a similar manner, the signal to be transmitted is processed by DSP 160, including modulation and coding. These DSP processed signals are input to transmitter 152 for digital-to-analog (D/A) conversion, frequency up-conversion, filtering, amplification, and transmission over network 200 via antenna 156 . The DSP 160 not only processes communication signals, but also provides control to the receiver and transmitter. For example, the gain applied to the communication signal in receiver 150 and transmitter 152 may be adaptively controlled by an automatic gain control algorithm implemented in DSP 160. the

The wireless link between mobile device 100 and network 200 may comprise one or more different channels (typically different RF channels) and be associated with the protocol used between mobile device 100 and network 200 . RF channels are limited resources that must be reserved, typically due to limitations in overall bandwidth and limited battery power of the mobile device 100 . the

When making the mobile device 100 fully functional, the transmitter 152 is typically only turned on when transmitting to the network 200, and turned off otherwise to conserve resources. Similarly, the receiver 150 is turned off periodically to conserve power until it is required to receive a signal or information (if any) during a specified time period. the

Referring now to FIG. 3 , a block diagram of a node of a wireless network is shown at 202 . In practice, network 200 includes one or more nodes 202 . Mobile device 100 communicates with node 202 within wireless network 200 . In the example implementation of FIG. 3, node 202 is configured according to General Packet Radio Service (GPRS) and Global System for Mobile Communications (GSM) technologies. The node 202 comprises a base station controller (BSC) 204 with associated base station tower 206, a packet control unit (PCU) 208 added to support GPRS in GSM, a mobile switching center (MSC) 210, a home location register (HLR) 212, Visitor Location Register (VLR) 214 , Serving GPRS Support Node (SGSN) 216 , Gateway GPRS Support Node (GGSN) 218 , and Dynamic Host Configuration Protocol (DHCP) 220 . This component list does not represent an exhaustive list of components for every node 202 in the GSM/GPRS network, but rather a list of components commonly used in communication over the network 200 . the

In a GSM network, the MSC 210 is connected to the BSC 204 and to a land network such as the Public Switched Telephone Network (PSTN) 222 for circuit switching requirements. The connection (also commonly referred to as shared network infrastructure) through the PCU 208, SGSN 216, and GGSN 218 to a public or private network (Internet) 224 represents the data path for a GPRS capable mobile device. In a GSM network that utilizes GPRS capability expansion, BSC 204 also includes a packet control unit (PCU) 208 connected to SGSN 216 to control segmentation, wireless channel allocation, and meet the needs of packet switching. The HLR 212 is shared between the MSC 210 and the SGSN 216 in order to track the location of the mobile device and to enable circuit-switched and packet-switched management. Access to the VLR 214 is controlled by the MSC 210. the

Station 206 is a fixed transceiver station. Station 206 and BSC 204 together form fixed transceiver equipment. Fixed transceiver equipment provides wireless network coverage for a specific coverage area commonly referred to as a "cell". The fixed transceiver equipment transmits and receives communication signals to and from mobile devices via station 206 within its cell. Fixed transceiver equipment, usually under the control of its controller, performs functions such as modulation and possibly encoding and/or encryption of signals to be transmitted to mobile equipment, according to specific (usually predetermined) communication protocols and parameters . The fixed transceiver device similarly performs demodulation and possibly decoding and decryption, if necessary, of any communication signals received from mobile devices 100 within its cell. Communication protocols and parameters may vary between different nodes. For example, one node may employ a different modulation scheme and operate at a different frequency than other nodes. the

Permanent configuration data such as user profiles are stored in the HLR 212 for all mobile devices 100 registered with a particular network. The HLR 212 also contains location information for each registered mobile device and can be queried to determine the current location of the mobile device. The MSC 210 is responsible for a set of location areas and stores in the VLR 214 the data of mobile devices currently within its area of responsibility. In addition, the VLR 214 also contains information about mobile devices that are accessing other networks. The information in the VLR 214 includes a portion of the permanent mobile device data sent from the HLR 212 to the VLR 214 for quick access. By moving additional information from the remote HLR 212 to the VLR 214, the amount of communication between these nodes can be reduced, thus providing faster response times to voice and data services while requiring the use of fewer computing resources. the

SGSN 216 and GGSN 218 are elements added to support GPRS; that is, support for packet switched data in GSM. SGSN 216 and MSC 210 have similar responsibilities in wireless network 200 by tracking the location of each mobile device 100. SGSN 216 also performs security functions and access control for data traffic on network 200. GGSN 218 provides Internet network connectivity to external packet-switched networks and is connected to one or more SGSNs 216 via an Internet Protocol (IP) backbone network operating within network 200. During normal operation, a given mobile device 100 must perform a "GPRS attach" to obtain an IP address and access data services. This need does not arise in circuit-switched voice channels because Integrated Services Digital Network (ISDN) addresses are used to route incoming and outgoing calls. Currently, all networks with GPRS capabilities use dedicated, dynamically assigned IP addresses, thus requiring a DHCP server 220 to be connected to the GGSN 218. Various mechanisms for dynamic IP assignment exist, including the use of a combination of Remote Authentication Dial-In User Service (RADIUS) servers and DHCP servers. Once the GPRS attachment is complete, a logical connection is established from the mobile device 100, through the PCU 208 and the SGSN 216 to the Access Node (APN) within the GGSN 218. The APN represents the logical end of an IP tunnel that provides direct access to Internet-compatible services or private network connections. The APN also represents the security authority of the network 200, therefore one or more APNs must be assigned to each mobile device 100 and a mobile device 100 cannot exchange data with an APN already authorized to use without first performing a GPRS attach. An APN can be thought of as similar to an Internet domain name such as "myconnection.wireless.com". the

Once the GPRS attachment is complete, the tunnel is created and all traffic is exchanged in standard IP packets using whatever protocol is supported in IP packets. This includes tunneling methods such as IP over IP in the case of some IP security protocol (IPsec) connections used by virtual private networks (VPNs). These tunnels are also known as Packet Data Protocol (PDP) contexts, and there are a limited number of these tunnels available in network 200 . In order to maximize the use of PDP contexts, the network 200 will run an idle timer for each PDP context to determine if there is no activity. When the mobile device 100 is not using its PDP context, the PDP context can be released and the IP address returned to the IP address pool managed by the DHCP server 220 . the

Referring now to FIG. 4 , a block diagram of components of the host system in an example configuration is shown. Host system 250 is typically a company office or other local area network (LAN), but in variant implementations it could be, for example, a home office computer or some other private system. In this example shown in FIG. 4, the host system 250 is depicted as the LAN of the organization to which the user of the mobile device 100 belongs. the

LAN 250 includes a plurality of network components connected to each other by LAN connection 260. For example, a user's desktop computing device ("desktop computer") 262a with an accompanying cradle 264 for the user's mobile device 100 is located on the LAN 250. The cradle 264 of the mobile device 100 can be connected to the computer 262a by, for example, a serial or universal serial bus (USB) connection. Other user computers 262b are also located on the LAN 250, and each computer may or may not have an accompanying stand 264 for the mobile device. The cradle 264 facilitates loading of information (e.g., PIM data, dedicated symmetric encryption keys to facilitate secure communications between the mobile device 100 and the LAN 250) from the user computer 262a to the mobile device 100, and is often used during initialization of the mobile device 100 The extensive information updates used are especially useful. Information downloaded to mobile device 100 may include S/MIME certificates or PGP keys used in message exchanges. The process of downloading information from the user's desktop computer 262a to the user's mobile device 100 is also referred to as synchronization. the

Those skilled in the art can understand that typically, the user computers 262a, 262b are also connected to other peripheral devices not explicitly shown in FIG. 4 . Furthermore, only a subset of the network components of LAN 250 are shown in FIG. 4, and those skilled in the art will appreciate that for this example configuration, LAN 250 includes additional components not explicitly shown in FIG. More generally, LAN 250 may represent a smaller portion of the organization's larger network (not shown), and may include different components, and/or be arranged in a different topology than that shown in the example of FIG. 4 . the

In this example, mobile device 100 communicates with LAN 250 through nodes 202 of wireless network 200 and shared network infrastructure 224, such as a service provider network or the public Internet. Access to LAN 250 may be provided through one or more routers (not shown), and computing devices of LAN 250 may operate behind a firewall or proxy server 266. the

In a variant implementation, LAN 250 includes a wireless VPN router (not shown) to facilitate data exchange between LAN 250 and mobile device 100. The concept of a wireless VPN router is relatively new in the wireless industry and implies that a VPN connection can be established with a mobile device 100 directly through a private wireless network. The use of wireless VPN routers has become possible in recent years and became available when the new sixth version of the Internet Protocol (IP) (IPv6) came into use in IP-based wireless networks. This new protocol will provide enough IP addresses to provide IP addresses to every mobile device, and information can be pushed to mobile devices at any time. The advantage of using a wireless VPN router is that it can be a custom VPN component without using a separate wireless gateway and a separate wireless infrastructure. In this variant implementation, the VPN connection is preferably a Transmission Control Protocol (TCP)/IP or User Datagram Protocol (UDP)/IP connection for passing messages directly to the mobile device 100 . the

First, a message intended for the user of the mobile device 100 is received by the message server 268 of the LAN 250. Such messages may originate from any of a number of sources. For example, the message may be sent by the sender from computer 262b within LAN 250, from computer 262b within LAN 250, from wireless network 200, or with Different mobile devices (not shown) connected to different wireless networks, or from different computing devices or other devices capable of sending messages. the

The message server 268 typically serves as the primary interface for the exchange of messages, especially e-mail messages, within the organization and over the shared network infrastructure 224 . Each user within an organization that is established for sending and receiving messages is typically associated with a user account managed by message server 268 . One example of message server 268 is a Microsoft Exchange ^™ server. In some implementations, LAN 250 may include multiple message servers 268 . The message server 268 is also adapted to provide additional functionality beyond message management, including, for example, the management of data associated with calendars and task lists.

As messages are received by the management server 268, they are typically stored in a message store (not shown) from which they can be later retrieved and delivered to users. For example, an email client application operating on user computer 262a may request email messages associated with a user account stored on message server 268 . These messages may then typically be retrieved from message server 268 and stored locally on computer 262a. the

While operating mobile device 100, a user may wish to retrieve email messages for delivery to the handheld device. An email client application running on the mobile device 100 may also request messages associated with the user account from the message server 268 . The email client may be configured (by the user or an administrator, possibly according to the organization's information technology (IT) policy) to make this request at the user's direction, at predetermined intervals, or when predetermined events occur. In some implementations, the mobile device 100 is assigned its own email address, and when messages specifically intended for the mobile device 100 are received by the message server 268, they are automatically redirected to the mobile device 100. the

To facilitate wireless communication of messages and message-related data between components of the mobile device 100 and the LAN 250, a number of wireless communication support components 270 may be provided. In this example implementation, wireless communication support component 270 includes message management server 272, for example. The message management server 272 is used to provide support specifically for the management of messages (eg, e-mail messages) to be processed by the mobile device. Generally, while messages are still stored on message server 268, message management server 272 is used to control when, if and how messages should be sent to mobile device 100. The message management server 272 also facilitates the processing of messages composed on the mobile device 100 that are sent to the message server 268 for later delivery. the

For example, message management server 272 may: monitor a user's "mailbox" (e.g., a message store associated with a user account on message server 268) for new email messages; apply user-definable filters to new messages to determine Whether and how messages are delivered to the user's mobile device 100; compress and encrypt new messages (e.g., using data such as Data Encryption Standard (DES) or Triple DES) and push them to the mobile device via shared network infrastructure 224 and wireless network 20 100; and receiving messages composed (e.g., encrypted using Triple DES) on the mobile device 100, decrypting and decompressing the composed messages, and if necessary, reformatting the composed messages so that they appear to originate from the user computer 262a, And the composed message is re-routed to the message server 268 for delivery. the

Certain attributes or restrictions associated with messages sent from and/or received by the mobile device 100 may be defined (eg, by an administrator in accordance with IT policy) and enforced by the message management server 272 . These attributes or restrictions may include, for example: whether the mobile device 100 can receive encrypted and/or signed messages, a minimum encryption key size, whether outgoing messages must be encrypted and/or signed, and whether messages sent from the mobile device 100 are to be A copy of all secure messages is sent to a predefined copy address. the

The message management server 272 may also be adapted to provide other control functions, such as pushing only certain message information or predetermined portions (eg, "chunks") of messages stored on the message server 268 to the mobile device 100 . For example, when a message is initially retrieved by the mobile device 100 from the message server 268, the message management server 272 is adapted to push only the first portion of the message to the mobile device 100, which portion is of a predetermined size (eg, 2KB). The user may then request that more portions of the message be delivered by the message management server 272 to the mobile device 100 in chunks of the same size, possibly up to a maximum predetermined message size. the

Accordingly, the message management server 272 facilitates better control over the type and amount of data communicated to the mobile device 100 and helps minimize possible waste of bandwidth or other resources. the

Those skilled in the art will appreciate that the message management server 272 does not need to be implemented on a separate physical server in the LAN 250 or other networks. For example, some or all of the functionality associated with message management server 272 may be integrated with message server 268 or other servers in LAN 250 . In addition, LAN 250 may include multiple message management servers 272, specifically, in variant implementations, a large number of mobile devices need to be supported. the

Although the Simple Mail Transfer Protocol (SMTP), RFC822 headers, and Multipurpose Internet Mail Extensions (MIME) body parts can be used to define the format of a typical e-mail message that does not require encoding, it is also possible in the communication of encoded messages (i.e. In Secure Messaging applications) Secure/MIME (S/MIME), which is a version of the MIME protocol, is used. S/MIME enables end-to-end authentication and confidentiality, and provides data integrity and confidentiality from when the originator of the message sends the message to when the message is decoded and read by the recipient. Other standards and protocols may be employed to facilitate secure messaging, such as Pretty Good Privacy ^™ (PGP) and PGP variants such as OpenPGP. It will be appreciated that although "PGP" is generally referred to herein, this term is intended to encompass implementations according to one of many variants of the more generalized PGP scheme.

Secure messaging protocols such as S/MIME and PGP-based protocols rely on public and private encryption keys to provide confidentiality and integrity. Data encrypted with the private key of a private/public key pair can only be decoded with the pair's corresponding public key, and data encrypted with the public key of a private/public key pair can only be decoded with the pair's corresponding private key . It is intended to never disclose private key information, but share public key information. the

For example, if a sender wishes to send a message in encrypted form to a recipient, the recipient's public key was used to encrypt the message, the message can only be decoded using the recipient's private key. Optionally, in some encoding techniques, a one-time session key is generated and used to decode the body of the message, typically using a symmetric encryption technique (eg Triple DES). The session key is then encrypted using the recipient's public key (eg using a public key encryption algorithm such as RSA), the session key can only be decrypted using the recipient's private key. Message headers can be used to specify a particular encryption scheme that must be used to decrypt the message. In variant implementations, other encryption techniques based on public key cryptography may be used. In each of these cases, however, only the recipient's private key can be used to facilitate successful decryption of the message, and in this way, the confidentiality of the message can be maintained. the

As another example, a sender may sign a message using a digital signature. A digital signature is a digest of the message (such as a hash of the message) encrypted with the sender's private key. The digital signature can then be added to the outgoing message. To verify a message's digital signature upon receipt, the recipient uses the same techniques as the sender (eg using the same standard hashing algorithm) to obtain a digest of the received message. The receiver also uses the sender's public key to decode the digital signature in order to obtain a matching digest of the received message. If the digest of the received message does not match, this indicates that the message content was changed during transmission and/or the message did not originate from the sender whose public key was used for authentication. The digital signature algorithm is designed in such a way that only the person who knows the sender's private key can encode a signature that the recipient can directly use the sender's public key to decode. Therefore, by verifying the digital signature in this manner, the authentication of the sender and the integrity of the message are maintained. the

Encoded messages can be encrypted, signed, or both. In S/MIME, certificates are used to verify the authenticity of the public keys used in these operations. A certificate may be a digital document issued by a certificate authority (CA). Certificates are used to authenticate the association between a user and their public key and, in essence, provide confidence in the authenticity of the user's public key. A certificate contains information about the certificate holder, and the certificate content is usually in a format according to an accepted standard (eg X.509). Certificates are usually digitally signed by a certificate authority. the

In PGP-based systems, PGP keys are used, which, like S/MIME certificates, contain public information including the public key and information about the key holder or owner. However, unlike S/MIME certificates, PGP keys are generally not issued by a certificate authority, and typically confidence in the authenticity of a PGP key requires verification that a trusted individual has vouched for the authenticity of a given PGP key. the

Standard email security protocols generally facilitate secure messaging between non-mobile computing devices (eg, computers 262a, 262b of FIG. 4; remote desktop devices). In order that the signed message received from the sender can be read from the mobile device 100 and the encrypted message can be sent from the mobile device 100, the mobile device 100 is adapted to store other individuals' public keys (e.g. PGP keys in S/MIME certificates). key). For example, keys stored on user computer 262a are downloaded from computer 262a to mobile device 100, typically via cradle 264. the

The mobile device 100 may also be adapted to store the private key of a public/private key pair associated with the user, so that the user of the mobile device 100 can sign outgoing messages composed on the mobile device 100, and decrypt messages encrypted with the user's public key. The message sent to the user. For example, the private key may be downloaded from the user's computer 262a to the mobile device 100 via the cradle 264 . Preferably, private keys are exchanged between computer 262a and mobile device 100 so that users can share one identity and one method to access messages. the

The user computers 262a, 262b may obtain S/MIME certificates and PGP keys from a variety of sources for storage, eg, in the keystores of the computers 262a, 262b and/or mobile devices (eg, mobile device 100). The source of these certificates and keys can be private (eg, dedicated within the organization) or public, can reside locally or remotely, and can be accessed from within the organization's private network or via, for example, the Internet. In the example shown in FIG. 4, a plurality of public key infrastructure (PKI) servers 280 associated with an organization reside on LAN 250. For example, PKI server 280 includes a CA server 282 that can be used to issue S/MIME certificates, Simplified Directory Access Protocol (SCA) that can be used to search and download S/MIME certificates and/or PGP keys (e.g., for individuals within an organization). LDAP) server 284 and an Online Certificate Status Protocol (OCSP) server 286 that can be used to verify the revocation status of S/MIME certificates. the

For example, certificates and/or PGP keys may be retrieved by user computer 262 a from LDAP server 284 for download to mobile device 100 via cradle 264 . However, in a variant implementation, the LDAP server 284 can be directly accessed by the mobile device 100 (i.e., "over the air" in this context), and the mobile device 100 can search and retrieve personal certificates and PGP via the mobile data server 288. key. Similarly, mobile data server 288 may be adapted to allow mobile device 100 to query ODSP server 286 directly to verify the revocation status of the S/MIME certificate. the

In a variant implementation, the mobile device can only access selected PKI servers 280 (eg, so that only certificates can be downloaded from the user's computer 262a, 262b, but the revocation status of the certificates can be checked from the mobile device 100). the

In a variant implementation, a specific PKI server 280 may also be made accessible only by mobile devices registered with specific users, according to IT policy, as specified by the IT administrator. the

Other sources (not shown) such as S/MIME certificates and PGP keys may include: Windows certificate or key stores, other secure certificate or key stores on or off the LAN 250, and smart cards. the

In a last system embodiment, policy engine 290 resides in LAN 250. For example, policy engine 290 may be provided as PGP General Server developed by PGP Corporation. This is just an example. In variant embodiments, the policy engine may be implemented in other devices or structures than the PGP generic server, and may be applied in the context of protocols other than PGP (eg, in an S/MIME policy engine). the

With respect to the above example, the PGP general server 290 is adapted to communicate with the user's desktop computer (eg, 262a) as well as the user's mobile device (eg, 100, via the message management server 272), and is also adapted to encrypt messages, eg, according to policies established by the administrator. As well as enforce compliance with security requirements regarding messages sent by users. The arrangement of the PGP Universal Server 290 in the LAN 250 as shown in FIG. 4 is merely an example, and other arrangements and configurations are possible. Depending on the placement of the PGP Universal Server 290 and the particular configuration of the LAN 250 in which the PGP Universal Server 290 may be employed, the level of control over securely encoded process messages (in particular, user-sent messages) may vary. the

For example, PGP Universal Server 290 is adapted to directly process all outgoing messages (i.e., messages sent by a user from a user's desktop computer, mobile device, or other computing device to one or more intended recipients), where it Policies (if any) defined on the PGP general server 290 determine which messages are to be encrypted and/or signed. If policy dictates that PGP be used to encrypt and sign messages to be sent by a user to a particular domain or belonging to a particular subject, the PGP general server 290 itself can encrypt and sign the message before sending. the

Alternatively, the user may download security policy data from the PGP general server 290 to the user computing device, such as through other PGP messaging applications on the user computer device in communication with the PGP general server 290 . Then, based on the obtained security policy data, the user or application can be instructed to encrypt and sign the message before sending it. the

Thus, PGP Generic Server 290 provides the ability to enforce centralized policies based on domains and other mechanisms. the

The PGP general server 290 is also adapted to store, validate, and manage PGP keys, and to retrieve PGP keys from remote key stores when keys are needed to encode (eg, encrypt and/or sign) messages. PGP Universal Server 290 may also provide stored or retrieved PGP keys to users as needed, upon request by the user or application. the

By employing a policy engine such as implemented by the PGP Generic Server 290 described by way of example, most of the responsibility associated with handling secure messages (e.g. e-mail) (in particular, deciding which messages to send securely and which which security encoding should be applied) is transferred to the policy engine. the

Referring now to FIG. 5 , a block diagram of components of one example of an encoded message that may be received by a message server (eg, message server 268 of FIG. 4 ) and forwarded to a user (eg, mobile device 100 ) is shown at 350 . An encoded message 350 typically includes one or more of the following components: a header 352, a body or data portion 354, optionally one or more encoded attachments 356, one or more encrypted session keys 358 (if the message is encrypted), and a digital signature Information 360 related to the signature. the

For example, header portion 352 of message 350 typically includes address information, such as "to," "from," and "Cc" message addresses, and may also include, for example, length indicators and encryption and signature scheme identifiers. The actual message content is typically included in a body or data portion 354 and possibly in one or more attachments 356 which may be encrypted by the sender using a session key. If a session key is to be used, it is typically encrypted for each intended recipient using each recipient's respective public key and included at 358 in the message. the

If the message is signed, the digital signature and signature-related information 360 is included. For example, this may include the sender's certificate when using a protocol such as S/MIME. As another example, if the signature is a PGP signature, the PGP signature will include a PGP key identifier that can be used to identify the PGP key that signed the message. Typically, the message does not include the PGP key. Typically, individuals who intend to communicate securely with each other can exchange PGP keys with each other prior to communicating. PGP keys typically also include information associated with the key holder, such as an address (eg, an email address) associated with the key holder. the

Signed messages need not be limited to messages with a single digital signature 360 added to the end of the message. For example, some protocols allow multiple independent portions of data in the message body 354 to be signed, and the resulting message may include multiple digital signatures contained within the message (possibly embedded in the message body 354 itself). the

The format of the encoded message as shown in FIG. 5 is provided as an example only, and those skilled in the art will appreciate that there are other formats of the encoded message. Depending on the particular secure messaging standard or protocol employed, the components of an encoded message may appear in a different order than shown in Figure 5, and the encoded message may include fewer, additional, or different components, depending on whether encrypted, signed Or both encrypt and sign encoded messages. For example, in various known implementations, session key 358 is placed after header 352 but before message body 354 . the

To facilitate a better understanding of the various features of the embodiments described herein, a number of example messages are provided in FIGS. 6A through 6E by way of illustration only. It will be appreciated that the general format and content of the messages will vary from implementation to implementation. the

It will also be appreciated that while most of the messages shown in these examples contain data that has been signed using a PGP-based protocol, features of the embodiments described herein are also applicable to messages containing data signed using other secure messaging protocols. the

For the sake of brevity, the actual PGP signatures that would appear in the messages shown in these figures are not explicitly shown, and for convenience, each signature is identified in these examples as "<...the signature appears here... >". the

Referring to FIG. 6A, as shown in header 402 of message 400, an example email message 400 sent from John Smith to the address janedoe@xyz.com includes a start message header 404, a signed data portion 406, and a signature corresponding to the signed data portion 406. PGP digital signature 408 corresponding to and identified by start signature header 409 . Digital signature 408 may be used in known manner to verify that signed data portion 406 was in fact signed by the key identified by the key ID in digital signature 408 and has not been modified in transit. the

Additionally, in one system embodiment, the address associated with the key used to generate the digital signature 408 may be determined by retrieving the key holder information associated with the key from the key/certificate store. For example, the recipient at janedoe@xyz.com of message 400 may have previously exchanged a PGP key with John Smith, and stored John Smith's PGP key at the key of her computing device (e.g., mobile device 100 of FIG. 4 ). in memory. Assuming the message was actually sent by John Smith, the key identified by the key ID in digital signature 408 matches John Smith's key stored in the key store. For better security, a verification that the address associated with the key matches the John Smith address identified in header 402 may be performed. If the addresses do not match, the recipient of the message 400 may be alerted to the detection of an address mismatch, regardless of whether the digital signature 408 itself was properly verified. the

Referring now to FIG. 6B, an example email message 410 shown here is a reply from Jane Doe, recipient of message 400 (FIG. 6A) at janedoe@xyz.com, to John Smith, as indicated by header 412 of message 410. The text of message 400 is incorporated into message 410, below message separator 414, and can be considered to represent a thread of conversation between John Smith and Jane Doe. the

In this example, the message separator 414 is an original message separator of the form "-----Original Message----". Generally, multiple message delimiters are used to separate the replied message data from the data in the current message, including for example: a straight line delimiter (that is, a straight line or a dotted line that divides the replied message data from the data in the current message) , the writing author separator (i.e. an indication of who wrote the message being replied to, perhaps e.g. "JohnSmith Wrote:" or "johnsmith@abc.xomwrote:" in message 410), and other predetermined separators for this purpose symbol. Similarly, forwarded message delimiters (eg, "----ForwardedMessage----"), author delimiters, and other predetermined delimiters may be used to separate forwarded message data from data in the current message. the

In the example message 410, Jane Doe did not digitally sign any part of her reply to John Smith. However, message 410 contains the text of the old message 400 that was replied to. Message 410 now contains a portion of signed data 406 and a corresponding digital signature 408 by incorporating the text of the old message. A device adapted to detect an address mismatch may assume that the address associated with the key used to generate digital signature 408 should match the address of the sender, Jane Doe, identified in header 412 of message 410 . In this case, an address mismatch was detected because the key used to generate the digital signature 408 belonged to John Smith. However, the user would be misdirected notifying the address mismatch because the error was the result of the old message 400 being correctly incorporated into the current message 410, rather than the result of a malicious third party, e.g., trying to impersonate Jane Doe. the

Thus, in a broader aspect, at least one predetermined action may be performed for each digital signature in a message that appears after the first message delimiter, as shown in various embodiments that will be discussed in detail with reference to FIGS. 7A to 7C , Its purpose is to avoid misleading users in the above situations. For example, in the example of FIG. 6B, John Smith's computing device would be adapted to ignore any digital signature (eg, 408) in the text of message 410 that appears after message delimiter 414, thus bypassing the sender address in header 412 Verification that matches the key associated with the key used to generate the digital signature 408 . As another example, John Smith's computing device is adapted to verify that the sender address in the header 412 matches an address associated with the key used to generate the digital signature 408, but is inhibited from notifying the user of a detected address mismatch. Other examples of predetermined actions in modified embodiments will be described here. the

Referring now to FIG. 6C, the example email message 410b shown here is a different example of a reply from Jane Doe as opposed to the reply shown in FIG. 6B. the

Message 410b is similar to message 410 . The text of message 400 is also incorporated into message 410b, below message separator 414. However, in the example message 410b, Jane Doe digitally signs the entire content of her reply message to John Smith using her own PGP key. Data signed by the Jane Doe key is identified as 416 in FIG. 6C , and the PGP digital signature corresponding to the signed data 416 is shown as 418 . the

Signed data 416 also incorporates a portion of signed data 406 and a corresponding digital signature 408 from the replied message 400 . the

Of the two digital signatures 408, 418 that appear in the message 41ob, in this example, John Smith's computing device detects a connection between the last digital signature 418 and the sender of the message 410b identified by the header 412 (i.e., Jane Doe). The address mismatch is appropriate. However, for the remaining digital signatures 408, at least one predetermined action may be performed, as described with reference to FIG. 6B. the

Figures 6D and 6E are other examples of messages 420, 420b containing longer conversation threads between John Smith and JaneDoe. Two optional replies from John Smith to Jane Doe as indicated by header 422 are shown. The replied message is incorporated into the message 420, 420b after the message separator 424. the

In FIG. 6D , the new text provided as John Smith's reply is signed, and the signed data and corresponding digital signature are shown as 426 and 428 respectively. In message 420 , message separator 424 does not appear in signed data 426 . the

In Figure 6E, the new text provided as a reply and the message that John Smith is replying to is signed, and the signed data and corresponding digital signature are shown as 426 and 428, respectively. In message 420b, message separator 424 appears within signed data 426 . the

In both examples, it is appropriate to detect whether there is an address mismatch between the digital signature 428 and the sender of the message 420 identified by the header 422 . However, with respect to other digital signatures present in message 426, at least one predetermined action may be performed. At least one embodiment described below provides these features. the

As noted above in this specification, the embodiments described herein generally relate to an apparatus and method that minimizes the number of address mismatch errors reported to message users, especially for correctly incorporated Messages that are part of a message other than someone else's signature, as in the case of a message containing a conversation thread. This can enhance the usability of the computing device and is especially advantageous when the computing device is a mobile device. the

Referring first to FIG. 7A , a flowchart of steps in a method of processing a signed message in an exemplary embodiment is shown generally at 500 . The various steps of method 500 (and methods 500b and 500c) and other details about attributes that may be employed in variant embodiments have been discussed in the preceding sections of this specification. the

At least some of the steps of method 500 (and methods 500b and 500c) are performed by an application program executing and resident on the computing device. The application may be an email or other messaging application, other application combined or integrated with the email or other messaging application (such as an add-on to provide the necessary functionality), or other application programmed to perform these steps . the

A computing device may be a desktop computer (eg, may include a laptop computer or some other computing device with which a mobile device may be synchronized), a mobile device, or some other computing device. The computing device may be connected to a policy engine (eg, as implemented in PGP general server 290 of FIG. 4). the

At step 510, a message (eg, an email message) is received at a computing device (eg, mobile device 100 of FIG. 4 ) by an application (eg, an email application) executing on the computing device. A received message includes a header which typically includes the address of the sender (i.e. where the message came from), the address of the recipient, the date and time the message was sent or received, the subject of the message, and possibly other information, as in the example of Figure 5 shown. the

The message received at step 510 to be processed according to method 500 also contains at least a portion of signed data and a digitally signed message corresponding to each portion of the signed data. The signed data section may include the entire message body. the

According to at least one embodiment, each of said at least one portion of signed data may be signed using a PGP key. A message can be started by a PGP header (e.g. "----BEGINPGP MESSAGE----" or "----BEGIN PGP SIGNED MESSAGE----") at its beginning, by the same PGP Begin Signed header (e.g. "----BEGIN PGPSIGNATURE----") defines at its end each of said at least one portion of signed data in the message, wherein the signed data is disposed between two headers. the

The signed data portion and corresponding digital signature may also be included as part of an old message that has been incorporated into the message received at step 510 (eg, a message being or has been replied to, or a message being or has been forwarded). In some cases, the signed data and corresponding digital signature may also be re-signed and embedded accordingly in another part of the signed data in the message received at step 510 (see FIG. 6E ). the

The message received at step 510 to be processed according to method 500 also includes at least one message delimiter indicating that at least one old message was incorporated into the received message. For example, the message separator can be an original message separator (such as "----Original Message----"), a straight line separator (such as "----" or a horizontal line or bar), an authoring separator (such as "<thesender> wrote:"), a forwarded message delimiter (such as "----Forwarded Message----"), or some other message delimiter predetermined by the application as appropriate for detection. Because message delimiters can vary widely across known systems, the application is suitable for detecting common variants. the

In a variant embodiment, the application is also adapted to detect a subsequent start message header as a message delimiter within the portion of signed data defined at the beginning with the first start message header. For example, if the first "----BEGIN PGP MESSAGE----" header appears, it means signed data follows, and after the first header and after "----BEGIN PGP SIGNATURE----" Before, the following "----BEGIN PGP MESSAGE----" header appears, the following header can be used as a message delimiter. the

At step 520, the first message delimiter in the message received at step 510 is located. Typically, the presence of the first message delimiter in the received message indicates that the data appearing in the message before the first message delimiter originates from the sender of the message received at step 510, while the data after the first message delimiter From someone other than the sender. For example, the data after the first message delimiter may belong to an old message that the sender of the message received at step 510 is replying to or forwarding. the

A message may or may not include one or more portions of signed data and a corresponding digital signature, both of which appear before the first message delimiter. These portions of the signed message most likely originated from the sender of the message received at step 510 . Each digital signature corresponding to signed data appearing before the first message delimiter can be verified in known manner (this step not shown). the

Additionally, in one embodiment, for each digital signature corresponding to signed data that appears before the first message delimiter, the application is adapted to: (1) verify that the header of the message received at step 510 identifies matches the address associated with the key used to generate the respective digital signature corresponding to the signed data that appears before the first message delimiter; and (2) if the sender address matches the key used for The addresses associated with the keys that generated the respective digital signatures do not match, and the user of the computing device is notified of the address mismatch, as shown in step 530 . the

In order to determine the address associated with the key used to generate a given digital signature, the key associated with the key must be retrieved when stored into a key store from which the address can be extracted (for example, on a computing device or from a remote key store). Associated key holder information (this step is not shown). Once the address associated with the key is determined, the application can verify that the determined address matches the sender address. the

In a variant embodiment, notifying the user at step 530 may be performed only if permitted by the security policy governing usage of the computing device. For example, an IT policy setting may specify under what circumstances a user of a computing device should be notified when an address mismatch is detected. the

At step 540 , it is determined whether the first message delimiter located at step 520 is present in a portion of the signed data in the message received at step 510 . For example, if the "----Original Message----" delimiter appears in the message, after "----BEGIN PGPMESSAGE----" or "----BEGIN PGP SIGNED MESSAGE----" header, but before "----BEGIN PGP SIGNATURE----", then this indicates that the first message separator appears as part of the signed data. the

If it is determined that the first message delimiter does not appear in a portion of the signed data, this generally indicates that the data associated with the old message incorporated into the message received at step 510 was not signed by the sender of the received message. If it is determined that the first message delimiter does not appear in a portion of the signed data, at least one predetermined action may be performed for each digital signature that appears in the message after the first message delimiter, which may cause a notification to the computing device user The number of misleading address mismatch errors is minimized. the

For example, in this embodiment, as shown in step 550, at least one predetermined action for a digital signature that appears after the first message delimiter includes bypassing the sender address associated with the key used to generate the digital signature The address matches the verification. Alternatively, to detect address mismatches, the application is adapted to ignore any digital signatures that appear after the first message delimiter. the

It will be appreciated that the application may verify the digital signature itself (ie decode the digital signature to authenticate the signer of the corresponding signed data and confirm message integrity) (this step is not shown). the

To detect address mismatches, by ignoring digital signatures that appear after the first message delimiter, the possibility of the user being notified of a misleading address mismatch error associated with an old message is eliminated, provided the first message delimiter in the message is correctly identified symbol. This can enhance the usability of the computing device and is especially advantageous when the computing device is a mobile device. For example, managing multiple misleading address mismatch error notifications on a mobile device is cumbersome for users. the

Referring again to step 540, if it is determined that the first message delimiter is present in a portion of the signed data, this generally indicates that data associated with at least one old message was incorporated into the message received at step 510 and is used by the receiving message's The sender signs it. There should be a digital signature corresponding to the portion of the signed data in which the first message delimiter occurs, but after the first message delimiter. Accordingly, at step 560, the application verifies that the sender address identified by the message header received at step 510 matches the address associated with the key used to generate the digital signature. At step 570, if the sender address does not match the address associated with the key used to generate the digital signature, the user of the computing device is notified of the address mismatch. the

Where it is routine to sign the entire body of a message in a conversation between two or more individuals, a digital signature corresponding to the current message received under any particular circumstances is typically appended to the end of the message. Therefore, in these cases, when the first message delimiter does appear in a part of the signed data, the digital signature corresponding to that part of the signed data in which the first message delimiter occurs is usually the last in the message Digital signature (see Figure 5E). the

In general, however, it is also possible that the digital signature corresponding to the portion of the signed data in which the first message delimiter occurs is not the last digital signature in the message. The correct corresponding digital signature must be determined, for example by determining which digital signature appearing after the first message delimiter was successfully verified with respect to a particular part of the signed data (this step is not explicitly shown). the

As noted above, in order to determine the address associated with the key used to generate a given digital signature, one must, when stored into a key store from which the address can be extracted (e.g., on a computing device or from a remote key store), Keyholder information associated with the key is retrieved (this step is not shown). Once the address associated with the key is determined, the application can verify that it matches the sender's address. the

In a variant embodiment, notifying the user at step 570 may be performed only if permitted by the security policy governing usage of the computing device. For example, an IT policy setting may specify under what circumstances a user of a computing device should be notified when an address mismatch is detected. the

At step 580, at least one predetermined action is performed for each digital signature in the message that appears after the first message delimiter except for the digital signature whose address was verified to match at step 560, which may cause notification to the computing device The number of misleading address mismatch errors by users is minimized. the

In this embodiment, the at least one predetermined action for each digital signature that appears after the first message delimiter except for the digital signature for which an address match was verified at step 560 includes: bypassing the sender address Verification that the address associated with the key that generated the digital signature matches. Alternatively, to detect address mismatches, the application is adapted to ignore any digital signature occurring after the first message delimiter other than the digital signature corresponding to the signed data in which the first message delimiter occurs. the

With regard to step 550, it is understood that the application may verify the digital signature itself (i.e., decode the digital signature to authenticate the signer of the corresponding signed data and confirm message integrity) (this step is not shown). the

Furthermore, similar to that described with respect to step 550, for detecting address mismatches, by ignoring other digital signatures that appear after the first message delimiter, the possibility of the user being notified of an address mismatch error associated with an old message can be eliminated, as long as Correctly identify the first message delimiter in the message. This can enhance the usability of the computing device and is especially advantageous when the computing device is a mobile device. For example, managing multiple misleading address mismatch error notifications on a mobile device is cumbersome for users. the

Referring to FIG. 7B , a flow chart of steps of a method for processing a signed message in another exemplary embodiment is shown at 500b. the

Method 500b is similar to method 500, except that the at least one predetermined action is performed for digital signatures that occur after the first message delimiter (i.e., for for each digital signature that occurs after the first message delimiter, otherwise for each digit that occurs after the first message delimiter except for the digital signature corresponding to the portion of the signed data in which the first message delimiter occurs signature) includes verifying that the sender's address matches the address associated with the key used to generate the digital signature, but prohibiting sending A user of the computing device notifies the address mismatch. The method is shown at steps 550b and 580b. The other steps of method 500b have been described above with reference to method 500 of FIG. 7A. the

In a variant embodiment, the prohibition of notifying the user at steps 550b and/or 580b may be performed only if allowed by the security policy governing the use of the computing device. For example, an IT policy setting may specify under what circumstances a user of a computing device should be notified when an address mismatch is detected. the

Similar to that described with reference to FIG. 7A , in order to determine the address associated with the key used to generate a given digital signature, it must be stored in the key store (e.g., on a computing device or from a remote key) from which the address can be extracted. memory) to retrieve the key holder information associated with the key (this step is not shown). Once the address associated with the key is determined, the application can verify that it matches the sender's address. the

It will also be appreciated that the application can verify the digital signature itself (i.e. decode the digital signature to authenticate the signer of the corresponding signed data and confirm message integrity) (this step is not shown). the

Referring to FIG. 7C , a flow chart of the steps of the method for processing a signed message in another exemplary embodiment is generally shown at 500c. the

Method 500c is similar to method 500, except that it attempts to provide context for digital signatures that appear after the first message delimiter so that proper verification of address matches can occur. This may provide additional security to the user. For example, assume that the sender of a part of an old message that a user assumes incorporated into a received message has signed that part, as shown in the text of a conversation thread. However, it is possible that the sender or sender address shown in the "From:" line in the old message of the conversation thread changed, making it appear that the old message was sent and signed by someone other than the actual sender. the

The embodiment described with respect to method 550c attempts to address this issue by determining the address associated with each particular portion of the signed data associated with the old message incorporated into the message received at step 510 . the

More specifically, for each portion of signed data in a message, an attempt is made to determine a partial private address, in addition to assuming that the address associated with the key used to generate the digital signature that appears in the received message should match the sender's address, so that the correct address can be matched when an address mismatch is detected. the

Specifically, in one embodiment, said at least one predetermined action for a digital signature that occurs after a first message delimiter (i.e., if the first message delimiter does not occur in a part of the signed data, then for occurrences of For each digital signature that follows the first message delimiter, otherwise for each digital signature that occurs after the first message delimiter A digital signature) includes: (1) determining the portion private address associated with the portion of the signed data to which the digital signature corresponds, as shown at steps 550c and 580c; (2) verifying the portion determined at steps 550c and 580c The private address matches the address associated with the key used to generate the digital signature, as shown at steps 552c and 582c, respectively; and (3) if the partial private address matches the address associated with the key used to generate the digital signature The addresses do not match, and the user of the computing device is notified of the address mismatch, as indicated at steps 554c and 584c, respectively. The other steps of method 500c have been described above with reference to method 500 of FIG. 7A. the

In one embodiment, the step of determining the portion of the private address associated with the portion of the signed data corresponding to the digital signature (e.g., steps 550c, 580c) includes, where possible, from the Extract the previous sender's address from the message delimiter preceding the corresponding portion of the signed data and from the text in the message between that portion of the signed data. Typically, the aim is to first determine where the old message that was incorporated into the received message and containing that portion of the signed data began, which is usually indicated by the closest message delimiter preceding the signed data. Thus, in at least some cases, the partial private address of the sender of the old message can often be determined from the header that appears after the message delimiter, in which case the header is set in the incorporated text. the

For example, consider the example of Figure 6D. Signed data 416 is the portion of the original message from Jane Doe shown in header 412 that has been replied in message 420 . In order to perform a correct match of addresses, the sender address appearing in header 412 (i.e. janedoe@xyz.com) preceding signed data 416 can be extracted as the corresponding address specifically associated with signed data 416 and corresponding digital signature 418 Some private addresses. Verification that the address associated with the corresponding digital signature 418 matches the sender's partial private address appearing in header 412 may then be performed, and the user may be notified if an address mismatch is detected. Similarly, with respect to digital signature 408 , the sender address appearing in header 402 preceding signed data 406 may be extracted as part of the private address specifically associated with signed data 406 and corresponding digital signature 406 . A verification that the address associated with the corresponding digital signature 408 matches the sender's partial private address appearing in the header 402 may then be performed, and the user may be notified if an address mismatch is detected. the

In this way, address mismatch errors can be correctly detected even when the signed data and corresponding digital signature are part of an old message that has been incorporated into the message received at the computing device. the

Similar to that described with reference to FIG. 7A , in order to determine the address associated with the key used to generate a given digital signature, it must be stored in a key store from which the address can be extracted (e.g., on a computing device or from a remote key). memory) to retrieve the key holder information associated with the key (this step is not shown). Once the address associated with the key is determined, the application can verify that it matches the partially private address. the

It will also be appreciated that the application can verify the digital signature itself (ie decode the digital signature to authenticate the signer of the corresponding signed data and confirm message integrity) (this step is not shown). the

For some messages, the sender's address of the received message or the previous sender's address of an old message that has been incorporated into the received message may not be explicitly shown in the received message. This situation arises, for example, when an application is adapted to process messages such that the sender is identified only by a name in a header of a given message, such as a name that is easily discernible by a user. the

Thus, in a variant embodiment, the step of determining the portion of the private address associated with the portion of the signed data to which the signature number corresponds (for example, steps 550c, 580c) includes: (1) starting from the from the message delimiter preceding the corresponding portion of the signed data and from the text in the message between that portion of the signed data, extracting the name of the previous sender; and (2) if the name is extracted, from The previous sender address associated with the extracted name is extracted from the address book as part of the private address. Typically, the aim is to first determine where an old message that has been incorporated into the received message and contains that portion of signed data begins, which is usually indicated by the closest message delimiter preceding the signed data. Thus, in at least some cases it is often possible to determine the sender name of an old message from a header that appears after the message delimiter, in which case the header is set in the incorporated text. From the name, an attempt can be made to determine the partial private address associated with the name from data in, for example, the user's address book. the

For example, consider the example of Figure 6E. Signed data 416 is the portion of the original message from Jane Doe shown in header 412 that has been replied in message 420 . To perform a correct match of addresses, the sender's name (ie Jane Doe) appearing in header 412 preceding signed data 416 may be extracted. Jane Doe's address can then be retrieved from the user's address book as a partial private address associated exclusively with the signed data 416 and corresponding digital signature 418. Verification that the address associated with the corresponding digital signature 418 matches the sender's partial private address associated with the name appearing in header 412 may then be performed, and the user may be notified if an address mismatch is detected. the

An address book is considered to include any directory, list, or other data structure in which names and associated addresses are provided. The data of the address book may reside on the computing device, or be in storage on a remote computing device, for example. the

In this variant embodiment, the address of the previous sender can be retrieved from the address book only if the address of the previous sender is not explicitly provided in the corresponding header. If an address is explicitly provided, the extracted address can be used to perform address verification as described above. the

Similar to that described with reference to FIG. 7A , in order to determine the address associated with the key used to generate a given digital signature, it must be stored in a key store from which the address can be extracted (e.g., on a computing device or from a remote cryptographic key). Keyholder information associated with the key is retrieved when stored in the key store (this step is not shown). Once the address associated with the key is determined, the application can verify that it matches the partially private address. the

It will also be appreciated that the application can verify the digital signature itself (ie decode the digital signature to authenticate the signer of the corresponding signed data and confirm message integrity) (this step is not shown). the

The embodiment of the method described with reference to FIGS. 7A to 7C is by way of example only, and other techniques may be used in variant embodiments to make misleading or incorrect information that may be generated by a computing device adapted to detect an address mismatch error The number of address mismatch errors is minimized. In particular, other heuristics may be applied to help determine when it may be inappropriate to notify a user of an address mismatch error for a particular message structure. the

Furthermore, in a variant embodiment, in case a verification is performed that the address of the sender or part of the private address matches the address associated with the key used to generate the particular digital signature, for the or subsequent digital signatures, the computing device is further adapted to suppress display of the message itself or one or more parts of the message to the user in the event of an address mismatch being detected. Suppressing display of at least a portion of the message may be performed only if permitted by a security policy governing use of the computing device. For example, an IT policy setting may specify under what circumstances a message (or a portion thereof) should be displayed when an address mismatch is detected. When the display of at least a part of the message is suppressed, the user is generally notified that the reason for suppressing the display of the message is the detection of an address mismatch error. the

It is also understood that combinations of the features of the various embodiments described herein may be employed in a given implementation. For example, an attempt to determine a portion-specific address may be made for a particular signed data portion in a message in order to perform address match verification, while other data portions in the message are simply bypassed and ignored. Whether a verification of an address match is performed for a particular old message incorporated into a received message may depend, for example, on how old the particular old message is in a given conversation thread. For example, the technique that should be applied to a given portion of signed data and the corresponding digital signature of an older message incorporated into a received message may be dictated by a security policy governing the use of the computing device (e.g., as indicated in an IT policy setting) . the

The steps of the methods described herein may be provided as executable software instructions stored on a computer-readable medium, including transmission-type media. the

The invention has been described with reference to a number of embodiments. However, it will be appreciated by those skilled in the art that other changes and modifications can be made without departing from the scope of the present invention as defined in the appended claims. the

Claims (24)

1. the method for the signature information that receives at the computing equipment place of a processing, described method comprises step:

Receive message, described message comprises:

Header comprises the sender address at least;

At least a portion is signed data;

With the corresponding digital signature of each part of signed data; And

At least one message separator character, described message separator character have indicated at least one Geju City message to be merged in received message;

Determine whether first message separator character appears at a part in the signed data, sender in the message before wherein present first message separator character is expressed in the appearance of first message separator character in receiving message, and outside the described sender other people after first message separator character data from received message;

If first message separator character does not appear at a part in the signed data,

At appearing at first message separator character each digital signature afterwards in the message, carry out at least one predetermined action, minimize so that be notified to the number of computing equipment user's misleading address mismatch error; And

If first message separator character appears at a part in the signed data,

Whether checking sender address is complementary with the address that is associated with key, the corresponding digital signature of that part of signed data that described key is used to produce after present first message separator character and occurs with first message separator character, and

At in other digital signature that appears in the message after first message separator character each, carry out at least one predetermined action, minimize so that be notified to the number of computing equipment user's misleading address mismatch error.

2. method according to claim 1, also comprise step: if first message separator character appears at a part in the signed data, when the sender address does not match with the address that is associated with key, to the user notification address of computing equipment mismatch, the corresponding digital signature of that part of signed data that described key is used to produce after present first message separator character and occurs with first message separator character.

3. method according to claim 2 wherein, has only when the security strategy of the use of Management Calculation equipment allows, just the exercise notice step.

4. according to the described method of one of claim 1 to 3, wherein, at least one predetermined action of carrying out at the digital signature that appears at after first message separator character comprises: walk around the checking whether (550,580) sender address is complementary with the address that is associated with the key that is used to produce described digital signature.

5. according to the described method of one of claim 1 to 3, wherein, comprise at least one predetermined action that appears at the digital signature execution afterwards of first message separator character:

Whether checking sender address is complementary with the address that is associated with the key that is used to produce described digital signature; And

If the sender address does not match with the address that is associated with the key that is used to produce described digital signature, forbid to the user notification address of computing equipment mismatch.

6. method according to claim 5 wherein, has only when the security strategy of the use of Management Calculation equipment allows, and just forbids to user notification address mismatch.

7. according to the described method of one of claim 1 to 3, wherein, comprise at least one predetermined action that appears at the digital signature execution afterwards of first message separator character:

Whether checking sender address is complementary with the address that is associated with the key that is used to produce described digital signature; And

If the sender address does not match with the address that is associated with the key that is used to produce described digital signature, forbid showing at least a portion message to the user of computing equipment.

8. method according to claim 7 wherein, has only when the security strategy of the use of Management Calculation equipment allows, and just forbids showing at least a portion message to the user of computing equipment.

9. according to the described method of one of claim 1 to 3, wherein, comprise at least one predetermined action that appears at the digital signature execution afterwards of first message separator character:

Determine with the part specific address that is associated with the corresponding that part of signed data of described digital signature;

Whether the verification portion specific address is complementary with the address that is associated with the key that is used to produce described digital signature; And

As the fruit part specific address be used to produce as described in the address that is associated of the key of digital signature do not match, to the user notification address of computing equipment mismatch.

10. method according to claim 9 wherein, has only when the security strategy of the use of Management Calculation equipment allows, just the Notify Address mismatch.

11. method according to claim 9, wherein, at least one predetermined action of carrying out at the digital signature that appears at after first message separator character also comprises: as the fruit part specific address be used to produce as described in the address that is associated of the key of digital signature do not match, forbid showing at least a portion message to the user of computing equipment.

12. method according to claim 11 wherein, has only when the security strategy of the use of Management Calculation equipment allows, and just forbids showing at least a portion message to the user.

13. method according to claim 9, wherein, the step of determining section specific address comprises: from the text that appears at the message separator character that was right after before the corresponding with it that part of signed data of digital signature and described that part of message between the signed data, extract the sender's of received message last sender's address.

14. method according to claim 9, wherein, the step of determining section specific address comprises:

From the text that appears at the message separator character that was right after before the corresponding with it that part of signed data of digital signature and described that part of message between the signed data, extract the sender's of received message last sender's title; And

The described last sender's that retrieval is associated with title from address book address.

15., also comprise step according to the described method of one of claim 1 to 3: at each digital signature that appears in first message separator character message before,

Whether checking sender address is complementary with the address that is associated with the key that is used to produce described digital signature; And

If the sender address does not match with the address that is associated with the key that is used to produce described digital signature, to the user notification address of computing equipment mismatch.

16. method according to claim 15 wherein, has only when the security strategy of the use of Management Calculation equipment allows, just the exercise notice step.

17. according to the described method of one of claim 1 to 3, each digital signature at appearing in first message separator character message before also comprises step:

Whether checking sender address is complementary with the address that is associated with the key that is used to produce described digital signature; And

If the sender address does not match with the address that is associated with the key that is used to produce described digital signature, forbid showing at least a portion message to the user of computing equipment.

18. method according to claim 17 wherein, has only when the security strategy of the use of Management Calculation equipment allows, and just forbids showing at least a portion message to the user.

19., also comprise step:, come definite address that is associated with described key by the key holder information that retrieval from crypto key memory is associated with the key that is used to produce digital signature according to the described method of one of claim 1-3.

20. according to the described method of one of claim 1-3, wherein, at least one message separator character comprises one or more message separator characters of selecting from following group: straight line separated symbol, origination message separator, transmit message separator character, writing author separator, partly by beginning message header and predetermined separator subsequently in the first beginning part that message header limited signed data.

21. according to the described method of one of claim 1 to 3, wherein, use the PGP key that each of described at least a portion signed data is signed, and begin the header that begins to sign of corresponding PGP in message header and the message by PGP and limit described at least a portion each of signed data.

22., wherein, use S/MIME that each of described at least a portion signed data is signed according to the described method of one of claim 1 to 3.

23. according to the described method of one of claim 1-3, wherein, computing equipment is a mobile device.

24. the equipment of the signature information that a processing receives at the computing equipment place comprises:

Receive the device of message, described message comprises:

Header comprises the sender address at least;

At least a portion is signed data;

With the corresponding digital signature of each part of signed data; And

At least one message separator character, described message separator character have indicated at least one Geju City message to be merged in received message;

Determine device, be used for determining whether first message separator character appears at part signed data, sender in the message before wherein present first message separator character is expressed in the appearance of first message separator character in receiving message, and outside the described sender other people after first message separator character data from received message;

Final controlling element, do not appear at part signed data if be used for first message separator character, then at appearing at first message separator character each digital signature afterwards in the message, carry out at least one predetermined action, minimize so that be notified to the number of computing equipment user's misleading address mismatch error; And

If first message separator character appears at a part in the signed data,

Demo plant, be used to verify whether the sender address is complementary with the address that is associated with key, the corresponding digital signature of that part of signed data that described key is used to produce after present first message separator character and occurs with first message separator character, and

Carry out the device of at least one predetermined action at each that appears in the message in first message separator character other digital signature afterwards, minimize so that be notified to the number of computing equipment user's misleading address mismatch error.

Images