WO2010053319A2 - 보안 키 교환 장치 및 방법과 이에 관한 시스템 - Google Patents

보안 키 교환 장치 및 방법과 이에 관한 시스템 Download PDF

Info

Publication number
WO2010053319A2
WO2010053319A2 PCT/KR2009/006532 KR2009006532W WO2010053319A2 WO 2010053319 A2 WO2010053319 A2 WO 2010053319A2 KR 2009006532 W KR2009006532 W KR 2009006532W WO 2010053319 A2 WO2010053319 A2 WO 2010053319A2
Authority
WO
WIPO (PCT)
Prior art keywords
key
public
generated
public key
information
Prior art date
Application number
PCT/KR2009/006532
Other languages
English (en)
French (fr)
Other versions
WO2010053319A3 (ko
Inventor
박재성
박태성
권재훈
정수환
최재덕
Original Assignee
삼성전자 주식회사
숭실대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사, 숭실대학교 산학협력단 filed Critical 삼성전자 주식회사
Priority to US13/128,106 priority Critical patent/US8380992B2/en
Publication of WO2010053319A2 publication Critical patent/WO2010053319A2/ko
Publication of WO2010053319A3 publication Critical patent/WO2010053319A3/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols

Definitions

  • the present invention relates to an apparatus and method for sharing a security key and a system supporting the same, and more particularly, to an apparatus and a method and a system supporting the security key through a security key exchange between both terminals.
  • the development of the communication industry has created various additional services utilizing a network, and a representative example of the additional services is an Internet service.
  • the value-added service utilizing the network has made it easier for many users to share information through collection and delivery of information.
  • a security technique for encrypting and transmitting personal information by a security key previously promised between a transmitter and a receiver is generally used to protect personal information transmitted on a network.
  • security technology using certificates issued from public institutions for financial and payment services is being used through the Internet.
  • a security key to be used between the transmitting side and the receiving side needs to be promised in advance.
  • a procedure for sharing the security key is required to promise a security key to be used between the transmitter and the receiver.
  • the present invention provides an apparatus and method for exchanging keys without the intervention of an intermediary in exchanging keys between two terminals, and a system thereof.
  • the present invention relates to an apparatus and method for dividing a public key generated by each device to perform data communication into two, and transmitting the two divided public keys to a counterpart device through different paths, and a related art. Provide a system.
  • the present invention predicts the public key of the counterpart device using two public keys provided from the counterpart device through different paths, and transmits / receives data using the master key obtained by the predicted public key.
  • An apparatus and method and a system related thereto are provided.
  • the present invention also verifies a public key of a predicted counterpart device using two public keys provided from the counterpart device through different paths, and performs verification on a master key obtained by the verified public key.
  • An apparatus and method are provided.
  • a communication system for sharing a security key between devices for performing data communication divides a public key generated by itself into two public keys, and the divided two public keys. Transmit one of the divided public keys through a signaling path with the counterpart device, and transmit the public information signed with the other divided public key and a private key generated by itself through the media path with the counterpart device; Predict a public key generated by the counterpart device by using two split public keys received from the device through the signaling path and the media path, and determine the media path from the predicted public key and the counterpart device. Performs authentication on the signed counterpart public information received through the anticipated public key and the signature And a client device for generating a master key for use in data communication with the counterpart device, upon successful authentication of the disclosed counterpart public information.
  • a method of sharing a security key with a counterpart device in a client device for data communication with the counterpart device comprises the steps of: splitting a public key generated by itself into two public keys; Transmitting one partitioned public key of the public keys through a signaling path with the counterpart device, and transmitting public information signed with the other partitioned public key and a private key generated by itself through the media path with the counterpart device Predicting a public key generated by the counterpart device using two split public keys received from the counterpart device through the signaling path and the media path, and predicting the predicted public key and the counterpart.
  • Authenticating the signed relative public information received from the device via the media path; After a successful authentication to the predicted one public key and the signature public external information includes the step of generating a master key used in data communication with the partner apparatus.
  • the present invention has the advantage of avoiding the attack of the man-in-the-middle because it is difficult for the man-in-the-middle to attack through each path by dividing the public key between the two terminals and transmitting them through different paths.
  • the present invention has the advantage that it is easy to apply to the current VoIP environment by performing a key exchange using a private key and a public key generated directly between the two terminals.
  • the present invention has the advantage that the user can directly perform key authentication between the two terminals without having to authenticate the public key directly.
  • FIG. 1 is a view showing an overall flow diagram for a key exchange in the key exchange system according to an embodiment of the present invention
  • FIG. 2 is a control flow diagram illustrating a process for a client to split a public key and transmit it to a proxy server and a server according to an embodiment of the present invention
  • FIG. 3 is a control flow diagram illustrating a process for a client to generate and authenticate a public key using a first split public key and a second split public key received from a server according to an embodiment of the present invention
  • FIG. 4 is a control flowchart illustrating a process of a server dividing a public key and transmitting it to a proxy server and a client according to an embodiment of the present invention
  • FIG. 5 is a control flowchart illustrating a process for a server to generate and authenticate a public key using a first split public key and a second split public key received from a client according to an exemplary embodiment of the present invention.
  • SRTP Secure Real-time Transport Protocol
  • the scheme using only the signaling path is MIKEY-NULL (Multimedia Internet KEYing-NULL) technology, MIKEY-PSK (MIKEY-Pre-Shared Key) technology, MIKEY-Rivest Shamir Adleman (MIKEY-RSA) technology, MIKEY-RSA- MIKEY-RSA-Reverse (R) technology, MIKEY-DHSIGN (MIKEY-DH SIGNature) technology, MIKEY-DHHMAC (MIKEY-DH Hash Message Authentication Code) technology, and SDP Security Descriptions for Media Streams technology.
  • MIKEY-NULL Multimedia Internet KEYing-NULL
  • MIKEY-PSK MIKEY-Pre-Shared Key
  • MIKEY-Rivest Shamir Adleman MIKEY-RSA
  • MIKEY-RSA- MIKEY-RSA-Reverse (R) technology MIKEY-DHSIGN (MIKEY-DH SIGNature) technology
  • MIKEY-DHHMAC MIKEY-DH
  • DTLS-SRTP Datagram Transport Layer Security-SRTP
  • This technology exchanges SRTP keys by performing a DTLS process on a public key infrastructure (PKI), which typically uses certificates.
  • PKI public key infrastructure
  • the SRTP key is exchanged using a self-signed certificate using both signaling and media paths.
  • This method transmits the fingerprint of the public key to the Session Description Protocol (SDP) of the signaling path, and transmits the self-signed certificate while performing DTLS in the media path.
  • SDP Session Description Protocol
  • a security technology called Enhancements for authenticated identity management in the SIP is used, in which a proxy server adds a signature value for a fingerprint in the middle of the transmission path.
  • the user authenticates the sender's self-signed certificate by using the fingerprint of the public key received through the signaling path.
  • an embodiment of the present invention to be described later is to provide a method for protecting data transmitted and received by exchanging and authenticating a security key directly between two devices to perform data communication.
  • two devices for performing data communication share one public key of two public keys divided from a public key generated by itself using a signaling path.
  • the two devices to perform the data communication share the public information signed by the other public key and the private key of the two divided public keys using a media path.
  • the private key is generated by the device together with the public key.
  • Each of the two devices predicts the public key generated by the counterpart device using two public keys transmitted from the counterpart device and authenticates the predicted public key and the signed public information received from the counterpart device. do.
  • each of the two devices generates a master key and master key confirmation information when the predicted public key and the signed public information received from the counterpart device are successfully authenticated.
  • Each of the two devices performs verification on the master key generated by the master key confirmation information transmitted from the counterpart device. When the verification is successful, the two devices transmit / receive data using the master key generated by the two devices. do.
  • FIG. 1 shows the overall flow for secure key exchange in a secure key exchange system according to an embodiment of the present invention.
  • Security key exchange system is composed of a client device 101, a server 102 and the proxy server 103.
  • the device acting as the user agent client is abbreviated to the client device 101 and the client acting as the user agent server to the server 102.
  • the client device 101 and the server 102 are divided for convenience of description. However, it will be apparent that the operations performed by the client device 101 and the server 102 proposed in the embodiment of the present invention may be performed interchangeably.
  • the proxy server 103 is one of a communication server type for establishing a signaling path between the client device 101 and the server 102.
  • the client device 101 generates its own RSA private key and RSA public key.
  • the server 102 also generates its own RSA private key and RSA public key. Thereafter, the client device 101 and the server 102 generate a random Diffie-Hellman secret value to split each RSA public key, and use the generated Diffie-Hellman secret value to generate Diffie-Hellman public information. To calculate.
  • Each of the client device 101 and the server 102 uses its calculated Diffie-Hellman public information to refer to its RSA public key as the first RSA public key (hereinafter referred to as "first split public key").
  • the second RSA public key (hereinafter referred to as "second split public key”) is divided.
  • step 110 the client device 101 transmits its first split public key to the proxy server 103 through a signaling path.
  • the proxy server 103 transmits the first split public key received from the client device 101 to the server 102 through a signaling path in step 111.
  • the server 102 transmits its first split public key to the proxy server 103 through a signaling path.
  • the proxy server 103 transmits the first split public key received from the server 102 to the client device 101 through a signaling path in step 113.
  • step 114 the client device 101 signs the Diffie-Hellman public information previously calculated using its RSA private key, and uses the second divided public key and the signed Diffie-Hellman public information in a media path. Directly to the server 102 through. At this time, the client device 101 also delivers Diffie-Hellman public information that is not signed by the RSA private key.
  • the server 102 obtains the first partitioned public key, the second partitioned public key, the signed Diffie-Hellman public information, and the unsigned Diffie-Hellman public information of the client device 101.
  • the server 102 generates an RSA public key of the client device 101 using the first split public key and the second split public key of the client device 101 obtained in step 115.
  • the server 102 performs an authentication procedure on whether the generated RSA public key of the client device 101 matches the RSA public key generated by the client device 101.
  • the server 102 also verifies the signed Diffie-Hellman public information of the client device 101 obtained above using the RSA public key of the authenticated client device 101.
  • the server 102 proceeds to the secure master key in step 117. Generate a security master key verification information value by using the public parameter value necessary to generate the security master key.
  • the server 102 signs the Diffie-Hellman public information previously calculated using its RSA private key, its own second partitioned public key, the signed Diffie-Hellman public information, and the security generated earlier.
  • the master key and secret master key confirmation information values are transmitted to the client device 101 through a media path. At this time, the server 102 also delivers unsigned Diffie-Hellman public information.
  • the client device 101 generates an RSA public key of the server 102 using the first split public key and the second split public key transmitted from the server 102 in step 119.
  • the client device 101 performs an authentication procedure on whether the generated RSA public key of the server 102 matches the RSA public key generated by the server 102.
  • the client device 101 also verifies the signed Diffie-Hellman public information of the server 102 obtained earlier using the RSA public key of the authenticated server 102.
  • the client device 101 If the authentication of the generated RSA public key of the server 102 and the signed Diffie-Hellman public information of the server 102 obtained earlier is successful, the client device 101 generates a secure master key in step 121. And generate a security master key verification information value using the public parameter values required to generate the security master key.
  • the client device 101 uses a security master key confirmation information value received from the server 102 and a security master key confirmation information value generated by the client device 101 to determine a normal value of the security master key generated by the server 102. Verify that it is.
  • the client device 101 If the client device 101 verifies that the security master key generated by the server 102 is a normal value, the client device 101 transmits the security master key verification information value generated earlier in step 123 to the server 102.
  • the server 102 receives the security master key confirmation information value transmitted from the client device 101, and in step 124, the received security master key confirmation information value of the client device 101 and the security master generated by the server 102.
  • the key verification information value is used to verify whether the security master key generated by the client device 101 is a normal value.
  • the server 102 verifies that the security master key generated by the client device 101 is a normal value, the server 102 recognizes that the same security master key as that generated by the client device 101 has been generated by the client device 101. do.
  • the client device 101 and the server 102 perform an operation of transmitting or receiving data using the corresponding security master key in step 125.
  • a security master key may be exposed by a man in the middle attack (MITM).
  • MITM man in the middle attacker
  • ZRTP technology uses a short authentication string (SAS) authentication method to allow a user to directly perform authentication. This approach required the user to perform some action for authentication.
  • SAS short authentication string
  • the public key between the client device and the server may be divided and exchanged through two paths, thereby preventing the public key from being exposed by the intermediate attacker.
  • security keys can be exchanged and authenticated between the client device and the server without direct user intervention.
  • FIGS. 2 and 3 illustrate a control flow performed by a client device to exchange security keys according to an embodiment of the present invention.
  • step 200 the client device 101 generates its own private key and public key.
  • the private key generated by the client device 101 is used.
  • the public key Assume that In addition, the private key generated by the server 102 The public key Assume that
  • step 201 the client device 101 generates its own public key. Calculate the Diffie-Hellman public information to use for partitioning.
  • the Diffie-Hellman disclosure information may be calculated using any Diffie-Hellman secret value.
  • the random Diffie-Hellman secret value is generated by the client device 101.
  • Diffie-Hellman public information (DHPartAlice) calculated using the random Diffie-Hellman secret value x is It can be defined as.
  • g is a generator
  • mod is a modular operator
  • p primary number is a large prime number that is only divided by 1 and its own number p.
  • step 202 the client device 101 generates the Diffie-Hellman public information previously generated. Using public key First public key And second split public key Split into
  • Equation 1 the public key First public key partitioned from And second split public key It defines.
  • the second divided public key Is the Diffie-Hellman public information generated earlier This can be achieved by applying the SHA1 hash function (H) to the.
  • the second split public key The size of the RSA public key The second split public key to match the size of Padding with zeros.
  • the client device 101 determines the first split public key. Is inserted into the session attribute field existing in the SDP of the SIP message INVITE and transmitted to the proxy server 103 through the signaling path.
  • the client device 101 transmits a first divided public key of the server 102 from the proxy server 103 through the signaling path. Checks to see if it is received.
  • the client device 101 can determine the first split public key of the server 102 through the signaling path. Receives the private key in step 205. Diffie-Hellman public information Sign the. And the signed Diffie-Hellman public information And second split public key Is transmitted to the server 102 through the RTP session which is a media path using the RTP address and the port number included in the INVITE and 200 OK message. At this time, the client device 101 is a private key Diffie-Hellman public information not signed by Is transmitted to the server 102 via the media path.
  • the client device 101 determines the Diffie-Hellman public information signed from the server 102 in step 206. And second split public key , Security key verification information value Check if it is received. At this time, the client device 101 is unsigned Diffie-Hellman public information from the server 102. It also checks if it is received.
  • the client device 101 When the client device 101 receives the desired information from the server 102, the client device 101 receives the first split public key received from the server 102 in step 207. And second split public key A public key generated by the server 102 using Calculate
  • the client device 101 may generate a public key generated by the server 102 by Equation 2 below. Can be calculated.
  • the client device 101 receives the first split public key received from the server 102 through different paths. And second split public key Generated by the server 102 by an XOR operation of Can be predicted.
  • the client device 101 uses Dashie-Hellman public information received from the server 102 using a hash function in step 208. Calculate the hash result of.
  • the client device 101 determines the public key of the server in step 209. Perform verification on.
  • the verification includes the calculated hash result value and the second split public key received from the server 102. Is made by whether or not it matches.
  • Equation 3 This is the Diffie-Hellman public information received from the server 102 as shown in Equation 3 below.
  • the second partitioning public key of the server by applying a hash function (H) to the It can be judged by the calculation.
  • the client device 101 is configured to generate the hash result and the second public key received from the server 102. If is matched, proceed to step 210. However, the calculated hash result value and the second split public key received from the server 102. Does not match, the client device 101 determines that the public key has been modified by the intermediate attacker and ends the key exchange process.
  • the client device 101 is a public key of the predicted server Is verified, in step 210 the public key of the predicted server Signed Diffie-Hellman public information received from the server 102 using Verify.
  • the private key generated by the server 102 itself Diffie-Hellman public information signed
  • the public key of the server 102 Can be verified using
  • the client device 101 receives the signed Diffie-Hellman public information received from the server 102. If the verification fails, the intermediate attacker determines that the signed Diffie-Hellman public information has been modified and terminates the key exchange process. However, the signed Diffie-Hellman public information received from the server 102 If the verification is successful, the client device 101 proceeds to step 211.
  • step 211 the client device 101 generates a security master key using Equation 5 below.
  • the base g is a generator
  • one of the exponents y is a secret value of the server 102
  • the remaining exponent x is a secret value of the client device 101.
  • p means large prime numbers
  • mod means modular operations.
  • the client device 101 confirms security master key confirmation information to mutually confirm the generated security master key with the server 102.
  • the security master key verification information is a security master key And public parameter values required to generate the security master key. Wow This can be calculated by applying a hash function to.
  • the client device 101 In operation 212, the client device 101 generates the generated security master key. Perform verification on.
  • the generated security master key Is the security master key confirmation information received from the server (102) Can be verified using
  • the client device 101 is the generated security master key Security master key verification information generated earlier for verification And security master key verification information received from the server 102. Compare
  • the client device 101 is a master generated by the server 102. Determine to match key. However, if the calculated security master key confirmation information and the security master key confirmation information received from the server 102 do not match, the client device 101 is a security master key confirmation information received from the server 102 is intermediate It is determined that it has been changed by the attacker.
  • the security master key confirmation information newly calculated in step 213. Is transmitted to the server 102.
  • the client device 101 After the verification of the security master key is completed as described above, the client device 101 performs data transmission / reception with the server 102 using the verified security master key in step 214.
  • the client device 101 divides its public key and transmits it to the server 102 through two different paths, so that even if an attack is performed by an intermediate attacker, the public key is not exposed. .
  • 4 and 5 illustrate a control flow performed by a server to exchange security keys according to an embodiment of the present invention.
  • step 300 the server 102 has its own private key.
  • step 301 the server 102 generates its own public key. Calculate the Diffie-Hellman public information to use for partitioning.
  • the Diffie-Hellman disclosure information may be calculated using an arbitrary Diffie-Hellman secret value y.
  • the random Diffie-Hellman secret value y is generated by the server 102.
  • the calculated Diffie-Hellman public information (DHPartBob) It can be defined as.
  • step 302 the server 102 generates the Diffie-Hellman public information previously generated. Using public key First public key And second split public key Split into
  • Equation 7 the public key First public key partitioned from And second split public key It defines.
  • the second divided public key Is the Diffie-Hellman public information generated earlier This can be achieved by applying the SHA1 hash function (H) to the.
  • the second split public key The size of the RSA public key The second split public key to match the size of Padding with zeros.
  • step 303 the server 102 determines the first partitioned public key of the client device 101 through a signaling path from the proxy server 103. Checks to see if it is received.
  • the server 102 divides the first split public key of the client device 101 through the signaling path.
  • the server 102 determines the first split public key. Is inserted into the session attribute field existing in the SDP of the SIP message 200 OK and transmitted to the proxy server 103 through the signaling path.
  • the server 102 displays the Diffie-Hellman public information signed from the client device 101 in step 305. And second split public key Checks to see if it is received. The server 102 then unsigned Diffie-Hellman public information from the client device 101. It also checks if it is received.
  • the server 102 When the server 102 receives the desired information from the client device 101, the server 102 receives the first split public key received from the client 101 in step 306. And second split public key The public key of generated by the client device 101 using Calculate
  • the server 102 generates a public key generated by the client device 101 by Equation 8 below. Can be calculated.
  • the server 102 receives the first split public key received from the client device 101 through different paths. And second split public key Generated by the client device 101 by an XOR operation Can be predicted.
  • step 307 the server 101 uses Dashie-Hellman public information received from the client device 101 using a hash function. Calculate the hash result of.
  • the server 101 determines the public key of the predicted client device in step 308. Perform verification on.
  • the verification includes the calculated hash result value and the second split public key received from the client device 101. Is made by whether or not it matches.
  • the server 102 generates the calculated hash result value and the second split public key received from the client device 101. If is matched, proceed to step 309. However, the calculated hash result value and the second split public key received from the client device 101. If does not match, the server 102 determines that the public key has been modified by the intermediate attacker and ends the key exchange process.
  • the server 102 determines the public key of the predicted client. Is verified, in step 309 the public key of the predicted client 101 Signed Diffie-Hellman public information received from the client 101 using Verify.
  • Diffie-Hellman public information signed Public key of the client device 101 Can be verified using
  • the server 102 receives the signed Diffie-Hellman public information received from the client device 101. If the verification fails, the intermediate attacker determines that the signed Diffie-Hellman public information has been modified and terminates the key exchange process. However, the signed Diffie-Hellman public information received from the client device 101 If the verification is successful, the server 102 proceeds to step 310.
  • step 310 the server 102 generates a security master key using Equation 11 below.
  • g the base of g xy , is a generator, and one of the exponents, y, is a secret value of the server 102, and the remaining exponent, x, means a secret value of the O client device 101.
  • p means large prime numbers, and mod means modular operations.
  • the server 102 confirms security master key confirmation information to mutually confirm the generated security master key with the client device 101.
  • the security master key verification information is a security master key And public parameter values required to generate the security master key. Wow This can be calculated by applying a hash function to.
  • the server 102 When the server 102 calculates the security master key confirmation information, the server 102 stores its private key in step 311. Diffie-Hellman public information Sign the. And the signed Diffie-Hellman public information And second split public key Your own security master key verification information value Is transmitted to the client device 101 through the RTP session which is a media path using the RTP address and the port number included in the INVITE and the 200 OK message. At this time, the server 102 has its own private key Diffie-Hellman public information not signed by Is transmitted to the client device 101 via the media path.
  • step 312 the server 102 checks security master key confirmation information from the client device 101. Checks if a is received.
  • the server 102 generates the generated security master key. Perform verification on.
  • the generated security master key Is the security master key confirmation information received from the client device 101 Can be verified using
  • the server 102 is the generated security master key Newly generated security master key verification information for verification And secure master key confirmation information received from the client device 101. Compare
  • the server 102 If the calculated security master key confirmation information and the security master key confirmation information received from the client device 101 match, the server 102 generates the generated security master key by the client device 101. Determine that it matches the master key. However, if the calculated security master key confirmation information and the security master key confirmation information received from the client device 101 do not match, the server 102 determines that the security master key confirmation information received from the client device 101 is different. It is determined that the change was made by an intermediate attacker.
  • the server 102 After the verification of the security master key is completed as described above, the server 102 performs data transmission / reception with the client device 101 using the verified security master key in step 314.
  • the server 102 divides its public key and transmits it to the client device 101 through two different paths, so that the public key is not exposed even if an attack by an intermediate attacker is made. .
  • the public key is divided between the user terminals and exchanged through different paths, so that even if any one of the divided public keys is attacked by an intermediate attacker, the key exchange is possible between the terminals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Lock And Its Accessories (AREA)

Abstract

본 발명은 양측 단말 간의 보안 키 교환을 통해 보안 키를 공유할 수 있도록 하는 장치 및 방법과 이를 지원하는 시스템에 관한 것이다. 이를 위해 자체적으로 생성한 공개키를 두 개로 분할하고, 상기 분할된 두 개의 공개키를 서로 다른 경로를 통해 상대 장치로 전달하며, 상대 장치로부터 전달되는 두 개의 공개키를 이용하여 상대 장치의 공개키를 예측한다. 그리고 상기 예측된 공개키에 대한 검증을 수행하고, 상기 검증이 이루어진 공개키를 이용하여 마스터 키를 생성한다. 그 후 상기 생성된 마스터 키에 대한 검증을 수행하며, 상기 검증이 이루어진 마스터 키를 사용하여 상대 장치와의 데이터 송신 및 수신을 수행하도록 한다.

Description

보안 키 교환 장치 및 방법과 이에 관한 시스템
본 발명은 보안 키를 공유하기 위한 장치 및 방법과 이를 지원하는 시스템에 관한 것으로, 특히 양측 단말 간의 보안 키 교환을 통해 보안 키를 공유할 수 있도록 하는 장치 및 방법과 이를 지원하는 시스템에 관한 것이다.
통신 산업의 발전은 네트워크를 활용한 다양한 부가 서비스를 창출하였으며, 상기 부가 서비스의 대표적인 예가 인터넷 서비스이다. 상기 네트워크를 활용한 부가 서비스는 정보의 수집 및 전달을 통해 많은 이용자들이 정보를 공유하는 것이 용이하여 졌다.
이러한 네트워크를 활용하여 부가 서비스를 이용하는 경우에는 비밀이 요구되는 개인 정보를 전달이 필요한 경우가 종종 발생하고 있어, 개인 정보가 제3자에 의해 노출될 가능성이 증가할 수 있다. 따라서 네트워크 상에서 전달되는 개인 정보의 보호를 위한 다양한 방안 마련이 요구되고 있는 것이 현실이다.
이를 위한 방안으로써 네트워크 상에서 전달되는 개인 정보를 보호하기 위해 송신측과 수신측 간에 미리 약속된 보안 키에 의해 개인 정보를 암호화하여 전송하는 보안 기술이 일반적으로 사용되고 있다. 그 외에도 인터넷 망을 통해 금융 및 결재 서비스를 위해 공공 기관 등으로부터 발급받은 인증서를 이용한 보안 기술이 사용되고 있다.
상술한 예에서 보안 키를 이용하여 개인 정보를 보호하고자 하는 경우에는 송신측과 수신측 간에 사용할 보안 키가 사전에 약속될 필요가 있다. 이와 같이 송신측과 수신측 간에 사용할 보안 키를 약속하기 위해서는 상기 보안 키를 공유하기 위한 절차가 요구된다.
이때 상기 보안 키를 공유하기 위해서는 상기 보안 키를 공유하기 위해 필요한 정보를 네트워크를 통해 송신측과 수신측 간에 전달하는 절차가 불가피하게 요구된다. 이로 인해 중간 공격자가 상기 보안 키를 공유하기 위해 전달되는 정보를 네트워크 상에서 가로챌 수 있는 환경이 마련될 수 있다.
따라서 네트워크 상에서 안심하고 다양한 부가 서비스를 이용하기 위해서는 개인 정보의 노출을 완전하게 방지할 수 있을 뿐만 아니라 이용자에게 편리함을 제공할 수 있는 보안 키 공유 방안 마련이 시급하다고 할 것이다.
따라서, 본 발명은 두 단말기 간의 키 교환 시 중간자의 개입 없이 키를 교환하기 위한 장치 및 방법과 이에 관한 시스템을 제공한다.
또한, 본 발명은 데이터 통신을 수행할 장치들 각각이 자체적으로 생성한 공개키를 두 개로 분할하고, 상기 분할된 두 개의 공개키를 서로 상이한 경로를 통해 상대 장치로 전송하는 장치 및 방법과 이에 관한 시스템을 제공한다.
또한, 본 발명은 서로 다른 경로를 통해 상대 장치로부터 제공받은 두 개의 공개키를 이용하여 상대 장치의 공개키를 예측하고, 상기 예측된 공개키에 의해 획득한 마스터 키를 이용하여 데이터를 송/수신하는 장치 및 방법과 이에 관한 시스템을 제공한다.
또한, 본 발명은 서로 다른 경로를 통해 상대 장치로부터 제공받은 두 개의 공개키를 이용하여 예측한 상대 장치의 공개키를 검증하고, 상기 검증된 공개키에 의해 획득한 마스터 키에 대한 검증을 수행하는 장치 및 방법을 제공한다.
상술한 바를 달성하기 위한 본 발명에 따른 데이터 통신을 수행할 장치들 상호간에 보안 키를 공유하도록 하는 통신 시스템은, 자체적으로 생성한 공개키를 두 개의 공개키로 분할하고, 상기 분할된 두 개의 공개키들 중 하나의 분할 공개키를 상대 장치와의 시그널링 경로를 통해 전송하고, 다른 하나의 분할 공개키와 자체적으로 생성한 개인키로 서명된 공개 정보를 상기 상대 장치와의 미디어 경로를 통해 전송하며, 상기 상대 장치로부터 상기 시그널링 경로와 상기 미디어 경로를 통해 수신한 두 개의 분할 공개키를 이용하여 상기 상대 장치에 의해 자체적으로 생성된 공개키를 예측하고, 상기 예측한 공개키와 상기 상대 장치로부터 상기 미디어 경로를 통해 수신한 서명된 상대 공개 정보에 대한 인증을 수행하며, 상기 예측한 공개키와 상기 서명된 상대 공개 정보에 대한 인증에 성공하면, 상기 상대 장치와의 데이터 통신 시에 사용할 마스터 키를 생성하는 클라이언트 장치를 포함한다.
또한, 본 발명에 따른 상대 장치와의 데이터 통신을 위해 클라이언트 장치에서 상기 상대 장치와 보안 키를 공유하는 방법은, 자체적으로 생성한 공개키를 두 개의 공개키로 분할하는 과정과, 상기 분할된 두 개의 공개키들 중 하나의 분할 공개키를 상대 장치와의 시그널링 경로를 통해 전송하고, 다른 하나의 분할 공개키와 자체적으로 생성한 개인키로 서명된 공개 정보를 상기 상대 장치와의 미디어 경로를 통해 전송하는 과정과, 상기 상대 장치로부터 상기 시그널링 경로와 상기 미디어 경로를 통해 수신한 두 개의 분할 공개키를 이용하여 상기 상대 장치에 의해 자체적으로 생성된 공개키를 예측하는 과정과, 상기 예측한 공개키와 상기 상대 장치로부터 상기 미디어 경로를 통해 수신한 서명된 상대 공개 정보에 대한 인증을 수행하는 과정과, 상기 예측한 공개키와 상기 서명된 상대 공개 정보에 대한 인증에 성공하면, 상기 상대 장치와의 데이터 통신 시에 사용할 마스터 키를 생성하는 과정을 포함한다.
본 발명은 두 단말기 간의 공개 키를 분할하여 서로 다른 경로를 통해서 전송함으로써 중간자가 각각의 경로를 통해서 공격하기 어렵기 때문에 중간자의 공격을 피할 수 있다는 이점이 있다.
또한 본 발명은 두 단말기 간에 직접 생성된 개인키 및 공개키를 이용하여 키 교환을 수행함으로써 현재 VoIP 환경에 적용하는 것이 용이하다는 이점이 있다.
뿐만 아니라 본 발명은 사용자가 직접 공개키를 인증할 필요 없이 두 단말기 간에 직접 키 인증을 수행할 수 있다는 이점이 있다.
도 1은 본 발명의 실시 예에 따른 키 교환 시스템에서 키 교환을 위한 전체 흐름도를 나타내는 도면,
도 2는 본 발명의 실시 예에 따라 클라이언트가 공개 키를 분할하여 프록시 서버 및 서버로 전송하기 위한 과정을 나타내는 제어 흐름도,
도 3은 본 발명의 실시 예에 따라 클라이언트가 서버로부터 수신된 서버의 제1분할 공개키 및 제2분할 공개키를 이용하여 공개키 생성 및 인증을 위한 과정을 나타내는 제어 흐름도,
도 4는 본 발명의 실시 예에 따라 서버가 공개 키를 분할하여 프록시 서버 및 클라이언트로 전송하기 위한 과정을 나타내는 제어 흐름도,
도 5는 본 발명의 실시 예에 따라 서버가 클라이언트로부터 수신된 클라이언트의 제1분할 공개키 및 제2분할 공개키를 이용하여 공개키 생성 및 인증을 위한 과정을 나타내는 제어 흐름도.
하기에서 본 발명을 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술 되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
VoIP(Voice over Internet Protocol) 네트워크에서 개인 정보의 보호를 위한 대표적인 보안 키 교환 기술로써 SRTP(Secure Real-time Transport Protocol)를 동작시키기 위한 사용자 단말 간에 보안키를 교환하는 기술들이 존재한다. 상기 SRTP 보안키를 교환하는 기술은 시그널링 경로만을 이용하는 방안과, 미디어 경로만을 이용하는 방안 및 시그널링 경로와 미디어 경로 모두를 이용하는 방안으로 분류된다.
첫 번째로 시그널링 경로만을 이용하는 방안은 MIKEY-NULL(Multimedia Internet KEYing-NULL) 기술, MIKEY-PSK(MIKEY-Pre-Shared Key) 기술, MIKEY-RSA(MIKEY-Rivest Shamir Adleman) 기술, MIKEY-RSA-R(MIKEY-RSA-Reverse) 기술, MIKEY-DHSIGN(MIKEY-DH SIGNature) 기술, MIKEY-DHHMAC(MIKEY-DH Hash Message Authentication Code) 기술, SDP Security Descriptions for Media Streams 기술 등이 존재한다.
하지만 상술한 시그널링 경로만을 이용하는 방안은 시그널링에 보안이 적용되어 있거나 사전에 공유된 보안 정보 또는 인증서를 필요로 함에 따라, 현실적으로 VoIP 서비스 등에 적용하기는 어렵다.
두 번째로 미디어 경로만을 이용하는 방안으로는 Diffie-Hellman 키 교환 기법으로 SRTP를 위한 키를 양단 간에 공유하고, 사용자의 목소리로 Diffie-Hellman 결과 값과 관련된 짧은 단어를 직접 읽어서 인증하는 ZRTP 기술이 존재한다.
하지만 상술한 미디어 경로만을 이용하는 방안은 사용자가 인증 시도를 위해 직접 개입하여야 하는 불편함이 있다.
세 번째로 시그널링 경로와 미디어 경로 모두를 이용한 방안으로는 DTLS-SRTP(Datagram Transport Layer Security-SRTP) 기술이 존재한다.
이 기술은 일반적으로 인증서를 사용하는 PKI(Public Key Infrastructure) 기반에서 DTLS 과정을 수행하여 SRTP 키를 교환한다.
만약 인증서를 사용하는 PKI 기반이 아닌 경우에는 시그널링 경로와 미디어 경로 모두를 이용한 자체 서명 인증서 (Self-Signed Certificate) 방식으로 SRTP 키의 교환을 시도한다.
이러한 방식은 시그널링 경로의 SDP(Session Description Protocol)에 공개 키의 특징(fingerprint)을 전송하고, 미디어 경로에서 DTLS를 수행하면서 Self-Signed 인증서를 전송한다. 이때 전송되는 공개키의 특징(fingerprint)을 보호하기 위해 전송 경로 중간에 프락시 서버가 fingerprint에 대한 서명값을 추가하는 Enhancements for authenticated identity management in the SIP라는 보안 기술이 사용된다.
한편 사용자는 시그널링 경로를 통해 수신한 공개 키의 특징(fingerprint)을 이용하여 송시니자의 자체 서명 인증서(Self-Signed Certificate)를 인증한다.
상술한 바와 같이 일반적인 SRTP에 의한 키 교환 기술에서는 제3의 기관이 개입된 인증서의 사용이 요구되거나 사용자의 직접적인 개입이 필요하였다.
따라서 후술 될 본 발명의 실시 예에서는 데이터 통신을 수행할 두 장치 상호간에 직접 보안 키를 교환 및 인증함으로써, 송수신되는 데이터를 보호할 수 있도록 하는 방안을 마련하고자 한다.
이를 위한 본 발명의 실시 예에서는 데이터 통신을 수행할 두 장치는 자체적으로 생성한 공개키로부터 분할된 두 개의 공개키 중 하나의 공개키를 시그널링 경로를 사용하여 공유한다. 그리고 상기 데이터 통신을 수행할 두 장치는 상기 분할된 두 개의 공개키 중 다른 하나의 공개키와 개인키에 의해 서명된 공개 정보를 미디어 경로를 사용하여 공유한다. 여기서 상기 개인키는 해당 장치에 의해 상기 공개키와 더불어 자체적으로 생성된다.
상기 두 장치 각각은 상대 장치로부터 전달된 두 개의 공개키를 이용하여 상대 장치에 의해 생성된 공개키를 예측하고, 상기 예측된 공개키와 상기 상대 장치로부터 수신한 서명된 공개 정보에 대한 인증을 수행한다.
그 후 상기 두 장치 각각은 상기 예측된 공개키와 상기 상대 장치로부터 수신한 서명된 공개 정보의 인증이 성공적으로 이루어지면 마스터 키와 마스터 키 확인 정보를 생성하며, 상기 생성된 마스터 키 확인 정보를 상대 장치로 전달한다. 상기 두 장치 각각은 상대 장치로부터 전달된 마스터 키 확인 정보에 의해 자신이 생성한 마스터 키에 대한 검증을 수행하고, 상기 검증이 성공적으로 이루어지면 상기 자신이 생성한 마스터 키를 이용하여 데이터 송/수신한다.
이하 본 발명의 실시 예에서 제안하고자 하는 보안 키의 교환 방안에 대해 첨부된 도면을 참조하여 구체적으로 설명한다.
도 1은 본 발명의 실시 예에 따른 보안 키 교환 시스템에서 보안 키 교환을 위한 전체 흐름을 보이고 있다.
본 발명의 실시 예에 따른 보안 키 교환 시스템은 클라이언트 장치(101), 서버(102) 및 상기 프록시 서버(103)로 구성된다. 이때, 본 발명의 실시 예에서는 사용자 에이전트 클라이언트로 동작하는 장치를 클라이언트 장치(101)로 사용자 에이전트 서버로 동작하는 클라이언트를 서버(102)로 축약하여 기재하도록 한다. 또한, 본 발명의 실시 예에서는 설명의 편의를 위해 클라이언트 장치(101)와 서버(102)를 구분하였다. 하지만 본 발명의 실시 예에서 제안하는 상기 클라이언트 장치(101)와 상기 서버(102)에서 수행하는 동작은 서로 교체하여 수행하는 것도 가능함은 자명할 것이다.
그리고 본 발명의 실시 예에서 프록시 서버(103)는 상기 클라이언트 장치(101)와 상기 서버(102) 간의 시그널링 경로를 설정하는 통신 서버 종류의 하나이다.
상기 클라이언트 장치(101)는 자체적으로 RSA 개인키 및 RSA 공개키를 생성한다. 상기 서버(102)도 자체적으로 RSA 개인키 및 RSA 공개키를 생성한다. 이후 상기 클라이언트 장치(101)와 상기 서버(102)는 각각의 RSA 공개키를 분할하기 위해 임의의 Diffie-Hellman 비밀 값을 생성하고, 상기 생성된 Diffie-Hellman 비밀 값을 이용하여 Diffie-Hellman 공개 정보를 산출한다. 그리고 상기 클라이언트 장치(101)와 상기 서버(102) 각각에서는 산출된 Diffie-Hellman 공개 정보를 이용하여 자신의 RSA 공개키를 첫 번째 RSA 공개키(이하 "제1분할 공개키"이라 칭함)와 두 번째 RSA 공개키(이하 "제2분할 공개키"이라 칭함)로 분할한다.
이후 상기 클라이언트 장치(101)는 110단계에서 자신의 제1분할 공개키를 시그널링 경로를 통해서 상기 프록시 서버(103)로 전달한다. 상기 프록시 서버(103)는 111단계에서 상기 클라이언트 장치(101)로부터 전달받은 제1분할 공개키를 시그널링 경로를 통해서 상기 서버(102)로 전달한다.
한편 상기 서버(102)는 112단계에서 자신의 제1분할 공개키를 시그널링 경로를 통해서 상기 프록시 서버(103)로 전달한다. 상기 프록시 서버(103)는 113단계에서 상기 서버(102)로부터 전달받은 제1분할 공개키를 시그널링 경로를 통해서 상기 클라이언트 장치(101)로 전달한다.
상기 클라이언트 장치(101)는 114단계에서 자신의 RSA 개인키를 사용하여 앞서 산출된 Diffie-Hellman 공개 정보를 서명하고, 자신의 제2분할 공개키와 상기 서명된 Diffie-Hellman 공개 정보를 미디어 경로를 통해서 상기 서버(102)로 직접 전달한다. 이때, 상기 클라이언트 장치(101)는 RSA 개인키에 의해 서명되지 않은 Diffie-Hellman 공개 정보도 함께 전달한다.
이로써 상기 서버(102)는 상기 클라이언트 장치(101)의 제1분할 공개키와 제2분할 공개키 및 서명된 Diffie-Hellman 공개 정보, 서명되지 않은 Diffie-Hellman 공개 정보를 획득한다.
상기 서버(102)는 115단계에서 앞에서 획득한 상기 클라이언트 장치(101)의 제1분할 공개키 및 제2분할 공개키를 이용하여 상기 클라이언트 장치(101)의 RSA 공개키를 생성한다.
그리고 상기 서버(102)는 116단계에서 상기 생성된 클라이언트 장치(101)의 RSA 공개키가 상기 클라이언트 장치(101)에 의해 생성된 RSA 공개키와 일치하는 지에 대한 인증 절차를 수행한다. 또한 상기 서버(102)는 상기 인증된 클라이언트 장치(101)의 RSA 공개키를 이용하여 앞에서 획득한 클라이언트 장치(101)의 서명된 Diffie-Hellman 공개 정보에 대한 검증을 수행한다.
상기 생성된 클라이언트 장치(101)의 RSA 공개키와 앞에서 획득한 클라이언트 장치(101)의 서명된 Diffie-Hellman 공개 정보에 대한 인증이 성공적으로 이루어지면, 상기 서버(102)는 117단계에서 보안 마스터 키를 생성하고, 상기 보안 마스터 키를 생성하기 위해 필요한 공개 파라미터 값을 이용하여 보안 마스터 키 확인 정보 값을 생성한다. 상기 서버(102)는 118단계에서 자신의 RSA 개인키를 사용하여 앞서 산출된 Diffie-Hellman 공개 정보를 서명하고, 자신의 제2분할 공개키와 상기 서명된 Diffie-Hellman 공개 정보와 앞에서 생성된 보안 마스터 키 및 보안 마스터 키 확인 정보 값을 미디어 경로를 통해서 상기 클라이언트 장치(101)로 전달한다. 이때, 상기 서버(102)도 서명되지 않은 Diffie-Hellman 공개 정보를 함께 전달한다.
상기 클라이언트 장치(101)는 119단계에서 상기 서버(102)로부터 전달된 제1분할 공개키 및 제2분할 공개키를 이용하여 상기 서버(102)의 RSA 공개키를 생성한다.
그리고 상기 클라이언트 장치(101)는 120단계에서 상기 생성된 서버(102)의 RSA 공개키가 상기 서버(102)에 의해 생성된 RSA 공개키와 일치하는 지에 대한 인증 절차를 수행한다. 또한 상기 클라이언트 장치(101)는 상기 인증된 서버(102)의 RSA 공개키를 이용하여 앞에서 획득한 서버(102)의 서명된 Diffie-Hellman 공개 정보에 대한 검증을 수행한다.
상기 생성된 서버(102)의 RSA 공개키와 앞에서 획득한 서버(102)의 서명된 Diffie-Hellman 공개 정보에 대한 인증이 성공적으로 이루어지면, 상기 클라이언트 장치(101)는 121단계에서 보안 마스터 키를 생성하고, 상기 보안 마스터 키를 생성하기 위해 필요한 공개 파라미터 값을 이용하여 보안 마스터 키 확인 정보 값을 생성한다.
상기 클라이언트 장치(101)는 상기 서버(102)로부터 수신된 보안 마스터 키 확인 정보 값과 자신이 생성한 보안 마스터 키 확인 정보 값을 이용하여 상기 서버(102)에 의해 생성된 보안 마스터키가 정상적인 값인지 여부를 검증한다.
상기 클라이언트 장치(101)는 상기 서버(102)에 의해 생성된 보안 마스터키가 정상적인 값이라고 검증되면, 123단계에서 앞에서 생성한 보안 마스터 키 확인 정보 값을 상기 서버(102)로 전달한다.
상기 서버(102)는 상기 클라이언트 장치(101)로부터 전달된 보안 마스터 키 확인 정보 값을 수신하고, 124단계에서 상기 수신된 클라이언트 장치(101)의 보안 마스터 키 확인 정보 값과 자신이 생성한 보안 마스터 키 확인 정보 값을 이용하여 상기 클라이언트 장치(101)에 의해 생성된 보안 마스터 키가 정상적인 값인지 여부를 검증한다.
상기 서버(102)는 상기 클라이언트 장치(101)에 의해 생성된 보안 마스터 키가 정상적인 값이라고 검증되면, 자신이 생성한 보안 마스터 키와 동일한 보안 마스터 키가 상기 클라이언트 장치(101)에 의해 생성되었다고 인지한다.
상기 클라이언트 장치(101)와 상기 서버(102)는 상호간에 생성된 보안 마스터 키에 대한 검증이 완료되면, 125단계에서 해당 보안 마스터 키를 이용하여 데이터를 송신하거나 수신하는 동작을 수행한다.
일반적으로 제 3자의 개입 없이 두 사용자 간의 키를 교환하는 경우에는 중간 공격자(MITM, Man In The Middle Attack)에 의해 보안 마스터 키가 노출될 수 있었다. 이러한 중간 공격자에 대응하기 위해 ZRTP 기술에서는 SAS(Short Authentication String) 인증 방식을 이용하여 사용자가 직접 인증을 위한 동작을 수행하도록 하였다. 이러한 방식은 사용자가 인증을 위해서 어떠한 동작을 수행해야 했다.
하지만 상술한 본 발명의 실시 예에 의하면, 클라이언트 장치와 서버 간의 공개키를 서로 분할하여 두 가지 경로를 통해 교환함으로써 중간 공격자에 의해 공개키가 노출되는 것을 방지할 수 있다. 뿐만 아니라 사용자의 직접적인 개입 없이 클라이언트 장치와 서버 간의 보안 키의 교환 및 인증 동작을 수행할 수 있다.
도 2와 도 3은 본 발명의 실시 예에 따라 보안 키를 교환하기 위해 클라이언트 장치에서 수행하는 제어 흐름을 보이고 있다.
도 2와 도 3을 참조하면, 200단계에서 클라이언트 장치(101)는 자신의 개인키 및 공개키를 생성한다. 예를 들어, 상기 클라이언트 장치(101)가 생성한 개인키를
Figure PCTKR2009006532-appb-I000001
라고 하고, 공개키를
Figure PCTKR2009006532-appb-I000002
라고 가정한다. 또한 서버(102)가 생성한 개인키를
Figure PCTKR2009006532-appb-I000003
라고 하고, 공개키를
Figure PCTKR2009006532-appb-I000004
라고 가정한다.
201단계에서 상기 클라이언트 장치(101)는 생성된 자신의 공개키
Figure PCTKR2009006532-appb-I000005
를 분할하기 위해 사용할 Diffie-Hellman 공개 정보를 산출한다. 상기 Diffie-Hellman 공개 정보는 임의의 Diffie-Hellman 비밀 값을 이용하여 산출할 수 있다. 상기 임의의 Diffie-Hellman 비밀 값은 상기 클라이언트 장치(101)에 의해 생성된다.
예컨대 생성된 임의의 Diffie-Hellman 비밀 값이 x라고 하면, 상기 임의의 Diffie-Hellman 비밀 값 x를 이용하여 산출된 Diffie-Hellman 공개 정보(DHPartAlice)는
Figure PCTKR2009006532-appb-I000006
로 정의될 수 있다. 여기서, g는 생성자(Generator)이고, mod는 모듈러 연산자이며, p(prime number)는 1과 자기 자신의 수 p로만 나눠지는 큰 소수를 의미한다.
202단계에서 상기 클라이언트 장치(101)는 앞에서 생성한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000007
를 이용하여 공개키
Figure PCTKR2009006532-appb-I000008
를 제1분할 공개키
Figure PCTKR2009006532-appb-I000009
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000010
로 분할한다.
하기 <수학식 1>에서는 공개키
Figure PCTKR2009006532-appb-I000011
로부터 분할된 제1분할 공개키
Figure PCTKR2009006532-appb-I000012
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000013
를 정의하고 있다.
수학식 1
Figure PCTKR2009006532-appb-M000001
상기 <수학식 1>에 의하면, 제2분할 공개키
Figure PCTKR2009006532-appb-I000014
는 앞에서 생성된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000015
에 SHA1 해쉬 함수(H)를 적용함으로써 얻을 수 있다. 이때 상기 제2분할 공개키
Figure PCTKR2009006532-appb-I000016
의 크기가 RSA 공개키
Figure PCTKR2009006532-appb-I000017
의 크기와 일치되도록, 상기 제2분할 공개키
Figure PCTKR2009006532-appb-I000018
에 0을 패딩한다.
그리고 제1분할 공개키
Figure PCTKR2009006532-appb-I000019
는 RSA 공개키
Figure PCTKR2009006532-appb-I000020
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000021
의 배타적 논리 합(XOR: Exclusive OR) 연산에 의한 결과 값
Figure PCTKR2009006532-appb-I000022
에 의해 얻을 수 있다.
203단계에서 상기 클라이언트 장치(101)는 상기 제1분할 공개키
Figure PCTKR2009006532-appb-I000023
를 SIP 메시지 INVITE의 SDP 안에 존재하는 세션 속성 필드(Session attribute Field)에 삽입하여 시그널링 경로를 통해 프록시 서버(103)로 전달한다.
204단계에서 상기 클라이언트 장치(101)는 상기 시그널링 경로를 통해 상기 프록시 서버(103)로부터 서버(102)의 제1분할 공개키
Figure PCTKR2009006532-appb-I000024
가 수신되는지 검사한다.
상기 클라이언트 장치(101)는 상기 시그널링 경로를 통해 상기 서버(102)의 제1분할 공개키
Figure PCTKR2009006532-appb-I000025
를 수신하면, 205단계에서 자신의 개인키
Figure PCTKR2009006532-appb-I000026
를 이용하여 앞에서 산출한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000027
를 서명한다. 그리고 상기 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000028
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000029
를 INVITE와 200 OK 메시지에 포함된 RTP 주소 및 포트 번호를 이용하여 미디어 경로인 RTP 세션을 통해 상기 서버(102)로 전송한다. 이때 상기 클라이언트 장치(101)는 개인키
Figure PCTKR2009006532-appb-I000030
에 의해 서명하지 않은 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000031
를 상기 미디어 경로를 통해 상기 서버(102)로 전송한다.
한편 상기 클라이언트 장치(101)는 206단계에서 상기 서버(102)로부터 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000032
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000033
, 보안키 확인 정보 값
Figure PCTKR2009006532-appb-I000034
이 수신되는지 검사한다. 이때 상기 클라이언트 장치(101)는 상기 서버(102)로부터 서명되지 않은 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000035
가 수신되는지에 대해서도 검사한다.
상기 클라이언트 장치(101)는 상기 서버(102)로부터 원하는 정보가 수신되면, 207단계에서 상기 서버(102)로부터 수신한 제1분할 공개키
Figure PCTKR2009006532-appb-I000036
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000037
를 이용하여 상기 서버(102)에 의해 생성된 공개키
Figure PCTKR2009006532-appb-I000038
를 산출한다.
예컨대 상기 클라이언트 장치(101)는 하기 <수학식 2>에 의해 상기 서버(102)에 의해 생성된 공개키
Figure PCTKR2009006532-appb-I000039
를 산출할 수 있다.
수학식 2
Figure PCTKR2009006532-appb-M000002
상기 <수학식 2>에 의하면, 상기 클라이언트 장치(101)는 상기 서버(102)로부터 서로 다른 경로를 통해 수신한 제1분할 공개키
Figure PCTKR2009006532-appb-I000040
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000041
의 XOR 연산에 의해 상기 서버(102)에 의해 생성되었을
Figure PCTKR2009006532-appb-I000042
를 예측할 수 있다.
한편 상기 클라이언트 장치(101)는 208단계에서 해쉬 함수를 이용하여 상기 서버(102)로부터 수신한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000043
의 해쉬 결과값을 산출한다.
그 후 상기 클라이언트 장치(101)는 209단계에서 상기 예측된 서버의 공개키
Figure PCTKR2009006532-appb-I000044
에 대한 검증을 수행한다. 상기 검증은 상기 산출된 해쉬 결과값과 앞에서 상기 서버(102)로부터 수신한 제2분할 공개키
Figure PCTKR2009006532-appb-I000045
가 일치하는지 여부에 의해 이루어진다.
이는 하기 <수학식 3>에서 보여지는 바와 같이 상기 서버(102)로부터 수신한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000046
에 해쉬 함수(H)를 적용하여 서버의 제2분할 공개키
Figure PCTKR2009006532-appb-I000047
산출되는지로 판단할 수 있다.
수학식 3
Figure PCTKR2009006532-appb-M000003
상기 클라이언트 장치(101)는 상기 산출된 해쉬 결과값과 상기 서버(102)로부터 수신한 제2분할 공개키
Figure PCTKR2009006532-appb-I000048
가 일치하면 210단계를 진행한다. 하지만 상기 산출된 해쉬 결과값과 상기 서버(102)로부터 수신한 제2분할 공개키
Figure PCTKR2009006532-appb-I000049
가 일치하지 않으면, 상기 클라이언트 장치(101)는 중간 공격자에 의해 공개키가 수정되었다고 판단하여 키 교환 과정을 종료한다.
상기 클라이언트 장치(101)는 상기 예측된 서버의 공개키
Figure PCTKR2009006532-appb-I000050
에 대한 검증이 이루어지면, 210단계에서 상기 예측된 서버의 공개키
Figure PCTKR2009006532-appb-I000051
를 이용하여 상기 서버(102)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000052
를 검증한다.
이때, 상기 서버(102)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000053
는 하기 <수학식 4>에 의해 검증할 수 있다.
수학식 4
Figure PCTKR2009006532-appb-M000004
상기 <수학식 4>에 의하면, 서버(102)에 의해 자체적으로 생성된 개인키
Figure PCTKR2009006532-appb-I000054
로 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000055
를 상기 서버(102)의 공개키
Figure PCTKR2009006532-appb-I000056
를 이용하여 검증할 수 있다.
상술한 바에 의해 상기 클라이언트 장치(101)는 상기 서버(102)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000057
에 대한 검증에 실패하면, 중간 공격자에 의해 상기 서명된 Diffie-Hellman 공개 정보가 수정되었다고 판단하여 키 교환 과정을 종료한다. 하지만 상기 서버(102)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000058
에 대한 검증에 성공하면, 상기 클라이언트 장치(101)는 211단계로 진행한다.
상기 클라이언트 장치(101)는 211단계로 진행하면, 하기 <수학식 5>를 이용하여 보안 마스터 키를 생성한다.
수학식 5
Figure PCTKR2009006532-appb-M000005
여기서, 에서 기수인 g는 생성자이고, 지수 중 하나인 y는 서버(102)의 비밀 값이며, 나머지 지수인 x는 클라이언트 장치(101)의 비밀 값을 의미한다. 그리고 p는 큰 소수를 의미하며, mod는 모듈러 연산을 의미한다.
그리고 상기 클라이언트 장치(101)는 상기 생성된 보안 마스터 키를 상기 서버(102)와 상호 확인 하기 위해 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000059
를 산출한다. 여기서 상기 보안 마스터 키 확인 정보는 보안 마스터 키
Figure PCTKR2009006532-appb-I000060
와 상기 보안 마스터 키를 생성하기 위해 필요한 공개 파라미터 값
Figure PCTKR2009006532-appb-I000061
와
Figure PCTKR2009006532-appb-I000062
에 해쉬 함수를 적용함으로써 산출할 수 있다.
한편 상기 클라이언트 장치(101)는 212단계에서 상기 생성된 보안 마스터 키
Figure PCTKR2009006532-appb-I000063
에 대한 검증을 수행한다. 상기 생성된 보안 마스터 키
Figure PCTKR2009006532-appb-I000064
는 상기 서버(102)로부터 수신한 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000065
를 이용하여 검증할 수 있다.
이는 하기 <수학식 6>으로 일반화될 수 있다.
수학식 6
Figure PCTKR2009006532-appb-M000006
상기 클라이언트 장치(101)는 상기 생성된 보안 마스터 키
Figure PCTKR2009006532-appb-I000066
의 검증을 위해 앞에서 산출된 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000067
와 상기 서버(102)로부터 수신한 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000068
를 비교한다.
상기 클라이언트 장치(101)는 상기 산출된 보안 마스터 키 확인 정보와 상기 서버(102)로부터 수신한 보안 마스터 키 확인 정보가 일치하면, 상기 생성된 보안 마스터 키가 상기 서버(102)에 의해 생성된 마스터 키와 일치한다고 판단한다. 하지만 상기 산출된 보안 마스터 키 확인 정보와 상기 서버(102)로부터 수신한 보안 마스터 키 확인 정보가 일치하지 않으면, 상기 클라이언트 장치(101)는 상기 서버(102)로부터 수신한 보안 마스터 키 확인 정보가 중간 공격자에 의해 변경되었다고 판단한다.
상기 클라이언트(101)는 상기 마스터 키에 대한 검증이 이루어지면, 213단계에서 새롭게 산출한 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000069
을 상기 서버(102)로 전송한다.
상술한 바에 의해 보안 마스터 키에 대한 검증이 완료된 이후 상기 클라이언트 장치(101)는 214단계에서 상기 검증된 보안 마스터 키를 이용하여 상기 서버(102)와의 데이터 송수신을 수행한다.
이와 같이 상기 클라이언트 장치(101)는 자신의 공개키를 분할하여 서로 다른 두 가지 경로를 통해 상기 서버(102)로 전송함으로써, 중간 공격자에 의한 공격이 이루어지더라도 공개키가 노출되지 않는다는 이점이 있다.
도 4 와 도 5는 본 발명의 실시 예에 따라 보안 키를 교환하기 위해 서버에서 수행하는 제어 흐름을 보이고 있다.
도 4 와 도 5를 참조하면, 300단계에서 서버(102)는 자신의 개인키
Figure PCTKR2009006532-appb-I000070
및 공개키
Figure PCTKR2009006532-appb-I000071
를 생성한다.
301단계에서 상기 서버(102)는 생성된 자신의 공개키
Figure PCTKR2009006532-appb-I000072
를 분할하기 사용할 Diffie-Hellman 공개 정보를 산출한다. 상기 Diffie-Hellman 공개 정보는 임의의 Diffie-Hellman 비밀 값 y을 이용하여 산출할 수 있다. 상기 임의의 Diffie-Hellman 비밀 값 y은 상기 서버(102)에 의해 생성된다.
이때, 산출된 Diffie-Hellman 공개 정보(DHPartBob)는
Figure PCTKR2009006532-appb-I000073
로 정의될 수 있다.
302단계에서 상기 서버(102)는 앞에서 생성한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000074
를 이용하여 공개키
Figure PCTKR2009006532-appb-I000075
를 제1분할 공개키
Figure PCTKR2009006532-appb-I000076
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000077
로 분할한다.
하기 <수학식 7>에서는 공개키
Figure PCTKR2009006532-appb-I000078
로부터 분할된 제1분할 공개키
Figure PCTKR2009006532-appb-I000079
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000080
를 정의하고 있다.
수학식 7
Figure PCTKR2009006532-appb-M000007
상기 <수학식 7>에서 제2분할 공개키
Figure PCTKR2009006532-appb-I000081
는 앞에서 생성된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000082
에 SHA1 해쉬 함수(H)를 적용함으로써 얻을 수 있다. 이때 상기 제2분할 공개키
Figure PCTKR2009006532-appb-I000083
의 크기가 RSA 공개키
Figure PCTKR2009006532-appb-I000084
의 크기와 일치되도록, 상기 제2분할 공개키
Figure PCTKR2009006532-appb-I000085
에 0을 패딩한다.
그리고 제1분할 공개키
Figure PCTKR2009006532-appb-I000086
는 RSA 공개키
Figure PCTKR2009006532-appb-I000087
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000088
의 배타적 논리 합(XOR: Exclusive OR) 연산에 의한 결과 값
Figure PCTKR2009006532-appb-I000089
에 의해 얻을 수 있다.
303단계에서 상기 서버(102)는 프록시 서버(103)로부터 시그널링 경로를 통해 클라이언트 장치(101)의 제1분할 공개키
Figure PCTKR2009006532-appb-I000090
가 수신되는지 검사한다.
상기 서버(102)가 상기 시그널링 경로를 통해서 상기 클라이언트 장치(101)의 제1분할 공개키
Figure PCTKR2009006532-appb-I000091
를 수신하면, 304단계에서 상기 서버(102)는 상기 제1분할 공개키
Figure PCTKR2009006532-appb-I000092
를 SIP 메시지 200 OK의 SDP 안에 존재하는 세션 속성 필드(Session attribute Field)에 삽입하여 시그널링 경로를 통해 프록시 서버(103)로 전달한다.
또한 상기 서버(102)는 305단계에서 상기 클라이언트 장치(101)로부터 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000093
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000094
가 수신되는지 검사한다. 이때 상기 서버(102)는 상기 클라이언트 장치(101)로부터 서명되지 않은 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000095
가 수신되는지에 대해서도 검사한다.
상기 서버(102)는 상기 클라이언트 장치(101)로부터 원하는 정보가 수신되면, 306단계에서 상기 클라이언트(101)로부터 수신한 제1분할 공개키
Figure PCTKR2009006532-appb-I000096
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000097
를 이용하여 상기 클라이언트 장치(101)에 의해 생성된 의 공개키
Figure PCTKR2009006532-appb-I000098
를 산출한다.
예컨대 상기 서버(102)는 하기 <수학식 8>에 의해 상기 클라이언트 장치(101)에 의해 생성된 공개키
Figure PCTKR2009006532-appb-I000099
를 산출할 수 있다.
수학식 8
Figure PCTKR2009006532-appb-M000008
상기 <수학식 8>에 의하면, 상기 서버(102)는 상기 클라이언트 장치(101)로부터 서로 다른 경로를 통해 수신한 제1분할 공개키
Figure PCTKR2009006532-appb-I000100
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000101
의 XOR 연산에 의해 상기 클라이언트 장치(101)에 의해 생성되었을
Figure PCTKR2009006532-appb-I000102
를 예측할 수 있다.
한편 상기 서버(101)는 307단계에서 해쉬 함수를 이용하여 상기 클라이언트 장치(101)로부터 수신한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000103
의 해쉬 결과값을 산출한다.
그 후 상기 서버(101)는 308단계에서 상기 예측된 클라이언트 장치의 공개키
Figure PCTKR2009006532-appb-I000104
에 대한 검증을 수행한다. 상기 검증은 상기 산출된 해쉬 결과값과 앞에서 상기 클라이언트 장치(101)로부터 수신한 제2분할 공개키
Figure PCTKR2009006532-appb-I000105
가 일치하는지 여부에 의해 이루어진다.
이는 하기 <수학식 9>에서 보여지는 바와 같이 상기 클라이언트 장치(101)로부터 수신한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000106
에 해쉬 함수(H)를 적용하여 클라이언트 장치의 제2분할 공개키
Figure PCTKR2009006532-appb-I000107
가 산출되는지로 판단할 수 있다.
수학식 9
Figure PCTKR2009006532-appb-M000009
상기 서버(102)는 상기 산출된 해쉬 결과값과 상기 클라이언트 장치(101)로부터 수신한 제2분할 공개키
Figure PCTKR2009006532-appb-I000108
가 일치하면 309단계를 진행한다. 하지만 상기 산출된 해쉬 결과값과 상기 클라이언트 장치(101)로부터 수신한 제2분할 공개키
Figure PCTKR2009006532-appb-I000109
가 일치지 않으면, 상기 서버(102)는 중간 공격자에 의해 공개키가 수정되었다고 판단하여 키 교환 과정을 종료한다.
상기 서버(102)는 상기 예측된 클라이언트의 공개키
Figure PCTKR2009006532-appb-I000110
에 대한 검증이 이루어지면, 309단계에서 상기 예측된 클라이언트(101)의 공개키
Figure PCTKR2009006532-appb-I000111
를 이용하여 상기 클라이언트(101)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000112
를 검증한다.
이때, 상기 클라이언트 장치(101)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000113
는 하기 <수학식 10>에 의해 검증할 수 있다.
수학식 10
Figure PCTKR2009006532-appb-M000010
상기 <수학식 10>에 의하면, 클라이언트 장치(101)에 의해 자체적으로 생성된 개인키
Figure PCTKR2009006532-appb-I000114
로 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000115
를 상기 클라이언트 장치(101)의 공개키
Figure PCTKR2009006532-appb-I000116
를 이용하여 검증할 수 있다.
상술한 바에 의해 상기 서버(102)는 상기 클라이언트 장치(101)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000117
에 대한 검증에 실패하면, 중간 공격자에 의해 상기 서명된 Diffie-Hellman 공개 정보가 수정되었다고 판단하여 키 교환 과정을 종료한다. 하지만 상기 클라이언트 장치(101)로부터 수신한 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000118
에 대한 검증에 성공하면, 상기 서버(102)는 310단계로 진행한다.
상기 서버(102)는 310단계로 진행하면, 하기 <수학식 11>를 이용하여 보안 마스터 키를 생성한다.
수학식 11
Figure PCTKR2009006532-appb-M000011
여기서, gxy에서 기수인 g는 생성자이고, 지수 중 하나인 y는 서버(102)의 비밀 값이며, 나머지 지수인 x는 O라이언트 장치(101)의 비밀 값을 의미한다. 그리고 p는 큰 소수를 의미하며, mod는 모듈러 연산을 의미한다.
그리고 상기 서버(102)는 상기 생성된 보안 마스터 키를 상기 클라이언트 장치(101)와 상호 확인을 하기 위해 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000119
를 산출한다. 여기서 상기 보안 마스터 키 확인 정보는 보안 마스터 키
Figure PCTKR2009006532-appb-I000120
와 상기 보안 마스터 키를 생성하기 위해 필요한 공개 파라미터 값
Figure PCTKR2009006532-appb-I000121
와
Figure PCTKR2009006532-appb-I000122
에 해쉬 함수를 적용함으로써 산출할 수 있다.
상기 서버(102)는 상기 보안 마스터 키 확인 정보를 산출하면, 311단계에서 자신의 개인키
Figure PCTKR2009006532-appb-I000123
를 이용하여 앞에서 산출한 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000124
를 서명한다. 그리고 상기 서명된 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000125
와 제2분할 공개키
Figure PCTKR2009006532-appb-I000126
, 자신의 보안 마스터 키 확인 정보 값
Figure PCTKR2009006532-appb-I000127
를 INVITE와 200 OK 메시지에 포함된 RTP 주소 및 포트 번호를 이용하여 미디어 경로인 RTP 세션을 통해 상기 클라이언트 장치(101)로 전송한다. 이때 상기 서버(102)는 자신의 개인키
Figure PCTKR2009006532-appb-I000128
에 의해 서명하지 않은 Diffie-Hellman 공개 정보
Figure PCTKR2009006532-appb-I000129
를 상기 미디어 경로를 통해 상기 클라이언트 장치(101)로 전송한다.
한편 상기 서버(102)는 312단계에서 상기 클라이언트 장치(101)로부터 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000130
가 수신되었는지 검사한다.
한편 상기 서버(102)는 313단계에서 상기 생성된 보안 마스터 키
Figure PCTKR2009006532-appb-I000131
에 대한 검증을 수행한다. 상기 생성된 보안 마스터 키
Figure PCTKR2009006532-appb-I000132
는 상기 클라이언트 장치(101)로부터 수신한 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000133
를 이용하여 검증할 수 있다.
이는 하기 <수학식 12>로 일반화될 수 있다.
수학식 12
Figure PCTKR2009006532-appb-M000012
상기 서버(102)는 상기 생성된 보안 마스터 키
Figure PCTKR2009006532-appb-I000134
의 검증을 위해 새롭게 산출한 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000135
와 상기 클라이언트 장치(101)로부터 수신한 보안 마스터 키 확인 정보
Figure PCTKR2009006532-appb-I000136
를 비교한다.
상기 서버(102)는 상기 산출된 보안 마스터 키 확인 정보와 상기 클라이언트 장치(101)로부터 수신한 보안 마스터 키 확인 정보가 일치하면, 상기 생성된 보안 마스터 키가 상기 클라이언트 장치(101)에 의해 생성된 마스터 키와 일치한다고 판단한다. 하지만 상기 산출된 보안 마스터 키 확인 정보와 상기 클라이언트 장치(101)로부터 수신한 보안 마스터 키 확인 정보가 일치하지 않으면, 상기 서버(102)는 상기 클라이언트 장치(101)로부터 수신한 보안 마스터 키 확인 정보가 중간 공격자에 의해 변경되었다고 판단한다.
상술한 바에 의해 보안 마스터 키에 대한 검증이 완료된 이후 상기 서버(102)는 314단계에서 상기 검증된 보안 마스터 키를 이용하여 상기 클라이언트 장치(101)와의 데이터 송수신을 수행한다.
이와 같이 상기 서버(102)는 자신의 공개키를 분할하여 서로 다른 두 가지 경로를 통해 상기 클라이언트 장치(101)로 전송함으로써, 중간 공격자에 의한 공격이 이루어지더라도 공개키가 노출되지 않는다는 이점이 있다.
이처럼 본 발명의 실시 예에서는 사용자 단말 간의 공개 키 각각을 분할하여 서로 다른 경로를 통해 교환함으로써 분할된 어느 하나의 공개 키가 중간 공격자에 의해 공격을 받더라도 단말 간의 키 교환이 가능하다는 이점이 있다.

Claims (18)

  1. 데이터 통신을 수행할 장치들 상호간에 보안 키를 공유하도록 하는 통신 시스템에 있어서,
    자체적으로 생성한 공개키를 두 개의 공개키로 분할하고, 상기 분할된 두 개의 공개키들 중 하나의 분할 공개키를 상대 장치와의 시그널링 경로를 통해 전송하고, 다른 하나의 분할 공개키와 자체적으로 생성한 개인키로 서명된 공개 정보를 상기 상대 장치와의 미디어 경로를 통해 전송하며,
    상기 상대 장치로부터 상기 시그널링 경로와 상기 미디어 경로를 통해 수신한 두 개의 분할 공개키를 이용하여 상기 상대 장치에 의해 자체적으로 생성된 공개키를 예측하고, 상기 예측한 공개키와 상기 상대 장치로부터 상기 미디어 경로를 통해 수신한 서명된 상대 공개 정보에 대한 인증을 수행하며,
    상기 예측한 공개키와 상기 서명된 상대 공개 정보에 대한 인증에 성공하면, 상기 상대 장치와의 데이터 통신 시에 사용할 마스터 키를 생성하는 클라이언트 장치를 포함하는 통신 시스템.
  2. 제1항에 있어서, 상기 클라이언트 장치는,
    상기 상대 장치에 의해 분할된 두 개의 공개키 중 하나의 분할 공개키와, 상기 서명된 상대 공개 정보를 마스터 키 확인 정보와 함께 상기 미디어 경로를 통해 상기 상대 장치로부터 수신함을 특징으로 하는 통신 시스템.
  3. 제2항에 있어서, 상기 클라이언트 장치는,
    상기 생성한 마스터 키와, 상기 서명된 공개 정보 및 상기 서명된 상대 공개 정보를 이용하여 상기 생성한 마스터 키에 대응한 마스터 키 확인 정보를 생성함을 특징으로 하는 통신 시스템.
  4. 제3항에 있어서, 상기 클라이언트 장치는,
    상기 생성한 마스터 키에 대응하여 생성된 마스터 키 확인 정보와 상기 상대 장치로부터 수신한 마스터 키 확인 정보의 비교에 의해 상기 상대 장치에 의해 생성되었을 마스터 키에 대한 검증을 수행함을 특징으로 하는 통신 시스템.
  5. 제4항에 있어서, 상기 클라이언트 장치는,
    상기 상대 장치에 의해 생성되었을 마스터 키에 대한 검증이 이루어지면, 상기 생성한 마스터 키에 대응하여 생성된 마스터 키 확인 정보를 상기 미디어 경로를 통해 상기 상대 장치로 전송함을 특징으로 하는 통신 시스템.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 클라이언트 장치는,
    상기 상대 장치로부터 상기 시그널링 경로와 상기 미디어 경로를 통해 수신한 두 개의 분할 공개키를 배타적 논리 합 연산하여 상기 상대 장치에 의해 자체적으로 생성된 공개키를 예측함을 특징으로 하는 통신 시스템.
  7. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 클라이언트 장치는,
    상기 자체적으로 생성한 공개키로부터 분할된 두 개의 공개키들 중 하나의 분할 공개키를 상기 자체적으로 생성한 개인키로 서명되기 전의 공개 정보에 해쉬 함수를 적용하여 생성하며,
    상기 자체적으로 생성한 공개키와 상기 해쉬 함수를 적용하여 생성된 분할 공개키를 배타적 논리 합 연산하여 다른 하나의 분할된 공개키를 생성함을 특징으로 하는 통신 시스템.
  8. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 클라이언트 장치는,
    디피-헬만(Diffie-Hellman) 비밀 값을 생성하고, 상기 생성한 디피-헬만(Diffie-Hellman) 비밀 값을 이용하여 상기 자체적으로 생성한 개인키로 서명할 공개 정보를 산출함을 특징으로 하는 통신 시스템.
  9. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 클라이언트 장치는,
    상기 서명된 상대 공개 정보에 해쉬 함수를 적용하여 상기 상대 장치로부터 상기 미디어 경로를 통해 수신한 분할 공개키가 생성되는지에 의해 상기 예측한 공개키에 대한 인증을 수행하고, 상기 인증이 이루어진 상기 예측한 공개키를 이용하여 상기 서명된 상대 공개 정보에 대한 인증을 수행함을 특징으로 하는 통신 시스템.
  10. 상대 장치와의 데이터 통신을 위해 클라이언트 장치에서 상기 상대 장치와 보안 키를 공유하는 방법에 있어서,
    자체적으로 생성한 공개키를 두 개의 공개키로 분할하는 과정;
    상기 분할된 두 개의 공개키들 중 하나의 분할 공개키를 상대 장치와의 시그널링 경로를 통해 전송하고, 다른 하나의 분할 공개키와 자체적으로 생성한 개인키로 서명된 공개 정보를 상기 상대 장치와의 미디어 경로를 통해 전송하는 과정;
    상기 상대 장치로부터 상기 시그널링 경로와 상기 미디어 경로를 통해 수신한 두 개의 분할 공개키를 이용하여 상기 상대 장치에 의해 자체적으로 생성된 공개키를 예측하는 과정;
    상기 예측한 공개키와 상기 상대 장치로부터 상기 미디어 경로를 통해 수신한 서명된 상대 공개 정보에 대한 인증을 수행하는 과정;
    상기 예측한 공개키와 상기 서명된 상대 공개 정보에 대한 인증에 성공하면, 상기 상대 장치와의 데이터 통신 시에 사용할 마스터 키를 생성하는 과정을 포함하는 보안 키 공유 방법.
  11. 제10항에 있어서,
    상기 상대 장치에 의해 분할된 두 개의 공개키 중 하나의 분할 공개키와, 상기 서명된 상대 공개 정보는 마스터 키 확인 정보와 함께 상기 미디어 경로를 통해 상기 상대 장치로부터 수신됨을 특징으로 하는 보안 키 공유 방법.
  12. 제11항에 있어서,
    상기 생성한 마스터 키와, 상기 서명된 공개 정보 및 상기 서명된 상대 공개 정보를 이용하여 상기 생성한 마스터 키에 대응한 마스터 키 확인 정보를 생성하는 과정을 더 포함하는 보안 키 공유 방법.
  13. 제12항에 있어서,
    상기 생성한 마스터 키에 대응하여 생성된 마스터 키 확인 정보와 상기 상대 장치로부터 수신한 마스터 키 확인 정보의 비교에 의해 상기 상대 장치에 의해 생성되었을 마스터 키에 대한 검증을 수행하는 과정을 더 포함하는 보안 키 공유 방법.
  14. 제13항에 있어서,
    상기 상대 장치에 의해 생성되었을 마스터 키에 대한 검증이 이루어지면, 상기 생성한 마스터 키에 대응하여 생성된 마스터 키 확인 정보를 상기 미디어 경로를 통해 상기 상대 장치로 전송하는 과정을 더 포함하는 보안 키 공유 방법.
  15. 제10항 내지 제14항 중 어느 한 항에 있어서, 상기 공개키를 예측하는 과정은,
    상기 상대 장치로부터 상기 시그널링 경로와 상기 미디어 경로를 통해 수신한 두 개의 분할 공개키를 배타적 논리 합 연산하여 상기 상대 장치에 의해 자체적으로 생성된 공개키를 예측하는 과정임을 특징으로 하는 보안 키 공유 방법.
  16. 제10항 내지 제14항 중 어느 한 항에 있어서, 상기 분할하는 과정은,
    상기 자체적으로 생성한 개인키로 서명되기 전의 공개 정보에 해쉬 함수를 적용하여 상기 자체적으로 생성한 공개키로부터 분할된 두 개의 공개키들 중 하나의 분할 공개키를 생성하는 단계와,
    상기 자체적으로 생성한 공개키와 상기 해쉬 함수를 적용하여 생성된 분할 공개키를 배타적 논리 합 연산하여 다른 하나의 분할된 공개키를 생성하는 단계를 포함하는 보안 키 공유 방법.
  17. 제10항 내지 제14항 중 어느 한 항에 있어서,
    상기 자체적으로 생성한 개인키로 서명할 공개 정보는 디피-헬만(Diffie-Hellman) 비밀 값을 생성하고, 상기 생성한 디피-헬만(Diffie-Hellman) 비밀 값을 이용하여 산출됨을 특징으로 하는 보안 키 공유 방법.
  18. 제10항 내지 제14항 중 어느 한 항에 있어서, 상기 인증을 수행하는 과정은,
    상기 서명된 상대 공개 정보에 해쉬 함수를 적용하여 상기 상대 장치로부터 상기 미디어 경로를 통해 수신한 분할 공개키가 생성되는지에 의해 상기 예측한 공개키에 대한 인증을 수행하는 단계와,
    상기 인증이 이루어진 상기 예측한 공개키를 이용하여 상기 서명된 상대 공개 정보에 대한 인증을 수행하는 단계를 포함하는 보안 키 공유 방법.
PCT/KR2009/006532 2008-11-06 2009-11-06 보안 키 교환 장치 및 방법과 이에 관한 시스템 WO2010053319A2 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/128,106 US8380992B2 (en) 2008-11-06 2009-11-06 Device and method for security key exchange and system pertaining to same

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020080109944A KR20100050846A (ko) 2008-11-06 2008-11-06 키 교환 시스템 및 방법
KR10-2008-0109944 2008-11-06

Publications (2)

Publication Number Publication Date
WO2010053319A2 true WO2010053319A2 (ko) 2010-05-14
WO2010053319A3 WO2010053319A3 (ko) 2010-07-29

Family

ID=42153406

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2009/006532 WO2010053319A2 (ko) 2008-11-06 2009-11-06 보안 키 교환 장치 및 방법과 이에 관한 시스템

Country Status (3)

Country Link
US (1) US8380992B2 (ko)
KR (1) KR20100050846A (ko)
WO (1) WO2010053319A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170031552A (ko) * 2015-09-11 2017-03-21 삼성전자주식회사 전자 장치의 근접 인증 방법 및 그 장치

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2656648B1 (en) 2010-12-21 2018-05-09 Koninklijke KPN N.V. Operator-assisted key establishment
EP2697786B1 (en) * 2011-04-13 2017-10-04 Nokia Technologies Oy Method and apparatus for identity based ticketing
US8601144B1 (en) * 2012-11-27 2013-12-03 Sansay, Inc. Systems and methods for automatic ICE relay candidate creation
JP6555258B2 (ja) * 2013-10-30 2019-08-07 日本電気株式会社 移動通信システム、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ、ＵＥ及び方法
US9240982B2 (en) 2013-12-27 2016-01-19 Canon Information And Imaging Solutions, Inc. Method for associating an image-forming device, a mobile device, and a user
KR102125562B1 (ko) * 2014-06-18 2020-06-22 삼성전자주식회사 키 공유 방법 및 장치
CN104102714A (zh) * 2014-07-16 2014-10-15 上海交通大学 基于累加器和布隆过滤器的外包数据查询验证方法及系统
EP3248359A4 (en) * 2015-01-22 2018-09-05 Visa International Service Association Method and system for establishing a secure communication tunnel
KR20170035665A (ko) 2015-09-23 2017-03-31 삼성에스디에스 주식회사 키 교환 장치 및 방법
DE102016220734A1 (de) * 2016-10-21 2018-04-26 Robert Bosch Gmbh Verfahren und Vorrichtung zum Erzeugen eines kryptographischen Schlüssels
CN106941487B (zh) * 2017-02-24 2021-01-05 创新先进技术有限公司 一种数据发送方法及装置
CN111342955B (zh) * 2018-12-19 2023-04-18 北京沃东天骏信息技术有限公司 一种通信方法及其设备、计算机存储介质
US11683380B2 (en) * 2021-02-09 2023-06-20 Cisco Technology, Inc. Methods for seamless session transfer without re-keying
KR102648499B1 (ko) * 2021-03-11 2024-03-19 한국전자통신연구원 기계 학습 기반 키 생성 장치 및 방법

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100720726B1 (ko) * 2003-10-09 2007-05-22 삼성전자주식회사 Ｒｓａ 알고리즘을 이용한 보안유지시스템 및 그 방법
KR20080051947A (ko) * 2006-12-07 2008-06-11 인하대학교 산학협력단 변형 디피 헬만 기반 키교환 방법
US20080229104A1 (en) * 2007-03-16 2008-09-18 Samsung Electronics Co., Ltd. Mutual authentication method between devices using mediation module and system therefor

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2369304A1 (en) * 2002-01-30 2003-07-30 Cloakware Corporation A protocol to hide cryptographic private keys
US7660419B1 (en) * 2004-08-13 2010-02-09 Texas Instruments Incorporated System and method for security association between communication devices within a wireless personal and local area network
US7596697B2 (en) * 2005-02-14 2009-09-29 Tricipher, Inc. Technique for providing multiple levels of security

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100720726B1 (ko) * 2003-10-09 2007-05-22 삼성전자주식회사 Ｒｓａ 알고리즘을 이용한 보안유지시스템 및 그 방법
KR20080051947A (ko) * 2006-12-07 2008-06-11 인하대학교 산학협력단 변형 디피 헬만 기반 키교환 방법
US20080229104A1 (en) * 2007-03-16 2008-09-18 Samsung Electronics Co., Ltd. Mutual authentication method between devices using mediation module and system therefor

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170031552A (ko) * 2015-09-11 2017-03-21 삼성전자주식회사 전자 장치의 근접 인증 방법 및 그 장치
US10462659B2 (en) 2015-09-11 2019-10-29 Samsung Electronics Co., Ltd. Method and apparatus for proximal authentication of wireless electronic device
KR102399665B1 (ko) 2015-09-11 2022-05-19 삼성전자주식회사 전자 장치의 근접 인증 방법 및 그 장치

Also Published As

Publication number Publication date
WO2010053319A3 (ko) 2010-07-29
KR20100050846A (ko) 2010-05-14
US20110211700A1 (en) 2011-09-01
US8380992B2 (en) 2013-02-19

Similar Documents

Publication Publication Date Title
WO2010053319A2 (ko) 보안 키 교환 장치 및 방법과 이에 관한 시스템
WO2021095998A1 (en) A trusted computing method and system
WO2014069783A1 (ko) 패스워드 기반 인증 방법 및 이를 수행하기 위한 장치
WO2013005989A2 (ko) 이동 기기에 대한 그룹 키 관리를 위한 방법 및 장치
EP1025675B1 (en) Security of data connections
WO2014175538A1 (ko) Puf 기반 하드웨어 otp 제공 장치 및 이를 이용한 2-factor 인증 방법
WO2014069778A1 (ko) 아이디 기반 암호화, 복호화 방법 및 이를 수행하기 위한 장치
WO2014063455A1 (zh) 即时通信方法和系统
CN111416807A (zh) 数据获取方法、装置及存储介质
WO2019132272A1 (ko) 블록체인 기반의 서비스로서의 아이디
KR100879982B1 (ko) 모바일 와이맥스 네트워크 시스템에서의 보안 시스템 및방법
WO2012093900A2 (en) Method and device for authenticating personal network entity
WO2012099330A2 (ko) Ｃｐｎｓ 환경에서 사용자 인증을 위한 인증키 발급 시스템 및 방법
WO2021112603A1 (en) Method and electronic device for managing digital keys
WO2018072261A1 (zh) 信息加密方法及装置、信息解密方法及装置及终端
WO2018147488A1 (ko) 클라우드 컴퓨팅을 위한 안전한 속성기반 인증 방법
WO2019132270A1 (ko) Nfv 환경에서 보안 통신 방법 및 그 시스템
WO2019182377A1 (ko) 블록체인 기반 암호화폐의 트랜잭션에 이용되는 주소 정보 생성 방법, 전자 장치 및 컴퓨터 판독 가능한 기록 매체
WO2015030553A1 (ko) 래티스 기반 인증서 비사용 서명 시스템 및 방법
CN111224784A (zh) 一种基于硬件可信根的角色分离的分布式认证授权方法
JP2024051151A (ja) 暗号通信システム、セキュアエレメント、デバイス及び暗号通信方法
WO2019124667A1 (ko) 웨어러블 디바이스 통신 지원 장치 및 방법
WO2020032351A1 (ko) 익명 디지털 아이덴티티 수립 방법
CN108199851B (zh) 一种数据安全传输方法、装置及系统
CN111901109B (zh) 基于白盒的通信方法、装置、设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09825002

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13128106

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 09825002

Country of ref document: EP

Kind code of ref document: A2