KR102289478B1 - System and method for providing electronic signature service - Google Patents

Abstract

A security key management method and a security key management server including the same are provided. In this security key management method, upon receiving a key generation request signal including information on the owner of the security key from an external device, receiving a key block and an authentication value corresponding to the security key from the hardware security module, and receiving the key block and authentication A key store file including a value is generated, a name of the key store file is generated based on owner information, and the key store file and the names of the key store file are stored in a device other than the hardware security module.

Description

Security key management method and security key management server {System and method for providing electronic signature service}

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

In information protection and authentication technology, the need for a device and system to safely manage personal authentication information and information such as passwords for financial transactions in hardware and cryptographic terms has been raised with the spread of the Internet.

Since confidential information is a means of authenticating an individual and confirming that the individual has performed a specific act, if the confidential information is exposed to others, the entire financial transaction system may be disrupted because the actor cannot be identified, so it must be managed very safely. .

In order to provide such a high level of security, the concept of a Hardware Secure Module, which is equipped with a cryptographically secure management system at the same time as hardware, is introduced.

Meanwhile, although hardware security module technology is used in various fields, 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 and a server for generating a separate dedicated file without storing the security key in the hardware security module and storing it in a database other than the hardware security module.

The security key management method according to an embodiment includes, when 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 receives the key generation request signal from the hardware security module. receiving a key blob corresponding to the security key; transmitting an authentication value request signal including the owner information and the 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 names of the key store files in a database other than the hardware security module.

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 a derivation key using the owner information and the pre-stored master key, and uses the information included in the head area, the information contained in the body area, and the derivation 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 the date and time the key store file was created.

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

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

In addition, when a first key use request signal including owner information and data to use the 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 possess the security key from the external device through the communication unit, the key generation request signal is requested from the hardware security module and corresponding to the security key from the hardware security module obtain a key blob, request an authentication value request signal including the owner information and the key blob from 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 and 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 setting the name of the key store file and the key store file in the hardware security It includes; a file handler that stores in a database other than a module.

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 a derivation key using the owner information and the pre-stored master key, and uses the information included in the head area, the information contained in the body area, and the derivation key. It may be a value generated by

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 when the key store file was created.

In addition, the file processor may store the name of the key store file grouped as an exclusive OR value in units of 2 bytes.

Then, the file processor checks whether a key store file including the same owner information as the owner information is stored in the database, and if a key store file including the same owner information is pre-stored, the key blob and the The authentication value can be updated in the pre-stored keystore file.

In addition, when receiving a first key use request signal including data to use the owner information and the security key from the external device through the communication unit, the file processor is configured to add the owner information included in the first key use request signal 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 embodiments, since the security key is not stored in the hardware security module, but 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 generates 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 whenever necessary using the name of the key store file, so the file processing speed is reduced. can be faster

1 is a diagram illustrating a security key management system according to an exemplary embodiment.
FIG. 2 is a block diagram illustrating the hardware security module shown in FIG. 1 .
3 is a block diagram illustrating 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 for a management system to use a security key 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 a plurality of security key related information according to an embodiment.

The terms used in the present invention have been selected as currently widely used general terms as possible while considering the functions in the present invention, but these may vary depending on the intention or precedent of a person skilled in the art, the emergence of new technology, and the like. In addition, in a specific case, there is a term arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the description of the corresponding invention. Therefore, the term used in the present invention should be defined based on the meaning of the term and the overall content of the present invention, rather than the name of a simple term.

Although the terms 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 only used to describe specific embodiments, and are not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly dictates otherwise. In the present application, terms such as “comprise” or “have” are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, but one or more other features It should be understood that this does not preclude the existence or addition of numbers, steps, operations, components, parts, or combinations thereof. Terms such as first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another.

1 is a diagram illustrating 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 hardware security module 100 that generates a security key and 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 a 'management server') that receives the blob and generates a key store file including the key blob and a 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 can 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.

FIG. 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 the like, and a data processor that applies the security key to data. 130 may be included.

The key processor 120 may receive a security key generation request signal from the management server 200 through the first communication unit 110 to generate a security key. The security key generation request signal may include information such as owner information of the security key, the type of the security key, and the type of data related to the security key. The above-described 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. The security key 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, etc., 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 convert the key blob received through the first communication unit 110 into a security key. When generating the 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 pre-stored in the hardware security module 100, or may generate an authentication value for authenticating a key store file to be described later using the derivation key. .

The data processor 130 may encrypt or decrypt data using the security key according to the request of the management server 200 , or may generate signature data for signing data 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 above configuration, the hardware security module 100 can generate a security key internally by itself and encrypt/decrypt data based on it. The hardware security module 100 cannot extract the internally generated security key in any way, and if you want to extract data by a physical method, a safety device such as self-destructing the data is installed in the hardware security module ( 100) may be further included.

3 is a block diagram illustrating the management server 200 illustrated in FIG. 1 . As shown in FIG. 3 , the management server 200 is a hardware security module 100 and a second communication unit 210 that communicates with the external device 400 , and the hardware security module 100 at the request of the external device 400 . ) requesting the generation of a security key or generating a key store file including a key blob corresponding to the security key received from the hardware security module 100, and a storage unit for storing the key store file ( 230) may be included.

Hereinafter, a method for the management server 200 to generate and use a key store file will be described in detail.

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 for generation of the security key from the external device (S410), the management server 200 requests generation of the security key from the hardware security module 100 (S415). In response to the 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 the 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, and the like, and may be a private key or a public key. Data other than the security key may be further added to the above 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 the security key, a body area including a key blob, and a protection area including an authentication value.

The owner information included in the head area may be information received from the external device 400 . The security key generation request signal received from the external device 400 may include owner information. 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, biometric information, mobile phone number, email address, CI, resident registration number, etc. set by the owner.

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

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

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

The file processor 220 of the management server 200 may generate a head area and a body area of the keystore 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 the hardware security module for an authentication value for checking whether the key store file has been tampered with through the second communication unit 210 (S435), and the above-described 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 region of the key store file and information included in the body region 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 induced key using owner information and the master key pre-stored in the hardware security module 100, and is included in the head area of the key store file. The authentication value may be generated using the acquired information, the information included in the body region of the key store file, and the derivation key. For example, the key processor 120 may use an encryption algorithm when generating the derivation 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 acquire the authentication value.

Then, the file processor 220 may complete the key store file by including the authentication value in the protection area of the key store file (S450). The file processor 220 may update the last update date and time of the head area of the key store file upon completion of the key store file.

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

The body region 520 may include specific information corresponding to the security key. A key alias per security key, a hash value of a key blob, and a key blob may be stored. When the hardware security module 100 generates a plurality of security keys for one owner, a key blob, a key alias, and a hash value of the key blob corresponding to each security key may be included in the body region, respectively. 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 the management of the key store file is 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 the 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 the owner information of the security key and the date and time when the key store file was initially created. For example, the file processor 220 expresses a hash value of the owner information of the security key as a string of hexadecimal digits, and expresses the first generated year, month, date, hour, minute and second of the key store file as a string By doing so, you can create a name for the keystore file. The owner information of the security key may be information that can identify the owner as the key owner's mobile phone number, e-mail address, CI, or resident registration 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 hexadecimal string, and the middle end of the key store file is the first created year, month, date, hour, minute, and second. is expressed, and the rear end may be expressed as an extension name of the keystore file.

In addition, the file processor 220 may also generate a history of the key store file and the key store file to match the name of the key store file ( S470 ). The file processor 220 may create or update the history of the key store file whenever the key store file is created, deleted, or changed. The file processor 220 provides the serial number of the history, that is, a number updated every time the history is created, the name of the key store file, the date and time using the key store file (access date and time), and the form using the key store file (for example, , creation, deletion, key blob addition, key blob deletion, key blob use, etc.), key alias corresponding to the 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 the 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 may be used for 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 can be stored in the database 300 by matching them with each other (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 exclusive-ORs values derived from owner information included in the name of the keystore file in 2-byte units, groups them into exclusive-OR values, stores the name of the keystore file, and corresponds to the name The key store file and the history of the key store file can be matched and stored. By grouping and storing the names of the key store files, it may be easy to manage the database.

Alternatively, the file processor 220 groups the names of the key store files for each purpose of the security key, each service related to the above-mentioned security key, and groups the names of the grouped key store files back to an exclusive OR value and stores them. . As described above, since the name of the keystore file is stored in a plurality of steps, it is easy to read the name of the keystore file.

In FIG. 4 , 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 for storing the key store file and the name of the key store file in different storage devices as described above is for more secure security and is not limited thereto. Of course, the key store file may 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 the storage unit or 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 , the present invention 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. Generating the key store file, the name of the key store file, and the history of the key store file is the same as in steps S430 to S480, and thus 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 , upon receiving the 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 using the name of the key store file (S730). A key use request transmitted by the external device 400 to the management server 200 is referred to as a first key use request, and a 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 first key use request including owner information of the security key and data to which the security key is to be applied is received from the external device 400 , the file processor 220 of the management server 200 performs the second communication unit 210 . Through this, the name of the key store file including the owner information of the security key may be read from the database 300 . When the name of the key store file as well as 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 responds to the name of the key store file through the second communication unit 210 . It can be obtained by reading the history of the matched key store file and the directory of the key store file 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 230 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 information included in the body area of the key store file through the second communication unit 210 to the hardware security module ( 100), you can request an authentication value. The hardware security module 100 generates a derivation key using the owner information included in the head area of the key store file and the master key stored in the hardware security module 100, and information included in the head area of the key store file. , an authentication value may be generated using the information included in the body region of the key store file and the derivation key. The hardware security module 100 transmits the generated authentication value to the management server 200, and the management server 200 compares 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 keystore 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 the temporary key.

In FIG. 7 , the owner is verified after verifying the key store file, but the present invention is not limited thereto. After verifying the owner, you can also verify the keystore file. 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 obtaining the key blob, the file processor 220 may verify the key blob using a hash value of the key blob. For example, the file processor 220 generates a hash value of the key blob using owner information of the security key included in the head region of the key store file and the key blob included in the body region of the key store pie, and then generates A key blob can be verified by comparing the hash value of one key blob with the hash value of the key blob included in the key store file. If the generated key blob hash value and the pre-stored key blob hash value are the same, verification is deemed complete.

On the other hand, when a plurality of key blobs are included in the key store file, the management server 200 may acquire only the 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 hardware security module 100 security key is applied (S780). The key use request signal may include data to which the security key is applied and a key blob. 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 data, and transmit the result to the management server 200 . When the above data is data for authentication, the data processor 130 may generate signature data in which the data is signed with the 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 encrypts or decrypts the data with the security key converted from the key blob to generate encrypted data or decrypted data. , 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 one key store file may include a plurality of key blobs corresponding to a plurality of security keys, 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 a device 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 receiving a request to generate a security key from an external device (S810), the file processor 220 of the management server 200 determines whether a key store file including the same owner information as the owner information requesting the security key generation is pre-stored. do (S820). For example, the management server 200 determines whether the name of the key store file including the same owner information as the owner information of the security key included in the key generation request signal is pre-stored. If the name of the key store file is pre-stored, it may be determined that the key store file of the same owner is pre-stored.

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

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

If it is determined that the security key has not been previously generated (S840-NO), the management server 200 requests the hardware security module 100 to generate a third key (S845). The pre-stored key store file means that a specific type of security key has been previously generated. The pre-generated security key is referred to as a first key, and the security key that requests 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 may generate a third key, generate a third key blob corresponding to the third key, and transmit the third key blob to the management server 200 . There is (S850). The security key may be an encryption key or an authentication key.

Also, 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 the 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 region, body region, and protection region of the key store file. For example, the file processor 220 updates information on the date and time (date and time) when the key store file in the head area was last updated, information on the number of security keys generated by the hardware management server 200, and the like. can do.

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

In addition, the file processor 220 of the management server 200 may update the authentication value for checking whether the key store file has been tampered with using the hardware module. Specifically, the management server 200 may request an authentication value from the hardware security module 100 . When requesting an authentication value, the management server may provide information included in the head region of the key store file and information included in the body region 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 by using the key owner information and the master key stored in the hardware security module 100, the information included in the head area of the key store file, the key store An authentication value can be generated using the information and the derivation key included in the body region of the file. For example, the key processor 120 may generate the derivation key using the ENC algorithm and may generate the 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 language security module transmits the generated authentication value to the management server 200 so that the management server 200 may acquire the authentication value.

Then, the file processor 220 includes the above-described 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. The file processor 220 may update the last update date and time of the head area of the key store file upon completion of the key store file.

In addition, the file processor 220 may also update the history of the key store file (S870). The file processor 220 may create or update the history of the key store file whenever the key store file is created, deleted, or changed. The file processor 220 provides the serial number of the history, that is, a number updated every time the history is created, the name of the key store file, the date and time using the key store file (access date and time), and the form using the key store file (for example, , key store file creation, deletion, key blob addition, key blob deletion, key blob use, etc.), key alias, key store file authentication value, history Hash value for the history of key store file just before creation, history It may include at least one of a hash value for the history of the key store file generated after generation, and a date and time when the history of the key store file is generated. The history of the key store file may be used for 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 a plurality of security key related information according to an embodiment. 9 , in the body region of the keystore file, a first key alias corresponding to the first security key, a hash value of the first key blob, and a first key blob, and a second key alias corresponding to the second security key , a hash value of the second key blob, and the second key blob are included. Thus, it is possible to include information on a plurality of security keys in one key store file, thereby facilitating management of the security keys.

The management server 200 has described a method of generating a key store file using one hardware security module 100 . However, the present invention 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, when the management server includes the first and second management servers, the key store file is stored in the first management server, and the second management server receives a request to generate a security key or use the security key from an external device. , 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. In addition, 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 the security key.

The security key management server 200 that generates the 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 servers separated according to functions. For example, the security key management server 200 may be a combination of a server that generates a key store file, a server that authenticates the key store file, and the like. 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. In addition, the structure of the data used in the above-described embodiment of the present invention may be recorded in a computer-readable recording medium through various means. The computer-readable recording medium includes a storage medium such as a magnetic storage medium (eg, a ROM, a floppy disk, a hard disk, etc.) and an optically readable medium (eg, a CD-ROM, a DVD, etc.).

So far, the preferred embodiments have been mainly looked at. Those of ordinary skill in the art to which the present invention pertains will understand that the present invention can be implemented in modified forms without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments are to be considered in an illustrative rather than a restrictive sense. The scope of the present invention is indicated 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 (14)

When receiving a key generation request signal including owner information to own the 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 the 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 names of the key store files in a device other than the hardware security module;
The step of creating the store file is,
checking whether a key store file including the same owner information as the owner information is stored in the other device; and
and updating the key blob and the authentication value to the previously stored key store file if a key store file including the same owner information is previously stored. The method of claim 1,
The keystore file is
A security key management method comprising: a head area including the owner information; a body area including the key blob; and a protection area including the authentication value. 3. The method of claim 2,
The authentication value is
The hardware security module generates a derivation key using the owner information and the pre-stored master key, and manages the security key that is the information included in the head region, information included in the body region, and a value generated using the derivation key. method. The method of claim 1,
The name of the keystore file is
A security key management method comprising information on a character string derived from the owner information and a date and time when the key store file was created. The method of claim 1,
The name of the keystore file is
A security key management method that is grouped and stored as an exclusive OR value of 2-byte units. delete The method of claim 1,
When a first key use request signal including owner information and data to use the 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 retrieved from the other device. reading;
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. 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 to the hardware security module and a key corresponding to the security key from the hardware security module get blobs,
requesting an authentication value request signal including the owner information and the key blob to the hardware security module through the communication unit, and obtaining an authentication value corresponding to the authentication value request signal from the hardware security module;
generates a key store file including the key blob and the authentication value, generates a name of the key store file based on the owner information, and sets the name of the key store file and the key store file by the hardware security module a file handler that stores it on a device other than
The file handler,
It is checked whether a key store file including 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 pre-stored, the key blob and the authentication value are stored in a pre-stored key Security key management server that updates the store file. 9. The method of claim 8,
The keystore file is
A security key management server comprising a head area including the owner information, a body area including the key blob, and a protection area including the authentication value. 10. The method of claim 9,
The authentication value is
The hardware security module generates a derivation key using the owner information and the pre-stored master key, and manages the security key that is the information included in the head region, information included in the body region, and a value generated using the derivation key. server. 9. The method of claim 8,
The file handler,
A security key management server for generating a name of the key store file to include a character string derived from the owner information and information on a date and time when the key store file was created. 9. The method of claim 8,
The file handler,
A security key management server for grouping and storing the names of the key store files as exclusive OR values of 2-byte units. delete 9. The method of claim 8,
The file handler,
When a first key use request signal including the owner information and data to use the security key is received 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 is received. obtain, obtain the key blob from the key store file,
A security key management server that transmits a second key use request signal including the key blob and the data to the hardware security module through the communication unit to receive the data to which the security key is applied from the hardware security module.

Images