AGENT FOR PROVIDING SECURITY CLOUD SERVICE AND SECURITY TOKEN DEVICE FOR SECURITY CLOUD SERVICE BACKGROUND OF THE INVENTION 5 1. Field of the Invention The present invention generally relates to an agent for providing a security cloud service and a security token device for a security cloud service. More particularly, the present 10 invention relates to technology for enhancing security, in which user authentication and header encryption-decryption are performed on files in the hardware security token device that is detachable from a user terminal and then the files are stored in a cloud server. 15 2. Description of the Related Art These days, cloud computing environments are widely used for the efficient distribution of IT resources and secure storing of data. In the 1960s, the computer scientist John 20 McCarthy proposed the concept of cloud computing. Recently, the rapid progress in communication infrastructure and a growing need for the efficient distribution of computing environment resources has contributed to the fast development of cloud computing. 25 In a cloud computing environment, investment costs in IT 1 equipment on the client's side can be reduced because users do not need high-end terminals and because IT resources can be efficiently distributed depending on the service environments. However, clouding computing has security problems. For 5 example, when a server of cloud computing is hacked into, data can be stolen, or service providers can deliberately leak confidential user data. Furthermore, as cloud services have been used not only in PC environments but in mobile environments such as smartphones 10 and the like, security issues should be solved to protect a cloud server from being hacked into. Accordingly, documents including Korean Patent Application 10-1107056 disclose a method in which a synchronized file is encrypted before being transmitted from a 15 client terminal to a cloud server and a file is decrypted in the client terminal after being received from the cloud server. In some products using the above-described method, encryption is performed by software algorithm modules using 20 encryption keys managed by a Windows agent application, or files are encrypted in software using encryption keys stored in a hardware device. In other words, because existing file encryption methods for enhancing cloud service security perform encryption in 25 software and encryption keys are managed by a Windows program, 2 the keys may be exposed to monitoring programs run by hackers. Thus, it is difficult to assure security in the conventional art. 5 Documents of Related Art (Patent Document 1) KR10-1107056 SUMMARY OF THE INVENTION 10 Accordingly, the present invention has been made keeping in mind the above problems occurring in the related art, and an object of the present invention is to randomly generate a header, which is an encryption key of a file, in a security token device connected to a user terminal, and to encrypt the 15 file in an agent, whereby the security key may be prevented from being leaked and the amount of transmitted and received data may be reduced because the security token device encrypts and decrypts only the header. Also, to enhance security, the present invention encrypts 20 and decrypts a cloud file and synchronizes the file only when a security token device is being connected with a user terminal. Also, the object of the present invention is to generate a session key using a random value derived from a password key 25 when a security token device is connected to a user terminal 3 so as to improve security. In order to accomplish the above object, according to an embodiment of the present invention, an agent, installed on a 5 user terminal, for providing a security cloud service may include: a header generation unit for generating a header that has a random value for encrypting a file to be uploaded to a cloud server when the file is received from the user terminal; a session key generation unit for generating a session key to 10 create a session with a security token device when the security token device that is detachable from the user terminal is detected, the security token device encrypting the generated header or decrypting a header of a file downloaded from the cloud server; and a file encryption-decryption unit 15 for encrypting the file to be uploaded to the cloud server, using the encrypted header when the header is encrypted by the security token device, and for decrypting the file downloaded from the cloud server using the decrypted header when the header is decrypted by the security token device. 20 The header generation unit may encrypt the generated header using the session key, and transmit the encrypted header to the security token device. The session key generation unit may receive a password and request a public key from the security token device when 25 detecting connection of the security token device; generate 4 authenticator data that includes a random value for authentication, encrypt the data using the public key, and transmit the data to the security token device; and generate a session key using the random value for authentication and 5 using a random value for response when receiving from the security token device, response data that includes the random value for response. To accomplish the above object, a security token device for a security cloud service according to an embodiment of the 10 present invention may include: an interface unit, detachable from a user terminal, for providing an interface with an agent installed in the user terminal; a storage unit for storing an encrypted header, the header being an encryption key that is generated to a random value for encrypting and decrypting a 15 file to be shared in a cloud server; and an encryption decryption conversion support controller, which encrypts a header for a file to be uploaded to the cloud server when receiving the header, stores the encrypted header in the storage unit, and transmits the header to the agent; and 20 stores an encrypted header for a file downloaded from the cloud server in the storage unit when receiving the header, decrypts the encrypted header, and transmits the header to the agent. Also, the security token device may further include a 25 security authentication chip, which transmits a public key 5 when the public key is requested by the agent and receives authenticator data including a random value for authentication; generates response data including a random value for response and transmits the response data to the 5 agent; and generates a session with the agent when receiving a session key from the agent, the session key being generated by the agent using the random value for authentication and using the random value for response. The security authentication chip may encrypt the 10 encrypted header or the decrypted header using the session key, and transmit the header to the agent. According to the present invention, confidential data for individuals or companies cannot be opened though a cloud 15 server is hacked into, and because a file header (an encryption key with a random value) is encrypted and decrypted in a token key device, leakage of the encryption key can be prevented even if a PC is hacked into. Therefore, security can be remarkably improved. 20 Also, a session key is generated using a random value derived from a password key when a security token device is connected to a user terminal, and an encrypted or decrypted header is transmitted after being encrypted by the session key, whereby security can be improved. 25 6 BREIF DESCRIPTION OF THE DRAWINGS The above and other objects, features and other advantages of the present invention will be more clearly 5 understood from the following detailed description taken in conjunction with the accompanying drawings, in which: FIG. 1 is a configuration diagram of a system for providing a security cloud service according to the present invention; 10 FIG. 2 is a block diagram illustrating a detailed configuration of an agent of a user terminal of FIG. 1; FIG. 3 is a view illustrating the generation of authenticator data by a session key generation unit of FIG. 2; FIG. 4 is a block diagram illustrating a detailed 15 configuration of a security token device of FIG. 1; FIG. 5 is a view for explaining the generation of response data by a security authentication chip of FIG. 4; FIG. 6 is a flow diagram illustrating a prior process for the use of a security token device in a PC environment; 20 FIG. 7 is a flow diagram illustrating a process in which a file is encrypted using a security token device and then transmitted to a cloud server; FIG. 8 is a flow diagram illustrating a process in which a file is decrypted using a cloud service in a mobile 25 environment; 7 FIG. 9 is a flow diagram illustrating a user authentication process when a security token device is connected to a user terminal; FIG. 10 illustrates a file header encryption process in a 5 security token device when a file is uploaded; and FIG. 11 illustrates a file header decryption process in a security token device when a file is downloaded. DESCRIPTION OF THE PREFERRED EMBODIMENTS 10 The present invention will now be described in detail based on aspects (or embodiments). The present invention may, however, be embodied in many different forms and should not be construed as being limited to only the embodiments set forth 15 herein, but should be construed as covering modifications, equivalents or alternatives falling within ideas and the technical scope of the present invention. Reference now should be made to the drawings, in which the same reference numerals are used throughout the different 20 drawings to designate the same or similar components. In the description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments. It will be understood that, although the terms first, 25 second, etc. may be used herein to describe various elements, 8 these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first 5 element, without departing from the scope of the present invention. As used here, the term "and/or" includes any and all combinations of one or more of the associated listed items. It will be understood that when an element is referred to 10 as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, there are no 15 intervening elements present. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a, " "an" and "the" are intended to include the plural 20 forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes" and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude 25 the presence or addition of one or more other features, 9 integers, steps, operations, elements, components, and/or groups thereof. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as 5 commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the 10 relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined here. FIG. 1 is a configuration diagram of a system for providing a security cloud service according to the present 15 invention; FIG. 2 is a block diagram illustrating a detailed configuration of the agent of FIG. 1; and FIG. 4 is a block diagram illustrating a detailed configuration of the security token device of FIG. 1. As illustrated in FIG. 1, the system for providing a 20 security cloud service according to the present invention is configured to include a user terminal 1, a security token device 2, and a cloud server 3. The user terminal 1 is a device in which user files are stored, and it includes various types of terminals capable of storing files, displaying files, 25 and Internet access, such as PCs, laptops, tablet PCs, 10 smartphones, and the like. In FIG. 1, 1A represents a PC, 1B represents a tablet PC, and 1C represents a smartphone. Also, the cloud server 3 is a device for providing a cloud service to share user files, and it stores a user's 5 contents such as documents, contacts, and media files including movies, photos, and music. When a user terminal including a PC, a smart phone, and a smart TV requests the contents, the user terminal can download the contents stored in the server. In Korea, cloud services are provided by Naver 10 NDrive, KT ucloud, Daum Cloud, etc., and global cloud services such as Dropbox, Box, Sugarsync, Google drive, Sky Drive, etc. are also provided. As illustrated in FIG. 2, an agent 100 is installed in the user terminal 1 to provide a security cloud service 15 according to the present invention. The agent 100 may include an event detection unit 110, a session key generation unit 120, a header generation unit 120, and a file encryption decryption unit 140. The event detection unit 110 may detect the occurrence of 20 a file event. In this case, the event indicates the creation, the copy, the deletion, and the like of downloaded files or of files to be uploaded. Here, the creation, the copy, and the like of the files to be uploaded, which require an encryption process, may 25 become a first event. Conversely, the creation, the deletion, 11 and the like of the downloaded files, which require a decryption process, may become a second event. When detecting the first event including the file upload and file copy, the header generation unit 130 may generate a 5 header having a random value, and transmit the header to the security token device 2. Here, the header is an encryption key for encrypting or decrypting a file, and may be generated to a random value at an interval of the first event. Also, when detecting the second event including the file 10 download and file deletion, the header generation unit 130 may transmit to the security token device 2, the header of the file downloaded from the cloud server 3. When a user uploads a file to the cloud server 3 or copies a file, the event detection unit 110 determines whether 15 the security token device 2 is being connected. To enhance security, the event detection unit 110 initiates encryption on the header of the file to be uploaded to the server in the security token device 2 only when the security token device 2 is connected. 20 Also, when a user downloads an encrypted file from the cloud server and stores it, or when the user deletes a file, the event detection unit 110 determines whether the security token device 2 is being connected, and may initiate decryption on the header of the encrypted file in the security token 25 device 2 only when the security token device 2 is connected. 12 When detecting the connection of the security token device 2, the session key generation unit 120 may create a session for logical connection with the security token device 2 that is physically connected, through user authentication. 5 When the security token device 2 is connected to the user terminal 1, the session key generation unit 120 generates a session key by transmitting an authenticator value to the security token device 2 and by receiving a response value for the authenticator value from the security token device 2. 10 Then, the session key generation unit 120 may create a session with the security token device 2 by transmitting the generated session key to the security token device 2. Here, the authenticator value is obtained by encrypting using a public key, an authentication random value derived from a password. 15 Specifically, when detecting the physical connection with the security token device 2, the session key generation unit 120 may receive a password from a user. Also, the session key generation unit 120 may request a public key and receive it from the security token device 2 when the password is input. 20 The generation of the authenticator value is described with reference to FIG. 3. FIG. 3 is a view illustrating the generation of authenticator data by the session key generation unit of FIG. 2. 25 The session key generation unit 120 may generate an 13 authentication random value derived from a password. Here, the authentication random value may be generated using Advanced Encryption Standard (AES) algorithm, and may be encrypted using Cipher Block Chaining (CBC) mode. 5 The authentication random value (key) can be generated to a 16-byte key in CBC mode, using the following equation: Tempkey = password(20) G padding(12) Key = E ((SNO G SNO-1), Tempkey) The authentication random value is obtained by the 10 following process. First, Initialization Vector (IV) is XOR operated with a first block of a password plaintext and then encrypted. Repeatedly, the next block of the plaintext (SNO) is XOR operated with the previous encrypted block (SNO-1) and then encrypted. Here, the last block may be a padded block. 15 When the 16-byte authentication random value that is derived from the password is generated, the session key generation unit 120 divides it into two blocks, the first 8 byte block 220 (the first random value) and the next 8-byte block 230 (the second random value), and then inserts the 20 password string 210 at the beginning of each of the blocks to generate the first block and the second block of the authenticator data. For example, when the password is "SZTGBPWD" and the authentication random value obtained by the above-described 25 equation is OxO 01 02 03 04 05 06 07 08 09 OA GB OC CD CE OF, 14 the first block becomes "S Z T G B P W D 00 01 02 03 04 05 06 07", and the second block becomes "S Z T G B P W D 08 09 OA GB OC CD CE OF". Here, the first block and the second block can be encrypted according to Public Key Cryptography Standard, 5 PKCS#5. As shown in FIG. 3, the authenticator data may be 256 bytes, and may be made up of multiple blocks having a 16-byte column. The first block may consist of 8 bytes of the password 10 string 210 and 8 bytes of the first random value 220 that is derived from the password. The second block may consist of 8 bytes of the password string 210 and 8 bytes of the second random value 230 that is derived from the password. 15 Also, a third block may contain 4 bytes of a verification value 240 that indicates a result of the verification of the public key received from the security token device 2, and the remaining 12 bytes of the third block can be filled with padding. In other words, 220 bytes of the authenticator data 20 can be filled with padding 250. The session key generation unit 120 may perform RSA encryption on 256 bytes of the authenticator data of FIG. 3 using the public key received from the security token device 2, and then may transmit it to the security token device 2. 25 Also, in response to the encrypted authenticator data, the 15 session key generation unit 120 receives response data that is encrypted using the password from the security token device 2, and generates a session key. Then, the session key generation unit 120 may create a session by transmitting the generated 5 session key to the security token device 2. The header generation unit 130 generates a header for the file in which the first event is detected, encrypts the generated header using the session key generated by the session key generation unit 120, and may transmit it to the 10 security token device 2. Here, the header for a file to be uploaded is encrypted in the security token device 2, and may be transmitted to the file encryption-decryption unit 140. Also, the header for a downloaded file is decrypted in the security token device 2, 15 and may be transmitted to the file encryption-decryption unit 140. The file encryption-decryption unit 140 encrypts a file in which the first event is detected, using the header encrypted in the security token device 2, and may upload the 20 encrypted file to the cloud server 3. Also, the file encryption-decryption unit 140 decrypts a file in which the second event is detected, using the header decrypted in the security token device 2, so as to make the file run in the user terminal 1. 25 The security token device 2 is detachable from the user 16 terminal 1, and operates when it is connected with the user terminal 1. The security token device 2 receives from the header generation unit 130, the header of the file in which occurrence of the event is detected by the event detection 5 unit 110; encrypts or decrypts the header; and transmits the header to the file encryption-decryption unit 140. Specifically, the security token device 2 encrypts the header received from the header generation unit 130 and transmits it to the file encryption-decryption unit 140, 10 during the file upload process. Conversely, during the file download process, the security token device 2 decrypts the header of the encrypted file that is downloaded from the cloud server 3 when receiving the header from the header generation unit 130, and transmits the decrypted header to the file 15 encryption-decryption unit 140. Also, when an event such as the copy, the deletion, and the like of the file occurs, the security token device 2 may perform the encryption-decryption process. On the other hand, the detailed configuration of the 20 security token device 2 is illustrated in FIG. 4. As shown in FIG. 4, the security token device 2 is configured to include interface units 10A and 10B, an encryption-decryption conversion support controller 20, a storage unit 30, and a security authentication chip 40. 25 The interface units 10A and 10B are a connector to be 17 electrically connected the user terminal 1. As an example, a USB connector 10A and a micro-USB connector 10B are illustrated, but various types of interface devices can be used. 5 The encryption-decryption conversion support controller 20 performs encryption or decryption on the header of the file in which an event occurs, through an encryption key and an encryption engine block that are stored in the controller, and performs a control operation for data backup when the security 10 token device 2 of the present invention is used as backup memory. Here, when encryption or decryption is performed, the data amount that is transmitted or received can be reduced and data processing speed can be improved by encrypting or 15 decrypting only the header of the file. Also, the encryption-decryption conversion support controller 20 performs user authentication through the security authentication chip 40 when the security token device 2 is connected to the user terminal 1, and performs the 20 encryption or decryption only when the user authentication is successful. Here, the user authentication can be performed by generating a session key using an authenticator value obtained by encrypting a random value derived from the password that is input by the user, and using a response value for the 25 authenticator value. 18 The storage unit 30 stores the encrypted header. Also, the storage area of the storage unit 30 can be divided so that some parts of the area may be used for a common storage area and the remaining parts may be used for storing the encrypted 5 header. The storage unit 30 includes flash memory such as commonly used USB memory or other various storage media. The security authentication chip 40 is a chip for providing a security function by performing user authentication when the security token device 2 is connected 10 to the user terminal 1, and may store at least one among password information as the means of authenticating a user, user's fingerprint information, and an OTP generation module for generating an OTP value. The password information is a personal identification 15 number that has been predetermined by a user, and differs from an encryption key. Also, when user's fingerprint information is used for user authentication, a fingerprint reader device should be installed in the security token device or installed as an external device. 20 The OTP generation module uses either increment or time and a random value as input values of an encryption algorithm to generate an OTP value, and transmits the OTP value to an authentication server to authenticate a user. Through such a multiple authentication process, security of the security 25 token device can be enhanced. On the other hand, the multiple 19 authentication process may improve security of the security token device, but when a user loses the security token device 2, the user cannot open the encrypted file that has been uploaded in the cloud server 3. Such a problem concerns some 5 users and cooperators, thus multiple products having the same encryption key can be sold for companies and groups that want to use two or more security token devices as a measure of the loss. Also, to manage the history of a file that is changed by 10 the collaborative work of several people, an additional agent sever service can be interconnected. In other words, the multiple security token devices for the coworkers use the same single encryption key, but an identification number is allocated to each of the security token devices to distinguish 15 the devices, thus history of the file that is changed by collaborative work can be managed, for example, who last modified the file, when the file was copied, etc., On the other hand, during the user authentication process, the security authentication chip 40 generates 20 response data for the authenticator data received from the session key generation unit 120 of the agent 100 and transmits it to the agent 100. Then, the security authentication chip 40 may create a session with the agent 100 by receiving a session key that is generated by the agent 100 using the 25 response data. The generation of the response data is 20 specifically described with reference to FIG. 5. FIG. 5 is a view for explaining the generation of the response data of the security authentication chip 40 of FIG. 4. 5 When receiving the authenticator data from the session key generation unit 120, the security authentication chip 40 decrypts the authenticator data using a password and may confirm the password match. When the password match is successful, the security 10 authentication chip 40 may generate a response random value derived from the password. Here, the response random value can be generated by the same algorithm used for the generation of the authentication random value. In other words, it can be generated using Advanced Encryption Standard (AES) algorithm, 15 and can be encrypted using Cipher Block Chaining (CBC) mode. In this case, the response random value (keyl) can be generated to a 16-byte key in CBC mode, using the following equation: Tempkey = password(20) ( padding(12) 20 Key = E ((SNO ( SNO-1), Tempkey) The response random value can be obtained by the following process. First, Initialization Vector (IV) is XOR operated with a first block of a password plaintext and then encrypted. Repeatedly, the next block of the plaintext (SNO) 25 is XOR operated with the previous encrypted block (SNO-1) and 21 then encrypted. When the 16-byte random value that is derived from the password is generated, the security authentication chip 40 divides it into two blocks, the first 8-byte block 320 (the 5 third random value) and the next 8-byte block 330 (the fourth random value), and then inserts the password string 310 at the beginning of each of the blocks to generate the first block and the second block of the response data 300. As shown in FIG. 5, the response data may be 32 bytes, 10 and may be made up of the first block and the second block, the blocks each having a 16-byte column. The first block may consist of 8 bytes of the password string 310 and 8 bytes of the third random value 320 that is derived from the password. 15 The second block may consist of 8 bytes of the password string 310 and 8 bytes of the fourth random value 330 that is derived from the password. The security authentication chip 40 may encrypt 32 bytes of the response data of FIG. 5 using the password, and may 20 transmit it to the session key generation unit 120. The security authentication chip 40 may create a session when receiving a session key from the session key generation unit 120. Here, the session key can be generated by the session key 25 generation unit 120, using the authentication random value 22 generated by the session key generation unit 120 and using the response random value that is included in the response data received by the session key generation unit 120 from the security token device 2. 5 FIG. 6 is a flow diagram illustrating a prior process for the use of a security token device in a PC environment. When a security token device 2 is connected to a user PC at step S100, an agent 100 loaded on the user PC is driven at step S110. The agent 100 is a program for providing a 10 security cloud service by being interconnected with the security token device 2, and performs the processes such as: sending a target file header, generated by a header generation unit 130, to the security token device 2 to perform hardware encryption on the header when the target file to be encrypted 15 is detected during cloud synchronization; decrypting the header of a file that is downloaded from the cloud server 3, through the security token device 2; and performing automatic encryption and decryption operations according to whether the security token device 2 is connected. 20 When the agent 100 is driven, a user is connected to the homepage of the manufacturer of the security token device 2 and is induced to register at the homepage and to sign up for a membership at step S120. Then, user authentication is performed at step S130. As described above, the user 25 authentication is performed using various means such as a 23 password, fingerprint information, OTP, and the like. Also, security can be further improved by generating a session key using a random value derived from the password. Then, the agent 100 leads the user to specify or create a 5 local synchronization folder at step S140, that is, a folder to be synchronized with the cloud server 3. Here, the local synchronization folder can be transmitted to the cloud server 3 after all the files stored in the local synchronization folder are encrypted using the encrypted header transmitted 10 from the security token device 2. As a variation, the local synchronization folder can be divided into a common synchronization folder, of which files are transmitted to the cloud server 3 without encryption, and a secure synchronization folder, of which files are uploaded 15 to the cloud server 3 after being encrypted using a header. In this case, the agent may create the secure synchronization folder as a child folder of the local synchronization folder, and an operation for the security cloud service can be performed only for the files stored in the secure 20 synchronization folder at step S150. FIG. 7 is a flow diagram illustrating a process in which a file is encrypted using a security token device and then transmitted to a cloud server. The agent 100 loaded on a user PC monitors the connection 25 of a security token device 2 to the user PC at step S201, and 24 may generate a session key by performing user authentication at step S202 when the connection is detected. The detailed description of the user authentication is described in FIG. 9. The agent 100 detects the first event such as the 5 creation or the copy of a file to be uploaded to the cloud server 3 at step S203, and may generate a header for the corresponding file at step S204 when the first event is detected. Here, the header is an encryption key for encrypting the file in which the first event is detected, and 10 it can be generated to a random value. Next, the generated header is encrypted using the session key generated at step S202 and transmitted to the security token device at step S205. When the transmitted header is encrypted by the security token device 2 and transmitted to 15 the agent 100 at step S206, the agent 100 may encrypt the file in which the first event is detected, using the encrypted header at step S207. When the file to be uploaded is encrypted, the agent 100 stores the encrypted file in a relevant folder at step S208. 20 The encrypted file is stored in the local synchronization folder or the secure synchronization folder, which is a child folder of the local synchronization folder, depending on the encryption scope, and the file stored in the corresponding folder is transmitted to the cloud server 3 by running a cloud 25 application. 25 If, during the automatic encryption operation, removal of the security token device 2, in other words, the disconnection of the device is detected at step S209, the agent 100 cancels the automatic encryption at step S210 and deletes the files in 5 the corresponding folder to prevent synchronization with the cloud server 3. FIG. 8 is a flow diagram illustrating a process in which a file is decrypted using a cloud service in a mobile environment. 10 First, a cloud application for providing a cloud service is run at step S301, and when an encrypted file is downloaded from the cloud server 3 to a mobile terminal, the occurrence of the second event is detected at step S302. When the encrypted file is received, the agent 100 for 15 the security cloud service is driven and monitors whether the security token device 2 is connected. When the security token device 2 is connected to the mobile terminal at step S303, a session key is generated through user authentication and a session with the agent 100 20 is created at step S304. When the user authentication is completed, the agent encrypts the header of the encrypted file using the session key generated at step S304 and may transmit it to the security token device 2 at step S305. When the header is decrypted by the security token device 25 2 at step S306 and transmitted to the terminal, the agent 100 26 may decrypt the file using the decrypted header at step S307. The user terminal 1 may display the decrypted file on the screen by running it. If the removal, in other words, the disconnection of the 5 security token device 2 is detected during the file download operation at step S308, the agent 100 cancels the automatic decryption and deletes the decrypted cache files in the corresponding folder to prevent the files from running at step S309. 10 FIG. 9 is a flow diagram illustrating a user authentication process when a security token device is connected to a user terminal. For the description of FIG. 9, FIG. 2 to 5 can be referred to. When the physical connection of the security token device 15 2 is detected in the user terminal 1 in which the agent 100 is installed, the agent 100 may receive a password from a user at step S410. When the password is input from the user, the agent 100 may request a public key from the security token device 2 at 20 step S420. In response to the request for the public key, the security token device 2 transmits the public key at step S430 and the agent 100 may receive and store it at step S440. Next, the session key generation unit 120 of the agent 100 may generate an authentication random value derived from 25 the input password at step S450. Here, the authentication 27 random value can be generated using Advanced Encryption Standard (AES) algorithm, and can be encrypted using Cipher Block Chaining (CBC) mode. Here, the authentication random value is 16 bytes, and it 5 may be used for generating authenticator data by dividing it into the first 8 bytes as the first random value and the next 8 bytes as the second random value. Next, the session key generation unit 120 of the agent 100 generates the authenticator data using the generated 10 authentication random value, encrypts it using the public key received from the security token device 2 at step S460, and may transmit it to the security token device 2. Here, the authentication data is 256 bytes, and may consist of the password, the authentication random value, a 15 verification value for the public key, padding, and the like. The generation of the authentication random value and authenticator data is described above in FIG. 3, so the description about it is omitted hereinafter. The security token device 2 may confirm the password by 20 decrypting the encrypted authenticator data that is received from the agent 100, using the password at step S470. Next, the security token device 2 may generate a response random value derived from the password at step S480. Here, the response random value can be generated using Advanced 25 Encryption Standard (AES) algorithm, and can be encrypted 28 using Cipher Block Chaining (CBC) mode. In this case, the response random value is 16 bytes, and can be used to generate response data by dividing it into the first 8 bytes (the third random value) and the next 8 bytes 5 (the fourth random value). Next, the security token device 2 generates the response data using the generated response random value at step S490, encrypts it using the password at step S500, and may transmit it to the agent 100. 10 Next, the agent 100 generates a session key at step S510 using the authentication random value generated at step S450 and using the response random value included in the response data that is received from the security token device 2, and may transmit the generated session key to the security token 15 device 2. Next, when the session key is received, the security token device 2 creates a session that is logically connected with the agent 100 for a login process at step S520. FIG. 10 illustrates a file header encryption process in a 20 security token device when a file is uploaded, and FIG. 11 illustrates a file header decryption process in a security token device when a file is downloaded. In FIG. 10 and 11, an example in which a user terminal 1 is connected to a USB connector 10A is illustrated. 25 First, referring to FIG. 10, when a file is uploaded, 29 data flow from the agent 100 to the security token device 2 is represented by the dashed arrow, and data flow in the opposite direction is represented by the dotted arrow. When a header for encrypting an original file to be 5 uploaded is input from the agent 100 at step Si, the encryption-decryption conversion support controller 20 encrypts the received header of the original file at step S2, stores the encrypted header in the storage unit 30 at step S3, and delivers the encrypted header stored in the storage unit 10 30 to the agent 100 at step S4. The agent 100 receives the encrypted header, encrypts the original file to be uploaded, and may upload the file to the cloud server 3. Subsequently, referring to FIG. 11, when a file is 15 downloaded, data flow from the agent 100 to the security token device 2 is represented by the dashed arrow, and data flow in the opposite direction is represented by the dotted arrow. When the header of the file downloaded from the cloud server 3 is input from the agent 100 at step Sll, the encryption 20 decryption conversion support controller 20 passes through the encrypted header and stores it in the storage unit 30 at step S12, decrypts the encrypted header stored in the storage unit 30 at step S13, and delivers the decrypted header to the agent 100 at step S14. 25 The agent 100 receives the decrypted header, and decrypts 30 the encrypted file, which is downloaded from the cloud server, to be run on the user terminal 1. On the other hand, besides the creation of a file by upload or download of the file, when the events such as file copy, deletion, and the like occur, 5 encryption-decryption can be performed depending on the data flow described in FIG. 10 and 11. Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, 10 additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims. 31