System and method for verifying digital signatures on certificates

METHOD, SYSTEM AND MEDIA LEGIBLE BY COMPUTER TO CHECK DIGITAL SIGNATURES ON 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.

Petition 870180142935, of 10/22/2018, p. 13/14

2/50

<img file="BRPI0505083B1_D0001.tif" />

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 chain of 10 certificates. 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 20 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 25 computing resources), particularly when the checks are carried out on smaller devices, such as mobile devices, for example. When multiple certificates are processed ^ on the user's computing device, the same digital signature may be subjected to verification more than once. Versions of the invention are •• I * · ™ *¹

3/50

<img file="BRPI0505083B1_D0002.tif" />

generally directed 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 — invention, - and 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 issuer of the certificate; 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 whether the digital signature was successfully verified in the first signature verification operation and whether a match is determined

5 in the compare stage, in which the second signature verification operation does not need to be performed.

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, for example,

<img file="BRPI0505083B1_D0003.tif" />

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 node in a wireless network.

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.

0 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 30 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 5 may be referred to as a “messaging device”^_s; a bilateral radio call device, a cell phone with data messaging capabilities, 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. 0

0 microprocessor 102 controls the general operation of the mobile device 100. Communication functions, including data and voice communication, are carried out through the communication subsystem 104. The communication subsystem

104 receives messages and sends messages to and from a wireless network 25. 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 - Global System for 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 the Enhanced Data GSM Environment (EDGE - GSM Enhanced Data Environment) and Universal Mobile Telecommunications Service (UMTS)

Universal Mobile Telecommunication). 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 persons skilled in the art that the invention intends to use any other suitable standards 10 that will be developed in the future. The 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 15 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-centric wireless networks, voice-centric wireless networks, 25 and dual-mode networks that can support both voice and data communication over them. physical base stations. Combined dual mode networks include, but are not limited to, Code Division Multiple Access (CDMA - Code Division Multiple Access) or CDMA2000 networks, 30 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).

Microprocessor 102 also interacts with additional subsystems 10 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 15 devices 124.

Some of the subsystems of the mobile device 100 perform communication-related functions, while other subsystems may provide resident functions¹¹ or on the device. For example, the display device 20 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 task list. The operating system software 25 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. 0 access — to the network — 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 network. 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 communicating with network 200. By inserting SIM 12 6 into the SIM 128 interface, the subscriber can access all subscribed services.

Services could include:

Web scanning and messages such as electronic correspondence, voice correspondence, Message Service

Short (SMS), and Multimedia Messaging Services (MMS).

More advanced services may include: point of sale, field service and automation of the sales team. SIM 126 includes a processor and memory to store information.

Once SIM 126 is inserted into 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 can store additional subscriber information for the mobile device as well, including date book (or calendar) information and recent call information.

The mobile device 100 is a battery-powered and i-ncl-ui device — a battery-in-te-r-face 132 for receiving one or more rechargeable batteries 130. The battery interface 132 is coupled to a regulator ( not shown), which assists battery 130 to provide V + power to the mobile device 100. Although current technology makes use of a battery, future technologies such as micro fuel cells may supply the power to the mobile device 100.

The microprocessor 102, in addition to its functions as an operating system, allows the execution of software applications on the mobile device 100. A set of applications that control the basic operations of the device, including voice and data communication applications, will normally be installed. on the mobile device 20 100 during its manufacture. Another application that can be loaded on the mobile device 100 would be a personal information manager (PIM). 0 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. The PIM data items may be carefully integrated, synchronized, and updated over the wireless network 200 with the corresponding mobile device subscriber data items stored and / or associated with a main computer system. This functionality creates a host computer mirrored on the mobile device 100 5 with respect to these items. This can be particularly advantageous when O — s^_i host computer and the computer system of the mobile device subscriber's office.

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 Installing applications increases the functionality of the mobile device 15 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 down payment route, for example, could be used to load an encryption key into the mobile device 100 over a direct connection, and thus reliable and trusted, to provide secure device communication.

I had you

11/50

<img file="BRPI0505083B1_D0004.tif" />

The short-range communication subsystem 122 provides communication between the mobile device 100 and different systems or devices, without using network 200. For example, subsystem 122 may include an • 5 infrared device and associated circuits and components for the-- e-ur-Lo-a-loance 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 web page download will be processed by the communication subsystem 104 and entered into microprocessor 102. Microprocessor 102 will then process the received signal to 15 output on the display device 110 or alternatively to auxiliary I / O subsystem 112. The subscriber can 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 touch screen, a mouse, a rotating sphere, an infrared fingerprint detector, or a rotating wheel with the ability to press a dynamic button. 0 keypad 116 is an alphanumeric keypad and / or a telephone type keypad. 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

<img file="BRPI0505083B1_D0005.tif" />

118, and signals for transmission would be generated by microphone 120. Alternative audio or voice I / O subsystems, such as the voice message recording subsystem, may also be implemented on the mobile device

100. Although the output of the voice or audio signal is performed — essentially - at-ravé s-do-alto - fa 1 ante 118, the— display device 110 can also be used to provide additional information such as identity the calling party, the duration of a voice call, or other information related to the voice call.

Referring now to Figure 2, a block diagram of the component of the communication subsystem 104 of Figure 1 is shown. The communication subsystem 104 comprises a receiver 150, a transmitter 152, one or 15 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.

The particular design of the communication subsystem 104 is dependent on the network 200 on which the mobile device 100 20 intends to operate. Thus, it must be understood that the project illustrated in Figure 2 serves only as an example. Signals received by antenna 154 through network 200 are input to receiver 150, which can perform common receiver functions such as signal amplification, frequency downward 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

.............. 'mil ............ mi ...... ά · ιιιι · ι »ιι.ι · ι.ι · ιι · .Ιιι »·. · Ιι ·· .ιιίι» »ιι» ί »ι ^ ·· ^ · .ιι * ····» ··· ιι · ^ .— · ί.

<img file="BRPI0505083B1_D0006.tif" />

DSP 160. These signals processed by the DSP are input to transmitter 152 for digital-analog conversion (D / A), upward frequency conversion, filtering, amplification and transmission over the 5 200 network via antenna 156. 0 DSP 160 it not only processes signals — of communion — 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 controlled additively through 10 automatic gain control algorithms implemented in 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 15 used between the mobile device 100 and the network 200. An RF channel is a limited resource that needs be conserved, typically due to the 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 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 required to receive 25 signals or information (if any) for designated periods of time.

With reference 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 10 0 communicates with the node 2 02 inside the

14/50 wireless network 200. In the example implementation of Figure 3, node 202 is configured according to the technologies of the General Packet Radio Service (GPRS - General Packet Radio Service) and Global Systems for Mobile Communication 5 (GSM - Global Systems for Mobile Communication). Node 202 includes a docker-from-base-station- (- BSC) 204 with an associated tower station 206, a Packet Control Unit (PCU) 2 08 added for GPRS support in GSM, a Switching Center Mobile (MSC) 210, a 10 Residential Location Register (HLR) 212, a

Visitor Location (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 list of components is not intended 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 the BSC 204 and to a land line network, such as the Public Telephony Switched 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 25 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) 208 that connects to SGSN 216 to control segmentation, allocation of the radio channel, and to meet the switching requirements of 30 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 the MSC 210 and SGSN 216. Access to the VLR 214 is controlled by the MSC 210.

Station 206 is a fixed transceiver station. THE

-station 206 and BSC 2 04 together form the equipment, fixed transceiver. 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. The 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 private communication protocols and parameters, usually predetermined, under the control of its controller. The fixed transceiver equipment demodulates and possibly decodes and decrypts, 20 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 25 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 every 30 registered mobile devices and can be consulted for

16/50 determine the current location of a mobile device. The MSC 210 is responsible for a group of localization areas and stores the data of the mobile devices currently in its area of ​​responsibility in the VLR 214. In addition, the VLR 214 5 also contains information about mobile devices that are so important - or-tras —- networks -.— A — information — no — VLR — 2-1-4includes part of the permanent mobile device data transmitted from HLR 212 to VLR 214 for faster access. By moving additional information from a remote HLR 10 node 212 to VLR 214, the amount of traffic between these nodes can be reduced so that voice and data services can be provided 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 wireless network 200 in keeping track of the location of each mobile device 20. 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 via an Internet Protocol (IP) background network operated within the 2 00 network. During normal operation, a given mobile device 100 needs to perform a 'GPRS Attach' to acquire an IP address and access data services. This requirement is not present in circuit-switched voice channels as Integrated Services Digital Network 30 (ISDN) addresses are used

17/50 to route incoming and outgoing calls. Currently, all GPRS capable networks use dynamically assigned private IP addresses, thus requiring a DHCP 220 server connected to the GGSN 218. There are many 5 mechanisms for dynamic IP assignment, including the use of a Remote server combination Authentication Dial-In User Service (RADIUS - Remote Authentication Dialing User Service) and DHCP server. Once the GRPS Attach is finished, a logical connection is established from a mobile device 100, via PCU 2.08, and 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. 0 APN also represents a security mechanism for network 200, as each mobile device 100 must 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 on the 2 5 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 a limited number of them are available on the 200 network. To maximize the use of PDP Contexts, the

18/50 network 200 will process an idle timer for each PDP Context to determine if there is a lack of activity. When ο mobile device 100 is not using its PDP Context, the PDP Context can be deallocated and IP address 5 returned to the IP address pool managed by DHCP server 220. - - ------------ Referring now to Figure 4, a block diagram is shown that illustrates components of a host system in an example configuration. 0 host system 10 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 15 is represented as a LAN of an organization to which the user of mobile device 100 belongs.

LAN 250 comprises a number of network components connected to each other via LAN 260 connections. For example, the user's desktop computer 2 62a with a companion cradle 264 for the user's mobile device 100 is located on LAN 250. The cradle 264 for the mobile device 100 can be coupled to the 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. The cradle 264 facilitates the loading of information (for example, PIM data, private symmetric encryption keys 30 to facilitate secure communication between the

19/50 mobile device 100 and LAN 250) from the user's computer 2 62 a to the mobile device 10 0, and may be particularly useful for wholesale information updates, often carried out at startup of the mobile device 100 for use . The information downloaded on 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 10 other peripheral devices not shown explicitly in Figure 4.

In addition, 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 (not shown) network 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, the mobile device 100 communicates with LAN 250 through node 220 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 wall of fire or a 266 replacement server.

In a variant implementation, the LAN 250 comprises a *¹¹ ** *¹ * 11 ^ 1¾ IhW. *.¹»! RH1HKMÍ 'JMtifr M 1 ^ * 1 * * * M * «*»&gt; f 11} &lt;&lt;pp p TftHJ ff

20/50 wireless VPN router (not shown) to facilitate ο data exchange between LAN 2 50 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 through a specific wireless network for the —disposdt-i-vo — mobile — 1-0Ό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 20 directly to the mobile device 100 in this variant implementation.

Messages directed to the user of the mobile device 10 0 are initially received by a message server 268 on LAN 250. These messages may originate25 from any number of sources. For example, a message may have been sent by a sender from a computer 262b within LAN 250, from a different mobile device (not shown) connected to wireless network 200 or a different wireless network, or from a device 30 different computing or other 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 the exchange of messages, particularly e-mail messages, within the organization and through the shared network infrastructure 224. Each user in the organization that has been established for 10 sending and receiving 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, the LAN 250 may comprise multiple 15 message servers 268. The message server 268 may also be adapted to provide additional functions in addition to message management, including the management of 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 user's computer 262a, may request e-mail messages associated with the user's account stored on the message server 268. These messages would then typically be retrieved from message server 268 and stored locally on computer 262a.

ϊ

22/50

<img file="BRPI0505083B1_D0007.tif" />

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 that operates on the mobile device 100 may also request messages associated with the user account of the 268 message server. 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, at any pre- defined or when a pre-defined event occurs. In some implementations, mobile device 100 is assigned its own electronic mailing address, and messages addressed specifically to mobile device 100 are automatically redirected to mobile device 100 as they are received by 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, the wireless communication support components 270 comprise a message management server 272, for example. The 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

<img file="BRPI0505083B1_D0008.tif" />

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 5 272 also facilitates the handling of messages composed on the mobile device — 1-0-0— which are sent to the 268 message server for subsequent delivery.

For example, message management server 10 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 if and how the 15 messages will be passed on to the user's mobile device 100; 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 via the shared network infrastructure 224 and the 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 25 they appear to have originated from the user's computer 262a, and re-route the messages. composed messages to message server 268 for delivery.

Certain properties or restrictions associated with messages that are to be sent from and / or received 30 by the mobile device 100 can be defined (by '' 'íwm' ** I i''wu iamt'Jfiuinumn lift jiEfrtMaitfr-i ^ jii ^ - iÍ-itiWMBiiiittiiii · uMtfi ^ jfawtMi! ww

24/50

<img file="BRPI0505083B1_D0009.tif" />

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

0 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 10 0, with the

0 part being of a predefined size (for example, 2 KB).

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 even a predefined message dimension.

5 maximum.

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 10 0, and can help minimize potential wear 30 of bandwidth or other resources .

25/50

<img file="BRPI0505083B1_D0010.tif" />

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 5 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 must 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 RFC822 headers of the Mail Transfer Protocol

Simple (SMTP), and parts of the Multipurpose Internet Correspondence Extensions (MIME) body may be used to define the format of a typical electronic correspondence message that does not require encryption, Secure / MIME (S / MIME), a version of protocol

MIME, 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 since the originator of the message 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.

o 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 descript-og-ra-fedos using the corresponding public key of the pair, and vice versa. Private key information is never made public, whereas public key information is shared.

For example, if the sender wants to send a message to a recipient in encrypted form, the public key of the recipient

<img file="BRPI0505083B1_D0011.tif" />

receiver 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

27/50 one of these 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 message.

The 10 exit. 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. The recipient also uses the sender's public key to decode the digital signature, to obtain what must be a matched summary for the message received. If the summaries of the received message do not match, this suggests that either the message content was modified during transport and / or the message did not originate from the sender whose public key 20 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 5, 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. 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. The 20 310 certificate will also typically include other information and attributes that identify the certificate holder (for example, e-mail address, name of the organization, unit name of the organization, location, etc.). When the individual composes a message to be sent 25 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 be de.s_e.j_ar. check the trust status of the 310 certificate affixed to the message received. 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. 0 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 certificate 20 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 can be referred to as an 'intermediate certificate' in the certificate chain 300; any chain of certificates given up to the particular root certificate 30, 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 the 330 certificate and a root certificate issued by a trusted source (from a large certifying authority 5. such as Verisign or Entrust, for example) then the 310 certificate can be considered to be ... trusted because 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 10 certificate cannot be chained to a trusted certificate, the certificate can be considered to be ¹ unreliable¹.

Certificate servers store information about certificates and lists that identify the 15 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 verify the 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 3 0 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 of 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 the mobile device 15 100, it can be verified on the mobile device 100 by matching the certificate to one stored on the 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 25. 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

<img file="BRPI0505083B1_D0012.tif" />

posts .

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, the mobile device 10 0). 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. The PKI 2 80 servers include a CA 282 server for issuing certificates, an LDAP 284 server used to search and download certificates (for example, for within the organization), and an OCSP 286 server used to verify the revocation status of certificates.

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 via cradle 264. However, in a variant implementation, the LDAP server 284 can be accessed directly (ie , 'over the air' in this context) by the mobile device 100, and the mobile device 100 will be able to retrieve and retrieve individual certificates 25 through 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 verify the revocation status of the certificates.

In variant implementations, only PKI servers

The selected 33/50 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 revocation status 5 of the 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 sources of certificates (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 encoded message, as it may be received by a message server (for example, the message server 268 of Figure 4). The encoded 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 information related to the 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 sender's signature and encryption scheme identifiers, for example. example. The content of the effective message usually includes a message body or

34/50 part of data 354 and possibly one or more attachments 356, 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 5 using the respective public key for each recipient, and included in the message at 3 58. If the message —fo-i— signed, a signature and information related to 360 subscription are 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 15 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 the encoded message be encrypted, signed, or the two 20's.

Versions of the invention are generally aimed at a system and method that facilitates the 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

<img file="BRPI0505083B1_D0013.tif" />

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

Referring first to Figure 7A, a .um.— 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 fewer or more certificates than represented in the examples shown.

Many organizations establish their own CAs, which issue certificates specifically to 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 20 associated with the organization. A final entity certificate is often issued by one of a number of subordinate or intermediate CAs within a hierarchy of CAs headed by a root CA for the organization. This root CA will be able to provide a self-signed root certificate to 2 5 be used as a 'trusted anchor¹ - the starting point for the validation of certificates issued within the organization.

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

36/50 **** τ ** · ** Ηί ί '^ ΝΙίΜΜΜΜΜΜΜΜΜΜΜΜΙΜΜΜΜ — Ι — Ι— · ——— Μ — I organization' ABC¹. Ο certificate 402a chains up to the self-signed root certificate 404a, issued by the root CA to an intermediate CA of the organization. Certificates issued within the ABC organization can be retrieved 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 10 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 retrieved 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 attached his certificate 042b to the message, the user will not be able to verify the trust status of user2's certificate 402b with just that certificate (assuming the user no longer stored user2's certificate 402b and marked it as trustworthy). If the user does not trust the certificates of the organization XYZ, then the certificate 402b 2 5 of user2 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 the 30 organizations. An authentication method known as

<img file="BRPI0505083B1_D0014.tif" />

37/50

<img file="BRPI0505083B1_D0015.tif" />

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 with —relative infrequency, 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 certificate chain 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 2 0 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.

The 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 30 may issue a certificate

38/50

<img file="BRPI0505083B1_D0016.tif" />

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 5 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 electronic correspondence 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 15 individuals across different organizations.

Cross-certificates facilitate secure communication between individuals in organizations that have established a relationship of trust. Consider again the situation where the user of organization ABC receives a coded message 20 from user2 of organization XYZ. The user will be able to verify the trust status of the user's certificate 402b, by retrieving certificates in a chain from the user'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

Ο 10

Ο user2 certificate 402b, user1 needs to obtain the 402b certificate. This will usually accompany the message from user2 to the user; however, in the event that certificate 0402b 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. 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 ABZ's LDAP server, 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 encrypted using the private key from CA. 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 a time-consuming and costly process (for example, in terms of using computing resources), particularly when verifications are performed on small devices, such as mobile devices, for example. 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 indicated above, when attempting to verify the digital signature on a certificate signed by the CA, the public key of the CA is uúLhúm

41/50 required. However, there may be multiple certificates (each with a public key attached) that appears to be similar

The. holder belongs to the same CA. This situation can arise certificates having the same or topic data (that is, the certificate data that identifies the certificate) or if the CA has been issued multiple public keys (some of which are no longer valid), for 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 photograph is generally shown as 42 0 which illustrates 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 application of

The validation by running certificate-certified device can be on a mobile computing device. In addition_f the resident application other than validation does not need to be a unitary application, and functionality of the certificate validation application may be run and device implemented in one or more applications residing on the mobile device or on another computing device.

Generally, in method 420, when a given public key is used to digitally verify a certificate, a copy is placed in temporary memory, success of that or the public key signature otherwise stored in a memory store. For example, the public key can 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 in the checks. - successful subscription. 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 10 decryption of some data using a public key, the public key that would have been used to verify 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, as 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 20 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 25 below.

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

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 20 previously using this public key. As indicated above, this can be done by comparing a stored public key for the certificate issuer used previously to successfully verify the digital signature on the on-screen certificate (if it exists, as stored in step 470 in the cache or elsewhere) memory store) 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 employed in successful verification attempts are stored in temporary memory or elsewhere

44/50

<img file="BRPI0505083B1_D0017.tif" />

memory store in this version, if a match was 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 before 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 10 as determined in step 460 using this public key, then the public key used in this successful verification is stored in the temporary memory or in another memory store for future use, in step 470, according to this version. For example, public key 15 stored in step 470 may 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 storing the name of the issuer and the serial number of the certificate 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 the decryption of some data using the public key, thus making the signature verification process more efficient. This may help to conserve battery power and improve

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

The steps of method 42 0 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.

Method 42 0b is similar to method 42 0, except that in O 10, it contrasts with method 420, in which only public keys used in successful signature checks are stored in temporary memory or in another memory store, in method 42 0b, the public keys used in any attempt to verify the signature (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 performing an expensive signature verification operation that requires at least some data decryption

............... .............. ....... ή: ir nt ....... mi *; ir'T .ibr · 1 »

46/50

<img file="BRPI0505083B1_D0018.tif" />

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 public key given 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 10 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 certificate on screen was previously verified using this public key. As indicated above, this can be done by comparing a public key 30 to the certificate issuer previously used for

<img file="BRPI0505083B1_D0019.tif" />

* verify the digital signature on the on-screen certificate (if one exists, as stored in step 470 in the 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 one marriage. If the * marriage 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 carried out 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 (ie, 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, when storing the certificate serial number with the public key).

If the digital signature on the on-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 another store of 30 memory and a determination is made as to whether the result tMuuàiiuutfú

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 5 an indication that the current check should not be successful is provided.

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

Instead of performing a 10-signature verification operation that requires at least decrypting some data 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 15 most efficient signature verification process. 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 operation of verifying the actual signature requiring at least 20 decoding of some data using the public key needs to be performed only once, and subsequent attempts will fail immediately after performing a relatively efficient comparison operation (for example, byte mesh). 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 time, after what they can be considered worn out and subject to erasure from the temporary memory or another O 10 memory store. This can be done for security purposes so that an effective signature verification operation that requires at least decrypting some data using a public key needs to be redone from time to time. This duration may 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 managed by the user or the administrator, for 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 successfully verified a certificate signature previously) are not invalid after storage, for example.

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

50/50

<img file="BRPI0505083B1_D0020.tif" />

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 appended hereto.