System and method for searching and retrieving certificates
17 claims: 2 independent, 15 dependent
- 1証明書を検索し、取り出す方法であって、該方法のステップは、 第2のデバイスと通信する 第1のコンピューティングデバイスによって実行され、該方法は、 該第1のコンピューティングデバイスが、 該第2のデバイスから 証明書検索要求を受け取るステップと、 該第1のコンピューティングデバイスが、1つ以上の認証サーバーにおいて検索を実行するステップであって、該証明書検索要求を満たす証明書 を該1つ以上の認証サーバーから 取り出 すこと を要求するために、少なくとも1つのクエリが 該第1のコンピューティングデバイスによって 該1つ以上の認証サーバーに提出される、ステップと、 該第1のコンピューティングデバイスが、該1つ以上の認証サーバーから少なくとも1つの証明書を取り出すステップと、 該第1のコンピューティングデバイスが、 各証明書に対する 検索結果データを決定するために、該第1のコンピューティングデバイスにおいて取り出された証明書の各々を処理するステップであって、 各証明書に対する 検索結果データは、 それぞれの 証明書 の 全体ではないが、それぞれの証明書を一意に識別するデータを備える、ステップと、 該処理された証明書の各々に対して、該第1のコンピューティングデバイスが、該処理された証明書に関連する検索結果データを、該それぞれの証明書が 該 第2のデバイスに格納されているかどうかを 該第2のデバイスによって 決定するために、該第1のコンピューティングデバイスから該第2のデバイスに通信するステップと を包含する、方法。
- 2前記それぞれの証明書を一意に識別するデータが、該それぞれの証明書に対するシリアル番号および発行者データを備え、前記処理するステップが、該それぞれのシリアル番号および発行者データを得るために、前記取り出された証明書の各々を解析することを包含する、請求項1に記載の方法。
- 3前記それぞれの証明書を一意に識別するデータが、該それぞれの証明書の少なくとも一部のハッシュを備え、前記処理するステップが、それぞれのハッシュを得るために前記取り出された証明書の各々にハッシュアルゴリズムを適用することを包含する、請求項1に記載の方法。
- 4前記証明書の各1つの証明書について得られたハッシュが、該1つの証明書全体のハッシュである、請求項3に記載の方法。
- 5前記第2のデバイスが、モバイル機器を含む、請求項1~4のいずれか一項に記載の方法。
- 6前記第1のコンピューティングデバイスが、モバイルデータサーバーを含む、請求項5に記載の方法。
- 7前記第2のデバイスが、前記取り出された証明書のリストを表示することをさらに包含し、該リストは、 それぞれの証明書に対するインジケータを含み、各インジケータは、該それぞれの 証明書が該第2のデバイスに すでに 格納され た と決定され た か 否か を示す、請求項1~6のいずれか一項に記載の方法。
- 8前記第1のコンピューティングデバイスが、前記リストから選択された証明書を識別するデータを 該第2のデバイスから 受信することと、 該第1のコンピューティングデバイスが、該選択された証明書を前記第2のデバイスに通信することと をさらに包含する、請求項7に記載の方法。
- 9コンピューティングデバイスにおいて実行するためのソフトウエアアプリケーションであって、該ソフトウエアアプリケーションは、コンピュータ記録媒体に格納される複数の命令を備え、該複数の命令は、実行されたときに、該コンピューティングデバイスに請求項1~8のいずれか一項に記載の方法をインプリメントさせる、ソフトウエアアプリケーション。
- 10証明書を検索し、取り出すためのシステムであって、 該システムは、少なくとも第1のコンピューティングデバイスおよび第2のデバイスを備え、 該第1のコンピューティングデバイスが、 該第2のデバイスから証明書検索要求を受け取ることと、 該証明書検索要求を満たす証明書の取り出しを要求するために1つ以上の認証サーバーに少なくとも1つのクエリを提出することによって、該1つ以上の認証サーバーにおいて検索を実行することと、 該1つ以上の認証サーバーから少なくとも1つの証明書を取り出すことと、 各証明書に対する 検索結果データを決定するために、該取り出された証明書の各々を処理することであって、 各証明書に対する 検索結果データは、 それぞれの 証明書 の 全体ではないが、それぞれの証明書を一意に識別するデータを備える、ことと、 該処理された証明書の各々に対して、該処理された証明書に関連する検索結果データを、該それぞれの証明書が該第2のデバイスに格納されているかどうかを 該第2のデバイスによって 決定するために、該第2のデバイスに通信することと を実行するように適合されている、システム。
- 11前記それぞれの証明書を一意に識別するデータは、該それぞれの証明書に対するシリアル番号および発行者データを備え、該証明書の各々の処理において、前記第1のコンピューティングデバイスは、該それぞれのシリアル番号および発行者データを得るために、前記取り出された証明書の各々を解析するように適合されている、請求項10に記載のシステム。
- 12前記それぞれの証明書を一意に識別するデータは、該それぞれの証明書の少なくとも一部のハッシュを備え、該証明書の各々の処理において、前記第1のコンピューティングデバイスは、該それぞれのハッシュを得るために取り出された証明書の各々にハッシュアルゴリズムを適用するように適合されている、請求項10に記載のシステム。
- 13前記証明書の各1つの証明書について得られたハッシュが、該1つの証明書全体のハッシュである、請求項12に記載のシステム。
- 14前記第2のデバイスが、モバイル機器を含む、請求項10~13のいずれか一項に記載のシステム。
- 15前記第1のコンピューティングデバイスが、モバイルデータサーバーを含む、請求項14に記載のシステム。
- 16前記第2のデバイスは、前記取り出された証明書のリストを表示するように適合されており、該リストは、 それぞれの証明書に対するインジケータを含み、各インジケータは、該それぞれの 証明書が該第2のデバイスに すでに 格納され た と決定され た か 否か を示す、請求項10~15のいずれか一項に記載のシステム。
- 17前記第1のコンピューティングデバイスは、前記リストから選択された証明書を識別するデータを 該第2のデバイスから 受信することと、該選択された証明書を前記第2のデバイスに通信することとを実行するように適合されている、請求項16に記載のシステム。
Independent claims17
94 paragraphs, as filed
The present invention relates generally to processing messages such as e-mail messages, and more particularly to systems and methods for retrieving and retrieving certificates used in processing encoded messages.
Email (email) messages can be encoded using one of the well-known protocols. Those protocols (eg, Secure Multiple Internet Mail Extensions (S / MIME)) provide confidentiality and integrity by relying on public and private encryption keys, and also provide PKI (Public Key). Some rely on Infrastructure) to convey information that provides authentication and authorization. Data encrypted with the private key of a private / public key pair can only be decrypted with the corresponding public key of that pair and vice versa. The authenticity of the public key used to encode the message is verified using a certificate. In particular, if a user of a computer device wants to encrypt a message before sending it to a particular individual, the user will need a certificate for that individual. The certificate usually consists of the individual's public key and other information related to the identification. Similarly, if a user of a computer device wants to authenticate the sender of a signed message, the user will need a certificate for the sender.
If the intended recipient's essential certificate is not stored on the user's computer device, the certificate must first be retrieved. Searching and retrieving a certificate for a particular recipient introduces an authentication server by allowing the user to manually enter the intended recipient's name and email address in the search form displayed on the computer device. It is a process that is generally involved in doing. In general, the certificate found by the search may be temporarily downloaded to the computer device for review, and the list of found certificates may be displayed to the user. The selected certificate in the list may then be actually identified by the user for storage in the non-volatile storage of the computer device for future use.
However, in some executions, instead of instantly and temporarily downloading all search-positioned certificates to a computer device, only the specific data needed to generate a list of search-positioned certificates is available. It can be downloaded first to your computer device. The list is displayed to the user and typically identifies each positioned certificate using a common name and the email address of the individual to whom each certificate was issued. Only after the user selects a particular certificate from the list will the certificate be downloaded to the computer device for storage. In particular, if the computer device is a mobile device, the download of the certificate to the mobile device can be deferred and only the user-selected certificate download can significantly minimize resource waste.
Unfortunately, in these runs where certificate downloads are pending, any certificate identified in the list is stored in the computer device's certificate storage from only the downloaded data used to store the list. It is generally not possible to reliably determine whether or not it has been done. For example, the actual certificate is typically downloaded to the computer device so that the application on the computer device can reliably determine that the given certificate identified in the list is stored in the certificate storage device. To ensure that you have the essential data you need to make and make decisions. This is a time consuming and expensive task (eg with respect to bandwidth) and can be wasteful if the downloaded certificate is actually in certificate storage.
<p> Embodiments of the present invention are generally oriented towards systems and methods for more efficiently retrieving certificates in computer devices and for more efficient retrieval of certificates for storage in computer devices. There is.</p><p> One broad aspect of the invention provides a method of retrieving and retrieving a certificate that constitutes the next step: Receiving a certificate search request; Retrieving a certificate that meets the certificate search request. To perform a search on one or more authentication servers to which at least one query is submitted; retrieve at least one certificate from one or more authentication servers; first to determine search result data Steps to process each retrieved certificate on your computer device, the search result data contains data that uniquely identifies each certificate; for each retrieved certificate, the associated search. The step of communicating the result data from the first computer device to the second device for use in determining whether each certificate is stored in the second device.</p><p> In another broad aspect of the invention, the data that uniquely identifies each certificate comprises serial number and issuer data for each certificate, and the processing step contains the respective serial number and issuer data. Includes parsing each certificate retrieved to obtain.</p><p> In another broad aspect of the invention, the data that uniquely identifies each certificate comprises at least a partial hash of each certificate, and the processing steps are taken to obtain each hash. Includes applying a hash algorithm to the certificate.</p><p> In another broad aspect of the invention, a system comprising at least a first computer device and a second device for retrieving and retrieving certificates is provided. The first computer device receives a certificate search request; performs a search on one or more authentication servers by submitting at least one query to additionally request a certificate retrieval that meets the certificate search request. At least one certificate is retrieved from one or more authentication servers; each certificate retrieved is processed to determine the search result data, and the search result data uniquely identifies each certificate. For each certificate retrieved, the associated search result data is provided for use in determining whether each certificate is stored on a second device. Adapted to communicate with 2 devices.</p><p> The present invention further provides the following means.</p><p> (Item 1) A method of searching for and retrieving a certificate. Steps to receive a certificate search request and b. A step of performing a search on one or more authentication servers, at least one query is submitted to the one or more authentication servers to request retrieval of a certificate that meets the certificate search request. Steps and c. The step of retrieving at least one certificate from the one or more authentication servers, d. The step of processing each certificate retrieved in step c) on the first computer device to determine the search result data, the search result data uniquely identifies each certificate. Steps and e. For each certificate retrieved in step c), the associated search result data is used to determine if each certificate is stored in a second device. With the step of communicating from the first computer device to the second device A method of including.</p><p> (Item 2) The data that uniquely identifies each certificate comprises serial number and issuer data for each certificate, and the steps to process to obtain the respective serial number and issuer data. , The method of item 1, comprising parsing each certificate retrieved in step c).</p><p> (Item 3) The data that uniquely identifies each certificate comprises at least a portion of the hash of each certificate, and each certificate that the processing process retrieves in step c) to obtain each hash. The method of item 1, which comprises applying a hash algorithm to the document.</p><p> (Item 4) The method according to item 3, wherein the above hash obtained for each certificate is the entire hash of each certificate.</p><p> (Item 5) The method according to any one of items 1 to 4, wherein the second device is a mobile device.</p><p> (Item 6) The method according to item 5, wherein the first computer device is a mobile data server.</p><p> (Item 7) Further including displaying the list of certificates retrieved in step c) to the user, which certificates are stored in the second device as determined in step e). The method according to any one of items 1 to 6, indicating that.</p><p> (Item 8) 7. The method of item 7, further comprising extracting one or more certificate selections from the list and communicating the selected certificates to the second device.</p><p> (Item 9) A software application for execution on a computer device, the application comprising a plurality of instructions stored in a computer-removable medium, for implementing the method according to any one of items 1-8. The instruction, the application.</p><p> (Item 10) A system for retrieving and retrieving certificates, including at least a first computer device and a second device. The first computer device is a) Receive the certificate search request b) Perform the search on one or more authentication servers by submitting at least one query to additionally request the retrieval of certificates that meet the certificate search request. c) Extract at least one certificate from the one or more authentication servers d) Process each certificate retrieved to determine search result data that includes data that uniquely identifies each certificate. e) For each certificate retrieved, the search result data associated with it is used in the second device for use in determining whether each certificate is stored in the second device. A system that is adapted to communicate with.</p><p> (Item 11) The data that uniquely identifies each certificate has a serial number and issuer data for each certificate, and in processing each certificate, the first computer device is said to have its respective serial number. The system according to item 10, adapted to parse each certificate retrieved to obtain number and issuer data.</p><p> (Item 12) The data that uniquely identifies each certificate comprises at least a portion of the hash of each certificate, and in processing each certificate, the first computer device obtains the respective hashes. The system according to item 10, which is adapted to apply a hash algorithm to each certificate retrieved for. (Summary) Provides a system and method for retrieving and retrieving certificates that can be used in the processing of coded messages. In one broad aspect, a certificate search request is received, a search for one or more authentication servers is performed for the certificate that meets the request, and the data that uniquely identifies each found certificate is determined. In order to do so, the found certificate in the first computer device is retrieved, processed, and the search result data containing the determined data is stored in the second device. A method of communicating with a second device (eg, a mobile device) is provided for use in determining whether or not it has been done.</p>
For the purpose of further understanding the embodiments of the present invention and more clearly showing how the present invention can be put into practice, the accompanying drawings will be referred to below as examples.
The present invention also has an embodiment using a mobile station. A mobile station is a two-way communication device having a high level of data communication performance capable of communicating with another computer system, and the mobile station is generally referred to as a mobile device in the present specification. Mobile devices may also include voice communication performance. Due to the features provided by mobile devices, mobile devices are referred to as data messaging equipment, two-way pagers, mobile phones with data messaging capabilities, wireless internet equipment, or data communication equipment (with or without telephone performance). Can be done. The mobile device communicates with another device via the network of the transmitting and receiving stations.
Refer to Figures 1-3 to help understand the structure of mobile devices and how to communicate with other devices.
With reference to FIG. 1, the block diagram of the mobile device in one implementation example is shown as approximately 100. The mobile device 100 has a plurality of elements, and the control element is the microprocessor 102. The microprocessor 102 controls all operations of the mobile device 100. Communication functions, including data communication and voice communication, are performed via the communication subsystem 104. The communication subsystem 104 sends and receives messages to and from the wireless network 200. In this embodiment of the mobile device 100, the communication subsystem 104 is configured based on the GSM (Global System for Mobile Communication) and GPRS (General Packet Radio Services) standards. GSM / GPRS wireless networks are used all over the world, but EDGE (Enhanced Data GSM Environment) and UMTS (Universal Mobile Telecommunications) It is believed that it will eventually be replaced by Service). New standards have also been set. They appear to have similarities to the network modalities described herein. It will also be appreciated by those skilled in the art that the present invention is intended for use in all suitable standards developed in the future. The radio link connecting the communication subsystem 104 to the network 200 represents one or more different radio frequency (RF) channels, which operate according to the defined protocols defined in GSM / GPRS communication. These channels can support both circuit-switched voice communications and packet-switched data communications using new network protocols.
The wireless network associated with the mobile device 100 is a GSM / GPRS wireless network in one implementation of the mobile device 100, but another wireless network may also be associated with the mobile device 100 in another implementation. Other types of wireless networks that can be used include, for example, data-centric and voice-centric wireless networks, which support both voice and data communications in the same existing base station. Includes dual mode networks that can be. CDMA (Code Division Multiple) for combined dual-mode networks Access) or CDMA2000 networks, including, but not limited to, GSM / GPRS networks mentioned above and future 3rd generation (3G) networks such as EDGE and UMTS. Examples of pre-existing data-centric networks include the Mobitex® radio network and the DataTAC® radio network. Examples of traditional voice-centric networks include PCS (Personal Communication Systems) networks, which are similar to GSM, and Time Division Multiple Access (TDMA) systems.
The microprocessor 102 also has random access memory (RAM) 106, flash memory 108, display 110, auxiliary input / output (I / O) subsystem 112, serial port 114, keyboard 116, speaker 118, and so on. Short-range communication with microphone 120<u style="single">sub-system</u>Interacts with additional subsystems such as 122 and another device 124.
Some subsystems of the mobile device 100 perform communication-related functions, and other subsystems may provide functions in a "resident" or device. For example, the display 110 and keyboard 116 can be used as communication-related functions (eg, inputting text messages for transmission over network 200) and device-related functions (eg, calculator or task list). The operating system software used by the microprocessor 102 is typically stored in persistent storage such as flash memory 108 (or read-only memory (ROM) or similar storage element (not shown)). Those skilled in the art will appreciate that an operating system, an application of a particular device, or a portion thereof, can be temporarily incorporated into a volatile storage device such as RAM 106.
The mobile device 100 may send and receive communication signals on the network 200 after the desired network registration or activation means is completed. Network access pertains to subscribers, or users of mobile devices 100. For the purpose of identifying a subscriber, the mobile device 100 requires that a Subscriber Identity Module, or "SIM" card 126, be inserted into the SIM interface 128, thereby communicating with the network. .. SIM126 is one of the traditional "smart card" types used to identify a subscriber to a mobile device 100 and to personalize the mobile device 100 from another. Without SIM126, mobile device 100 would not be fully operational for communication with network 200. By inserting the SIM 126 into the SIM interface 128, the subscriber can access all the contracted services. Its services include web browsing, email, voice mail, and SMS (Short Message). It can include messaging such as Service) and MMS (Multimedia Messaging Services). More advanced services may include point of sale, field service, and salesperson automation. SIM 126 includes a processor and a memory for storing information. When the SIM 126 is inserted into the SIM interface 128, the SIM 126 is coupled to the microprocessor 102. To identify the subscriber, SIM126 includes user parameters such as IMSI (International Mobile Subscriber Identity). The advantage of using SIM126 is that subscribers do not have to be tied to a single real mobile device. SIM126 can also store additional subscriber information for mobile devices. The additional information includes data book (or calendar) information and recent call information.
The mobile device 100 is a battery-powered device and includes a battery interface 132 that receives one or more rechargeable batteries 130. The battery interface 132 is coupled to a regulator (not shown), which assists the mobile device 100 in providing the input voltage V + by the battery 130. Although today's technology uses batteries, future technologies, such as micro fuel cells, can supply the input voltage to the mobile device 100.
In addition to the functionality of the operating system, the microprocessor 102 enables the execution of software applications on the mobile device 100. A set of applications that control the operation of basic devices, including data and voice communication applications, are typically installed on the mobile device 100 during manufacturing. Another application that can be incorporated into the mobile device 100 is PIM (personal information). manager) would be. PIM has the ability to organize and manage data items of interest to subscribers. The data items are, for example, emails, calendar events, voicemails, appointments, and task items, but not limited to them. The PIM application can send and receive data items over the wireless network 200. PIM data items can be seamlessly organized, synchronized, updated, and the corresponding data items of mobile device subscribers are stored and / or associated with the host computer system over the wireless network 200. .. This feature creates a mirrored host computer on the mobile device 100 for such items. It can be especially advantageous when the host computer system is a mobile device subscriber's office computer system.
Additional applications may also be incorporated into mobile device 100 via network 200, auxiliary I / O subsystem 112, serial port 114, short range communication subsystem 122 or another suitable subsystem 124. The flexibility of installation of this application may increase the functionality of the mobile device 100 and provide functionality in enhanced equipment, communication-related functionality, or both. For example, secure communications applications may enable the functionality of e-commerce and other financial transactions made using the mobile device 100.
Serial port 114 allows subscribers to set preferences via an external device or software application. The serial port 114 extends the performance of the mobile device 100 by providing information or software downloads to the mobile device 100 by means other than via a wireless communication network. By using an alternative download path, for example, the encryption key can be taken into the mobile device 100 directly, and therefore via a reliable and reliable connection, thereby providing secure device communication.
The short-range communication subsystem 122 provides communication between the mobile device 100 and a different system or device without using the network 200. For example, subsystem 122 may include an infrared device, associated circuitry, and elements for short-range communication. Examples of short-range communications may include standards developed by the IrDA (Infrared Data Association), Bluetooth, and the 802.11 family of standards developed by the IEEE.
In use, received signals such as text messages, email messages, or web page downloads can be processed by the communication subsystem 104 and input to the microprocessor 102. The microprocessor 102 may then process the received signal for output to the display 110 or to the auxiliary I / O subsystem 112. For example, a subscriber may use a keyboard 116 with a display 110 and possibly an auxiliary I / O subsystem 112 to configure data items such as e-mail messages. The auxiliary substem 112 may include devices such as a touch screen, mouse, trackball, infrared fingerprint detector, or roller wheel capable of dynamically pressing a button. The keyboard 116 is an alphanumeric keyboard and / or a telephone-type keypad. The configured items may be transmitted over network 200 via subsystem 104.
The general operation of the mobile device 100 for voice communication is also substantially similar, except that the received signal can be output to the speaker 118 and the microphone 120 can generate a transmission signal. An alternative voice or audio I / O subsystem (eg, voice message recording subsystem) may be implemented in the mobile device 100. The voice or audio signal output is obtained primarily through the speaker 118, but the display 110 also provides additional information (eg, caller identification, voice call time, or information related to another voice call). Can be used to
With reference to FIG. 2, a block diagram of the communication subsystem element 104 of FIG. 1 is shown. The communication subsystem 104 includes a receiver 150, a transmitter 152, one or more built-in or internal antenna elements 154, 156, a LO (Local Oscillator) 158, and a processing module such as a DSP (Digital Signal Processor) 160. To be equipped.
The specific design of the communication subsystem 104 depends on the network 200 in which the mobile device 100 is intended to operate. Therefore, it should be understood that the design shown in Figure 2 serves only as an example. The signal received by the antenna 154 via the network 200 is input to the receiver 150. The receiver 150 may perform normal receiver functions such as signal amplification, frequency down conversion, filtering, channel selection, and analog-to-digital (A / D) conversion. The A / D conversion of the received signal allows the DSP160 to perform more complex communication functions (eg, demodulation and decoding). In a similar manner, the DSP160 processes the signal to be transmitted later (processing including modulation and coding). The signal processed by the DSP is input to transmitter 152 for digital-to-analog (D / A) conversion, frequency up-conversion, filtering, amplification and transmission over antenna 156 over network 200. The DSP160 not only processes communication signals, but also provides receiver and transmitter control. For example, the gain applied to the communication signal at the receiver 150 and the transmitter 152 can be adaptively controlled via an automatic gain control algorithm implemented in the DSP 160.
A wireless link between mobile device 100 and network 200 has one or more different channels (typically different RF channels) and associated protocols used between mobile device 100 and network 200. Can include. RF channels are a finite resource that needs to be preserved, typically due to overall bandwidth limitations and the finite battery power limitations of mobile devices 100.
When mobile device 100 is fully operational, transmitter 152 normally operates only when it is locked or transmitted to network 200, otherwise it is shut down to conserve resources. .. Similarly, to preserve power, receiver 150 is periodically shut down for a defined period of time, if any, until it needs to receive a signal or information.
With reference to FIG. 3, a block diagram of the nodes of the wireless network is shown as 202. During implementation, network 200 includes one or more nodes 202. The mobile device 100 communicates with the node 202 within the wireless network 200. In the implementation example shown in FIG. 3, the node 202 is configured based on GPRS (General Packet Radio Service) and GSM (Global System for Mobile) technology. Node 202 includes a BSC (base station controller) 204 with an associated tower station 206, a PCU (Packet Control Unit) 208 added to support GPRS in GSM, and an MSC (Mobile Switching Center) 210. HLR (Home Location Register) 212, VLR (Visitor Location Registry) 214, SGSN (Serving GPRS Support Node) 216, GGSN (Gateway) Includes GPRS Support Node) 218 and DHCP (Dynamic Host Configuration Protocol) 220. This list of elements is not intended to cover all the elements of node 202 in the GSM / GPRS network, but is a list of elements commonly used for communication over network 200.
In the GSM network, the MSC210 is coupled to a BSC204 and a telephone network such as the PSTN (Public Switched Telephone Network) 222, thereby satisfying circuit replacement requirements. The connection of PCU208, SGSN216, and GGSN218 to a public or private network (Internet) 224 (also referred to herein as generally a shared network infrastructure) represents the data path of a GPRS-capable mobile device. In a GSM network extended to GPRS performance, the BSC204 also includes a PCU (Packet Control Unit) 208 that controls segmentation and radio channel allocation by connecting to the SGSN216 and meets packet switching requirements. The HLR212 is shared by the MSC210 and SGSN216 to locate mobile devices and to enable both circuit switching management and packet switching management. Access to VLR214 is controlled by MSC210.
Station 206 is a fixed transmitting and receiving station. The station 206 and the BSC 204 form a fixed transmitter / receiver facility. The equipment of the fixed transmitter / receiver provides a specific reception area, usually referred to as a "cell", to the reception area of the wireless network. The fixed transmission / reception equipment transmits / receives communication signals to / from the mobile device in the cell via the station 206. Fixed transmitter / receiver equipment, under the control of the controller, modulates, and possibly encodes and / or encrypts, signals that are later transmitted to the mobile device, usually according to certain predefined communication protocols and parameters. Ordinarily perform functions such as. Similarly, if necessary, the fixed transmitter / receiver demodulates, possibly decodes, and decodes the communication signal received from the mobile device 100 in the cell. Communication protocols and parameters can vary from node to node. For example, one node may use different modulation methods than another node and may operate at different frequencies.
Persistence configuration data such as user profiles are stored in the HLR212 for all 100 mobile devices registered in a particular network. The HLR 212 also includes the location information of each of the registered mobile devices, which can be queried to determine the current location of the mobile device. The MSC210 is responsible for the location area group and stores the current data of the mobile device in the area of responsibility of the VLR214. In addition, the VLR214 also contains information about mobile devices accessing another network. The information in the VLR214 includes some of the persistent mobile device data transmitted from the HLR212 to the VLR214 for faster access. By moving additional information from remote HLR212 nodes to VLR214, the amount of traffic between those nodes can be reduced. Thereby, the response time of voice service and data service can be further shortened, and at the same time, the consumption of computer resources required can be reduced.
SGSN216 and GGSN218 are additional elements for GPRS support (ie, packet-switched data support) within GSM. The SGSN216 and MSC210 have similar responsibilities within the wireless network 200 by keeping track of the location of each mobile device 100. SGSN216 provides security features and access control for data traffic on network 200. The GGSN218 provides an internetwork connection with an external packet-switched network and connects to one or more SGSN216s via an IP (Internet Protocol) backbone network operating within network 200. During normal operation, the predetermined mobile device 100 needs to perform a "GPRS connection" in order to obtain an IP address and access the data service. For circuit switch audio channels, this is not necessary. It is ISDN (Integrated Services Digital) to route incoming and outgoing cells. This is because the Network) address is used. Today, all GPRS-capable networks use private, dynamically assigned IP addresses, and therefore the DHCP server 220 needs to be connected to the GGSN 218. There are many mechanisms for dynamically allocating IP, including a mechanism that uses a combination of a RADIUS (Remote Authentication Dial-In User Service) server and a DHCP server. Once the GPRS connection is complete, the APN (Access Point) in the GGSN 218 from the mobile device 100 via the PCU208 and SGSN216 A logical connection to Node) is built. The APN represents the logical termination of an IP tunnel that allows direct access to Internet compatible services or private network connections. Unless each mobile device 100 must be designated as one or more APNs and the mobile device 100 cannot exchange data without making a first GPRS connection to an approved APN, the APN will Also represents the security mechanism of Network 200. APNs can be thought of as similar to Internet domain names such as "myconnection.wireless.com".
Once the GPRS connection is complete, a tunnel is created and all traffic is exchanged within a standard IP packet using any protocol that can be supported in the IP packet. It includes tunneling methods (eg, IP over IP), as is often the case with IP security (IPsec) connections used with VPNs (Virtual Private Networks). The tunnel is also called the PDP (Packet Data Protocol) context, and the number available in the network 200 is limited. In order to make the best use of the PDP context, the network 200 runs an idle timer for each PDP context to determine if there is any movement. If the mobile device 100 does not use the PDP context, the PDP context can be released and the IP address can be returned to the IP address pool managed by the DHCP server 220.
With reference to FIG. 4, a block diagram illustrating the elements of the host system in one configuration example is shown. The host system 250 is usually a corporate office or another local area network (LAN), but in another embodiment it can be, for example, a home office computer or another private system. In this example shown in FIG. 4, the host system 250 is shown as the LAN of the organization to which the users of the mobile device 100 belong.
The LAN 250 includes a plurality of network elements connected to each other by the LAN connection 260. For example, a user's desktop computer 262a with the cradle 264 that came with the user's mobile device 100 is on LAN250. The cradle 264 of the mobile device 100 can be coupled to the computer 262a, for example via a serial or USB (Universal Serial Bus) connection. Another user computer 262b is also LAN Located on the 250, each may or may not have the cradle 264 that comes with the mobile device. The cradle 264 facilitates the capture of information from the user computer 262a to the mobile device 100 (eg, PIM data, a symmetric encrypted private key that facilitates secure communication between the mobile device 100 and the LAN 250). Cradle 264 can be particularly useful for bulk information updates, which are often done in the initialization of mobile devices 100 for use. The information downloaded to the mobile device 100 may include certificates used for exchanging messages. Those skilled in the art will appreciate that the user computers 262a and 262b can usually be connected to peripheral devices not specified in FIG.
An embodiment of the present invention generally relates to processing a message such as an e-mail message, and an embodiment of the present invention also generally relates to communication of the above message to the mobile device 100 and communication from the mobile device 100. Therefore, for simplification of disclosure, FIG. 4 shows only a subset of the network elements of LAN250, and those skilled in the art will appreciate additional elements not specified in FIG. 4 for this simple configuration. It will be understood that can be included. More generally, the LAN250 can represent a small portion of an organization's large network (not shown), can contain elements different from those shown in the example in Figure 4, and / or have different topologies. Can be placed.
In this example, the mobile device 100 communicates with LAN 250 via node 202 of wireless network 200 and shared network infrastructure 224 such as service provider network or public internet. Access to LAN250 may be provided via one or more routes (not shown). Computer devices in LAN250 can operate from behind a firewall or proxy server 266.
In another embodiment, the LAN 250 is equipped with a wireless VPN router (not shown) to facilitate data exchange between the LAN 250 and the mobile device 100. The concept of wireless VPN routers is new in the wireless industry and implies that it is possible to establish a VPN connection to a mobile device 100 directly over a particular wireless network. The prospect of using a wireless VPN router is only recently available and a new IP (Internet) Protocol) Wireless VPN routers can be used when version 6 (IPV6) reaches IP-based wireless networks. This new protocol may provide sufficient IP addresses to dedicate IP addresses to all mobile devices. As a result, information can always be pushed to mobile devices. The advantage of using a wireless VPN router is that it can be an off-the-shelf VPN element without the need to use individual wireless gateways and individual wireless infrastructures. In this other embodiment, preferably, the VPN connection can be a TCP (Transmission Control Protocol) / IP connection for sending a message directly to the mobile device 100, or a UDP (User Datagram Protocol) / IP connection.
Messages directed to users of mobile device 100 are first received by message server 268 on LAN250. The above message can come from any of multiple sources. For example, from computer 262b in LAN250, from wireless network 200 or another mobile device (not shown) connected to another wireless network, or from another computer device or device capable of sending messages. Messages can be sent by the sender, via the shared network infrastructure 224, and perhaps via an ASP (application service provider) or ISP (Internet service provider).
The message server 268 typically acts as a primary interface for exchanging messages, especially email messages, within an organization and on a shared network infrastructure 224. Each user in an organization set up to send and receive messages is typically associated with a user account managed by Message Server 268. An example of a message server 268 is the Microsoft Exchange® server. There are also implementations in which the LAN 250 can include multiple message servers 268. Message server 268 may also be adapted to provide additional functionality beyond message management. Its features include managing data related to calendars and task lists, for example.
When a message is received by the message server 268, the message is usually stored in message storage (not explicitly stated). After that, the message can be retrieved from the message storage device and sent to the user. For example, an email client application running on a user's computer 262a may request an email message associated with a user account stored on message server 268. The messages can then be typically retrieved from the message server 268 and stored locally on computer 262a.
While operating the mobile device 100, the user may wish to retrieve an email message for transmission to the handheld. An email client application running on mobile device 100 may request a message related to a user account from message server 268. An email client is configured to make this request at a given time interval (perhaps according to an organization's information technology) policy by a user or administrator, or at a given event at the user's direction. Can be done. Mobile device 100 is assigned its own email address, and messages that are explicitly addressed to mobile device 100 are automatically redirected to mobile device 100 when they are received by message server 268. There is also a form of realization.
Multiple wireless communication support elements 270 may be provided to facilitate wireless communication of messages and message-related data between the mobile device 100 and the elements of LAN 250. In this embodiment, the wireless communication support element 270 includes, for example, a message management server 272. The message management server 272 is specifically used to provide support for managing messages (eg, email messages) that are later processed by mobile devices. Generally, while the message is still stored in the message server 268, the message management server 272 can be used to control the conditions and modes when sending the message to the mobile device 100. The message management server 272 facilitates the processing of messages configured on the mobile device 100 that are sent to the message server 268 for later transmission.
For example, the message management server 272 can do the following: Its behavior is to monitor the user's "mailbox" for new email messages (for example, the message storage associated with the user account on message server 268); a new user-definable filter. Determining the conditions and aspects for relaying a message to a user's mobile device 100 by applying it to a message; for example, DES (Data Encryption). Compress and encrypt a new message using Standard) or Triple DES and push it to mobile device 100 over shared network infrastructure 224 and wireless network 200; and configured on mobile device 100 Received a message (eg, a message encrypted with Triple DES), decrypted and decompressed the configured message, and if necessary, the configured message was generated from the user's computer 262a. Reformat the configured message so that it looks like, and send the configured message to the outgoing message server 268 via a new route.
Certain characteristics and restrictions associated with messages sent from and / or received by mobile device 100 may be defined by, for example, an administrator in accordance with IT policies and may be enforced by message management server 272. .. They need to, for example, whether the mobile device 100 can receive encrypted and / or encrypted messages, the minimum size of the encryption key, and the outgoing messages to be encrypted and / or encoded. Whether or not and whether or not a copy of all secure messages sent from the mobile device 100 should be sent to a given copy address may be included.
Message management server 272 may be adapted to provide another control function. Its function is, for example, to simply push certain message information or a predetermined portion of a message stored in the message server 268 (eg, a "block") to the mobile device 100. For example, when a message is first retrieved from message server 268 by mobile device 100, message management server 272 is adapted to push only the first part of the message to mobile device 100, which part is of a given size. There is (for example, 2KB). The user can then request further messages, which are sent by the message management server 272 to mobile device 100 in blocks of similar size, perhaps with a predetermined maximum message size.
Therefore, the message management server 272 can facilitate good control of the data type and amount of data transmitted to the mobile device 100 and help minimize the potential waste of bandwidth or other resources. ..
Those skilled in the art will appreciate that the message management server 272 does not need to be implemented on LAN250 or an individual server that exists in another network. For example, some or all of the functionality associated with Message Management Server 272 may be integrated with Message Server 268, or with another server on LAN250. In addition, the LAN250 may include multiple message management servers 272, especially in other embodiments that need to support a large number of mobile devices.
Embodiments of the present invention generally relate to the processing of coded messages such as encrypted and / or signed e-mail messages. The Simple Mail Transfer Protocol (SMTP), RFC822 headers, and Multipurpose Internet Mail Extensions (MIME) body parts can be used to define typical email message standards that do not require encoding, but the MIME protocol. A version of Secure / MIME (S / MIME) can be used to communicate coded messages (in other words, secure messaging applications). S / MIME enables end-to-end authentication and confidentiality, protecting the integrity and confidentiality of data from the time the message author sends the message until it is decrypted and read by the recipient of the message. To facilitate the communication of secure messages, another well-known standard and protocol (eg, PGP (Pretty Good)) Privacy®), OpenPGP, and others well known to those of skill in the art) can be used.
Secure messaging protocols such as S / MIME provide confidentiality and integrity by relying on public and private encryption keys, and information that provides authentication and authorization by relying on PKI (Public Key Infrastructure). To convey. Data encrypted with the private key of a private / public key pair can only be decrypted with the corresponding public key of that pair, and vice versa. Public key information is shared, but private key information is never disclosed.
For example, if the sender wishes to send the message to the recipient in encrypted form, the message is encrypted using the recipient's public key. The message can only be deciphered using the recipient's private key. Alternatively, in some coding techniques, a one-time session key is generated and used to encrypt the body of the message, usually using a symmetric encryption technique (eg, Triple DES). .. The session key is then encrypted using the recipient's public key by a public key cryptographic algorithm such as RSA. The session key can only be decrypted using the recipient's private key. The body of the message can be decrypted by using the decrypted session key. Message headers can be used to identify the particular encryption method that needs to be used to decrypt the message. In another embodiment, another encryption method based on the public key cryptosystem may be used. However, in either case, only the recipient's private key can be used to facilitate decryption of the message. In this way, the confidentiality of the message can be maintained.
As a further example, the sender can sign the message with a digital signature. A digital signature is a digest of a message encrypted with the sender's private key (eg, a hash of the message), which can be added to the outgoing message. To verify the signature of a message on reception, the recipient uses the same techniques as the sender (eg, using the same standard hashing algorithm) to obtain a digest of the received message. To get which is the digest that matches the received message, the recipient uses the sender's public key to decrypt the digital signature. If the digest of the received message does not match, the fact that it does not match means that the content of the message is changed during transmission and / or the public key used for matching is not the public key of the sender who created the message. Suggest. By matching the digital signature in this manner, the sender's authentication and message integrity can be maintained.
The encoded message can be encrypted, signed, or encrypted and signed. The authenticity of the public key used in this work is confirmed using a certificate. A certificate is a digital document issued by a certificate authority (CA). A certificate is used to authenticate the association between a user and his public key and basically provides a trust level of trust in the user's public key. Certificates contain information about the owner of the certificate and are usually formatted according to generally accepted standards (eg, X.509).
Consider Figure 5, where an exemplary proof chain 300 is shown. The certificate 310 issued to "John Smith" is an example of a certificate issued to an individual and may also be referred to as an end entity certificate. The end-entity certificate 310 typically identifies the certificate owner 312 (John Smith in this example) and the certificate issuer 314, with the issuer's digital signature 316 and the certificate owner's public key. Includes 318 and. Certificate 310 may typically include other information and attributes that identify the owner of the certificate (eg, email address, organization name, organizational unit name, location, etc.). When an individual composes a message to send to a recipient, it usually accompanies the message with the individual's certificate 3<u style="single">1</u>Contains 0.
For a trusted public key, the configuration it issues must be trusted. The relationship between a trusted CA and a user's public key can be represented by a set of related certificates (called a certificate chain). By following the certificate chain, the validity of the certificate can be determined.
For example, in the exemplary certificate chain 300 shown in FIG. 5, the recipient of a message that John Smith intended to send may wish to check the trust status of certificate 310 attached to the received message. For example, in order to confirm the trust status of the certificate 310 on the recipient's computer device (for example, the computer 262a in FIG. 4), the certificate 320 of the issuer ABC is obtained, and by using the certificate 320, the certificate 310 Make sure that is indeed signed by the issuer ABC. The certificate 320 may already be stored in the certificate storage device of the computer device. Alternatively, it may need to be retrieved from a certificate source (for example, LDAP server 284 in Figure 4, or another public or private LDAP server). Certificate 320 is already stored on the recipient's computer device, and if the recipient indicates that the certificate has been trusted, then the certificate is connected to the stored and trusted certificate. The 310 is considered trusted.
However, in the example shown in FIG. 5, certificate 330 requires verification of the authenticity of certificate 310. Certificate 330 is self-signed and is referred to as the "root certificate". Therefore, certificate 320 may be referred to as an "intermediate certificate" in the certificate chain 300. Assuming that the chain to the root certificate can be determined for a particular end entity certificate, any given certificate chain to the root certificate may not include an intermediate certificate. Or it may include one or more. If certificate 330 is a root certificate issued by a trusted source (eg, trusted by a large certificate authority such as Verisign or Entrust), then certificate 310 leads to a trusted certificate. Because of this, it can be considered to be trusted. It implies that both the sender and the recipient of the message trust the source of the root certificate 330. A certificate can be considered "untrusted" if the certificate cannot be attached to a trusted certificate.
The authentication server remembers the certificate and a list that identifies the revoked certificate. By accessing these authentication servers, the certificate can be obtained, and the authenticity and revocation status of the certificate can be confirmed. For example, an LDAP (Lightweight Directory Access Protocol) server can be used to obtain a certificate, and an OCSP (Online Certificate Status Protocol) server can be used to check the revocation status of a certificate.
Standard email security protocols typically facilitate the transmission of secure messages between non-mobile computer devices (eg, computers 262a and 262b in Figure 4; remote desktop devices). Seeing FIG. 4 again, the mobile device 100 is designed to ensure that the signed message received by the sender is read from the mobile device 100 and the encrypted message is sent to that sender. Adapted to remember another person's certificate and associated public key. The certificate stored on the user's computer 262a can usually be downloaded from the computer 262a to the mobile device 100, for example via a cradle 264.
The certificate stored in the computer 262a and downloaded to the mobile device 100 is not limited to a certificate related to an individual, but may include, for example, a certificate issued to a CA. Certain certificates stored on computer 262a and / or mobile device 100 may also be explicitly indicated by the user as "trusted". Therefore, when a certificate is received by a user of the mobile device 100, the certificate is stored in the mobile device 100 and is shown to be trusted, or is trusted. By matching with the certificate determined to be tied to the certificate, it can be verified on the mobile device 100.
The mobile device 100 may be adapted to store the private key of the public / private key pair associated with the user. Thereby, the user of the mobile device 100 can sign the message created and exited by the mobile device 100, and decrypt the message sent to the user encrypted by the user's public key. be able to. For example, the private key can be downloaded from the user's computer 262a to the mobile device 100 via the cradle 264. Preferably, the private key is exchanged between the computer 262a and the mobile device 100 so that the user can share one identification and one way to access the message.
The user computers 262a and 262b can obtain certificates from multiple sources instead of the storage devices of the computers 262a and 262b and / or the mobile device (eg, mobile device 100). For example, their certificate sources can be private (eg, for use within an organization) or public, can be local or remote, and can be accessed from within the organization's private network or over the Internet. obtain. In the example shown in Figure 4, multiple PKI servers 280 associated with the organization are on LAN250. The PKI server 280 is the CA server 282 that issues the certificate, the LDAP server 284 that is used to retrieve and download the certificate (for example, for individuals in the organization), and to check the revocation status of the certificate. Includes OCSP server 286 used.
The user computer 262a may retrieve the certificate from LDAP server 284 for download to mobile device 100, for example via cradle 264. However, in another embodiment, the LDAP server 284 can be accessed directly by the mobile device 100 (ie, "via radio waves" in this situation), where the mobile device 100 is an individual certificate via the mobile data server 288. You can search and retrieve books. Similarly, the mobile data server 288 may be adapted so that the mobile device 100 can directly query the OCSP server 286 to check the revocation status of the certificate.
Those skilled in the art will not need that the mobile data server 288 be on an individual computer device of another element of the LAN 250, and in another embodiment, the mobile data server 288 will be on the same computer device as another element of the LAN 250. It will be understood that can be provided. Moreover, in another embodiment, the functionality of the mobile data server 288 may be integrated with the functionality of another element of the LAN 250 (eg, message management server 272).
In another embodiment, only the selected PKI server 280 can be made accessible to the mobile device (for example, the certificate revocation status is allowed to be checked from the mobile device 100, but the certificate download is by the user. Only allowed from computers 262a and 262b).
In another embodiment, one PKI server 280 may be made accessible only to mobile devices registered with a particular user, for example, perhaps in accordance with IT policy, as specified by the IT administrator.
Other sources of certifiers (not shown) may include, for example, a Windows® certificate storage device, another secure certificate storage device on or off LAN250, and a smart card.
Referring to FIG. 6, a block diagram illustrating an example element of a coded message that can be received by a message server (eg, message server 268 of FIG. 4) is shown as approximately 350. A coded message 350 is typically a header part 352, a coded body part 354, one or more coded attachments 356 of any choice, and one or more encrypted sessions. Includes key 358 and one or more signatures and signature-related information 360. For example, the header portion 352 typically includes address information such as "To", "From", "CC" addresses, and may include, for example, a message length indicator and an identifier for the sender's encryption and signature method. The actual content of the message usually contains a message body, i.e. part 354 of the data, and perhaps one or more attachments 356, which can be encrypted by the sender using the session key. When using a session key, the key is encrypted for each of the intended recipients with its own public key for each recipient and is included in the message at 358. If the message is signed, the signature and the information 360 associated with the signature are also included. It can include, for example, the sender's certificate.
The standard for coded messages as shown in FIG. 6 is provided by way of example only, and those skilled in the art will be able to apply embodiments of the present invention to coded messages of another standard. It will be understood that it is possible. Depending on the specific messaging method used, the coded message elements may appear in a different order than that shown in Figure 6. The elements of a coded message can be few or many, or can contain other elements, which means that the coded message is encrypted or signed, or encrypted and signed. It can depend on the person.
Embodiments of the present invention are generally directed to systems and methods for more efficient retrieval of certificates in the device and retrieval of certificates for storage in the device. In one embodiment, the device is a mobile device (eg, mobile device 100 in Figure 4), and the certificate retrieval application that resides and runs on the mobile device is one or more certificate servers (eg, LDAP in Figure 4). It is programmed on server 284) to initialize the certificate lookup. In this embodiment, the mobile device looks up and retrieves each certificate from the certification server via an intermediate computer device (eg, mobile data server 288 in FIG. 4).
With reference to FIG. 4, consider an example in which the certificate retrieval application of the mobile device 100 retrieves and retrieves individual certificates from the LDAP server 284 via the mobile data server 288. The search request is received by the certificate search application. The request is usually a request by a user who provides the first name, last name, and email address of an individual for whom the user is desired to retrieve the certificate. For example, by configuring a search query where you enter a few letters of the name and return all certificates issued with names that include those letters as a prefix, or by wildcards or blanks in the input field. A search request can be expanded by extending the search by using items. The search request is then propagated from the mobile device 100 to the mobile data server 288, which queries LDAP server 284 for the requested certificate. In this embodiment, the retrieved certificate is retrieved by the mobile data server 288 and specific search result data associated with each of the retrieved certificates (eg, the individual (or entity) to which each certificate was issued). ) Common name and email address) are transmitted to the mobile device 100, which may generate a list from the data of the search results for display to the user. The user can then select a particular certificate to download and store on the mobile device 100 from the list. The selection is then propagated to the mobile data server 288, from which the selected certificate is downloaded to the mobile device 100.
In the first example, instead of the entire certificate for the mobile device 100, by communicating only the specific search result data used to generate the list of installed certificates, and by the identification selected by the user. Certificate retrieval and retrieval can be performed more efficiently (for example, in terms of time and bandwidth) by simply downloading the certificate. However, the prior art system indicates to the user that the certificate in the list is stored in the certificate storage of the mobile device 100 without downloading the certificate to the mobile device 100 to facilitate the decision. Can be adapted to determine or provide. In such a system, the selected certificate may need to be downloaded to ensure that the selected certificate is not stored in certificate storage. This takes time and bandwidth and is potentially unnecessary.
Therefore, embodiments of the present invention generally relate to a method, in which the method does not require the entire certificate to be downloaded to the device and whether the certificate can be stored in the device (eg, mobile device 100). Facilitate that decision.
With reference to FIG. 7, a flowchart showing a process in the method of retrieving and retrieving a certificate in an embodiment of the present invention is generally shown as 400.
In step 410, the first computer device receives a request from the second device to search for at least one authentication server for the certificate. In an exemplary embodiment, the first computer device is a second device and a mobile data server (eg, FIG. 4) where the second device is a mobile device (eg, mobile device 100 in FIG. 4). Acts as an intermediate between at least one authentication server, such as Mobile Data Server 288). In one exemplary implementation, the authentication server to be retrieved can be an LDAP server (eg, LDAP server 284 in FIG. 4).
The request may consist of data provided by an authentication lookup application running and resident on the second device. The data can arise from user input to an authenticated search application (eg, if the search is initiated by a user), or from data generated by an application that initiates the search in a different embodiment. Although the data typically contains at least one name and / or email address, it will be appreciated by those skilled in the art that various search queries can be constructed without departing from the scope of the invention.
For convenience, further steps of Method 400 are described with reference to exemplary implementations. In an exemplary embodiment, the first computer device is a mobile data server and the second device is a mobile device. However, in the embodiment of the invention described with reference to Method 400 or Method 400b of FIG. 7B, the first computer device is not a mobile data server, but any other computer device, and / or a second. The device can be applied to run any other computer device, not a mobile device. For example, in a system configuration with first and second devices and at least one authentication server, data transmission between the first and second devices generally involves the first device and at least one authentication. It is more costly than transmitting data to and from a server (eg, in terms of time and / or bandwidth) and may benefit from the application of embodiments of the invention.
In step 420, the mobile data server introduces at least one authentication server for the certificate based on the search request from the mobile device authentication search application received in step 410. The certificate found by the search is retrieved from at least one authentication server by the mobile data server.
In step 430, the mobile data server returns the search result data for each retrieved certificate to the mobile device authentication search application. The returned search result data typically includes the common name for which each certificate is issued and the email address of the individual (or group). However, according to this embodiment of the invention, the mobile data server analyzes each retrieved certificate to identify the serial number and issuer of each certificate returned as part of the search result data. By doing so, each retrieved certificate is further processed.
In some embodiments, the certificate retrieved in step 420 is only temporarily stored until the search result data is returned to the mobile device in step 430 and the retrieved certificate is deleted. In other embodiments, the certificate retrieved in step 420 may be cached or otherwise stored more permanently (eg, until the response to the returned search result data is retrieved from the mobile device, or. For any given time).
In step 440, the certificate search application applies the serial number and issuer data for each retrieved certificate and the serial number and issuer data for the certificate stored on the mobile device in one or more designated certificate storage devices. Compare with issuer data.
In step 450, a list of retrieved certificates is generated and displayed to the user of the mobile device. The list is generated from at least a subset of the search result data returned to the mobile device in step 430. For example, the list may identify each found certificate by a common name and / or the email address of the individual (or group) to which the certificate is issued. In one embodiment of the invention, an indicator with each entry in the list paired with each retrieved certificate may also be provided, and the indicators will be the respective certificates based on the determination in step 440. Indicates whether is already stored on the mobile device. Therefore, the user does not have to select the certificate already stored on the mobile device for download, and the duplicate certificate does not necessarily have to be downloaded to the mobile device. The indicator may include, for example, a checked or unchecked box. As a further example, each entry in the list may or may not be highlighted, depending on the state of the indicator.
In step 460, a certificate is selected for download, for example by a user of a mobile device.
In step 470, the data identifying the selection in step 460 is retrieved from the mobile device by the mobile data server and the selected certificate is then returned to the mobile device for storage in the mobile device. In some embodiments, it may not be necessary for the mobile data server to query the authentication server for the selected certificate before the certificate is returned to the mobile device (a process not shown), and in the end, the previous The certificate is not held by the mobile data server for download.
Explaining FIG. 7B, a flow chart showing a process in a method of retrieving and retrieving a certificate according to another embodiment of the present invention is generally shown as 400b. Method 400b becomes method 400, except that the search result data for the certificate returned by the first computer device to the second device constitutes a hash of at least a portion of each retrieved certificate. It is similar.
In particular, in step 430b, the mobile data server returns the search result data for each positioned certificate to the certificate search application on the mobile device. The returned search result data typically includes a common name and the email address of the individual (or group) from which each certificate is issued. According to this embodiment of the invention, the mobile data server further processes each retrieved certificate by applying a hash algorithm to at least a portion of the hash of each retrieved certificate. The hash is then returned as part of the search result data. In one implementation, the entire certificate is hashed and produces a returned hash. However, in different implementations, one or more specific parts or fields of a certificate can be hashed to produce the returned hash, but it is possible that the hash independently identifies the exact same certificate. , Can be reduced based on the hashed part or field.
In step 440, the authentication retrieval application generates a hash for each certificate stored on the mobile device in one or more designated certificate storage devices, each generated hash and each retrieved. Compare with the hash for the certificate to determine if each certificate is stored on the mobile device. When generating a hash of a stored certificate, the same hashing algorithm used in step 430b applies to this step (or in the same part or field of the stored certificate if the entire certificate is not hashed). Applies. Therefore, if the generated hash of a given certificate matches the hash received from the mobile data server in step 430b, then the match is considered to have been determined.
Details accompanying the rest of Method 400b are provided with reference to Figure 7A.
Other embodiments of the invention that can be used to uniquely identify a certificate and can be communicated more efficiently (eg, in terms of time and / or bandwidth) than communicating the entire certificate. The data can be returned to the second device as part of the search result data and used to determine if the certificate was stored in the second device.
The embodiments of the present invention described above generally allow a user to quickly determine which certificate needs to be downloaded to a computer device without making costly demands. In a different embodiment of the invention, the authentication search request cannot be initiated by the user, but instead can be initiated by an application running on a second device (perhaps a certificate retrieval application or any other application). In these embodiments, the list could not be generated for the display paired to the user (eg, in step 450 of FIGS. 7A and 7B) and identified which certificate could be stored in the second device. Later, the certificate can be automatically specified for download without user intervention (eg, in step 440 of FIGS. 7A and 7B).
In different embodiments, the invention may also be applied to other applications that are not involved in certificates. For example, some earlier techniques may be used, for example, to determine if a particular contact data record or electronic document is stored on a computer device.
The steps of the method of retrieving and retrieving a certificate in an embodiment of the invention may be provided as executable software instructions stored on a computer-readable medium, which may include a transmission type medium.
The present invention has been described with respect to a plurality of embodiments. However, it will be appreciated by those skilled in the art that other modifications and amendments may be made without departing from the scope of the invention as defined in the appended claims.
<figref num="1">It is a block diagram of a mobile device in one realization example.</figref><figref num="2">It is a block diagram of the communication subsystem element of the mobile device of FIG.</figref><figref num="3">It is a block diagram of a node of a wireless network.</figref><figref num="4">It is a block diagram which illustrates the element of the host system in one configuration example.</figref><figref num="5">It is a block diagram which shows an example of a certificate chain.</figref><figref num="6">It is a block diagram which shows the element of an example of a coded message.</figref><figref num="7A">It is a flowchart which shows the process of the method of searching and retrieving a certificate in one Embodiment of this invention.</figref><figref num="7B">It is a flowchart which shows the process of the method of searching and retrieving a certificate in another embodiment of this invention.</figref>
Code description
100 mobile devices 272 Message management server 280 PKI server 282 CA server 284 LDAP server 286 OCSP server 288 Mobile data server 310, 320, 330 certificate 350 messages
8 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2001197055A | Cites | Japan |
| JP2004048139A | Cites | Japan |
| JP2005259332A | Cites | Japan |
| JP2001265216A | Cites | Japan |
| JP200346499A | Cites | Japan |
28 members in 13 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 04104240 | European Patent Office (EPO) | A | |
| 04104240 | European Patent Office (EPO) | A | |
| 041042409 | European Patent Office (EPO) | – | |
| 200404104240 | – | – | – |
| EP20040104240 | – | – | – |
Members28
| Document | Office | Kind | |
|---|---|---|---|
| CA2517211A1 | Canada | A1 | |
| CN1744490A | China | A | |
| EP1633101A1 | European Patent Office (EPO) | A1 | |
| AU2005204223A1 | Australia | A1 | |
| JP2006074786A | Japan | A | |
| US2006059332A1 | United States of America | A1 | |
| SG120313A1 | Singapore | A1 | |
| BRPI0503811A | Brazil | A | |
| KR20060050933A | Republic of Korea | A | |
| TW200629859A | Taiwan Province of China | A | |
| HK1087274A1 | Hong Kong, China | A1 | |
| KR100650432B1 | Republic of Korea | B1 | |
| TWI282231B | Taiwan Province of China | B | |
| AU2005204223B2 | Australia | B2 | |
| EP1633101B1 | European Patent Office (EPO) | B1 | |
| AT392080T | Austria | T | |
| ATE392080T1 | Austria | T1 | |
| DE602004013000D1 | Germany | D1 | |
| DE602004013000T2 | Germany | T2 | |
| CN100531029C | China | C | |
| US7640428B2 | United States of America | B2 | |
| US2010100730A1 | United States of America | A1 | |
| JP4530953B2This record | Japan | B2 | |
| CA2517211C | Canada | C | |
| US8209530B2 | United States of America | B2 | |
| US2012239927A1 | United States of America | A1 | |
| US8566582B2 | United States of America | B2 | |
| BRPI0503811B1 | Brazil | B1 |
31 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Written request for registration of change of domicileJAPANESE INTERMEDIATE CODE: R313531S531 | S531 | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of acceptance of power of attorneyJAPANESE INTERMEDIATE CODE: A7422RD02 | RD02 | |
| Notification of resignation of power of attorneyJAPANESE INTERMEDIATE CODE: A7424RD04 | RD04 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 4530953
- Publication, DOCDB
- 4530953
- Publication, EPODOC
- JP4530953B
- Application
- 253511
- Application, DOCDB
- 2005253511
- Application, EPODOC
- JP20050253511
Titles2
- Japanese
- 証明書を検索し取り出すシステムおよび方法
- English
- Systems and methods for finding and retrieving certificates
Classification
- CPC, 7
- H04L63/0428
- G06F15/00
- H04L63/062
- H04L63/0823
- H04W80/00
- H04L51/58
- H04L51/222
- IPC, 3
- H04L9 32
- H04L12 28
- H04L29 06
