KR20150069863A

KR20150069863A - Apparatus for data security

Info

Publication number: KR20150069863A
Application number: KR1020130156516A
Authority: KR
Inventors: 안성준
Original assignee: (주)필리아아이티
Priority date: 2013-12-16
Filing date: 2013-12-16
Publication date: 2015-06-24

Abstract

And a detuned portion for detuning the first data including the tokenized security target field into original data, wherein the detuning portion performs the detuning if the integrity of the authority for requesting the detuning is confirmed Security device.

Description

[0001] APPARATUS FOR DATA SECURITY [0002]

The present invention relates to a security device, and more particularly, to a security device capable of managing various personal information with reliable security.

Data encryption alone can not prevent unauthorized access to data, so there is a problem in that reliable security can not be guaranteed by a method that relies solely on data encryption. The database is a mandatory component in charge of information input / output in various fields in the Internet age. Especially, since information on business secrets of companies as well as personal information such as resident registration numbers is sensitive to security, .

Korean Patent Registration No. 1098947 discloses a storage medium having a general storage area for storing file data; An operating system unit for storing new file data in the general storage area according to a user input or outputting an output command for storing changed file data different from stored file data to the storage medium; And a data security unit for storing the new file data or the changed file data or for backing up the stored file data by setting a part of the area as a security area. However, the solution to the above problem is insufficient.

Korean Patent Registration No. 1098947

The present invention is intended to provide a security device capable of managing various personal information with reliable security.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not intended to limit the invention to the precise forms disclosed. Other objects, which will be apparent to those skilled in the art, It will be possible.

The security device of the present invention may include a storage unit in which second data encrypted with the security object field and first data are stored together.

The security device of the present invention includes a detoken part for detonating first data including a tokenized security object field into original text data, Tokenization can be performed.

The security device of the present invention includes a tokenizing unit for performing a tokenizing of first data including a tokenized security object field into original text data, the first tokenizing unit storing the first data, It is possible to perform the demodulation by decoding the second data.

The security device of the present invention can enhance the security of the original text data by storing the first data obtained by tokenizing the security target field of the original text data and the second data obtained by encrypting the original text data.

That is, by storing the first data and the second data instead of storing the original data, it is possible to prevent the problem that the original data is exposed to the unauthorized person.

Also, the security device of the present invention can prevent the phenomenon that the first data is deconnected by the unauthorized person by performing the deconnection only when the integrity of the authority that requested the deconnection of the first data is confirmed.

In addition, the security apparatus of the present invention does not need to store the original text data in the storage unit by decrypting and returning the second data obtained by encrypting the original text data when the first data is to be deconnected. Thus, the security of the original text data can be enhanced.

1 is a block diagram showing a security device of the present invention.
2 is a schematic view showing an interface displayed by a setting unit;
3 is a schematic diagram showing data stored in the security device of the present invention.
4 is a schematic diagram showing a security system to which the security device of the present invention is applied.
5 is a flowchart illustrating the operation of the security device of the present invention.

1 is a block diagram showing a security device of the present invention.

The security apparatus shown in FIG. 1 may be a so-called token server 100, and includes a token unit 110 for generating tokenized tokenized fields of original data to generate first data.

At this time, the token unit 110 can perform the tokenization by replacing the security target field of the original text data with at least one of a random character and a number. The characters are made up of, for example, uppercase and lowercase letters in English.

The security target field of the original text data means a field of the original text data requiring security. The security target field may be a part or whole of the original text data. For example, if the original data is a telephone number such as '1234-5678', the security target field may be the entire telephone number. In addition, the security target field may be some field of the original text data such as '5678' which is the last four digits of the telephone number.

In addition, the security target field does not have to be contiguous. For example, the security target field may consist of a '3' digit and a '6' digit separated from each other at a telephone number '1234-5678'.

Syntax separators such as '-' in the security target field can be excluded. For example, the security target field for the telephone number '1234-5678' may be configured to exclude the '-' digit.

The token unit 110 can determine the security target field according to the type of the original text data. For example, if the original text data is a telephone number, the place after the syntax identifier '-' can be determined as the security target field. In case of resident registration number, as the '345678-1 ******', the security target field can be determined from the second position following the syntax identification symbol '-'. In this case, the security target field is a place marked with '*'.

Also, the token unit 110 may replace the security target field with a numeric character or a character. Therefore, the number of digits in the to-be-secured field and the number of digits in the to-be-before field are the same.

The determination of the security target field according to the type of the original text data is performed so that indexes or statistics are made through the first data. In the case of the above resident registration number, it is possible to index or calculate statistics using the original field "345678-1" instead of the security target field.

The first data is data obtained by tokenizing the security target field of the original text data. According to the definition of the tokenization described above, for example, when the security target field of the telephone number '1234-5678' is '5678', the original text data '5678' can be tokenized as 'ABCD'.

The first data is configured to include a security objective field in which the tokenization is made.

Therefore, the first data may be composed of only the security target field. In this case, the first data may be composed of 'ABCD'.

In addition, the first data may be composed of at least some of the original text field and the security target field excluding the security target field in the original text data. According to this, the first data may be composed of '1234-ABCD', '34 -ABCD ', and the like. In this case, the syntax identifier '-' can be excluded.

The first data described above is stored in a storage unit 130 (so-called database) shown in FIG. 1. The storage unit 130 stores second data that is encrypted with a security target field. In order to de-tokenize the first data to the original data later, it is necessary to store the original text data in the storage unit 130 together. However, storing the original text data directly in the storage unit 130 as described above causes a decrease in security reliability.

Accordingly, the storage unit 130 stores the second data obtained by encrypting the original text data. It is not necessary to store the original text data in the storage unit 130 since the original text data can be recovered by decoding the second data in the future. This further enhances the security of the original data.

The security device of the present invention may include an encryption unit 150 for generating second data.

The encryption unit 150 encrypts the security target field of the original text data to generate second data. The second data at this time may be configured to include only the security target field or may include both the original text field and the security target field. In the latter case, since the original text field is not subject to security, the encryption unit 150 can encrypt or bypass the original text field according to the policy.

The encryption unit 150 may include a plurality of encryption algorithms necessary for encryption of the security target field. At this time, the encryption unit 150 may encrypt the security target field with the selected encryption algorithm. It is difficult to know which encryption algorithm is applied to the second data by including a plurality of encryption algorithms to be applied to the encryption of the security target field. Thereby enhancing the security of the second data.

The encryption algorithm may be, for example, 3-Way, AES, AES-128, AES-256, Akelarre, Anubis, Aria, Blowfish, Camellia, CAST-128, CAST-256, CMEA, CS- MUSIC, MAGENTA, MARS, MISTY1, MMB, MACHUFFIN, Madryga, MUSIC, MACHUFFIN, Madryga, MUSIC, , NewDES, Noekeon, RC2, RC5, RC6, REDOC, RedPike, S-1, SAFER, SEED, Serpent, SHACAL, SHARK, Skipjack, Square, TEA, Triple DES, Twofish, XTEA .

Meanwhile, the security device of the present invention may include a setting unit 170 for setting at least one of an algorithm for encrypting a security object field and a type of original data for determining a security object field. At this time, the type of the original text data is the same as the type of the first data.

Fig. 2 is a schematic diagram showing an interface displayed by the setting unit 170. Fig.

The interface shown in FIG. 2 is provided with a 'Key Usage' menu for selecting the type of original data ACC, CCN, PII and SSN and an 'Algorithm' menu for selecting Triple DES, AES-128 and AES-256 encryption algorithms do.

Here, ACC (accounts) represents a bank account number, and CCN (payment cards) represents a credit card number. PII (personal information) represents general information, and SSN represents a personal identification number such as so-called resident registration number.

If 'Creat New Key' is selected after selecting the type of the original text data and the encryption algorithm, the result is reflected in the policy table 120.

In the policy table 120, types of original text data, encryption algorithms, key IDs such as AAC and AAD are recorded, and recording time is recorded in some cases.

The key ID may be input by the user or automatically generated by the setting unit 170, and may be used later for the demodulation of the first data.

The recording date indicates the type of the original text data and the time at which the encryption algorithm is recorded and the key ID is generated. The algorithm applied due to the recording date can be updated.

For example, referring to FIG. 2, the AES-128 encryption algorithm is set to apply to the number 2 SSN on July 18, 2009. In addition, the triple DES encryption algorithm is set to apply to the number 3 SSN on July 19, 2009. According to this, the original text data inputted on July 18, 2009 is encrypted with AES-128, and the original text data inputted after July 19, 2007 is encrypted with Triple DES. By using this policy table 120, the password used for decryption can be determined at the time of demultiplexing the first data. That is, by referring to the policy table 120, the AES-128 encryption algorithm can be decrypted and decrypted with respect to the SSN original data entered on July 18, 2009, and the SSN original text input after July 19, Data can be decrypted by reversing the Triple DES encryption algorithm.

The types of original text data and the selection of encryption algorithms are important for the security of original text data and for later detonation. Therefore, it is necessary to allow the setting only to the party author.

Accordingly, the setting unit 170 can be activated when the integrity of the authority for requesting the tokenization of the original text data is confirmed. Likewise, the token unit 110 is preferably operated when the integrity of the authority for requesting the tokenization of the original text data is confirmed. The authority to request tokenization may include at least one of an identification number, an Internet Protocol (IP) address, and a request time. Of these, the request time represents a time zone in which the tokenizing request is permitted.

Meanwhile, the security apparatus may store the third data and the first data obtained by performing the hash processing on the first data. According to this, the security device may store the first data, the second data, and the third data together, and these examples are shown in Table 1 and FIG. For reference, the third data may be generated by the encryption unit 150, and the first data and the third data may be stored in the storage unit 130.

The first data The second data Third Data ABCDEF IsLKjskdfasoOIIk: KL LKJFlkasjdflakfjaoLKjlsklskd ...

3 is a schematic diagram showing data stored in the security device of the present invention.

In Table 1 and FIG. 3, the back six digits of the resident registration number 710101-1234567 corresponding to the original text data are the security target fields, and only the first data, the second data, and the third data are the security target fields.

710101-1234567, the token unit 110 tokenizes the security objective field to convert the last six digits '234567' to the random character 'ABCDEF'. In accordance with the tokenizing request, the encrypting unit 150 generates an 'IsLKjskdfasoOIIk: KL' by applying the encryption algorithm selected in '234567'. Also, the encryption unit 150 hashes the 'ABCDEF' generated in the token unit 110 to generate 'LKJFlkasjdflakfjaoLKjlsklskd ...'.

The first data, the second data, and the third data thus generated are stored in the storage unit 130. The reason for generating and storing the third data is to ensure identification reliability for the first data.

After the tokenization is performed, even if the integrity of the authority is confirmed, only the 710101-1ABCDEF in which the original text field 710101-1 and the first data ABCDEF are mixed can be obtained. To obtain 710101-1234567, a de-tokenization needs to be performed. The first data, ABCDEF, when performing the de-tokenization, can function as a so-called index. At this time, third data may be used to prevent an index error or a storage error of the first data.

The third data is the hash of the first data, and it is possible to convert from the first data to the third data, but the inverse conversion is impossible. Accordingly, the security of the first data due to the additional storage of the third data is not a problem. The third data increases the number of digits as compared with the first data in accordance with the hash process, and thus functions more reliably as an indexer.

Accordingly, it is possible to retrieve the target first data by searching / extracting the result of the hash processing of the first data requested to be decrypted in the de-tokenizing, from the third data stored in the storage unit 130. [ The search result is highly reliable as compared with the search using only the first data.

Hereinafter, a method of demodulating the first data into original data will be described.

As shown in FIG. 1, the security device of the present invention may include a detoken part 190 for detonating first data including a tokenized security objective field into original data.

At this time, the DTO token unit 190 can perform the DTO tokenization if the integrity of the right to request the DTO tokenization is confirmed.

De-tokenizing the first data into the original data is a very important issue because it restores the data that requires security. Therefore, in order to prevent the de-tokenization by the unauthorized person, the de-token unit 190 preferably performs the de-tokenization according to the integrity check result of the authority for requesting the de-tokenization.

The authority at this time may include at least one of an identification number, an Internet Protocol (IP) address, and a request time. When the integrity of the connection ID, the connection IP address, and the request time is confirmed, the detoken part 190 is driven. If the integrity of the authority is violated, the detoken part 190 is not activated. At this time, the security device may return 710101-1ABCDEF including the first data as it is, or may mask the security target field and convert it as 710101-1 ****** and return it.

The de-tokenization in the D-token unit 190 decodes the second data that is externally displayed, such as converting ABCDEF to 234567, internally stored together with the first data, and the second data is encrypted, .

It is noted that the first data and the second data are stored in the storage unit 130 and the third data may be additionally stored in some cases. The first data may be a data structure in which the security target field is replaced with a random character or number , It is difficult to obtain the original text data from the first data.

Accordingly, the detoken unit 190 acquires the original data using the second data stored together with the first data. Specifically, the de-token unit 190 searches the storage unit 130 for the first data for which the de-tokenization is requested, decodes the second data stored in the storage unit 130 together with the searched first data, Can be performed. If the third data is stored in the storage unit 130, the detalk unit 190 performs a hash process on the first data requested to be decrypted and then determines whether third data matching in the storage unit 130 exists The search of the first data can be omitted.

Since the second data is encrypted by applying an encryption algorithm to the original text data, decrypting the second data may be a reverse application of the encryption algorithm to the second data.

To do this, the detoken part needs to know the encryption algorithm used to generate the second data. In addition, since the encryption algorithm can be selected differently according to the type of the first data, it is necessary to grasp the type of the first data.

To this end, the D token unit 190 can determine the type of the first data requested to be decrypted. In addition, the detent unit 190 may search the policy table 120 for a key ID and an encryption algorithm assigned to the type of the first data, and may decrypt the second data by reversing the retrieved encryption algorithm. The type of the first data may include at least one of a bank account number, a credit card number, and a personal identification number as described above.

The policy table 120 is mentioned in the description of the setting unit 170 and may be stored in at least one of the security device and the node of the connection IP address.

When the policy table 120 is stored in both the node of the connection IP address and the security device, the detoken unit 190 identifies the type of the first data requested to be decrypted, and if the type of the first data is the policy table 120 ), It requests the key ID assigned to the type of the first data to the node requesting the demodulation. That is, even if the policy table 120 is pre-stored in the de-token unit 190, the de-token unit 190 can request a key ID from the node.

When the key ID is received from the node, the DTO token unit 190 compares the received key ID with the key ID of the pre-stored policy table 120, and if the matching is performed, the DTO token unit 190 deducts the first data. Specifically, the encryption algorithm recorded in the policy table 120 is searched together with the key ID for which the matching result is confirmed, and the original data is decrypted by reversing the encryption algorithm to the second data to complete the de-tokenization.

If the key ID received from the node does not match the key ID of the pre-stored policy table 120, the detonator 190 generates an error message and returns to the node.

Meanwhile, the security device may include a log unit 140.

The log unit 140 generates a log including the history of decryption performed in the detalk unit 190, a connection ID requesting decryption, a connection IP address, a request time, and the like. Also, the log unit 140 may generate a log including a return result at the time of infringement integrity violation, an error message return result at the time of mismatching the key ID, and the like.

4 is a schematic diagram showing a security system to which the security device of the present invention is applied.

When the original data is input from the node, the ERP server receives the original data and transmits it to the token server 100 corresponding to the security device.

The token server 100 converts the original text data into first data and second data by driving the token unit 110 and stores the converted data. Optionally, the third data may be additionally stored.

After that, when the decryption non-authorizer at the predetermined node requests the decryption of the first data, the token server 100 determines that the integrity of the authority is infringed and returns the first data as it is or masks the security object field .

If the integrity of the authority is confirmed, the original text data, which is the decrypted second data, is transmitted to the decryption authority.

The operations of the detoken part 190 and the log part 140 are shown in FIG.

5 is a flowchart illustrating the operation of the security device of the present invention.

FIG. 5 discloses a demodulation process of the security device.

First, the de-token unit 190 receives a de-tokenization request of the first data from the node (S 510). At this time, the type of the first data, that is, the type of the original text data, may be received together with the request. Also, a record date, which is the time at which the original text data is tokenized, may be received together. The type of the first data and the record date must be grasped so that the corresponding key ID can be requested in the following process.

When the de-tokenizing request is received, the detokener 190 confirms the integrity of the authority (S 520).

When the integrity of the authority is confirmed (approved), the node requests a key ID (S 530).

At this time, the node may be a connection IP address, i.e., a terminal or an ERP server to which the terminal is connected. If the integrity of the rights is violated, the first data is returned as is, or the security target field is masked and returned (S 580). At this time, the non-authorizer obtains the tokenized first data or the masked data, so that the security of the original data is maintained.

When the key ID is received, the default token unit compares the key ID of the policy table 120 and the received key ID using the type of the first data received and the record date (S 540). In other words, verify the integrity of the key ID. For example, in the policy table 120 of FIG. 2, when the first data is tokenized after July 19, 2009, the key ID is AAD. Since the security device stores the corresponding policy table 120, it knows that the corresponding key ID is AAD. In this situation, if the received key ID indicates a different key value rather than AAD, the integrity of the key ID is regarded as infringed.

If the received key ID matches the pre-stored key ID in the policy table 120, the de-token unit 190 performs a de-tokenization (S 550). Thereafter, the original text data generated through the demultiplexing is returned (S 560). The de-tokenization may be implemented by applying the encryption algorithm back to the second data stored in the storage unit 130 together with the first data.

If the received key ID does not match the pre-stored key ID in the policy table 120, the de-token unit 190 generates an error message and returns (S 590).

Next, the security device may generate a log including the processing result of the dittoken portion (S570). The generation of the log is performed in the log unit 140, and the generated log can be stored in the storage unit 130. The log generated by the log unit 140 may also include a result of the first data return upon infringement of the integrity integrity, and an error message return result of integrity violation of the key ID.

Claims

And a detoken part for detonating the first data including the tokenized security target field into the original text data,
Wherein the detuning unit performs the detuning if the integrity of the authority for requesting the detuning is confirmed.

And a detoken part for detonating the first data including the tokenized security target field into the original text data,
And the detoken part performs the detokenization by decrypting second data that is stored together with the first data and is encrypted with the security-object field.

And a detoken part for detonating the first data including the tokenized security target field into the original text data,
The dittoken unit includes:
Identifying the type of the first data requested by the demodulation,
Searching a policy table for a key ID and an encryption algorithm assigned to the type of the first data,
And decrypting the second data, which is stored together with the first data by reversing the retrieved encryption algorithm, and encrypts the security target field.

The method of claim 3,
Wherein the type of the first data includes at least one of a bank account number, a credit card number, and a personal identification number.

And a detoken part for detonating the first data including the tokenized security target field into the original text data,
Wherein the dittoken unit identifies the type of the first data requested by the ditokenization and, if the type of the first data exists in the policy table, transmits a key ID assigned to the type of the first data, A security device that requests a node.

6. The method of claim 5,
The dittoken unit previously stores the policy table,
And compares the received key ID with a key ID of the pre-stored policy table according to a request of the key ID, and if the key ID is matched, demodulates the first data.