Note: Descriptions are shown in the official language in which they were submitted.
CA 02891610 2015-05-13
AGENT FOR PROVIDING SECURITY CLOUD SERVICE AND SECURITY TOKEN
DEVICE FOR SECURITY CLOUD SERVICE
BACKGROUND OF THE INVENTION
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
M 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.
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
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.
In a cloud computing environment, investment costs in IT
equipment on the client's side can be reduced because users do
1
CA 02891610 2015-05-13
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 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
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 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
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
software and encryption keys are managed by a Windows program,
the keys may be exposed to monitoring programs run by hackers.
Thus, it is difficult to assure security in the conventional
art.
2
CA 02891610 2015-05-13
Documents of Related Art
(Patent Document 1) KR10-1107056
SUMMARY OF THE INVENTION
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
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
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
when a security token device is connected to a user terminal 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
user telminal, for providing a security cloud service may
3
CA 02891610 2015-05-13
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
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 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.
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
detecting connection of the security token device; generate
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 using
a random value for response when receiving from the security
token device, response data that includes the random value for
4
CA 02891610 2015-05-13
response.
To accomplish the above object, a security token device for
a security cloud service according to an embodiment of the
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 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 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
security authentication chip, which transmits a public key 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 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.
5
CA 02891610 2015-05-13
The security authentication chip may encrypt the 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 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
W PC is hacked into.
Therefore, security can be remarkably
improved.
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.
BREIF DESCRIPTION OF THE DRAWINGS
The above and other objects, features and other advantages
of the present invention will be more clearly 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;
FIG. 2 is a block diagram illustrating a detailed
6
CA 02891610 2015-05-13
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
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;
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 environment;
FIG. 9 is a flow diagram illustrating a user authentication
process when a security token device is connected to a user
teLminal;
FIG. 10 illustrates a file header encryption process in a
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
The present invention will now be described in detail based
on aspects (or embodiments).
The present invention may,
7
CA 02891610 2015-05-13
however, be embodied in many different forms and should not be
construed as being limited to only the embodiments set forth
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
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,
second, etc. may be used herein to describe various elements,
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
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
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
8
CA 02891610 2015-05-13
"directly coupled" to another element, there are no 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 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 the presence or
addition of one or more other features, 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
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 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 invention;
FIG. 2 is a block diagram illustrating a detailed configuration
9
CA 02891610 2015-05-13
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
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, and
Internet access, such as PCs, laptops, tablet PCs, 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 contents
such as documents, contacts, and media files including movies,
photos, and music. When a user teLminal 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 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 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.
CA 02891610 2015-05-13
The event detection unit 110 may detect the occurrence of 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 become a
first event. Conversely, the creation, the deletion, 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
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
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 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.
11
CA 02891610 2015-05-13
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 device 2 only
when the security token device 2 is connected.
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.
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. 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.
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. The
generation of the authenticator value is described with
12
CA 02891610 2015-05-13
reference to FIG. 3.
FIG. 3 is a view illustrating the generation of
authenticator data by the session key generation unit of FIG. 2.
The session key generation unit 120 may generate an
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.
The authentication random value (key) can be generated to a
M 16-byte key in CBC mode, using the following equation:
Tempkey = password(20) padding(12)
Key = E ((SNO SNO-1), Tempkey)
The authentication random value is 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) is
XOR operated with the previous encrypted block (SNO-1) and then
encrypted. Here, the last block may be a padded block.
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 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
CA 02891610 2015-05-13
authentication random value obtained by the above-described
equation is Ox00 01 02 03 04 05 06 07 08 09 OA OB OC OD OE OF,
the first block becomes "SZTGBPWDOO 01 02 03 04 05 06
07", and the second block becomes "SZTGBPWDO8 09 OA OB
OC OD OE OF". Here, the first block and the second block can be
encrypted according to Public Key Cryptography Standard, 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
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.
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
can be filled with padding 250.
The session key generation unit 120 may perfoLm 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. Also,
in response to the encrypted authenticator data, the session key
14
CA 02891610 2015-05-13
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 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 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, 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 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.
The security token device 2 is detachable from the user
teLminal 1, and operates when it is connected with the user
teLminal 1.
The security token device 2 receives from the
CA 02891610 2015-05-13
header generation unit 130, the header of the file in which
occurrence of the event is detected by the event detection 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, 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 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
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.
The interface units 10A and 103 are a connector to be
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.
The encryption-decryption conversion support controller 20
16
CA 02891610 2015-05-13
perfoLms 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
perfoLms a control operation for data backup when the security
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 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 teLminal 1, and performs the 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 authenticator value.
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 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
17
CA 02891610 2015-05-13
a security function by perfoLming user authentication when the
security token device 2 is connected 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
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 fingeLprint reader device should
be installed in the security token device or installed as an
external device.
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 token
device can be enhanced.
On the other hand, the multiple
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 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
the collaborative work of several people, an additional agent
18
CA 02891610 2015-05-13
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 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 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 response data. The generation of the
response data is 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.
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
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
19
CA 02891610 2015-05-13
the authentication random value.
In other words, it can be
generated using Advanced Encryption Standard (AES) algorithm,
and can be encrypted using Cipher Block Chaining (CBC) mode.
In this case, the response random value (key1) can be
generated to a 16-byte key in CBC mode, using the following
equation:
Tempkey = password(20) padding(12)
Key = E ((SNO e 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) is XOR
operated with the previous encrypted block (SNO-1) and 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
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, 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
CA 02891610 2015-05-13
derived from the password.
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 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
generation unit 120, using the authentication random value
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.
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 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 is detected during
21
CA 02891610 2015-05-13
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.
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 authentication is
performed using various means such as a 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
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 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 to
the cloud server 3 after being encrypted using a header. In
22
CA 02891610 2015-05-13
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 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
of a security token device 2 to the user PC at step S201, and
may generate a session key by perfolming 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 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 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 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.
23
CA 02891610 2015-05-13
When the file to be uploaded is encrypted, the agent 100
stores the encrypted file in a relevant folder at step S208.
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
application.
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
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.
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 5302.
When the encrypted file is received, the agent 100 for 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 is created at
24
CA 02891610 2015-05-13
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 2
at step S306 and transmitted to the terminal, the agent 100 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
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.
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 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 step
S420.
In response to the request for the public key, the
CA 02891610 2015-05-13
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 the
input password at step 5450. Here, the authentication 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
W 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
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 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
decrypting the encrypted authenticator data that is received
from the agent 100, using the password at step S470.
26
CA 02891610 2015-05-13
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 Encryption
Standard (AES) algorithm, and can be encrypted 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 (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.
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 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
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
27
CA 02891610 2015-05-13
in which a user terminal 1 is connected to a USB connector 10A
is illustrated.
First, referring to FIG. 10, when a file is uploaded, 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
uploaded is input from the agent 100 at step S1, 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 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
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 S11, the encryption-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
28
CA 02891610 2015-05-13
step S14.
The agent 100 receives the decrypted header, and decrypts
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,
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, additions
and substitutions are possible, without departing from the scope
and spirit of the invention as disclosed in the accompanying
claims.
29
