System and method for verifying digital signatures on certificates

(54) Title: SYSTEM AND METHOD FOR CHECKING DIGITAL SIGNATURES ON CERTIFICATES (30) Unionist Priority: 29/10/2004 ep 04105424.8 (71) Depositor (s): Research In Motion Limited (CA) (72) Inventor (s): Michael K. Brown, Michael S. Brown (74) Attorney: Orlando de Souza (57) Summary: SYSTEM AND METHOD FOR VERIFYING DIGITAL SIGNATURES ON CERTIFICATES. A system and method for verifying a digital signature on a certificate, which can be used in the processing of encrypted messages. In one version, when the digital signature is successfully verified in a signature verification operation, the public key used to verify that digital signature is stored in temporary memory. When a subsequent attempt to verify the digital signature is made, the public key to be used to verify the digital signature is compared to the key in provisional memory. If the keys match, the digital signature can be successfully verified without requiring a signature verification operation in which some data is decrypted using the public key.

330

VERISIGN • 300 CAUTO-SIGNED »

<img file="BRPI0505083A_D0001.tif" />

318 • »w J · t '·&gt;

1/50

<img file="BRPI0505083A_D0002.tif" />

The * *&gt; *

SYSTEM AND METHOD FOR CHECKING DIGITAL SIGNATURES IN

CERTIFICATES

The invention relates generally to the processing of messages, such as electronic correspondence messages and, more specifically, to a system and method for validating certificates used in the processing of coded messages.

HISTORY OF THE INVENTION

Electronic correspondence messages may be encoded using one of a number of known protocols. Some of these protocols, such as Secure Multiple Internet Mail Extensions (S / MIME), for example, rely on public and private encryption keys to provide confidentiality and integrity, and on a Public Key Infrastructure (PKI - Public Key Infrastructure) to communicate information that provides authentication and authorization. Data encrypted using a private key from a public key / private key pair can only be decrypted using the corresponding public key from the pair, and vice versa. The authenticity of the public keys used in encrypting messages is validated using certificates. In particular, if the user of a computing device wants to encrypt a message before the message is sent to a particular individual, the user will require a certificate for that individual. This certificate will typically comprise the individual's public key, as well as other information related to identification.

2/50

Certificates are digital documents that are typically issued by certification authorities. To trust a private public key, the public key typically needs to be issued by a certification authority that is also trusted, or by an entity associated with the trusted certification authority. The relationship between the trusted certification authority and an issued public key can be represented by a series of related certificates, also referred to as a certificate chain. The certificate chain can be followed to determine the validity of a certificate.

Typically, the certification authority will digitally sign each certificate it issues, to certify that a specific public key belongs to the alleged owner as indicated in the respective certificate. When building certificate chains, the digital signatures on the chain's certificates often need to be verified. Verifying a digital signature on a certificate is a process that requires the public key of the certification authority that issued the certificate.

SUMMARY OF THE INVENTION

The verification process can be costly and time consuming (for example, in terms of using computing resources), particularly when checks are performed on smaller devices, such as mobile devices. When multiple certificates are processed on the user's computing device, the same digital signature may be submitted for verification more than once. Versions of the invention are

3/50 generally aimed at a system and method that facilitates more efficient verification of digital signatures on certificates by storing certain information used in signature verification operations for reuse.

In a broad aspect of the invention, a method of verifying a digital signature on a certificate on a computing device is provided, the method comprising the steps of performing a first operation of verifying the first signature on the digital signature using a first public key associated with the certificate issuer; determine whether the digital signature is successfully verified in the first verification operation of the first signature; store the first public key in a memory store; receive a request to perform a second signature verification operation on the digital signature using a second public key associated with a certificate issuer; compare the second public key with the first public key stored in the memory store to determine whether the first and second public keys match; and indicate the successful verification of the digital signature in response to the request if the digital signature was successfully verified in the first signature verification operation and if a match is determined in the compare step, where the second signature verification operation does not need to be carried out.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the versions of the invention, and to show more clearly how it can be carried out, reference will now be made, by way of example,

4/50 to accompanying drawings, in which:

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

Figure 2 is a block diagram of a component of the communication subsystem of the mobile device of Figure 1.

Figure 3 is a block diagram of a wireless network node.

Figure 4 is a block diagram that illustrates the components of a host system in an example configuration.

Figure 5 is a block diagram showing an example of a certificate chain.

Figure 6 is a block diagram that illustrates the components of an example of a coded message.

Figure 7A is a block diagram showing two example certificate chains.

Figure 7B is a block diagram showing cross certificates that link the certificate chains in Figure 7A.

Figure 8A is a flow chart that illustrates the steps in a method of verifying the digital signature on a certificate in a version of the invention. AND

Figure 8B is a flow chart that illustrates the steps in a method of verifying the digital signature on a certificate in another version of the invention.

DETAILED DESCRIPTION OF THE VERSIONS OF THE INVENTION

Some versions of the invention make use of a mobile station. The mobile station is a bilateral communication device with advanced data communication capability and having the ability to communicate with other communication systems.

5/50 computer, and is also referred to here generically as a mobile device. The mobile device may also include the ability for voice communication. Depending on the functionality provided by the mobile device, it may be referred to as a data messaging device, a bilateral radio call device, a cell phone with data messaging capability, a wireless Internet device, or a communication device (with or without telephony capability). The mobile device communicates with other devices through a network of transceiver stations.

To assist the reader in understanding the structure of a mobile device and how it communicates with other devices, reference is made to Figures 1 to 3.

First, with reference to Figure 1, a block diagram of a mobile device in an example implementation is shown generically as 100. The mobile device 100 comprises a number of components, the controller component being the microprocessor 102. The microprocessor 102 controls the operation general of the mobile device 100. Communication functions, including data and voice communication, are carried out through the communication subsystem 104. 0 communication subsystem 104 receives messages and sends messages to and from a wireless network 200. In this example implementation of mobile device 100, communication subsystem 104 is configured according to the standards of the Global System for Mobile Communication (GSM) Mobile Communication) and General Packet Radio Services (GPRS - General Packet Radio Services). The GSM / GPRS wireless network is used

6/50 worldwide and it is expected that its standards will eventually be surpassed by Enhanced Data GSM Environment (EDGE Enhanced Data Environment GSM) and Universal Mobile Telecommunications Service (UMTS - Universal Mobile Telecommunication Service). New standards are still being defined, but it is believed that they will have similarities with the network behavior described here, and will also be understood by people skilled in the art that the invention intends to use any other suitable standards that will be developed in the future. 0 wireless link that connects communication subsystem 104 with network 200 represents one or more different Radio Frequency (RF) channels, operating according to defined protocols specified for GSM / GPRS communication. With newer network protocols, these channels are capable of supporting both circuit-switched voice communication and packet-switched data communication.

Although the wireless network associated with the mobile device 100 is a GSM / GPRS wireless network in an example implementation of the mobile device 100, other wireless networks may also be associated with the mobile device 100 in variant implementations. The different types of wireless networks that may be employed, for example, include data-centered wireless networks, voice-centered wireless networks, and dual-mode networks that can support both voice and data communication from the same stations. physical basis. Combined dual mode networks include, but are not limited to, Code Division Multiple Access (CDMA - Code Division Multiple Access) or CDMA2000 networks, GSM / GPRS networks (as mentioned above), and future networks

7/50 third generation (3G) such as EDGE and UMTS. Some older examples of data-centric 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 systems (TDMA - Time Division Multiple Access).

Microprocessor 102 also interacts with additional subsystems such as Random Access Memory (RAM) 106, flash memory 108, display device 110, auxiliary input / output (I / O) subsystem 112, serial port 114, keyboard 116, speaker 118, microphone 120, short-range communication 122 and other devices 124.

Some of the subsystems of the mobile device 100 perform functions related to communication, while other subsystems may provide resident or device functions. For example, the display device 110 and the keyboard 116 can be used both for functions related to communication, such as entering a text message for transmission over network 200, as functions resident in the device, such as the calculator or the list task. 0 Operating system software used by microprocessor 102 is typically stored in a persistent store such as flash memory 108, which may alternatively be a read-only memory (ROM) or a similar storage element (not shown). Those skilled in the art will appreciate that the operating system, device-specific applications,

8/50 or parts thereof, may be temporarily loaded into a volatile warehouse such as RAM 106.

mobile device 100 will be able to send and receive communication signals over network 200 after registration on the required network or activation procedures have been completed. Network access is associated with the subscriber or user of a mobile device 100. To identify the subscriber, the mobile device 100 requires a Subscriber Identity Module card or 'SIM' card 126 to be inserted into a SIM 128 interface to communicate with the net. 0 SIM 126 is a type of conventional 'smart card' used to identify the subscriber of the mobile device 100 and to personalize the mobile device 100, among other things. Without SIM 126, mobile device 100 is not fully operational for communication with network 200. By inserting SIM 126 within the SIM 128 interface, the subscriber can access all subscribed services. Services could include: Web scanning and messages such as electronic correspondence, voice correspondence, Short Message Service (SMS), and Multimedia Messaging Services (MMS). More advanced services may include: point of sale, field service and automation of the sales team. SIM 12 6 includes a processor and memory for storing information. Once SIM 126 is inserted in the SIM 128 interface, it is coupled to microprocessor 102. To identify the subscriber, SIM 126 contains some user parameters such as an International Mobile Subscriber Identity (IMSI). An advantage of using SIM 126 is that the subscriber is not necessarily limited by any

9/50 unitary physical mobile device. SIM 126 may store additional subscriber information for the mobile device, including date book (or calendar) information and recent call information.

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 coupled to a regulator (not shown), which assists battery 130 in providing V + power to the mobile device 100. Although the current technology makes use of a battery, future technologies such as micro fuel cells could supply the power to the mobile device 100.

The microprocessor 102, in addition to its operating system functions, allows the execution of software applications on the mobile device 100. A set of applications that control the basic operations of the device, including data and voice communication applications, will normally be installed on the mobile device 100 during manufacture. Another application that can be loaded onto the mobile device 100 would be a personal information manager (PIM). PIM has functionality to organize and manage data items of interest to the subscriber, such as, but not limited to, electronic correspondence, calendar events, voice correspondence, appointments, and task items. The PIM application has the ability to send and receive data items over the wireless network 200. PIM data items can be carefully integrated, synchronized, and updated over the wireless network 2 00

10/50 with the corresponding mobile device subscriber data items stored and / or associated with a primary computer system. This functionality creates a host computer mirrored on the mobile device 100 with respect to these items. This can be particularly advantageous when the host computer system is the computer system of the subscriber's office of the mobile device.

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

Serial port 114 allows the subscriber to set preferences via an external device or software application and extends the capabilities of the mobile device 100 by providing information or software downloads to the mobile device 100 other than via a wireless communication network. The alternative low-way, for example, could be used to load an encryption key on the mobile device 100 through a direct connection, and thus reliable and trusted, to provide secure device communication.

11/50

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

In use, the signal received as a text message, an electronic correspondence message, or the download of a web page will be processed by the communication subsystem 104 and entered into the microprocessor 102. The microprocessor 102 will then process the received signal for output at the device display 110 or alternatively to auxiliary I / O subsystem 112. 0 The subscriber may also compose data items, such as electronic correspondence messages, for example, using the keyboard 116 in conjunction with the display device 110 and possibly the auxiliary I / O subsystem 112. The auxiliary subsystem 112 may include devices such as: a screen touch screen, a mouse, a rotating sphere, an infrared fingerprint detector, or a rotating wheel with the ability to press a dynamic button. Keyboard 116 is an alphanumeric keyboard and / or a telephone-type keyboard. The composite item can be transmitted over the network 200 through the communication subsystem 104.

For voice communication, the general operation of the mobile device 100 is substantially similar, except that the received signals would be output to the speaker

12/50

118, and the signals for transmission would be generated by microphone 120. Alternative audio or voice I / O subsystems, such as the voice message recording subsystem, can also be implemented in the mobile device 100. Although the signal output of voice or audio is carried out essentially through loudspeaker 118, the display device 110 may also be used to provide additional information such as the identity of the party

<td>that calls, the duration</td><td>in</td><td>a call</td><td>in</td><td>voice, or other</td>

<td>related information</td><td>with</td><td>the call from</td><td>voice.</td><td></td>

<td colspan="2">With reference now</td><td>The figure</td><td> 2,</td><td>is shown a</td>

<td>block diagram</td><td>of</td><td>component</td><td>of</td><td>subsystem</td>

communication 104 of Figure 1. The communication subsystem

104 comprises a receiver 150, a transmitter 152, one or more built-in or internal antenna elements 154, 156, local oscillators (LOs) 158, and a processing module such as the Digital Signal Processor (DSP) 160.

particular design of the communication subsystem 104 is dependent on the network 200 on which the mobile device 100 intends to operate. Thus, it should be understood that the project illustrated in Figure 2 serves only as an example. The signals received by the antenna 154 through the network 200 are input to the receiver 150, which can perform common receiver functions such as signal amplification, downward frequency conversion, filtering, channel selection, and analog-to-digital (A / D) conversion. . The A / D conversion of a received signal allows more complex communication functions such as demodulation and decoding to be carried out on the DSP 160. Similarly, the signals to be transmitted are processed, including modulation and

13/50 coding, by DSP 160. These signals processed by DSP are input to transmitter 152 for digital-analog conversion (D / A), upward frequency conversion, filtering, amplification and transmission over network 200 through antenna 156. 0 DSP 160 not only processes communication signals, but also provides control of the receiver and transmitter. For example, the gains applied to the communication signal at receiver 150 and transmitter 152 can be adaptively controlled through automatic gain control algorithms implemented in the

DSP 160.

The wireless link between the mobile device 100 and the network 200 may contain one or more different channels, typically different RF channels, and associated protocols used between the mobile device 100 and the network 200. An RF channel is a limited resource that needs to be conserved, typically due to limits on the general bandwidth and limited battery power of the mobile device 100.

When the mobile device 100 is fully operational, transmitter 152 is typically switched on or turned on only when it is sending to network 200 and is otherwise turned off to conserve resources. Similarly, receiver 150 is periodically turned off to conserve energy until it is needed to receive signals or information (if any) for designated periods of time.

Referring now to Figure 3, a block diagram of a wireless network node is shown as 202. In practice, network 200 comprises one or more nodes 202. The mobile device 100 communicates with node 202 within the network.

14/50 wireless network 200. In the example implementation of Figure 3, node 2 02 is configured according to the technologies of the General Packet Radio Service (GPRS - General Packet Radio Service) and Global Systems for Mobile Communication (GSM - Global Systems for Mobile Communication). Node 202 includes a base station controller (BSC) 204 with an associated tower station 206, a Packet Control Unit (PCU) 208 added for GPRS support in GSM, a Mobile Switching Center (MSC) 210, a Residential Location Registration (HLR) 212,. a Visitor Location Record (VLR) 214, a GPRS Server Support Node (SGSN) 216, a GPRS Portal Support Node (GGSN) 218, and a Dynamic Server Configuration Protocol (DHCP) 220. This component list is not intended to be a comprehensive list of the components of each node 202 within a GSM / GPRS network, but rather a list of components that are commonly used in communication over the network 200.

In a GSM network, the MSC 210 is coupled to BSC 2 04 and to a landline network, such as the Public Switched Telephone Network (PSTN) 222 to satisfy circuit switching requirements. The connection via PCU 208, SGSN 216 and GGSN 218 to the private or public network (Internet) 224 (also commonly referred to here as a shared network infrastructure) represents the data path for mobile devices capable of GPRS. In an extended GSM network with GPRS capabilities, the BSC 204 also contains a Packet Control Unit (PCU) 2.08 that connects to the SGSN 216 to control segmentation, radio channel allocation, and to satisfy switching requirements. package. To track location and availability

15/50 of the mobile device for both circuit switched and packet switched management, HLR 212 is shared between MSC 210 and SGSN 216. Access to VLR 214 is controlled by MSC 210.

Station 206 is a fixed transceiver station. Station 206 and BSC 204 together form the fixed transceiver equipment. Fixed transceiver equipment provides wireless network coverage for a particular coverage area commonly referred to as a 'cell'. The fixed transceiver equipment transmits communication signals and receives communication signals from mobile devices within its cell through station 206. 0 Fixed transceiver equipment normally performs functions such as modulation and possibly coding and / or encryption of signals to be transmitted to the mobile device according to particular communication protocols and parameters, usually predetermined, under the control of its controller. The fixed transceiver equipment demodulates and possibly decodes and decrypts, similarly, if necessary, any communication signals received from the mobile device 100 within its cell. Communication protocols and parameters may vary between different nodes. For example, a node may employ a different modulation scheme and operate at different frequencies than other nodes.

For all mobile devices 100 registered with a specific network, permanent configuration data, such as the user profile, is stored in the HLR 212. The HLR 212 also contains location information for each registered mobile device and can be consulted for

16/50 determine the current location of a mobile device. The MSC 210 is responsible for a group of location areas and stores data from mobile devices currently in its area of ​​responsibility in VLR 214. In addition, VLR 214 also contains information about mobile devices that are visiting other networks. The information on the VLR 214 includes part of the permanent mobile device data transmitted from the HLR 212 to the VLR 214 for faster access. By moving additional information from a remote HLR node 212 to VLR 214, the amount of traffic between these nodes can be reduced so that voice and data services can be delivered with faster response times and at the same time requiring less use of computing resources.

SGSN 216 and GGSN 218 are elements added for GPRS support, namely, packet-switched data support, within GSM. SGSN 216 and MSC 210 have similar responsibilities within the wireless network 200 in keeping track of the location of each mobile device 100. SGSN 216 also performs security and access control functions for data traffic on network 200. GGSN 218 provides inter-network connections to external packet-switched networks and connects to one or more SGSNs 216 through an Internet Protocol (IP) background network operated within network 200. During normal operation, a given mobile device 100 must make a 'GPRS Attach' to acquire an IP address and access dedicated services. This requirement is not present in circuit-switched voice channels as Integrated Services Digital NetWork addresses (ISDN) are used

17/50 to route incoming and outgoing calls. Currently, all networks capable of GPRS use dynamically assigned private IP addresses, thus requiring a DHCP 22 0 server connected to the GGSN 218. There are many mechanisms for dynamic IP assignment, including the use of a combination of a Remote Authentication Dial-In server User Service (RADIUS - Remote Authentication Dialing User Service) and DHCP server. Once the GRPS Attach is completed, a logical connection is established from a mobile device 100, via PCU 208, and from SGSN 216 to an Access Point Node (APN - Access Point Node) within GGSN 218. The APN represents the logical end of an IP tunnel that can access compatible direct Internet services or private network connections. The APN also represents a security mechanism for network 200, as each mobile device 100 needs to be assigned to one or more APNs and mobile devices 100 cannot exchange data without first performing a GPRS Attach to an APN that it has been authorized to use. . The APN can be considered to be similar to an Internet domain name like 'myconnection.wireless.com'.

Once GRPS Attach is finished, a tunnel is created and all traffic is exchanged within standard IP packets using any protocol that can be supported in the IP packets. This includes tunneling methods such as IP over IP as in the case of some IPSecurity (IPSec) connections used with Virtual Private Networks (VPN). These tunnels are also referred to as Packet Data Protocol Contexts (PDP) and there are a limited number of them available on the 200 network. To maximize the use of PDP Contexts, the

18/50 network 2 00 will process an idle timer for each PDP Context to determine if there is a lack of activity. When the mobile device 100 is not using its PDP Context, the PDP Context can be deallocated and the IP address returned to the IP address pool managed by the DHCP server 220.

Referring now to Figure 4, a block diagram is shown that illustrates components of a host system in an example configuration. The host system 250 will typically be a corporate office or other local area network (LAN), but may instead be a home office computer or some other private system, for example, in variant implementations. In this example shown in Figure 4, main system 250 is represented as a LAN of an organization to which the user of the mobile device 100 belongs.

LAN 250 comprises a number of network components connected to each other via LAN 260 connections. For example, user desktop computer 2 62a with a companion cradle 264 for user mobile device 100 is located on LAN 250. The cradle 264 for mobile device 100 can be coupled to computer 2 62a by a serial connection or a Universal Serial Bus (USB), for example. Other computers of user 262b are also located on LAN 250, and each may or may not be equipped with a companion cradle 264 for a mobile device. Cradle 264 facilitates the loading of information (for example, PIM data, private symmetric encryption keys to facilitate secure communication between the

19/50 mobile device 100 and LAN 250) from user computer 262a to mobile device 100, and may be particularly useful for wholesale information updates, often carried out at startup of mobile device 100 for use. The information downloaded to the mobile device 100 may include certificates used in the exchange of messages. It will be understood by persons skilled in the art that the computers of the user 262a, 262b will also typically be connected to other peripheral devices not shown explicitly in Figure 4.

Furthermore, only a subset of LAN 250 network components is shown in Figure 4 for ease of exposure, and it will be understood by persons skilled in the art that the LAN 250 will comprise additional components not shown explicitly in Figure 4, for this example configuration. More generally, LAN 250 may represent a smaller part of a larger network (not shown) of the organization, and may comprise different components and / or be arranged in different topologies than that shown in the example in Figure 4.

In this example, mobile device 100 communicates with LAN 250 through node 202 of wireless network 200 and a 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 LAN 250 computing devices may operate behind a fire wall or a 266 replacement server.

In a variant implementation, the LAN 250 comprises a

20/50 wireless VPN router (not shown) to facilitate data exchange between LAN 250 and mobile device 100. The concept of a wireless VPN router is new in the wireless industry and implies that the VPN connection can be established directly via a wireless network specific to the mobile device 100. The possibility of using a wireless VPN router was only recently made available and could be used when the new Internet Protocol (IP) Version 6 (IPV6) arrived on wireless networks based on IP. This new protocol will provide enough IP addresses to dedicate an IP address to each mobile device, making it possible to push information to the mobile device at any time. An advantage of using a wireless VPN router is that it could be an off-the-shelf VPN component, not requiring a separate wireless portal and separate wireless infrastructure to be used. The VPN connection would preferably be a Transmission Control Protocol (TCP) / IP or User Datagram Protocol (UDP) / IP connection to deliver messages directly to the mobile device 100 in this variant implementation.

Messages addressed to the mobile device user 100 are initially received by a LAN 250 message server 268. These messages may originate from any one of a number of sources. For example, a message may have been sent by a sender from a computer 2 62b within LAN 250, from a different mobile device (not shown) connected to wireless network 200 or a different wireless network, or from a device computing device or another device capable of sending

21/50 messages, through the shared network infrastructure 224, and possibly through an application service provider (ASP) or Internet service provider (ISP), for example.

Message server 268 typically acts as the primary interface for exchanging messages, particularly e-mail messages, within the organization and through the shared network infrastructure 224. Each user in the organization that has been established to send and receive messages is typically associated with a user account managed by the 268 messaging server. An example of a 268 messaging server is a Microsoft Exchange ™ Server. In some implementations, LAN 250 may comprise multiple message servers 268. Message server 268 may also be adapted to provide additional functions in addition to message management, including managing data associated with calendars and task lists, for example.

When messages are received by message server 268, they are typically stored in a message store (not shown explicitly), from which messages can subsequently be retrieved and delivered to users. For example, an e-mail client application that operates on the 262a user's computer, may request the e-mail messages associated with the user's account stored on the 268 message server. These messages would then typically be retrieved from message server 268 and stored locally on computer 262a.

22/50

When operating the mobile device 100, the user may want to have the electronic mail messages retrieved for delivery to the handset. An electronic mail client application operating on the mobile device 100 may also request messages associated with the user account of the message server 268. 0 e-mail client may be configured (either by the user or by an administrator, possibly in accordance with the organization's information technology (IT) policy) to make this request under the user's direction, within a predefined time interval or when a pre-defined event occurs. In some implementations, mobile device 100 is assigned its own e-mail address, and messages addressed specifically to mobile device 100 are automatically redirected to mobile device 100 as they are received by the message server

268 .

To facilitate wireless communication of messages and message-related data between mobile device 100 and components of LAN 250, a number of wireless communication support components 270 may be provided. In this example implementation, wireless communication support components 270 comprise a message management server 272, for example. 0 message management server 272 is used to specifically provide support for managing messages, such as electronic correspondence messages, which must be handled by mobile devices. Generally, although

23/50 messages are still stored on message server 268, message management server 272 can be used to control when, if and how messages should be sent to mobile device 100. Message management server 272 also facilitates the handling of messages composed on the mobile device 100, which are sent to the message server 268 for subsequent delivery.

For example, message management server 272 may: monitor the user's mailbox (for example, the message store associated with the user's account on message server 268) for new e-mail messages; apply user-defined filters to new messages to determine whether and how messages will be passed on to user 100's mobile device; compress and encrypt new messages (for example, using an encryption technique such as the Data Encryption Standard (DES) or Triple DES) and push them to the mobile device 100 through shared network infrastructure 224 and wireless network 200 ; and receive composite messages on the mobile device 100 (for example, encrypted using Triple DES), decrypt and decompress the composite messages, reformat the composite messages if desired so that they appear to have originated from the user's computer 262a, and re-route the messages composed for message server 268 for delivery.

Certain properties or restrictions associated with messages that are to be sent to and / or received by the mobile device 100 can be defined (for example,

24/50 (by an administrator in accordance with IT policy) and enforced by the message management server 272. These may include whether mobile device 100 can receive encrypted and / or signed messages, minimum encryption key sizes , whether outgoing messages need to be encrypted and / or signed, and whether copies of all secure messages sent from the mobile device 100 must be sent to a predefined copy address, for example.

message management server 272 may also be adapted to provide other control functions, such as just pushing certain message information or predefined parts (e.g., 'blocks') of a message stored on message server 268 to 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 part of a message to the mobile device 100, with the part being one size predefined (for example, 2 KB). 0 The user can then request more of the message, to be delivered in blocks of similar dimensions by the message management server 272 to the mobile device 100, possibly up to a maximum predefined message dimension.

Thus, the message management server 272 facilitates better control over the type of data and the amount of data that is communicated to the mobile device 100, and can help to minimize the potential wear on bandwidth or other resources.

25/50

It will be understood by persons skilled in the art that the message management server 272 does not need to be implemented on a separate physical server on LAN 250 or another network. For example, some or all of the functions associated with message management server 272 may be integrated with message server 268, or some other server on LAN 250 particularly in variant implementations where a large number of mobile devices need to be supported.

Versions of the invention generally relate to certificates used in the processing of encrypted messages, such as electronic correspondence messages that are encrypted and / or signed. While the Simple Mail Transfer Protocol (SMTP) RFC822 headers and parts of the Multipurpose Internet Correspondence Extensions (MIME) body can be used to define the format of a typical electronic correspondence message that does not require encryption, Secure / MIME (S / MIME), a version of the MIME protocol, can be used to communicate encrypted messages (that is, in secure messaging applications). S / MIME allows end-to-end authentication and confidentiality, and protects data integrity and privacy from when the message originator sends the message until it is decoded and read by the recipient of the message. Other known standards and protocols may be employed to facilitate secure message communication, such as Pretty Good Privacy ™ (PGP), OpenPGP, and others known in the art.

Secure message protocols such as S / MIME depend on

26/50 public and private encryption keys to provide confidentiality and integrity, and on a Public Key Infrastructure (PKI) to communicate information that provides authentication and authorization. Data encrypted using a private key from a private key / public key pair can be decrypted using the corresponding public key from the pair, and vice versa. Private key information is never made public, while public key information is shared.

For example, if the sender wants to send a message to a recipient in encrypted form, the recipient's public key is used to encrypt the message, which can then be decrypted only using the recipient's private key. Alternatively, in some encryption techniques, a one-time session key is generated and used to encrypt the body of a message, typically with a symmetric encryption technique (for example, Triple DES). The session key is then encrypted using the recipient's public key (for example, with a public key encryption algorithm like RSA), which can then be decrypted using only the recipient's private key. The decrypted session key can then be used to decrypt the message body. The message title can be used to specify the particular encryption scheme that needs to be used to decrypt the message. Other encryption techniques based on public key cryptography may be used in variant implementations. However, in each

In such cases, only the recipient's private key can be used to facilitate the decryption of the message, and in this way, the confidentiality of the messages can be maintained.

As another example, the sender can sign a message using a digital signature. The digital signature is a summary of the message (for example, a message hash) encoded using the sender's private key, which can then be appended to the outgoing message. To verify the digital signature of the message when received, the recipient uses the same technique as the sender (for example, using the same standard hash algorithm) to obtain a summary of the received message. 0 The recipient also uses the sender's public key to decrypt the digital signature, to obtain what should be a matched summary for the message received. If the summaries of the received message do not match, this suggests that either the content of the message was modified during transport and / or the message did not originate from the sender whose public key was used for verification. Digital signature algorithms are designed in such a way that only someone with knowledge of the sender's private key should be able to encrypt the signature that the recipient will correctly decrypt using the sender's public key. Therefore, by verifying the digital signature in this way, the sender's authentication and message integrity can be maintained.

An encrypted message can be encrypted, signed, or both encrypted and signed. The authentication of public keys used in these

28/50 operations are validated using certificates. The certificate is a digital document issued by a certificate authority (CA). Certificates are used to authenticate the association between users and their public keys, and essentially, it provides a level of confidence in the authenticity of users' public keys. Certificates contain information about the certificate holder, with the content of the certificate typically formatted according to an accepted standard (for example, X.509).

Consider Figure 5, where an exemplary certificate chain is shown. The 310 certificate issued to 'John Smith' is an example of a certificate issued to an individual, which may be referred to as a final entity certificate. The final entity certificate 310 typically identifies the certificate holder 312 (i.e., John Smith in this example) and the certificate issuer 314, and includes a digital signature of the issuer 316 and the public key of the certificate holder 318. 0 Certificate 310 will also typically include other information and attributes that identify the certificate holder (for example, e-mail address, organization name, unitary name of the organization, location, etc.). When the individual composes a message to be sent to a recipient, it is customary to include that individual's certificate 300 with the message.

For a public key to be trusted, its issuing organization must be trusted. The relationship between a trusted CA and the user's public key can be represented by a series of related certificates,

29/50 also referred to as a certificate chain. The certificate chain can be followed to determine the validity of a certificate.

For example, in the example 300 certificate chain shown in Figure 5, the recipient of a message apparently sent by John Smith may wish to check the trust status of the certificate 310 affixed to the received message. To check the trust status of certificate 310 on the recipient's computing device (ie, computer 262a in Figure 4), for example, certificate 320 from issuer ABC is obtained, and used to verify that certificate 310 was, from fact, signed by the ABC issuer. Certificate 320 may already be stored in a certificate store on the computer device, or it may need to be retrieved from a certificate source (for example, LDAP server 284 in Figure 4 or some other public or private LDAP server). If certificate 320 is already stored on the recipient's computer device and the certificate has been designated as trusted by the recipient, then certificate 310 is considered to be trusted because it chains up to a stored trusted certificate.

However, in the example shown in Figure 5, certificate 330 is also required to verify the trust status of certificate 310. Certificate 330 is self-signed, and is referred to as the 'root certificate'. Thus, certificate 320 may be referred to as an 'intermediate certificate' in the certificate chain 300; any chain of certificates given up to the particular root certificate, assuming that a chain up to the root certificate

30/50 can be determined for a final entity certificate, it can contain zero, one, or multiple intermediate certificates. If certificate 330 is a root certificate issued by a trusted source (from a major certification authority such as Verisign or Entrust, for example) then certificate 310 can be considered to be trusted as it links up to a trusted certificate. The implication is that both the sender and the recipient of the message trust the source of the root certificate 330. If the certificate cannot be chained to a trusted certificate, the certificate can be considered to be 'untrusted'.

Certificate servers store information about certificates and lists that identify certificates that have been revoked. These certificate servers can be accessed to obtain certificates and to verify the authenticity of the certificate and its revocation status. For example, a Lightweight Directory Access Protocol (LDAP) server can be used to obtain certificates, and an Online Certificate Status Protocol (OCSP) server can be used to check the status revocation of the certificate.

Standard electronic mail security protocols typically facilitate secure message transmission between non-mobile computing devices (for example, computers 262a, 262b in Figure 4, remote desktop devices). Referring again to Figure 4, so that signed messages are sent

31/50 for those senders, the mobile device 100 is adapted to store certificates and associated public keys from other individuals. Certificates stored on user 262a's computer will typically be downloaded from computer 262a to mobile device 100 via cradle 264, for example.

Certificates stored on computer 262a and downloaded to mobile device 100 are not limited to certificates associated with individuals, but may also include certificates issued to CAs, for example. Certain certificates stored on computer 262a and / or mobile device 100 can also be explicitly designated as 'trusted' by the user. Thus, when a certificate is received by the user on mobile device 100, it can be verified on mobile device 100 by matching the certificate to one stored on device 100 and designated as trusted, or otherwise determined to be chained to a trusted certificate.

The mobile device 100 may also be adapted to store the private key of the public key / 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 sent to the user. encrypted with the user's public key. The private key may be downloaded to the mobile device 100 from the user's computer 262a via cradle 264, for example. The private key is preferably exchanged between computer 262a and mobile device 100 so that the user can share an identity and a method for accessing

32/50 messages.

User computers 262a, 262b can obtain certificates from a number of sources, for storage on computers 262a, 262b and / or on mobile devices (for example, mobile device 100). These certificate sources may be private (for example, dedicated for use within an organization) or public, may reside locally or remotely, and may be accessed from within the organization's private network or via the Internet, for example. In the example shown in Figure 4, multiple PKI 280 servers associated with the organization reside on LAN 250. PKI 280 servers include a CA 282 server for issuing certificates, an LDAP 284 server used to fetch and download certificates (for example, for individuals within organization), and an OCSP 286 server used to check certificate revocation status.

Certificates can be retrieved from the LDAP server 284 by the user's computer 262a, for example, to be downloaded to the mobile device 100 through cradle 264. However, in a variant implementation, the LDAP server 284 can be accessed directly (that is, 'over the air' in this context) by the mobile device 100, and the mobile device 100 will be able to fetch and retrieve individual certificates via a mobile data server 288. Similarly, the mobile data server 288 may be adapted to allow the mobile device 100 to directly query the OCSP server to check the revocation status of the certificates.

In variant implementations, only PKI servers

33/50 selected 280 can be made accessible to mobile devices (for example, allowing certificates to be downloaded only from the user's computer 262a, 262b, while allowing the status of revocation of certificates to be verified from the mobile device 100).

In variant implementations, certain PKI 280 servers may be made accessible only to registered mobile devices for private users, as specified by an IT administrator, possibly in accordance with an IT policy, for example.

Other certificate sources (not shown) may include a Windows certificate store, another secure certificate store, on or off the LAN 250, and smart cards, for example.

Referring now to Figure 6, a block diagram is generally shown as 350 illustrating the components of an example of an encrypted message, as it may be received by a message server (for example, the message server 268 of Figure 4). The encrypted message 350 typically includes one or more of the following: a header part 352, an encrypted body part 354, optionally one or more encrypted displays 356, one or more encrypted session keys 358, and signature and related information 360 signature. For example, header part 352 typically includes addressing information such as' From ',' To 'and' CC addresses¹, and may also include message length indicators, and identifiers of the sender's signature and encryption scheme, for example. The content of the effective message usually includes a message body or

34/50 data part 3 54 and possibly one or more attachments 3 56, which can be encrypted by the sender using a session key. If the session key was used, it is typically encrypted for each intended recipient using the respective public key for each recipient, and included in the message at 358. If the message was signed, a signature and information related to the 360 ​​signature is also included. This may include the sender's certificate, for example.

The format for an encoded message as shown in Figure 6 is provided by way of example only, and those skilled in the art will understand that encoded messages may exist in other formats. For example, depending on the specific message scheme used, the components of an encoded message may appear in a different order than shown in Figure 6, and an encoded message may include at least additional or different components, which may depend on whether the encoded message is encrypted, signed, or both.

Versions of the invention are generally aimed at a system and method that facilitates more efficient verification of digital signatures on certificates by storing certain information used in signature verification operations for reuse. When building certificate chains (as discussed in the example in Figure 5), digital signatures on certificates often need to be verified. When multiple certificates are processed on the user's computing device, the same digital signature is often subjected to

35/50 verification more than once. This can be particularly prevalent when chains of certificates are formed containing cross-certificates. Cross certificates are discussed in more detail below with reference to Figure 7B.

Referring first to Figure 7A, a block diagram is shown showing two example certificate chains. The two example certificate chains are generally illustrated in 400a and 400b. It will be understood by persons skilled in the art that certificate chains 400a and 400b are provided as examples. In particular, the certificate chain may comprise a smaller or greater number of certificates than represented in the examples shown.

Many organizations establish their own CAs, which issue certificates specifically for individuals within their own organizations. Final entity certificates issued to individuals within a particular organization do not need to be issued by a single CA associated with the organization. A final entity certificate is often issued by one of a number of subordinate or intermediary CAs within a hierarchy of CAs headed by a root CA for the organization. This root CA may provide a self-signed root certificate to be used as a 'trust anchor' - the starting point for validating certificates issued within the organization.

The chain of certificates 400a represents an exemplary chain of certificates formed to validate the certificate 402a issued to the 'user', an individual within the

36/50 'ABC' organization. The 402a certificate chains up to the 404a self-signed root certificate, issued by the root CA to an organization's intermediate CA. Certificates issued within the ABC organization can be fetched and retrieved from an LDAP server maintained by the organization (for example, LDAP server 284 in Figure 4), for example.

Similarly, certificate chain 400b represents an exemplary chain of certificates formed to validate certificate 402b issued to 'user2', an individual within a different organization 'XYZ' and trusted by user2, through an intermediate certificate 406b. Certificates issued within the XYZ organization can be fetched and retrieved from an LDAP server maintained by the XYZ organization, for example.

Consider the exemplary situation in which the user of organization ABC receives a coded message from user2 of organization XYZ. Even if user2 has attached his 402b certificate to the message, the user will not be able to verify the trust status of user2's 402b certificate with just that certificate (assuming that user no longer stored user2's 402b certificate and marked it as trusted) . If the user does not trust the certificates from the XYZ organization, then the user2 certificate 402b cannot be validated as he does not link to a trusted certificate.

To facilitate secure communication between users from different organizations, it may be desirable to allow certificates to be used and trusted between organizations. An authentication method known as

37/50 cross-certification may be carried out between two organizations, where the CA of one organization certifies the CA of the other organization.

The term cross-certification can be used to refer generically to two operations. The first operation, which is typically performed relatively infrequently, relates to the establishment of a trust relationship between two CAs (for example, through organizations or within the same organization), by signing a CA public key by another CA in a certificate referred to as a cross certificate. The second operation, which is typically performed relatively frequently, involves verifying the user's certificate by forming a chain of certificates that includes at least one of these cross certificates.

Referring now to Figure 7B, a block diagram is shown showing examples of cross certificates linking two exemplary certificate chains. The cross certificate 410 issued by the root CA of organization ABC by the root CA of organization XYZ is shown in this example. Similarly, the cross certificate 412 issued to the root CA of the organization XYZ by the root CA of the organization ABC is shown.

example in Figure 7B illustrates mutual cross-certification between two root CAs. However, other methods of cross-certification are possible in variant implementations. For example, cross certificates can be issued by a subordinate CA in one organization to the root CA of another organization. As another example, a first organization's CA may issue a certificate

38/50 crossed to the CA of a second organization, even if the cross certificate is not issued back to the first organization by the second organization.

In addition, the use of certificates across organizations may be limited, as dictated by the organization's IT policy, for example. For example, an organization's IT policy may dictate that certificates from other organizations will be trusted only for the purpose of processing encrypted e-mail messages. In addition, cross-certificates may be revoked by an organization's issuing CA to end trust relationships with other organizations. This can facilitate more efficient control of secure electronic mail communication between individuals across different organizations.

Cross certificates facilitate secure communication between individuals in organizations that have established a relationship of trust. Consider again the situation in which the user of organization ABC receives a coded message from user2 of organization XYZ. The user will be able to verify the trust status of the user's certificate 402b2, by retrieving certificates in a chain from the user2's certificate 402 to the root certificate 404a issued by a root CA of the user's organization and the user's trust. Specifically, as shown in the example in Figure 7B, the chain includes the root certificate 404a from ABC, the cross certificate 412, the root certificate 404b from XYZ, the intermediate certificate 406b, and the certificate 402b from user2.

For the user to check the trust situation of the

39/50 User2 certificate 402b, the user needs to obtain the 402b certificate. This will usually accompany the message from user2 to the user; however, in the event that the 402b certificate is not provided and is not otherwise stored on the user's computing device, it needs to be retrieved, from the LDAP server maintained by the XYZ organization, or another certificate server, for example, In addition , each of the remaining certificates in the chain also needs to be retrieved to verify the trust status of the 402b certificate. The other certificates in the chain, which in this example include a root certificate and a cross certificate, would need to be retrieved from the ABZ LDAP server, the XYZ LDAP server, or some other LDAP server accessed by the user.

As discussed with reference to Figure 5, and Figures 7A and 7B, the digital signatures of issuing CAs on certificates often need to be verified when building certificate chains. Other tasks can also be performed when validating certificates, such as checking the validity of the certificate date, or checking other validation criteria that can be established by the organization in accordance with IT policy, for example.

Verifying a digital signature on a certificate is a process that requires the issuing CA's public key. When the CA digitally signs the certificate, the certificate information, including the name and public key of the certificate holder, for example, or a hash of that information obtained by applying a hash algorithm, is typically encoded using the

40/50 CA private key. The algorithm used by the issuing CA to sign a certificate is typically identified in the certificate. Subsequently, similarly to that employed in verifying the digital signature of a message signed by the user, the CA's digital signature on a certificate can be verified by decoding the encoded information or the hash using the CA's public key, and comparing the result with the expected certificate information or its hash, respectively. A successful match indicates that the CA has verified that the certificate holder's public key can be validly linked to the certificate holder, and suggests that the certificate holder's public key can be trusted if the CA is trusted.

Verifying certificate signatures can be both time-consuming and costly (for example, in terms of using computing resources), particularly when checks are made on small devices, such as mobile devices. Versions of the invention are generally aimed at a system and method that facilitates more efficient verification of digital signatures on certificates by storing certain information used in signature verification operations to be reused.

In at least one version, one or more public keys of a CA that issued a private certificate are associated with that certificate, and placed in temporary or stored memory. As noted above, when attempting to verify the digital signature on a certificate signed by the CA, the public key of the CA is

41/50 required. However, there may be multiple certificates (each with a public key attached) that appears to belong to the same CA. This situation can arise if several certificates have the same or similar topic data (that is, the certificate data that identifies the certificate holder) or if the CA has been issued multiple public keys (some of which are no longer valid), for example example. Thus, it can be beneficial to keep track of which private public key was used to successfully verify a private certificate.

With reference to Figure 8, a flow chart is generally shown as 42 0 illustrating the steps in a method of verifying digital signatures on certificates in a version of the invention.

In one version of the invention, at least some of the steps in the method are performed by a certificate validation application that runs and resides on a mobile device. In variant versions, the certificate validation application may be resident and running on a computing device other than the mobile device. In addition, the certificate validation application does not have to be a unitary application, and the functionality of the certificate validation application can be implemented in one or more applications that run and reside on the mobile device or another computing device.

Generally, in method 420, when a given public key is used to successfully verify the digital signature on a certificate, a copy of that public key is placed in temporary memory, or otherwise

42/50 stored in a memory store. For example, the public key may be stored with the certificate data associated with the certificate, or in a separate memory store (for example, a lookup table) adapted to store public keys used for successful signature checks. When a subsequent attempt to verify the digital signature on the same certificate is made, instead of immediately carrying out an expensive signature verification operation that requires at least decoding some data using a public key, the public key that would have been used to verifying the digital signature is again, instead, initially compared to the stored public key. If these public keys match, then the verification will be considered successful, since the public key to be used matches a key that was previously used successfully in a signature verification operation. It is considered unnecessary to perform an effective signature verification operation again for the same digital signature. Thus, at least some subsequent signature verification operations can be replaced by more efficient comparison operations (for example, the byte loop). The steps of method 420 are described in more detail below.

In step 430, verification of a digital signature on a certificate is initiated (for example, by the certificate validation application). The verification of digital signatures on certificates can be carried out, for example, when building chains of

43/50 certificates to validate specific certificates received by the user (for example, to verify the trust status of a certificate attached to a received message as discussed with reference to Figure 5). In this version, the digital signatures on the certificates being verified are those of the certification authorities that issued the respective certificates. As noted earlier, in a signature verification operation, the public key of the certification authority that issued the certificate is required. The certification authority's certificates and public keys may need to be retrieved at this stage (for example, from an LDAP server) if they are no longer stored in a certificate store on the mobile device or other computing device.

For a given public key, in step 44 0, before performing the signature verification operation using this public key, the determination is made as to whether the digital signature on the on-screen certificate has been successfully verified previously using this public key. As indicated above, this can be done by comparing a public key stored for the certificate issuer previously used to successfully verify the digital signature on the certificate on screen (if it exists, as stored in step 470 in the cache or in another warehouse memory) with the public key that is about to be used to verify the digital signature, and then determine if there is a match. Since only public keys used in successful verification attempts are stored in temporary memory or elsewhere

44/50 memory store in this version, if a match were determined, this would suggest that the digital signature on the screen certificate was previously successfully verified.

If the digital signature on the on-screen certificate has not been successfully verified previously using the given public key, then in step 450, the digital signature is verified using this public key in a known manner. If the signature is successfully verified as determined in step 460 using this public key, then the public key used in this verification successfully is stored in the temporary memory or in another memory store for future use, in step 470, according to this version . For example, the public key stored in step 470 can be stored with the data associated with the certificate on screen, or in a central memory store for public keys (for example, in a lookup table) indexed by the certificate (for example, when store the issuer name and the certificate serial number with the public key).

On the other hand, if the digital signature on the on-screen certificate had previously been successfully verified using the public key given as determined in step 440, then in step 480, an indication that the verification is successful is provided. This is done instead of performing an effective signature verification operation that requires at least decoding some data using the public key, thus making the signature verification process more efficient. This can help conserve battery power and improve

45/50 user experience, for example, particularly for small devices like mobile devices.

Method 420 steps can be repeated for additional public keys.

Referring now to Figure 8B, a flow chart illustrating the steps in a method of verifying digital signatures on certificates in another version of the invention is generally shown as 420b.

The 42 0b method is similar to the 42 0 method, except that in contrast to the 42 0 method, in which only the public keys employed in successful signature checks are stored in temporary memory or in another memory store, in method 420b, the public keys used in any signature verification attempt (whether successful or unsuccessful) are stored in temporary memory or in another memory store along with the result of the verification attempt.

Generally, in method 420b, when a given public key is used to verify the digital signature on a certificate, a copy of that public key is stored in temporary memory or otherwise stored in a memory store, along with the result of the operation. For example, the public key and associated result can be stored with the certificate data associated with the certificate, or in a separate memory store (for example, a lookup table). When a subsequent attempt to verify the digital signature on the same certificate is made using the given public key, instead of carrying out an expensive signature verification operation that requires at least decoding some data

46/50 using that public key, the public key that would have been used to verify the digital signature again, is instead initially compared to the stored public key. If the given public key matches the stored public key, then the current verification attempt will be considered successful or unsuccessful, depending on the stored result associated with that public key. If the stored result indicates that the previous verification attempt with that stored public key was successful, then the current verification attempt will be considered successful. If the stored result indicates that the previous verification attempt with that stored public key was not successful, then the current verification attempt is considered to have failed. Thus, the subsequent signature verification operation that would otherwise require the decryption of some data using public keys can be replaced by more efficient comparison operations (for example, byte mesh).

In step 430, verification of a digital signature on a certificate is initiated (for example, by the certificate validation application), as described with reference to method 420.

For a given public key, in step 440b, before performing the signature verification operation using this public key, a determination is made as to whether the digital signature on the screen certificate was previously verified using this public key. As indicated above, this can be done by comparing a public key to the certificate issuer previously used for

47/50 verify the digital signature on the on-screen certificate (if one exists, as stored in step 470 in temporary memory or another memory store) with the public key that is about to be used to verify the digital signature, and determine if there is a wedding. If the match is determined, this would suggest that an attempt to verify the digital signature on the screen certificate was made earlier.

If an attempt to verify the digital signature on the on-screen certificate has not been made previously, then a signature verification operation is performed in the manner known in step 450, as described in a similar manner with reference to method 420. Both the public key used in the verification and the result of the verification attempt (that is, an indicator of whether the digital signature was verified with or without success) are stored in the temporary memory or in another memory store for future use in step 470b, according to this version. For example, the public key and the result stored in step 470b may be stored with the data associated with the certificate on screen, or in a central memory more for public keys (for example, in a lookup table) indexed by certificate (for example). example, when storing the certificate serial number with the public key).

If the digital signature on the screen certificate was previously verified with the public key given as determined in step 440b, then in step 472, the result of the previous verification attempt with this key is retrieved from the temporary memory or from another memory store and a determination is made as to whether the result

48/50 stored indicates whether or not the previous verification attempt with this key was successful. If it was, then in step 480, an indication that the current check must be successful is provided; if not, then at step 4 90 an indication that the current check should not be successful is provided.

The steps of method 420b can be repeated for additional public keys.

Instead of performing a signature verification operation that requires at least some data to be decoded using a given public key, the results of previous verification attempts are used to determine whether a verification using this public key should fail, thus making the process more efficient signature verification. In particular, if the user requests verification of the digital signature of a certificate multiple times using the same invalid public key, then an expensive actual signature verification operation requiring at least the decryption of some data using the public key needs to be performed only once. time, and subsequent attempts will fail immediately after performing a relatively efficient comparison operation (for example, byte loop). This may also help to conserve battery power and improve the user experience, for example, particularly for small devices such as mobile devices.

It will be understood by people skilled in the art that information other than public keys and the results of the verification attempt described above may also

49/50 be stored in temporary memory or in another memory store, if desired, in variant versions.

In a variant version of the invention, public keys and other information (for example, results of attempted verification) stored in the temporary memory or in another memory store may only be allowed for use in comparisons of public keys for a limited duration after the that they may be considered spent and subject to erasure from the temporary memory or other memory store. This can be done for security purposes so that an effective signature verification operation that requires at least some data to be decoded using a public key needs to be redone from time to time. This duration can be fixed according to IT policy, for example. Similarly, in another variant version of the invention, part or all of the public keys and other information stored in the temporary memory or in another memory store may be marked as worn or deleted as it can be manually directed by the user or the administrator, for example. example, so the signature verification operation needs to be redone. For more enhanced security, validation operations can also be performed to ensure that public keys (for example, public keys that have previously successfully verified a certificate signature) are not invalid after storage, for example.

The steps in the method of verifying digital signatures on certificates in versions of the invention may be provided as executable software instructions

50/50 stored on media read by computer, which may include media of the transmission type.

The invention has been described with respect to a number of versions. However, it will be understood by persons skilled in the art that other variants and modifications may be made without departing from the scope of the invention as defined in the claims attached hereto.

• · · ♦ · ·

Ο · 4 • ·

<img file="BRPI0505083A_D0003.tif" />

<img file="BRPI0505083A_D0004.tif" />

1/2