WO2021025403A2

WO2021025403A2 - Security key management method and security key management server

Info

Publication number: WO2021025403A2
Application number: PCT/KR2020/010188
Authority: WO
Inventors: 박진우; 김진근; 이문혁; 이강희
Original assignee: 주식회사 티모넷
Priority date: 2019-08-02
Filing date: 2020-08-03
Publication date: 2021-02-11
Also published as: KR102289478B1; KR20210015534A; WO2021025403A3

Abstract

A security key management method and a security key management server including same are provided. The security key management method comprises: receiving, from a hardware security module, a key blob and an authentication value corresponding to a security key, when a key generation request signal including information of an owner that owns the security key is received from an external device; generating a key store file including the key blob and the authentication value; generating the name of the key store file on the basis of the owner information; and storing the key store file and the name of the key store file in another device that is not the hardware security module.

Description

Security key management method and security key management server

It relates to a security key management method and a security key management server.

In information protection and authentication technology, the necessity of developing technology for devices and systems that securely manage personal authentication information and information such as passwords for financial transactions in hardware and cryptographically has been raised with the spread of the Internet.

Confidential information is a means of authenticating an individual and confirming that the person has performed a specific act. If confidential information is exposed to others, the entire financial transaction system cannot be identified and the entire financial transaction system should be managed very safely. .

In order to provide such a high level of security, the concept of a hardware secure module (Hardware Secure Module) equipped with a cryptographically secure management system at the same time in hardware has been introduced.

Meanwhile, hardware security module technology is used in various fields, but the number of security keys that can be stored may be limited due to the hardware capacity of the hardware security module.

The present embodiment provides a method of generating a separate dedicated file without storing a security key in a hardware security module and storing it in a database other than a hardware security module, and a server thereof.

The security key management method according to an embodiment, upon receiving a key generation request signal including owner information to own the security key from an external device, transmits the key generation request signal to a hardware security module, and Receiving a key blob corresponding to the security key; Transmitting an authentication value request signal including the owner information and a key blob to the hardware security module, and receiving an authentication value corresponding to the authentication value request signal from the hardware security module; Generating a key store file including the key blob and the authentication value; Generating a name of the key store file based on the owner information; And storing the key store file and the name of the key store file in a database other than the hardware security module.

In addition, the key store file may include a head area including the owner information, a body area including the key blob, and a protection area including the authentication value.

In addition, as for the authentication value, the hardware security module generates an induction key using the owner information and a pre-stored master key, and uses information included in the head area, information included in the body area, and the induction key. It may be a value generated by

In addition, the name of the key store file may include a character string derived from the owner information and information on a date and time when the key store file was created.

In addition, the name of the key store file may be grouped and stored in an exclusive ORed value of 2 bytes.

The generating of the store file may include checking whether a key store file including owner information identical to the owner information is stored in the database; And if a key store file including the same owner information is previously stored, updating the key blob and the authentication value to a previously stored key store file.

In addition, when a first key use request signal including owner information and data to use a security key is received from the external device, the name of the key store file corresponding to the owner information included in the first key use request signal is stored in the database. Reading from; Obtaining a key store file matching the name of the key store file; Verifying the key store file by using the authentication value included in the key store file; Obtaining a key blob from the key store file when verification of the authentication value is completed; And transmitting a second key use request signal including the key blob and the data to the hardware security module, and receiving data to which the security key is applied from the hardware security module.

On the other hand, the security key management server according to an embodiment, a communication unit for communicating with an external device and a hardware security module; And when receiving a key generation request signal including owner information to own the security key from the external device through the communication unit, requesting the key generation request signal from the hardware security module and corresponding to the security key from the hardware security module Acquires a key blob, requests an authentication value request signal including the owner information and the key blob from the communication unit to the hardware security module, and obtains an authentication value corresponding to the authentication value request signal from the hardware security module And, a key store file including the key blob and the authentication value is generated, a name of the key store file is generated based on the owner information, and the name of the key store file and the key store file is changed to the hardware security It includes a file handler that stores in a database other than a module.

In addition, the file processor may generate a name of the key store file to include a character string derived from the owner information and information on a date and time at which the key store file was created.

Also, in the file processor, the name of the key store file may be grouped and stored in an exclusive OR value of 2 bytes.

In addition, the file processor checks whether a key store file including owner information identical to the owner information is stored in the database, and if a key store file including the same owner information is previously stored, the key blob and the The authentication value can be updated to a previously stored key store file.

In addition, when the file processor receives a first key use request signal including the owner information and data to use the security key from the external device through the communication unit, the owner information included in the first key use request signal is Obtaining the corresponding key store file, obtaining the key blob from the key store file, and transmitting a second key use request signal including the key blob and the data to the hardware security module through the communication unit Data to which the security key is applied may be received from the hardware security module.

According to the embodiments, since the security key is not stored in the hardware security module, a separate dedicated file is created and stored in a database other than the hardware security module, the hardware security module can be used without limitation in hardware capacity.

In addition, since the management server creates and stores the name of the key store file as well as the key store file, when user information is received from an external device, the key store file is read out whenever necessary using the name of the key store file, which speeds up file processing. It can be faster.

Fig. 1 is a diagram showing a security key management system according to an exemplary embodiment.

FIG. 2 is a block diagram showing the hardware security module shown in FIG. 1.

3 is a block diagram showing the management server shown in FIG. 1.

4 is a flowchart illustrating a method of generating a key store file in a management system according to an embodiment.

5 is a reference diagram illustrating a format of a key store file according to an embodiment.

6 is a reference diagram illustrating an example of a name of a key store file according to an embodiment.

7 is a flowchart illustrating a method of using a security key by a management system according to an embodiment.

8 is a flowchart illustrating a method of generating a key store file in a management system according to another embodiment.

9 is a reference diagram illustrating a key store file including information related to a plurality of security keys according to an exemplary embodiment.

The terms used in the present invention have been selected from general terms that are currently widely used while considering functions in the present invention, but this may vary depending on the intention or precedent of a technician working in the field, the emergence of new technologies, and the like. In addition, in certain cases, there are terms arbitrarily selected by the applicant, and in this case, the meaning of the terms will be described in detail in the description of the corresponding invention. Therefore, the terms used in the present invention should be defined based on the meaning of the term and the overall contents of the present invention, not a simple name of the term.

Although terms such as first, second, etc. are used to describe various elements, these elements are not limited by these terms. These terms are only used to distinguish one element from another.

The terms used in the present application are used only to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In the present application, terms such as "comprise" or "have" are intended to designate the presence of features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, but one or more other features. It is to be understood that the presence or addition of elements or numbers, steps, actions, components, parts, or combinations thereof, does not preclude in advance. Terms such as first and second may be used to describe various elements, but the elements should not be limited by the terms. These terms are used only for the purpose of distinguishing one component from another component.

Fig. 1 is a diagram showing a security key management system 10 according to an exemplary embodiment.

Referring to FIG. 1, a security key management system 10 according to an embodiment includes a security key and a hardware security module 100 for generating a key blob corresponding to the security key, and a key from the hardware security module 100. A security key management server 200 (hereinafter referred to as'management server') that receives the blob and generates a key store file including the key blob and the name of the key store file, and a database that stores the name of the key store file ( 300) may be included.

The hardware security module 100 and the database 300 communicate only with the management server 200 and do not directly communicate with the external device 400, so that the security of the hardware security module 100 may be enhanced. The external device 400 may transmit a request signal related to the security key to the management server 200 and receive the result from the management server 200. Here, the external device 400 may be various such as a user terminal, a bank server, a server operated by a public institution, and a server providing an e-commerce service.

2 is a block diagram illustrating the hardware security module 100 shown in FIG. 1. Referring to FIG. 2, the hardware security module 100 includes a first communication unit 110 that communicates with the management server 200, a key processor 120 that generates a security key, and a data processor that applies a security key to data. It may include (130).

The key processor 120 may generate a security key by receiving a security key generation request signal from the management server 200 through the first communication unit 110. The security key generation request signal may include information such as owner information of the security key, the type of security key, and the type of data related to the security key. The security key is generated through a random number generator (RNG) based on a security key generation request signal, and a plurality of security keys may be generated. Security keys can be generated in various ways. For example, a security key can be generated by a prime factorization encryption system or an elliptic curve encryption system. Here, the security key may be an authentication key, an encryption key, a decryption key, and the like, and may be a private key or a public key.

The key processor 120 may convert the generated security key into a key blob (binary large object), or may convert the key blob received through the first communication unit 110 into a security key. When generating a key blob, the key processor 120 may add specific data to the security key. In addition, the key processor 120 may generate a derivation key based on the master key previously stored in the hardware security module 100, or use the derivation key to generate an authentication value for authenticating a key store file to be described later. .

The data processor 130 may encrypt or decrypt data using a security key according to the request of the management server 200, or may generate signature data signed by using the security key. The data processor 130 may use various encryption/decryption algorithms such as SEED, ARIA, RSA, DES, MD5, DSS, SHA, and the like.

With the configuration as described above, the hardware security module 100 may generate a security key internally and encrypt/decrypt data based on this. The above-described hardware security module 100 cannot extract the security key generated internally by any method, and if the data is to be extracted by a physical method, a safety device such as destroying data by itself is used as a hardware security module ( 100) may be further included.

3 is a block diagram of the management server 200 shown in FIG. 1. As shown in FIG. 3, the management server 200 includes the hardware security module 100 and the second communication unit 210 communicating with the external device 400, and the hardware security module 100 at the request of the external device 400. ) To generate a security key, or a file processor 220 that generates a key store file including a key blob corresponding to the security key received from the hardware security module 100, and a storage unit that stores the key store file ( 230) may be included.

The following describes in detail how the management server 200 generates and uses the key store file.

4 is a flowchart illustrating a method of generating a key store file in the management system 10 according to an embodiment.

When the management server 200 receives a request to generate a security key from an external device (S410), the management server 200 requests the hardware security module 100 to generate a security key (S415). In response to a security key generation request, the hardware management server 200 may generate a security key, generate a key blob corresponding to the security key, and transmit the key blob to the management server 200 (S420). The security key generation request signal may include information such as owner information of the security key, the type of security key, and the type of data related to the security key. The security key may be an authentication key, an encryption key, a decryption key, or the like, and may be a private key or a public key. Data other than the security key may be further added to the key blob.

In addition, the file processor 220 of the management server 200 generates a part of the key store file including the key blob (S430). The key store file may include a head area including owner information of a security key, a body area including a key blob, and a protection area including an authentication value.

Owner information included in the head area may be information received from the external device 400. Owner information may be included in the security key generation request signal received from the external device 400. Alternatively, the management server 200 may transmit a signal requesting owner information to the external device 400 (eg, a user terminal) and receive owner information from the external device 400. The owner information is information identifying the owner who will own the security key, and may be a password set by the owner, biometric information, mobile phone number, email address, CI, social security number, and the like.

In the head area, at least one of version information on the key store file, information on the date and time when the key store file was last updated (date and time), and information on the number of security keys generated by the hardware management server 200 is further included. Can include.

Key blobs may be included in the body area. In addition, a key alias may be further included in the body area. The key alias is information for identifying a security key, and the management server may generate a key alias with an arbitrary value or may generate a key alias based on a key blob. The key alias described above may be a unique value for each key blob. The generated key alias can be included in the body area of the key store file.

In addition, the body region may further include a hash value of the key blob encrypted by the hash function. The file processor 220 may generate a hash value of the key blob by encrypting the key blob and owner information using a hash function.

The file processor 220 of the management server 200 may generate the head area and the body area of the key store file using information received from the external device 400 and information received from the hardware security module 100.

The file processor 220 of the management server 200 requests an authentication value for confirming whether the key store file has been tampered with through the second communication unit 210 (S435), and the above authentication from the hardware security module A value may be received (S440). When requesting an authentication value, the management server 200 may provide information included in the head area of the key store file and information included in the body area of the key store file to the hardware security module 100.

The key processor 120 of the hardware security module 100 requested to generate the authentication value generates an induction key using the owner information and the master key previously stored in the hardware security module 100, and includes it in the head area of the key store file. An authentication value may be generated using the obtained information, information included in the body area of the key store file, and the above-described derivation key. For example, the key processor 120 may use an encryption algorithm when generating an induction key, and may generate an authentication value using the HMAC algorithm, but is not limited thereto. Of course, the key processor 120 may apply another algorithm for generating an authentication value. The hardware security module 100 transmits the generated authentication value to the management server 200 so that the management server 200 may obtain the authentication value.

Then, the file processor 220 may complete the key store file by including the authentication value in the protected area of the key store file (S450). When the key store file is completed, the file processor 220 may update the last update date and time of the head area of the key store file.

5 is a reference diagram illustrating a format of a key store file according to an embodiment. As illustrated in FIG. 5, the key store file may include a head area 510, a body area 520, and a protection area 530. The head area 510 may include at least one of version information about a key store file, information about a date and time when the key store file was last updated, information about an owner, and information about the number of keys. Version information and information on the number of keys may be displayed as numbers, and owner information may be displayed as a bit string.

The body region 520 may include detailed information corresponding to the security key. A key alias per security key, a hash value of a key blob, and a key blob can be stored. When the hardware security module 100 generates a plurality of security keys for one owner, a key blob corresponding to each security key, a key alias, and a hash value of the key blob may be included in the body region. That is, even if there are a plurality of security keys for one owner, the management server 200 generates one key store file, so that management of the key store file becomes convenient.

In addition, the protection area 530 may include an authentication value generated by the hardware security module.

Also, the file processor 220 may generate a name of a key store file to match the key store file (S460). The management server 200 may assign a name so that the name of the key store file is not duplicated even if the number of key store files increases. For example, the file processor 220 may generate the name of the key store file, including a value derived from owner information of the security key and a date and time when the key store file was initially created. For example, the file processor 220 expresses the hash value of the owner information of the security key as a string of hexadecimal digits, and the year, month, date, hour, minute, and second of the key store file initially generated as a string. By doing so, the name of the key store file can be generated. The owner information of the security key may be information that can identify the owner as the key owner's mobile phone number, email address, CI, or social security number. 6 is a reference diagram illustrating an example of a name of a key store file according to an embodiment. As shown in Fig. 6, the front end of the key store file represents a hash value for owner information as a string of hexadecimal numbers, and the middle end of the key store file is the year, month, date, hour, minute, and second when the key store file was initially created. And the latter part may be expressed as the extension name of the key store file.

In addition, the file processor 220 may generate a key store file and a history of a key store file to match the name of the key store file (S470). The file processor 220 may generate or update the history of the key store file whenever the key store file is created, deleted, or changed. The file processor 220 includes a serial number of the history, that is, a number that is updated every time the history is generated, the name of the key store file, the date and time (access date) using the key store file, and the form using the key store file (e.g. , Key store file creation, deletion, key blob addition, key blob deletion, key blob usage, etc.), key alias corresponding to used key blob, authentication value of key store file, key store file just before history update It may include at least one of a hash value for the history, a hash value for the history of a key store file immediately after updating the history, and a date and time when the history of the key store file is generated. The history of the key store file described above may be used for the purpose of auditing access to the key store file.

The file processor 220 may store the key store file, the name of the key store file, and the history of the key store file in a database other than the hardware security module 100 that generated the security key (S475 and S480). For example, the file processor 220 stores the key store file in the storage unit 230 of the management server 200 (S475), the name of the key store file, the history of the key store file, and directory information of the key store file. May be matched with each other and stored in the database 300 (S480). The directory information may be directory information of the storage unit 230 in which the key store file is stored.

The file processor 220 stores the name of the key store file by exclusively ORing the value derived from the owner information included in the name of the key store file in units of 2 bytes, and grouping it into an exclusive ORed value, and corresponds to the above name. The key store file and the history of the key store file can be matched and stored. It can be easy to manage the database by grouping and storing the names of key store files.

Alternatively, the file processor 220 may group the name of the key store file according to the purpose of the security key and the service related to the security key, and store the grouped key store file name by grouping the grouped key store file name into an exclusive logical value. . As described above, since the name of the key store file is stored in a plurality of steps, it is easy to read the name of the key store file.

In FIG. 4, it is assumed that the key store file is stored in the storage unit 230 of the management server 200 and the name of the key store file is stored in the database 300. The reason why the names of the key store file and the key store file are stored in different storage devices as described above is for more secure security and is not limited thereto. It goes without saying that the key store file can also be stored in the database 300. Alternatively, the name of the key store file and the key store file may also be stored in a storage unit or a database included in the management server 200. That is, the name of the key store file and the key store file are stored in a device other than the hardware security module.

Although the generation of the security key has been described in FIG. 4, it is not limited thereto. The management server 200 may receive a security key injection request from the external device 400. The security key injection request may include a security key. The management server 200 may transmit the security key injection request to the hardware security module 100 and receive a key blob corresponding to the security key from the hardware security module 100. Thereafter, the management server 400 may generate a key store file for the injected security key, a name of the key store file, and a history of the key store file. The generation of the key store file, the name of the key store file, and the history of the key store file are the same as those of S430 to S480, and a detailed description thereof will be omitted.

7 is a flowchart illustrating a method of using a security key by the management system 10 according to an embodiment.

Referring to FIG. 7, when receiving a first key use request from the external device 400 (S710), the management server 200 reads the name of the key store file from the database 300 based on the owner information (S720). ), a key store file may be obtained by using the name of the key store file (S730). The key use request transmitted from the external device 400 to the management server 200 is called a first key use request, and the key use request signal transmitted by the management server 200 to the hardware security module 100 is used as a second key. It can be called a request.

Specifically, when a request for using the first key including owner information of the security key and data to which the security key is applied is received from the external device 400, the file processor 220 of the management server 200 is the second communication unit 210 The name of the key store file including the owner information of the security key may be read from the database 300 through. When not only the name of the key store file, but also the history of the key store file and the directory of the key store file are matched and stored in the database 300, the file processor 220 uses the second communication unit 210 to match the name of the key store file. The history of the matched key store file and the directory of the key store file may be obtained by reading from the database 300.

In addition, the file processor 220 may obtain a key store file matching the name of the key store file from the storage unit 230 by using the directory information.

The management server 200 may verify the key store file using the hardware security module 100 (S740). For example, the file processor 220 of the management server 200 transmits information included in the head area of the key store file and the information included in the body area of the key store file through the second communication unit 210 to a hardware security module ( You can request authentication values while providing them to 100). The hardware security module 100 generates an induction key using owner information included in the head area of the key store file and the master key previously stored in the hardware security module 100, and information included in the head area of the key store file. , The authentication value may be generated using the information included in the body area of the key store file and the above-described derivation key. The hardware security module 100 transmits the generated authentication value to the management server 200, and the management server 200 stores the authentication value received from the hardware security module 100 and the authentication value included in the key store file. By comparing, you can verify the key store file.

In addition, the management server 200 may verify the owner of the security key (S760). For example, the management server 200 may transmit a request signal for owner confirmation to the external device 400 (eg, a user terminal), and receive the result from the external device 400. In addition, the management server 200 may verify the owner by comparing the owner information included in the key store file with the result received from the external device 400. In addition, the owner can be verified using a temporary key.

In FIG. 7, the owner is verified after verifying the key store file, but this is not limited thereto. You can also verify the key store file after verifying the owner. The management server 200 may simultaneously verify the key store file and the owner.

After verification of the key store file and the owner is completed, the file processor 220 of the management server 200 may obtain a key blob included in the key store file (S760). Even when acquiring the key blob, the file processor 220 may verify the key blob using the hash value of the key blob. For example, the file processor 220 generates a hash value of the key blob using the owner information of the security key included in the head area of the key store file and the key blob included in the body area of the key store pie, and then generates A key blob can be verified by comparing a key blob hash value with a key blob hash value included in the key store file. If the generated key blob hash value and the previously stored key blob hash value are the same, it is assumed that the verification has been completed.

Meanwhile, when a number of key blobs are included in the key store file, the management server 200 may acquire only key blobs that match the key alias to be used.

Thereafter, the management server 200 may transmit a second key use request signal to the hardware security module 100 (S770), and receive data to which the security key is applied (S780). The key use request signal may include data and key blobs to which the security key is to be applied. The key processor 120 of the hardware security module 100 may convert the key blob into a security key and transmit it to the data processor 130. In addition, the data processor 130 of the hardware security module 100 may apply the converted security key to the data and transmit the result to the management server 200. When the above-described data is data for authentication, the data processor 130 may generate signature data that signs the data with a security key and transmit the signature data to the management server 200. When the data received from the management server 200 is data for encryption or decryption, the data processor 130 may generate encrypted data or decrypted data by encrypting or decrypting the data with the security key converted from the key blob, and , The result may be transmitted to the management server 200.

As described above, by generating a separate key store file corresponding to the security key and storing it in a device other than the hardware security module 100, the capacity of the hardware security module 100 can be unlimitedly expanded.

In addition, since a plurality of key blobs corresponding to a plurality of security keys may be included in one key store file, management of security keys for each owner is facilitated. In addition, even if a plurality of management servers exist, the key blob can be shared because the key store file is stored in devices other than the hardware security module.

8 is a flowchart illustrating a method of generating a key store file in a management system according to another embodiment. When a security key generation request is received from an external device (S810), the file processor 220 of the management server 200 determines whether a key store file including owner information identical to the owner information requesting the security key generation is previously stored. Do (S820). For example, the management server 200 determines whether a name of a key store file including owner information identical to the owner information of the security key included in the key generation request signal is previously stored. If the name of the key store file is previously stored, it can be determined that the key store file of the same owner is already stored.

If the key store file is previously stored (S820-YES), the file processor 220 of the management server 200 may determine whether or not the security key requested to be generated has been previously generated (S830).

If it is determined that the security key is para-generated (S830-YES), the file processor 220 of the management server 200 may transmit a signal to the external device 400 indicating that generation of the security key is not required (S840). .

If it is determined that the security key has not been generated (S840-NO), the management server 200 requests the hardware security module 100 to generate a third key (S845). When the key store file is pre-stored, it means that a specific type of security key has been previously generated. In FIG. 8, the generated security key is referred to as a first key, and the security key for requesting generation in FIG. 8 is referred to as a third key Can be called.

In response to the third key generation request, the hardware management server 200 generates a third key, generates a third key blob corresponding to the third key, and transmits the third key blob to the management server 200. Yes (S850). The security key may be an encryption key or an authentication key.

In addition, the management server 200 may update the key store file by adding a third key blob to the key store file (S860).

The key store file may include a head area including owner information of a security key, a body area including a key blob, and a protection area including an authentication value.

When adding the third key blob, the file processor 220 may update the head area, the body area, and the protection area of the key store file. For example, the file processor 220 updates information on the last time (date and time) the key store file in the head area was updated, information on the number of security keys generated by the hardware management server 200, etc. can do.

The file processor 220 may add a hash value of a third key blob obtained by encrypting a third key alias corresponding to the third key, a third key blob, and a third key blob using a hash function to the body region. .

In addition, the file processor 220 of the management server 200 may update an authentication value for checking whether the key store file is tampered with by using a hardware module. Specifically, the management server 200 may request an authentication value from the hardware security module 100. When the authentication value is requested, the management server may provide information included in the head area of the key store file and information included in the body area of the key store file to the hardware security module 100.

The key processor 120 of the hardware security module 100 generates a derivation key using the key owner information and the master key pre-stored in the hardware security module 100, and the information included in the head area of the key store file, the key store An authentication value may be generated using information and an induction key included in the body area of the file. For example, the key processor 120 may generate a derivation key using an ENC algorithm and may generate an authentication value using an HMAC algorithm, but is not limited thereto. Of course, the key processor 120 may apply another algorithm for generating an authentication value. The hardware language security module transmits the generated authentication value to the management server 200 so that the management server 200 may obtain the authentication value.

In addition, the file processor 220 includes the authentication value in the protected area of the key store file, so that the management server 200 can complete the update of the key store file. When the key store file is completed, the file processor 220 may update the last update date and time of the head area of the key store file.

In addition, the file processor 220 may update the history of the key store file (S870). The file processor 220 may generate or update the history of the key store file whenever the key store file is created, deleted, or changed. The file processor 220 includes a serial number of the history, that is, a number that is updated every time the history is generated, the name of the key store file, the date and time (access date) using the key store file, and the form using the key store file (e.g. , Key store file creation, deletion, key blob addition, key blob deletion, key blob use, etc.), key alias, authentication value of key store file, hash value for the history of the key store file just before the history was created, history The hash value for the history of the key store file generated after creation may include at least one of a date and time when the key store file is created. The history of the key store file described above may be used for the purpose of auditing access to the key store file.

The file processor 220 may store the updated key store file in the storage unit 230 (S875), and store the history of the updated key store file in the database 300 (S880).

9 is a reference diagram illustrating a key store file including information related to a plurality of security keys according to an exemplary embodiment. Referring to FIG. 9, in the body area of the key store file, a first key alias corresponding to a first security key, a hash value of a first key blob, a first key blob, and a second key alias corresponding to a second security key. , The hash value of the second key blob and the second key blob are included. Thus, information on a plurality of security keys can be included in one key store file, thereby facilitating management of security keys.

The management server 200 has described a method of generating a key store file using one hardware security module 100. However, it is not limited thereto. A plurality of management servers 200 may generate and use a key store file using one hardware security module 100.

For example, if the management server includes first and second management servers, the key store file is stored in the first management server, and the second management server receives a request from an external device to generate a security key or use a security key. , The second management server may confirm that the key store file is stored in the first management server from the name of the key store file read from the database. Further, the second management server may enable runtime security key synchronization by receiving a key store file from the first management server or requesting the first management server to generate a security key or use a security key.

The security key management server 200 that generates a key store file related to the security key described so far does not need to be implemented as a single hardware device. It may be a combination of separate servers according to functions. For example, the security key management server 200 may be a combination of a server that generates a key store file and a server that authenticates the key store file. Meanwhile, the above-described embodiments of the present invention can be written as a program that can be executed on a computer, and can be implemented in a general-purpose digital computer that operates the program using a computer-readable recording medium. Further, the structure of the data used in the above-described embodiment of the present invention can be recorded on a computer-readable recording medium through various means. The computer-readable recording medium includes a storage medium such as a magnetic storage medium (for example, a ROM, a floppy disk, a hard disk, etc.) and an optical reading medium (for example, a CD-ROM, a DVD, etc.).

So far, we have looked at the center of the preferred embodiments. Those of ordinary skill in the art to which the present invention pertains will be able to understand that the present invention can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments should be considered from an illustrative point of view rather than a limiting point of view. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

Claims

When receiving a key generation request signal including owner information to own a security key from an external device, transmitting the key generation request signal to a hardware security module, and receiving a key blob corresponding to the security key from the hardware security module. step;

Transmitting an authentication value request signal including the owner information and a key blob to the hardware security module, and receiving an authentication value corresponding to the authentication value request signal from the hardware security module;

Generating a key store file including the key blob and the authentication value;

Generating a name of the key store file based on the owner information; And

And storing the key store file and the name of the key store file in a device other than the hardware security module.
The method of claim 1,

The key store file,

A security key management method including a head area including the owner information, a body area including the key blob, and a protection area including the authentication value.
The method of claim 2,

The authentication value is,

The hardware security module generates an induction key using the owner information and a pre-stored master key, and manages a security key that is a value generated by using the information included in the head area, the information included in the body area, and the induction key Way.
The method of claim 1,

The name of the key store file is

A security key management method including a character string derived from the owner information and information on the date and time when the key store file was created.
The method of claim 1,

The name of the key store file is

A security key management method that is grouped and stored as an exclusive OR value of 2 bytes.
The method of claim 1,

The step of creating the store file,

Checking whether a key store file including owner information identical to the owner information is stored in the other device; And

And if a key store file including the same owner information is previously stored, updating the key blob and the authentication value to a previously stored key store file.
The method of claim 1,

When a first key use request signal including owner information and data to use a security key is received from the external device, the name of the key store file corresponding to the owner information included in the first key use request signal is transmitted from the other device. Reading;

Obtaining a key store file matching the name of the key store file;

Verifying the key store file using the authentication value included in the key store file

Obtaining a key blob from the key store file when verification of the authentication value is completed;

And transmitting a second key use request signal including the key blob and the data to the hardware security module, and receiving data to which the security key is applied from the hardware security module.
A communication unit communicating with an external device and a hardware security module; And

When receiving a key generation request signal including owner information to own the security key from the external device through the communication unit, the key generation request signal is requested from the hardware security module and the key corresponding to the security key from the hardware security module Acquire blobs,

Request an authentication value request signal including the owner information and the key blob to the hardware security module through the communication unit, and obtain an authentication value corresponding to the authentication value request signal from the hardware security module

A key store file including the key blob and the authentication value is generated, a name of the key store file is generated based on the owner information, and the name of the key store file and the key store file is designated by the hardware security module. A security key management server that includes a; file processor that stores the other device.
The method of claim 8,

The key store file,

A security key management server including a head area including the owner information, a body area including the key blob, and a protection area including the authentication value.
The method of claim 9,

The authentication value is,

The hardware security module generates an induction key using the owner information and a pre-stored master key, and manages a security key that is a value generated by using the information included in the head area, the information included in the body area, and the induction key. server.
The method of claim 8,

The file handler,

A security key management server that generates a name of the key store file to include a character string derived from the owner information and information on the date and time when the key store file was created.
The method of claim 8,

The file handler,

A security key management server that allows the name of the key store file to be grouped and stored in an exclusive logical value of 2 bytes.
The method of claim 8,

The file handler,

Check whether a key store file containing the same owner information as the owner information is stored in the other device, and if a key store file including the same owner information is previously stored, the key blob and the authentication value are pre-stored key Security key management server that updates the store file.
The method of claim 7,

The file handler,

When receiving a first key use request signal including the owner information and data to use the security key from the external device through the communication unit, the key store file corresponding to the owner information included in the first key use request signal Obtain, obtain the key blob from the key store file,

A security key management server for receiving data to which the security key is applied from the hardware security module by transmitting a second key use request signal including the key blob and the data to the hardware security module through the communication unit.