Method for executing ciphering starting processing between thin client and server device in data network

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to secure and reliable data communication between a client computer and a server computer, and more particularly between a two-way interactive communication device and a server computer in a data network such as a wireless network or the Internet. Regarding methods and devices for performing cryptographic initiation processing; here mobile devices. Two-way interactive communication devices such as cellular phones, landline phones, and control devices for Internet devices generally have limited computing resources such as computing power, memory, and graphic display power.

【0002】

[Conventional technology]

Electronic commerce is growing rapidly on the Internet. Electronic transactions are all done via the global internet. Trade support system for a wide range of business support services, supplies, products, specialized products, specially made supplies and services; ordering and replenishment support system; installation Assistance system; an integrated concept designed to work with management information and statistical reporting systems. However, the Internet is widely open and is a public and international network of computers and electronics interconnected worldwide. In order to do business on the Internet, a company or individual must have an efficient, reliable and secure way to communicate personally between them. Much effort has been made to protect the information of owners who travel across the Internet, most of which are computer devices on landline networks.

【0003】

One of the ongoing efforts is to use cryptography to ensure a personal communication session between the client computer and the server computer. Cryptography provides a way to transmit information across uncertain communication channels without disclosing the content of the information to anyone eavesdropping on the communication channel. Cryptographic encryption processing is used to protect the content of the data being transmitted from access by an unauthorized third group, while the intended group uses the corresponding decryption processing. It is possible to read the data. Encryption is the process of transforming a set of data into some unreadable "encrypted" form. Its purpose is to ensure privacy by hiding the actual content of the information from unintended recipients such as eavesdroppers who may access the encrypted data. Decryption is the reverse process of encryption. Decryption is the process of transforming the encoded data back into some understandable form that allows access to the actual content. Both encryption and decryption require the use of certain secret information, commonly referred to as the "key." The same key is used for both encryption and decryption, depending on the type of encryption mechanism used, while for other mechanisms the key used for encryption and decryption is different.

【0004】

Traditional cryptography knows the same secret key and is based on the sender and recipient of the message used: the sender uses the secret key to encrypt the message, and the recipient uses the same to decrypt the message. Use a key, often referred to as a secret key. Therefore, to keep the communication channel secure, no user other than the sender and receiver is allowed access to the private key. This method requires a private key or a secure channel for transmitting a symmetric private key between the sender and the receiver.

【0005】

The relatively new concept of encryption, known as public key cryptography, uses two different keys. Two-Key Public Key In a cryptosystem, each user has two keys: a public public key and a private key that is kept secret. To encrypt the message to the user receiving the public key, the sender uses the recipient's public key to encrypt the message. The recipient uses his private key to decrypt the message. Thus secure communication is possible without the need to transmit the private key through secure channels.

【0006】

The first advantage of public key cryptography is that private keys never need to be transmitted or made public to anyone. On the other hand, in private key cryptography, the private key or the information for generating it must be transferred (either by hand or by using a secure communication channel). However, one known drawback of using public keys for cryptography is the speed of encryption. In particular, there are popular private key cryptography methods that are significantly faster than other currently available public key cryptography methods. Therefore, encryption speed is a very important factor when considering the comparison between private key cryptography and public key cryptography when used in secure communication sessions involving thin client devices with limited computing resources. So-called thin client (thin) The client) device is considered to be a two-way interactive communication device such as a mobile computing device, a cellular telephone, a landline telephone, or an Internet device control unit. Thin client devices are generally designed to be as small, light, low power, economical and portable as possible. Such thin client designs typically have computing power typically less than 1% of the power of a typical desktop or mobile computer, for example, and their memory capacity is typically less than 250 kilobytes. In addition, communication between the thin client and the landline server computer is often over a wireless network characterized by low bandwidth, and the cost of that communication time is high. Therefore, private key cryptography is often used in communication sessions between thin clients and landline computers to meet speed requirements.

【0007】

The distribution of the private encryption key between two trusted communication devices is called the cryptocurrency process. Mutual distribution of private encryption keys in a secret way can be used as one of the cryptocurrency initiation methods, but its cost when there are hundreds or thousands of thin clients communicating with one landline server computer. Is significantly higher. Moreover, human error and reliability regarding this method make its practical application difficult. Therefore, there is a strong need for a general purpose cryptographic start process that allows the automatic distribution of private keys between each thin client and the landline server computer.

【0008】

An agreement protocol is used alone for each of the two communication groups to make a private key arrangement, but no authentication is provided. The use of key arrangement protocols does not guarantee that the arrangement key will not be attacked in any way. The lack of authentication in such schemes makes these negotiated keys strong enough to remain secure for long periods of time. There is a solution that modifies these schemes to have authentication in place, but it requires some secret information pre-loaded in the communication device, thus allowing communication between the thin client device and the server computer. The result is more. Additional communication requires a significant increase in the computing performance and memory of the thin device, increasing the potential for information coming from the server computer, which is generally undesirable. Therefore, there is a further need for a cryptographic start-up process that performs a cryptographic start-up process between two communication devices that use minimal computing power and memory.

【0009】

[Problems to be Solved by the Invention]

An object of the present invention is to provide a method of establishing a secure communication channel between a client device and a server device on a data network.

【0010】

[Means for solving problems]

The above purpose is to generate a client private value of a client device; generate a client public value based on the client private value of the client device; send a key request message consisting of the client public value from the client device to the server device. Achieved by receiving a server response from the server device to the key request message; with respect to the client private value and the server response, and by a method consisting of each step of generating a client-side private key by a key agreement protocol.

【0011】

BEST MODE FOR CARRYING OUT THE INVENTION

These and other features and advantages of the present invention will be better understood by the detailed description with reference to the drawings and claims below. Notation and predicate In the following detailed description of the invention, many specific details are given to fully understand the invention. However, it will be apparent to those skilled in the art that the present invention can be practiced without these specific details. The following well-known methods, procedures, components and circuits will not be described in detail for ease of understanding.

【0012】

The following detailed description of the present invention is made mostly with respect to procedures, steps, logical blocks, processes, and other symbolic representations that resemble networked data processing devices. Descriptions and expressions of these processes are the means used by those skilled in the art to most efficiently convey the content of their work to other skilled in the art. The present invention provides a method and a device for performing cryptographic start processing between interactive communication devices having a server device on a data network. The architecturally detailed method described below is a self-contained sequence of processes or steps that leads to the desired result. These steps or processes require a physical amount of physical manipulation. Although not necessary, these quantities are usually stored, transferred, combined, compared, and displayed in the form of electrical signals, or otherwise handled by a computer system or electrical computing device. take. It turns out that it is useful in principle to refer to these signals as bits, values, elements, symbols, operations, messages, numbers, or the like for normal use reasons. Is. All of these similar terms relate to the appropriate physical quantity and are simply convenient labels applied to these quantities. The use of terms such as "processing" or "computing" or "matching" or "display" throughout the present invention, as is apparent from the following description without particular reference, is to use computing devices or other electronic devices. The operation of the computing device and the operation and conversion of the data represented as the physical quantity in the register and memory of the computing device to other similarly represented data represented as the physical quantity in the device. Regarding processing. Introduction to the Diffie-Hellmann key arrangement protocol The Diffie-Hellman key arrangement protocol, also referred to as an exponential key arrangement, allows two users to exchange private keys on an insecure medium without any prior secret. This protocol has two system parameters p, g. Both p and g are open to all users in the system and can be used by them. The parameter p is the first number, and the parameter g (usually called a generator) is an integer less than or equal to p, which modulos the first p and multiplies itself a number of times from 1 to p-1. It is possible to generate all elements up to. Group A Transducer Consider the case where Group B is about to agree to share a private key using the Diffie-Hellmann key arrangement protocol. They proceed as follows. First, group A generates a random private value a, and group B generates a random private value b. They then use the parameters p, g and their private values to get their public values. The public value of group A is g^amod p, the public value of population B is g^{b b}mod p. Then they exchange their public value. Eventually group A is k_ab= (g^{b b})^aCalculate mod p, population H is k_ba= (g^a)^{b b}Calculate modp. k_ab= k^baSince = k, group A and group B share the private key k here. This protocol relies on a discrete logarithmic problem for its security. It is the two public values g given when the shared secret key prime p is large enough^amod p and g^{b b}mod p to k = g^ab It is assumed that it is not feasible to calculate mod p.

【0013】

Diffie-Hellman key exchange is vulnerable to middleman attacks. In this attack, the opposing group X steals the public value of group A and sends his own public value to group B. When group B sends his public value, group X exchanges it for his own number and sends it to group A. Thus, group X and group A match with a shared key, and group X and group B match with another shared key. After this exchange, Group X can easily decrypt any message sent by Group A or Group B and read and modify it before encrypting it with the appropriate key and sending it to the correct group. Is. This weakness is because the Diffie-Hellmann key exchange cannot trust the participants.

【0014】

A certified Diffie-Hellmann key arrangement was introduced to overcome the attack of the intermediary. Immunity is achieved by allowing two groups to trust each other through the use of digital signatures. The basic concept is as follows. Prior to the exchange protocol, the two groups A and B have a public / private key pair and proof for the public key, respectively. During the exchange protocol, group A uses its private key to compute the signature on a message, and group B is given the public value g along with its signature and its public key certificate.^aSend mod p. Group B also uses its private key to compute the signature on a message and gives Group A a public value g along with its signature and its public key certificate.^aSend mod p. Even if Group X still intercepts the message between Groups A and B, it cannot forge the signature without Group A's private key and Group B's private key. Therefore, the enhanced protocol can reject the attack of the vector. Preferred Examples According to the principle of the present invention, the cryptographic activation process for supplying the same private key to two communication groups is performed between the thin client and the server computer over the data network. Thin client devices typically have limited computing power and limited working memory. The server computer communicates with multiple such thin client devices. Only a pair of public values are exchanged between the thin client device in the data network and the server computer to ensure the security of the private keys on both sides and reduce network traffic. Each side generates its own private key from a self-generated private value along with the other side's public value received by a commonly used key arrangement protocol such as the Diffie-Hellmann key arrangement protocol. Encrypted by manual verification of the client-side private key generated after the verification process and the signatures generated from the two generated private keys to ensure that the generated private key is the same on both sides. The exchange of messages is continued. The private key proves to be the same when the encoded message is successfully decrypted by another private key, and is secure when the signature is verified. In order to reduce network traffic, the confirmation process is a piggyback method with a session request from the thin device to establish a secure and reliable communication session with the server computer. The present invention does not require significant computing performance and working memory and allows automatic distribution of private keys between each thin client and the server computer.

【0015】

Here, the same reference numerals are used throughout the drawings to refer to the same parts. FIG. 1 shows an outline of a data network 100 in which the present invention is implemented. The data network 100 includes an airnet 102 generally referred to as a wireless network and a landnet 104 generally referred to as a landline network. It operates as a communication medium for data transmission in each. Airnet 102 is called a carrier network because data transmission mediates space. This is because each airnet is controlled and operated by carriers such as AT & T and GTE. Each carrier has CDPD, CDMA, GSM, for Airnet 102 It has its own communication scheme like TDMA. The Landnet 104 used interchangeably here is the Global Internet, the Internet or other personal networks. To see 106, this is a mobile device, a cellular phone, a landline phone, or a mobile device that is an internet equipment controller that can communicate with the airnet 102 via antenna 108. The Airnet 102 can communicate with a plurality of two-way communication devices at the same time, and FIG. 1 shows only one representative example. Similarly, the Internet 104 is connected to a plurality of desktop PC 110s and a plurality of server computers 112, and only one of them is shown as a representative in FIG. The PC 110 shown is a personal computer SPL300 sold by NEC. PC110 runs a hypertext description language (HTML) web browser such as Netscape Navigator or Microsoft Internet Explorer to access information on the Internet 104 using the Hypertext Transport Protocol (HTTP). For example, the PC 110 accesses HTML information stored in a web server 112, which is a workstation sold by Sun Microsystems. It will be apparent to those skilled in the art to store the accessible information in the PC 110 so that it becomes a web server.

【0016】

A link server or proxy server computer 114 exists between the Internet 104 and the Airnet 102 for data communication between them. The proxy server computer 114, also referred to as a link server or gateway server computer, is a workstation or personal computer that performs mapping or transfer functions. For example, the proxy server computer 114 maps information from one protocol to the other for the mobile device 106 to communicate with either one of the servers 112 or the PC 110.

【0017】

One communication protocol used on the Internet 104 is the well-known Hypertext Transfer Protocol (HTTP) or a secure version of HTTPS, HTTP. HTTP uses the well-known Transport Control Protocol (TCP) to make connections for carrying hypertext description language (HTML) information. For example, an HTML web browser in the proxy server 114 accesses the HTML information stored in the web server 112. In the embodiment of FIG. 1, the communication protocol between the mobile device 106 and the proxy server 114 via the airnet 102 is the handheld device transport protocol (HDTP) or the secure uplink gateway protocol (SUGP), which is preferred. It is preferable to run on the User Datagram Protocol (UDP). HDTP controls the connection of a small web browser in mobile device 106 to proxy server 114. In the embodiment of FIG. 1, the browser of the mobile device 106 is a Handheld Device Markup Language (HDML) browser. The Handheld Device Markup Language (HDML) is a tag-based document language that consists of a set of commands or statements that specify how information can be displayed on a display device and is similar to HTML. HDML is a special description language designed to identify "cards" of how information is displayed on the small screen of mobile device 106. Usually, a large number of cards are grouped into a deck, which is the smallest unit of HDML information that can be exchanged between the mobile device 106 and the proxy server 114. Further descriptions of HDML cards and decks are appropriately described below. The HDTP specification entitled "HDTP Specification" and the HDML entitled "HDML 2.0 Language Reference" are cited here as a reference in their entirety.

【0018】

HDTP is a session-level protocol similar to HTTP, but without its overhead, and is highly optimized for use in thin devices with significantly less computing power and memory. Moreover, as will be apparent to those skilled in the art, the User Datagram Protocol (UDP) does not require an established connection between the client and server devices before information is exchanged, which is between the client and server. Eliminates the need to exchange large numbers of packets during session formation. Exchanging a very small number of packets during communication is one of the desirable features for mobile devices with very limited computing performance and memory to interact efficiently with landline devices.

【0019】

FIG. 2 shows a block diagram of a typical GSM digital mobile phone 120 used in FIG. 1 to carry out the present invention. Each of the hardware components of the mobile phone 120 is known to those skilled in the art and will not be described in detail here. Using the screen 116 and keypad 118, the user of the telephone 120 can interactively communicate with a server in the data network (not shown in Figure 2). According to an embodiment of the invention, the compiled and linked processes of the invention are stored in ROM 122 as client module 124 and support module 126. Upon activation of a given key sequence using the keypad 118, the physical layer processor or microcontrol 128 initiates a communication session request to a server device (not shown) using the client module 124 in ROM 122. .. Establishing a communication session, the telephone 120 typically receives a single HDML deck from the server device and stores that deck in RAM134 as a cache. An HDML deck or deck is the smallest unit of HDML information that can be exchanged between a thin client device and a server device. Each deck has a unique address identifier, such as a URL, and contains one or more cards. The card contains information requested to generate a screen display on the display screen 116. So the deck is just a group of screen displays. The number of cards in the card deck is selected for efficient use of resources in mobile devices and air networks. The display driver 130 receives information from the deck in RAM134 and translates it. Allow screen 116 to display the resulting information. The keypad driver 132 receives a signal indicating which button or key in the keypad 118 has been pressed and translates that signal into a representation understood by the microcontrol 128, which then, for example, which selection is the phone key. By operating each card in the deck or against a new deck if needed, depending on what was done through pad 118

【0020】

The architecture of the present invention is shown with reference to FIG. Three representatives of the plurality of mobile devices coupled to the airnet 102 are indicated by 302, 304, 306, and similarly 310, 312, 314 indicate three of the plurality of landline devices coupled to the landnet 104. .. The link server device 370 couples the airnet 102 to the landnet 104, so that any mobile device can communicate with the landline device via the airnet and through the link server 370 via the landnet 104. It will be apparent to those skilled in the art that the mobile device is one of those shown in Figure 2. Internal block diagrams of mobile device 302 and link server 370 are shown respectively for carrying out the description of the present invention. Other processors and hardware are well known to those of skill in the art and will not be discussed in detail here. Each mobile device, such as 302, is assigned device ID 316. Device ID 316 is the phone number of the device or a combination of IP address and port number such as 204.163.165.132:01905, where 204.163.165.132 is the IP address and 01905 is the port number. Device ID 316 is further associated with Subscriber ID 318 approved by the carrier within Link Server 370 as part of the procedure for activating subscriber account 320 for mobile device 302. Subscriber ID 318 takes the form, for example, 861234567-10900_pn.mobile.att.net by AT & T Radio Services, which is the only identification number for mobile device 302. In other words, each of the mobile devices 302, 304, 306 has a unique device ID corresponding to its respective user account on the linked server device 370. The following description focuses on the mobile device 302 and the associated account 320, and this description may apply equally to multiple mobile devices in simultaneous communication with the link server 370.

【0021】

The subscriber account 320 indexed by device ID 316 is a data structure consisting of subscriber information such as subscriber number 318, user information 322, key status 321, and signature 325. User information (info) 322 includes other account-related information such as account structure, username, URL, device version, and date. The key state 31 indicates the state of the shared private key. Signature 325 is the result of a shared private key using a symmetric encryption algorithm such as RC5. The key state 321 is set to "exchange" when the account is newly established and the signature is not available with signature 325. More details on the key state and signature are described below. The URL of the account takes the form, for example, www.att.com/Pocketnet, which indicates that Airnet 102 is powered by AT & T wireless services. When the link server 370 services a large number of mobile devices, there are preferably an equal number of such accounts held by the database service 328, each of which is assigned to one of the mobile devices. The database server 328 is not required in the present invention. Database server 328, which provides a means of storing accounts, can be another computer or memory storage within linked server 370. The link server 370 is one of the landline devices, and any of the landline devices functions as a link server 370 and is either a client device or a server device depending on the application used in the device. In order to minimize possible ambiguity in the following description, the mobile device will be referred to below as the client device or thin client device, and the link server 370 will simply be referred to as the server device.

【0022】

The process of the present invention compiled and linked as described above is stored in the memory as the client module 332 of the client device 302. Similarly, the corresponding compiled and linked process of the present invention is loaded into memory as server module 320 of server device 370. Communication between the client device 302 and the server device 370 is made between the client module 332 and the server module 320 via a pair of User Datagram Protocol (UDP) interfaces 336, 324. When a user of client device 302 presses a given key to interact with server device 370, for example to fetch price information on a particular stock, client module 332 corresponds to UDP interface 336 in the form of an HDML deck. It sends a request, which further forwards the request to UDP interface 324 on the opposite side of the server unit 370. If the link server 370 is not the host of the stock price information , the request is processed by the link server 370 and further connected to other server devices 310 and 312 on the Internet. Otherwise stock price information is accidentally packetized into one or more cards in the HDML deck at 340. The HDML deck is sent back to the client 302 by the server module 320 through UDP interfaces 336 and 324. The client module displays the card on the display screen of the client device 302, preferably cached in RAM on the received HDML deck. The information exchanged between the client device 302 and the link server device 370 may be kept secret, and secure communication using encryption / decryption technology may be performed before any confidential information is exchanged. Must be established in.

【0023】

As shown in FIG. 4, when the cryptographic initiation process is performed between the client device 302 and the linked server device 370, an exemplary dialogue between the client module 332 and the server module 320 through the respective UDP interface pairs. Is shown. When client device 302 is instructed by its user to interact with linked server device 470, client module 332 requests a session from server module 320 to form a communication session between client device 302 and linked server device 370. Send signal 402 (SR402). The signal component of SR402 depends on the state of client device 302 and generally consists of it.

【0024】

Session ID-An identifier that identifies all requests from Client Device 302 to Link Server Device 470; Session ID is always assigned to 0 when requesting the formation of a session; Many crypto-communication protocols available A number of 2 bytes representing the scripture choice currently used by the client in the presence of the encryption scheme; version-one representing the HDTP protocol version used to determine the underlay format of a communication protocol such as PDU. Number of bytes; Type-A fixed 5-byte number that represents which device is the client (eg 2PCSI means that the client is PCSI phone version 2); Device ID-Device identifier or client identifier Variables up to 255 bytes to represent; Header-Applies to the entire session and is automatically applied to subsequent service requests or session-specific parameters (hence the header is typically cached on the server up to the current session) token / Up to 32767 bytes consisting of a pair of values; C-nonce-a client represented by a non-repeatable number, typically 2 bytes, used by the client for subsequent server authentication. Nons.

【0025】

Modified C-Nonce-A modified version of the client nonce that the server uses to authenticate subsequent client nonces. More specifically, the SR402 cipher contains its parameters associated with an identifier for a particular encryption algorithm, i.e. the first byte of the cipher is the encryption algorithm and key size (eg 128 bits for the US or foreign). 40 bits) and the contents of its security attachment, the second byte of the cipher indicates additional parameters for the first byte. For example, the value 1 of the first byte has the encryption algorithm block cipher RC5, its key size is 128 bytes, and its 2-byte checksum is used as the message authentication code (MAC), and therefore the block cipher. The initialization vector (IV) for is not transmitted across the network, with padding bytes added if necessary. Information about block ciphers and various available cryptographic algorithms can be found in most books on current cryptography, or MJBRobshaw, "BlockCiphers", August 1995, Technical Report TR-601, Version 2.0, RSA Laboratories. , 94065-1031, Redwood, California Marine Parkway 100. Cryptographic identifiers can be assigned to unique values to identify insecure sessions if desired. The C-nonce is initially a non-repeatable number, and the modified C-nonce, which is randomly generated on the client and its modified version, is generated from the C-nonce through an operational relationship. For example, the modified C-nonce is an exclusive OR relationship (explained below) [0026]

[Number 1]

<img file="JPH11331147A_D0001.tif" />【0027】

Is formed using.

【0028】

[Number 2]

<img file="JPH11331147A_D0002.tif" />【0029】

Both the C-nonce and the modified C-nonce are encrypted with cryptography using the secret encryption key owned by the client device 302. The purpose of the modified C-nonce is to examine the relationship between the C-nonce and its modified C-nonce to ensure that the C-nonce is accurately decrypted and approved. Is to provide. If the server device 370 has an acceptable private key that is identical to one of the client devices 302, the encoded C-nonce and the modified C-nonce must be decrypted with the accepted private key. , The relationship between them remains the same. In other words, SR message 402 is expressed as: SR = {session ID, cipher, version, type, device ID, header, Encry [C-nonce, modified C-nonce]}; Here Encry [] indicates that the parameter or content in the bracket is thereby encoded.

【0030】

Server module 320 attempts to decrypt the Encry [C-nonce, modified C-nonce] when the SR is received. From the decryption process, the server device 370 can determine the state of the private key on both sides. There are four possible private key states: Valid, Verify, Exchange, and Force.

【0031】

The "allowed" key state obtained from the successful decryption of the SR402's encrypted message is that both private key pairs are the same, and thus each of the client device 302 or server device 370 shares a private key (the private key that is shared by each of the client device 302 or server device 370. It has SSK), which means that no new cryptocurrency initiation process is required. The "confirmation" state means that the SSK generated by the new cryptocurrency initiation process has not been confirmed and that the confirmation process (process) must be performed next. The "exchange" key state allows cryptographic initiation processing at any time on request by client device 302, which is the normal case when a new user account for client device 302 is established. A "forced" key state indicates that cryptographic initiation processing must be done before any new session occurs. It is entered into a "forced" state when the SR402 encrypted message has a completely unsuccessful result.

【0032】

The key state is automatically set to "replace" by default when the client device 302 is newly activated and powered on. The key request 406 is sent to the server device 370 to start the cryptographic initiation process. The C-nonce and modified C-nonce in the SR are not encoded, which causes an error when the server module 320 attempts to decrypt the Encry [C-nonce, modified C-nonce]. The server sends a response request 404 to client 332 with an error indicating that the communication session cannot be established without first performing crypto start processing.

【0033】

The cryptographic start process is always started by sending a key request 406 from the client device 302 to the server device 370 when the key state is either exchanged or enforced. Otherwise, the process may be started again if the server device 370 is started and the client device 302 agrees to be processed together with the crypto start process. This happens when the current SSK has expired. SSK has a limited lifespan for many reasons. The most important reason is protection against what is called cryptanalysis. Each time a SKK key is used, it produces a large number of ciphertexts. The use of repetitive keys allows an attacker to create a store of sufficient ciphertext (and possible original text) to successfully decrypt the key value. Another example of a server-initialized cryptocurrency initiation process involves a mismatch between two SSKs on both sides. The cryptographic start processing of the client device is started by the session request response (SRR) 404 sent from the server module 320 to the client module 322. SRR404 consists of key error messages due to SSK mismatch or expiration on both sides.

【0034】

Before the client device 302 issues the key request 406, the client module 332 generates a private value called a client private value from a random number. Random number generators usually accept a seed of random numbers. It will be apparent to those skilled in the art that there are many random number generators available, such as rand (), which are available in the standard C library. Furthermore, there are many ways to obtain a hard coded insource or random seed as supplied by the manufacturer of the client device, which detects the noise signal without an antenna. In a random number seed, the client's private value is generated by a random number generator, which is a one-way hash function as its core engine. It is significantly easier to do in one direction (forward) than in the opposite direction (reverse). One-way means eliminate the chance of getting a random seed from the generated random numbers. An example of a hash function is to multiply a value itself a certain number of times and then perform a modulo operation. Client private values usually take the form of 16-byte long binary numbers. Client-private values are generated that way, and statistical copying of client-private values based on trying all possible random numbers is unlikely. Therefore, the generated client private value is used as an input for generating a public value called a client public value by a key agreement protocol such as the Diffie-Hellmann key agreement protocol. The client public value is often a 96-byte binary number for communication within the United States and a 64-byte binary number for communication outside the United States. According to one embodiment of the invention, a library called LIBDH is used to generate client published values. LIBDH is part of a product called BSAFE, which is 94065-1031, A general-purpose, low-level cryptographic toolkit sold by the RSA Laboratories operating at Marine Parkway 100, Redwood, California. The engine consists of the Diffie-Hellmann key-agreement protocol and cryptographic and hash functions. The client private value is obtained within the client device 302 and the client public value is transferred to the server device 370. The client module then sends a key request signal 406 to server unit 370. Key request 406 has device ID 316 of client device 403 and the generated client public value.

【0035】

The implicit start processing in the server device 370 starts when the key request 406 from the client device 302 is received. As described above, the key request 406 from the client device 302 is obtained from an error message sent from the server device 370 or a manual request by the user of the client device. Upon receiving the key request from the client device 302, the server device 370 generates a private value called a server private value, performs a series of authentication processes based on the device ID 326, and then proceeds with the encryption start process. Similar to client private and public values, server private values are generated from random numbers that can be generated from noise sources such as noisy diodes or traffic events in server equipment 370. The private value is also a 16-byte long binary number. A server private value as input, the public value or server public value is also a 96 or 64 byte binary number, which is then generated using the LIBDH library.

【0036】

As mentioned above, the Diffie-Hellmann key agreement protocol requires two numbers to generate a private key. Server module 320 is a client within a key request signal 406 received along with a self-generated server private value to generate a server-side private key based on the Diffie-Hellmann key agreement protocol generated using the LIBDH library. Use public values. To help client device 302 to generate a client-side private key, server 370 sends a key response signal 408 consisting of server public values. Similarly, based on the received server signal and the self-generated client private value, client module 332 generates a client-side private key based on the same key agreement protocol generated by LIBDH. As mentioned above, the client-side private key must be the same as the server-side private key called the private key (SSK) shared under normal circumstances. The following two-step verification process is performed to ensure that the private key is the same and the public value has not been changed during transmission within the public data network due to an intermediary attack.

【0037】

In the first stage, the client module 332 sends a new SR410 to the server device 370. The C-nonce and the modified C-nonce part in the SR410 are encrypted here with a new private key on the client side. Upon receiving the new SR410, the server module 320 attempts to decrypt the Encry [C-nonce, modified C-nonce] with the newly generated server-side private key. If the decryption is successful, that is, if the private keys on both sides are the same, then it is assumed that there is no intermediary attack when the public values are exchanged within the data network. The private key is considered an authorized shared private key (SSK) and is attached to the server's persistent memory. SSK is exposed to further confirmation defined as the second step. What happens to the private keys on both sides if the decryption fails, which results from possible data corruption of the public key when they are transmitted over a data network such as Airnet 102. The new crypto start process is restarted by sending another request response 404 containing an error message to the client device 302, which indicates that the crypto start process has failed and another new crypto start process has been restarted. ..

【0038】

The second step is to inspect the signatures obtained from both private keys. The private key is a 16-byte binary number. The first 8 bytes are encrypted by the second 8 bytes as an encryption key with a mutually agreed cipher such as the block cipher RC5 on the RCA engine, and the encoded result is called the private key signature. .. This signature takes the form, for example, FE63ABCD47FA3DA3. If the public value is not changed, both private keys are the same, and therefore the signature is also the same. The use of signatures provides a means for direct verification between the client side and the server side. For example, a user of a client device calls a service device operator to see if there is a match between each of the two signatures obtained from the client private key and the server private key. If the signatures are the same, then there is no intermediary attack, otherwise the cryptocurrency initiation process is considered incorrect.

【0039】

The Phase 1 verification process is piggybacked in a new session formed to reduce air traffic. In other words, the verification process is initiated by client device 302 by sending a new session to server device 370. If the verification is successful, that is, if both encryption keys are the same, the new session continues with a series of authentications between client device 302 and server device 370 through session response 412 and completion message 414. A secure, authenticated communication session is thus established.

【0040】

The code listed in the appendix microfiche is an embodiment of the present invention. The source file sessions Txn.c and netsugp.c describe all the detailed steps and processes of the cryptographic initiation process for server unit 370 and client unit 320 respectively. A function called KeyExchInit () in netsugp.c initializes the cryptocurrency startup process by invoking the function KeyExchangeDoPhaseOne (), which first allocates a memory area to form a key exchange protocol through the DHInit () function. .. Random numbers are obtained from the DevGetRandom () function and are used in DHPhase () ne () as client private values. DHPhase () ne () generates a client public value for client device 332. In the netSetupKeyExch () function, the published value is entered into the KeyReqrestPDU function through the SugpKeyRqstSetKeyData () function. The configured KeyRequestPDU is then sent to the server through DevSendPDU () in the netDoTxn () function.

【0041】

The cryptographic start processing is started by the function TsessionTxn :: Ignition of SessionTxn, c when the KeyRequestPDU is received from the client device 302 by the server module 320. Server device 302 is set by the CIgnition function to initiate processing and forms a proto-session to retrieve the corresponding record 321 from outside database 328. The server device 370 then checks whether the client device 302 is temporarily registered or disabled, and whether cryptographic activation is allowed. If any one of these conditions is not satisfied, the cryptographic initiation process is aborted and an error code is sent from the server device 370 to the client device 302.

【0042】

When all these conditions are met, the server module 320 forms a TkeyAgree, keyagree instance object for the client device 302, which sends a KeyRequest PDU. Server module 320 runs on the key agree object with operations like Init (), PubkeyGen (), GetSSkey (), IsWeakKey (). The Init () operation initializes the computation for the key agreement protocol; PubkeyGen () generates public and private values through the key agreement protocol and random number generator; PubkyeGen () is first linked with the random number engine and then server private. A value is generated; GetSSkey () calculates the server-side private key by entering the client public value of the KeyRequest PDU from the client device 302 and its own private value. IsWeakKey () checks if the generated server-side private key was safely used as the encryption key. Otherwise, the above process is repeated until a good server-side private key is found. The function CmaxKeyTries controls the iteration before the server module gives up and subsequently sends an error message to the client. Upon receiving the error message, client device 302 sends another KeyRequest PDU to the good server to repeat the whole process until the private key is raised in CmaxKeyTries to the satisfaction of the server.

【0043】

Next, the server device 370 supplies the server public value to the client device 302 of the KeyReply PDU so that the client device 302 completes the cryptographic start processing by using the m_rAirlink-&gt; Deliver () function. Wait for server device 370 to save the server-side private key in m_pNewCipher and client device 302 to start the verification process to hand over the server-side private key to SSK, which in turn makes a new session formation request from client device 302. Loaded into a persistent database through.

【0044】

On the netsugp.c or client side, the KeyReplyPDU is received through the function NetDataArrived () and passed to the netHandleKeyRply () function. The server public value in the KeyReply from the server is extracted and populated into the KeyExchDPhaseTwo () function to form the client-side private key. After successful client-side private key formation, client module 332 saves it in its persistent record and clears its need for crypto start requests by calling the ClearNeeds (kKeyExhh) function. The client device 302 is newly generated to encrypt the C-nonce, the modified C-nonce in the SessionRequest PDU to verify both the private keys that were generated in the client device 302 and the server device 370. Form a new session request to form a new session by using the client-side private key, which can be seen with the netSetupSess () function. The SessionRequest PDU is sent from the client device 302 to the server device 370.

【0045】

In SessionTxn.C, when a SessionRequestPDU is received by server unit 370, server module 320 calls TSessionTxn :: Start () to process the request. As far as the crypto startup process is concerned, a successful decryption on the arrival of a SessionRequest PDU by using a newly generated server-side private key will pass the server-side private key to SSK, which in turn will then be its persistent database. Loaded into. In the same function, server module 320 checks for the existence of a pending crypto start process by checking for the existence of m_pNewCipher. If so, it is used to decrypt the SessionRequest PDU. If the decryption is successful, the server saves the server-side private key as a shared private key by using the functions m_rSession-&gt; m_pSubscriber-&gt; Set () and m_rSession-&gt; m_pSubscriber-&gt; ExchangeComplete (). The signature is also made and saved at that point by using the m_pNewCipher-&gt; MakeSignature () function. This completes the crypto start process on server 370.

【0046】

A data flowchart of the cryptographic start processing (CIP) of each of the client device 302 and the server device 370 is shown with reference to FIGS. 5 and 6. Both Figures 5 and 6 must be understood in connection with Figures 3 and 4. As described above, the cryptographic start process is started by several methods, one of which is to start the process by mutually requesting a new cryptographic start process to be performed between the server device 370 and the client device 302. The second method is, for example, from the error message of session request response 404 sent by server unit 370 due to a complete failure to decrypt SR402 or a mismatch or expiration of both SSKs.

【0047】

The client device starts the cryptographic start processing (CIP) at 502 in FIG. At step 504, the client module generates the client private value before it generates the client public value, the process of which is described above. When the client public value becomes available, the client module sends a key request signal 406 to the server module in step 506. The client device begins waiting for key response 408 from the server device at step 508. While waiting for key response 408, the client device receives a signal other than the desired key response 408 from the intended server device. If the received signals do not get the desired key response 408, they are discarded in step 510. To prevent the client device from waiting indefinitely, a time limit is set for the wait, for example 60 seconds. The desired key response 408 must be received within the time limit, otherwise an error message will be displayed on the client device display screen at stage 512 to inform the user that the current cryptographic activation was aborted at stage 514. Is displayed in.

【0048】

In response to the key request signal 406 from the client device in step 552 to see Figure 6, the server module is accompanied by a session identifier called the session ID to identify the session requested by the client device formed by the server. Form a protosession at stage 554 for the client device. A server proto session is a session entry marked as proto state in the session table, which indicates that the session is not authenticated and cannot communicate with the client in any way. The protosession is kept in the server's RAM, and there can be one or more protosessions if the server device is in communication with another client device. It is shallowly utilized if a protosession already exists for a particular client device. The received SR information is saved in the proto session. To ensure that the server module communicates with the authenticated client device, the server device makes a series of checks. At 556, the server device first checks whether the received SR402 device ID is acceptable by comparing it with the device ID assigned by the account. If the received device ID is acceptable, the server module further checks if the client device is enabled on the 558. In some cases the client device has a valid device ID, but the client device is disabled for some reason. When the client device is recognized by the server device and authenticated, the server module checks whether the cryptographic start process is enabled by checking the key state of the user account. As mentioned above, the key state is set to "exchange" when a new user account is established. The states that allow the crypto start process are "exchange" and "forced", which is considered to be the current crypto start process enabled, otherwise it is not.

【0049】

If any one of the confirmations in stages 556, 558, 560 fails, the server module sends a device error 562 to inform the client that the attempted CIP has been aborted. The server removes the formed protosession at stage 586 for this particular session and aborts the CIP at stage 590.

【0050】

Upon successful completion of all checks in stages 556, 558, 560, the server module proceeds to the stage of forming server private and server public values, a process described above. With the received client public value and server self-formed private value, the server module generates a server-side private key by the common key agreement protocol of stage 564. For security reasons, the server-side private key generated in stage 526 is passed through the key check process in stage 566. In the key inspection process, the formed private key has a sufficient random pattern and is not easily reconstructed by cryptanalysis. Some of the easily statistically detected patterns are keys with periodic 0s and 1s, such as 0101010101 ... 01, which facilitate unapproved replication. SSK is considered weak and must be destroyed and regenerated. There is a counter that monitors the number of times the private key formed in step 568 must be regenerated. If the counter is more than a certain number, for example 10 times, the server unit gives up and therefore sends an error message to the client in step 578 to request the client to restart the entire CIP. If the generated secret or regenerated private key goes through the key check process at stage 566, at stage 560 the server sends a key response signal to the client module along with the server public value to the client module with the client-side private key. To generate. Like the client device, the server module begins waiting for a response from the client device at stage 57. Any undesired signal is discarded at step 574. If the server module is kept waiting for a very long time, the first protosession formed is removed at stage 586 and the current crypto startup process is aborted at stage 590.

【0051】

As shown in Figure 5, the client module is waiting for a key response signal at step 508. The client module receives the key response signal from the server device and forms the client-side private key in step 516. Therefore the client module relies on testing against the weak SSK of the server. The client module initiates a similar key-forming process using the server public value and the client self-generated private value for client-side private key formation by the key-agreement protocol commonly used in step 516. It is assumed that the client-side private key generated from the perspective of the client device is allowed, and the client module SSKs the client-side private key generated by loading it into its persistent memory or RAM. Hand over to. The client then initiates a new session request 410 with Encry [C-nonce, modified C-nonce] by client formation SSK.

【0052】

As shown in Figure 6, when the server receives a new session request 410 in stage 572, the server looks for a protosession entry in the protosession table and in stage 576 a series of checks using the device ID in the new session request 410. Do the processing. It is better for Encry [C-nonce, modified C-nonce] with the current server-side private key to ensure that the server module comes from a new session request 410 recognized and approved client device. Check if it is decrypted and if it works, it indicates that the server-side private key is the SSK of the client device. The server module commits the server-side private key to the client device's SSK by loading it into the server's persistent memory at step 582. Otherwise it checks if the Encry [C-nonce, modified C-nonce] is successfully decrypted by the old SSK, which indicates that the client device failed with the current crypto startup process. The current crypto startup process is then quietly aborted at stage 590 (without sending an error message to the client) and a new session is formed with the old SSK. Therefore, this process saves the old SSK that exists if the current crypto startup process fails.

【0053】

Two signatures from the two SSKs are confirmed at stage 592 to provide a means of confirming the formed SSKs. This is done by verbal confirmation between the user of the client device and the operator of the server device. As described above, the client-side signature is formed when the client-side private key is formed. Similarly, the server-side signature is formed when the server-side private key is formed. If the two signatures do not match, the current cryptocurrency initiation process will fail and a secure communication session will not be established. If the verification is successful, the current cryptocurrency initiation process succeeds at stage 594. Oral confirmation is not a necessary part of the book, but is only used in one embodiment to illustrate means of confirming SSK by comparing signatures arising from SSK.

【0054】

The present invention has been described in a certain degree of sufficient detail. This disclosure of the examples has been made for illustration purposes only and it will be appreciated by those skilled in the art that innumerable changes in arrangement and steps, combinations of parts may be made without departing from the spirit and scope of the claims of the present invention. Is clear. Therefore, the scope of the present invention is determined only by claims, not by examples.

[Simple explanation of drawings]

[Figure 1]

The outline of the mobile data network in which the present invention can be carried out is shown.

[Figure 2]

A typical example of a mobile device including a linked and compiled process of the present invention is shown.

[Fig. 3]

The architecture of the present invention is shown.

[Fig. 4]

Indicates communication between the server module and the client module through each pair of UDP interfaces when the cryptographic initiation process is activated between the client device and the server device.

[Fig. 5]

It is a flowchart which shows the operation of the cryptographic start process between a client device and a server device.

[Fig. 6]

It is a flowchart which shows the operation of the cryptographic start process between a client device and a server device.

[Explanation of symbols]

100 data network 102 Airnet 104 Landnet 110 desktop PC 112 server computer 114 Proxy server computer 106 Mobile device 116 screen 118 keypad 120 phone 124 Client module 126 Support module 122 ROM 134 RAM 130 display driver 132 keypad driver 128 micro controller 302, 304, 306 mobile device 310, 312, 314 Landline equipment 370 Link server 316 Device ID 328 database service 332 Client module 320 server module 302 Client device 336, 324 UDP interface