CN101727407A - Safe storage system and method - Google Patents
Safe storage system and method Download PDFInfo
- Publication number
- CN101727407A CN101727407A CN200810173048A CN200810173048A CN101727407A CN 101727407 A CN101727407 A CN 101727407A CN 200810173048 A CN200810173048 A CN 200810173048A CN 200810173048 A CN200810173048 A CN 200810173048A CN 101727407 A CN101727407 A CN 101727407A
- Authority
- CN
- China
- Prior art keywords
- file
- encryption
- storage
- chaotic
- storage space
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000003860 storage Methods 0.000 title claims abstract description 120
- 238000000034 method Methods 0.000 title claims abstract description 52
- 230000000739 chaotic effect Effects 0.000 claims description 51
- 238000004422 calculation algorithm Methods 0.000 claims description 31
- 238000013475 authorization Methods 0.000 claims description 27
- 238000013507 mapping Methods 0.000 claims description 26
- 230000015654 memory Effects 0.000 claims description 26
- 238000012795 verification Methods 0.000 claims description 10
- 230000008859 change Effects 0.000 claims description 2
- 238000007726 management method Methods 0.000 description 24
- 230000008569 process Effects 0.000 description 22
- 238000004891 communication Methods 0.000 description 11
- 238000012545 processing Methods 0.000 description 9
- 238000013461 design Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000005291 chaos (dynamical) Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000002650 habitual effect Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 238000005312 nonlinear dynamic Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Landscapes
- Storage Device Security (AREA)
Abstract
The invention provides safe storage system and method. A storage space is created for storing a document. Chaos encryption is carried out for the document, the cryptograph of the document is stored into the storage space assigned to a corresponding account. The access for the storage space is controlled on the basis of preset authority corresponding to the account. In addition, the invention can provide version management, so that the version history of the document can be maintained.
Description
Technical Field
The following generally relates to information security.
Background
With the development of information technology, data storage and management services have become widespread. In some cases, a large number of electronic files need to be stored on a server. However, such stored files are often not managed efficiently and securely.
For example, some businesses generate a large number of files in a workflow. These files may belong to different persons or should be accessed by specific persons. In conventional storage services, files are simply stored in a common storage area. However, this often poses a safety issue. For example, the document may be exposed to an inappropriate person, or the document may be tampered with, either intentionally or unintentionally. That is, with conventional storage schemes, files lack good management and security is difficult to guarantee.
Additionally, in a workflow, files may be changed often. For example, in manufacturing, construction, design, etc., drawings or documents are often updated. In conventional storage management, an old version of a file may be overwritten by a newer file, thereby failing to maintain a complete revision history.
Disclosure of Invention
According to one embodiment, a secure storage system and method are provided. The storage system includes an encryption unit, one or more storage spaces, and a storage space management unit. The encryption unit performs chaotic encryption on the electronic file. The ciphertext of the file may be stored in a storage space allocated according to the account. The storage space management unit controls access to the storage space based on a predetermined authorization corresponding to the account.
The foregoing is a summary of the present application and thus contains, by necessity, simplifications, generalizations and omissions of detail; those skilled in the art will appreciate that the summary is illustrative of the application and is not intended to be in any way limiting. Other aspects, features and advantages of the devices and/or methods and/or other subject matter described in this specification will become apparent as the description proceeds. The summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Drawings
The above described and other features of the present application will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. It is to be understood that these drawings are solely for purposes of illustrating several embodiments of the present application and are not intended as a definition of the limits of the application, for which reference should be made to the appended drawings, wherein the disclosure is to be interpreted in a more complete and detailed manner.
FIG. 1 schematically illustrates an environment in which aspects of one embodiment may be applied;
FIG. 2 schematically illustrates a flow of a storage service according to one embodiment;
fig. 3 schematically shows a configuration example of a server according to an embodiment;
fig. 4 schematically shows a configuration example of an encryption unit according to an embodiment;
fig. 5 schematically shows an encryption process performed by an encryption unit according to an embodiment;
FIG. 6 illustrates a shift operation in a plaintext block in accordance with one embodiment;
fig. 7 schematically shows a configuration example of a storage space management unit according to an embodiment;
FIG. 8 schematically shows an example of a process for storing a file on a server according to one embodiment;
FIG. 9 schematically shows an example of a process for accessing a file according to one embodiment;
fig. 10 schematically shows a configuration example of a decryption unit according to an embodiment;
fig. 11 schematically shows a configuration example of a storage space management unit according to an embodiment; and
fig. 12 schematically shows a configuration example of a storage space management unit according to an embodiment.
Detailed Description
In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, like reference numerals generally refer to like parts throughout the specification unless otherwise specified. The illustrative embodiments described in the detailed description, drawings, and claims should not be considered limiting of the application. Other embodiments of, and changes to, the present application may be made without departing from the spirit or scope of the subject matter presented in the present application. It should be readily understood that the aspects of the present application, as generally described in the specification and illustrated in the figures herein, could be arranged, substituted, combined, designed in a wide variety of different configurations, and that all such modifications are expressly contemplated and made part of this application.
The present application also relates to methods, apparatuses, computer programs and systems relating to secure information storage.
FIG. 1 schematically illustrates an environment in which an embodiment may be applied.
As shown in fig. 1, a plurality of terminals can communicate with a server via a network. A terminal may be any device capable of communicating information, such as a Personal Computer (PC), a laptop, a Personal Digital Assistant (PDA), a smart mobile phone, or other data processing device. A server is typically implemented as a device or group of devices that can store and maintain data, and make the data accessible to terminals. Although a single device is shown generally in fig. 1, the server may be multiple separate devices located either proximally or remotely. The network may be any kind of communication network or computer network including, but not limited to, a wireless communication network, a wired communication network, a Wide Area Network (WAN), a Local Area Network (LAN), the internet, a hybrid network, and so forth. Although not shown, it is to be appreciated that in some applications any of the terminals may be directly connected to the server via a cable or direct wireless connection. In this case, the network described here and hereinafter is a connection medium or carrier wave between the server and the terminal.
According to one embodiment, a server creates and manages one or more storage spaces. The storage space may be created in advance on the server or created when an account is created upon request. The storage space may be a memory space for storing files. In one embodiment, the memory space is accessible by one or more terminals that represent ownership of the respective account.
FIG. 2 schematically illustrates a general flow of a storage system according to one embodiment. As shown in fig. 2, the terminal is used to store one or more files in a storage space on the server. The file is encrypted before being sent and stored in the storage space. Decryption is typically performed by the server. Any encryption scheme may be used. However, in view of the features of the chaos theory, chaotic encryption is employed in the embodiments described below. For example, chaos is known to be a complex nonlinear dynamic effect. The chaotic sequence has the characteristics of randomness, complex structure sensitivity to initial parameters, expanded spectrum and the like. The distribution does not satisfy the statistical probability theory and is difficult to analyze, reconstruct or predict. These attractive features make it useful for streaming cryptographic systems.
After the file is encrypted, the ciphertext of the file is stored in the corresponding storage space allocated to one account. That is, the file stored in each storage space is in the form of ciphertext.
When the server receives a request to access one or more files, the server validates the request; and controlling access to the memory space based on the authorization of the request. For example, upon verification, the server identifies the account associated with the request and allows browsing or access to files in the memory space assigned to the account, or in the memory space(s) to which the account is authorized to access.
When the server receives a request to read or retrieve a file stored in the storage space, the file stored in the form of ciphertext is decrypted and made available for access. As will be described, the decryption may be performed at the server, at the terminal or at a third trusted party.
Configuration examples of the server and the executed process will be described below with reference to fig. 3 to 6.
Fig. 3 schematically shows a configuration example of the server 100 according to an embodiment.
As shown in fig. 3, the server 100 mainly includes one or more storage spaces 110-1, 110-2, …, 110-n configured to store encrypted files, an encryption unit 120 for encrypting files to be stored, and a storage space management unit 130 for controlling access to the storage spaces based on predetermined authorization.
Although not shown, the server 100 may also include any other units/components, such as a communication unit for connecting with a network or a terminal, a display unit for displaying information to an operator of the server, an input unit for receiving data input, a controller for controlling the operation of the units, any necessary storage devices, and so forth. These components are known in the art and are therefore not described, and one of ordinary skill in the art will readily recognize that they may be added to a server according to any particular application.
Fig. 4 schematically shows a configuration example of the encryption unit 120 according to an exemplary embodiment.
As shown in fig. 4, the encryption unit 120 includes a mapping setting module 121 configured to set the chaotic mapping, an initial parameter setting module 122 configured to set initial parameters of the chaotic mapping, an encryption algorithm setting module 123 configured to set an encryption algorithm used when generating a ciphertext, a key generation module 124 configured to generate a key sequence from the chaotic mapping, and a ciphertext generation module 125 configured to generate a ciphertext of a file using the key sequence and the encryption algorithm.
Fig. 5 schematically shows the encryption process performed by the encryption unit 120. In brief, in step S501, the chaotic map setting module 121 sets the chaotic map, and in step S502, the initial parameter setting module 122 sets initial parameters for chaotic map iteration. In step S503, the key generation module 125 generates a key sequence through iteration of the chaotic mapping, using the parameters set by the initial parameter setting module 122 as initial inputs to the chaotic mapping. In step S504, the encryption algorithm setting module 123 sets the specific encryption algorithm (S) to be used for encrypting the file. Then, in step S505, the ciphertext generation module 125 encrypts the block of the file using the generated key sequence using the encryption algorithm set by the encryption algorithm setting module 123.
It should be noted that the order of the above steps is not limited to the order shown in the figures. For example, the step of setting the encryption algorithm may be performed before, after, or simultaneously with the step of setting the chaotic map. In addition, any other steps may be added to the flow for improvement or modification.
A specific operational example of chaotic encryption is presented below to provide a better understanding of the embodiments.
Suppose the plaintext of a file is denoted as M ═ M0，M1，M2，…，MnGenerating a key sequence B ═ B through iteration of chaotic mapping0，b1…, b, and modulo-2 addition
Is selected as the encryption algorithm, the ciphertext generation module 125 computes
(i-0, 1, 2, …, n) to obtain a ciphertext C-C0，c1，c2，…，cn。
The following describes an encryption process according to an embodiment, taking a Logistic map as an example.
First, the mapping setting module 121 of the encryption unit 120 sets the following four Logistic mappings
Wherein x isn iRepresenting the value after n iterations of the ith mapping. In one example, xn iAnd muiMay be a double precision value.
The initial parameter setting module 122 sets the initial inputs of the mapping. For example, the output parameter setting module 122 sets the random number μiE (3.57, 4) and
i＝1，2，3，4。
using these initial values, key generation module 124 performs, for example, 100 iterations of equation (1) to obtain four values x100 1、x100 2、x100 3、x100 4. This operation eliminates the trace of the initial value.
The key generation module 124 then performs 20 further iterations for each mapping. The value obtained after j iterations of the ith mapping is denoted xj i，xj iIn binary formWherein b isjn iIs xj iThe binary value of the nth bit.
After each of the 20 iterations, key generation module 124 proceeds from xj 1、xj 2、xj 3、xj 4Two bits are extracted from each to obtain an 8-bit sequence. E.g. from xj i(i-1, 2, 3, 4) to extract the 2 nd and 3 rd bits and obtain an 8-bit sequence bj2 1bj2 2bj2 3bj2 4bj3 1bj3 2bj3 3bj3 4。
After 20 iterations and extractions, a 128-bit key sequence a and another 32-bit sequence D are obtained as follows
A＝H1，2H1，3H2，2H2，3H3，2H3，3…H16，2H16，3
D＝H17，2H17，3H18，2H18，3H19，2H19，3H20，2H20，3
Wherein,
sequence a is used for the final encryption step and sequence B is used to generate the intermediate cipher text as will be described below.
In this example, before being encrypted, a block of plaintext is subjected to a shift operation in order to increase the encryption strength. In particular, the plaintext is divided into a series of blocks P0，P1，P2…, each block having a length of 128 bits.
Referring to FIG. 6, any block PkAre all divided into two sub-blocks Pk1 and Pk2, each sub-block has a length of 64 bits. Then, sub-block Pk1 and Pk2 respectively experience S1Bit sum S2Cyclic left shift of bits, where S1＝(H17，2H17，3)mod 64，S2＝(H18，2H18，3) mod 64. Sub-block Pk1 and Pk2 are combined to form a block P after being shiftedk'. Then, block Pk' also undergo a cyclic left shift of S bits to form an intermediate ciphertext Ck', wherein S ═ H19，2H19，3+H20，2H20，3)mod 128。
The above-described process of dividing and shifting blocks of plaintext may be performed by the ciphertext generation module 125, for example.
After obtaining the intermediate ciphertext Ck' thereafter, the ciphertext generation module 125 pairs the key sequence A and the intermediate ciphertext Ck' performing an addition (XOR) operation as follows to obtain block PkCipher text C ofk
In order to process the next block Pk+1The key generation module 124 performs the following calculation:
then, the key generation module 124 further performs E on the first mapping in equation (1)1A second iteration of performing E on the second mapping2A second iteration of performing E on the third mapping3A second iteration of performing E on the fourth mapping4And (5) performing secondary iteration. After that, for the block Pk+1Repeating the above generation through 20 iterationsSequences A and D, processing to shift a plaintext block to obtain an intermediate ciphertext, and generating a final ciphertext for the block using sequence A and the intermediate ciphertext to obtain ciphertext Ck+1。
The above process is performed until each block of the file is processed, and the final ciphertext of the file is obtained.
Information about the chaotic map, the initial and control parameters of the chaotic map, and the selected encryption algorithm is saved by the encryption unit for later decryption. Alternatively, the generated key sequence may be directly stored.
The above is just one example of chaotic encryption used in one embodiment. It will be readily appreciated that the present application is not limited to any of the specific processes described above, but may be subject to any simplification, substitution, modification or improvement.
For example, an exclusive or operation is used as an encryption algorithm in the above example to generate the ciphertext. However, any other encryption algorithm that generates ciphertext using a key may be employed, such as an addition operation, a subtraction operation, an inversion operation, a shift operation, a permutation operation, and so forth.
In the above embodiment, the same encryption algorithm is used for each block. However, in another embodiment, different encryption algorithms may be used for different blocks. For example, the encryption algorithm setting module 123 may select more than one encryption algorithm, and the ciphertext generation module 125 applies each of these encryption algorithms to a respective subset of the blocks. By using varying encryption algorithms when encrypting multiple blocks of a file, a "frequency statistics" attack on the ciphertext may be prevented.
It should be noted that both low-dimensional and high-dimensional chaotic systems are applicable. That is, the mapping setting module 121 may set a one-dimensional chaotic map or a multi-dimensional chaotic map. With a high-dimensional chaotic system, better characteristics of the key sequence can be obtained, such as long period, high nonlinear complexity and good statistical properties (including balance, autocorrelation, cross-correlation and propagation distribution). Because the high-dimensional chaotic sequence has improved attribute in the aspect of randomness, files encrypted by the high-dimensional chaotic system are difficult to crack, and the safety is ensured.
For example, the following three-dimensional Lorenz equation can be used to establish a chaotic system
dx1/dt＝-βx1+x2x3
dx2/dt＝-σ(x2-x3)
dx3/dt＝-x1x2+ρx2-x3
Where β, σ and ρ are system parameters with typical values β 8/3, σ 10 and ρ 28. Keeping sigma and beta unchanged, and when rho is larger than 24.74, the Lorenz system enters a chaotic state.
In the above example, the key sequence is generated starting from a randomly selected initial input to the iteration of the chaotic map. In another embodiment, the generation of the key sequence may be associated with the plaintext of the file. For example, the initial output may include information in the clear of the file.
In addition, in one embodiment, a pseudo-random noise sequence (PN sequence) may be used to improve the characteristics of the chaotic sequence. For example, the longest linear feedback shift register sequence may be generated as a PN sequence using a feedback shift register, and the PN sequence is added as a random perturbation to the chaotic sequence.
One configuration example of the storage space management unit 130 will be described below with reference to fig. 7.
As shown in fig. 7, the storage space management unit 130 includes an authorization module 131 configured to allocate storage space and specify access rights, an access control module 132 configured to control access to the storage space based on a received request, and an authentication module 133 configured to authenticate a request for accessing a file on a server.
During an initialization phase, authorization module 131 establishes one or more memory spaces allocated according to a predetermined set of parameters. For example, for an authenticated account, the authorization module 131 allocates a memory space on the server for the account and authorizes the account to access the memory space. A storage space is a storage space for storing electronic files, which may be a physical storage area or a virtual storage space (e.g., a folder created on a server). A plurality of storage spaces may be preset on the server and the authorization module 131 allocates them accordingly. Alternatively, the storage space may be created by authorization module 131 when the server receives a request to create a new account.
It should be noted that in some applications, pre-verification may be required prior to initial authorization. That is, if a new request for the storage service is generated, the verification unit 133 may first authenticate the identity of the request. A request successfully authenticated by the verification unit 133 may be allocated an account and corresponding storage space and granted access by the authorization module 131.
The association of the memory space with the respective account is registered, for example, in an authorization database maintained by authorization module 131. In applications where memory is enabled and accessible to an associated account, the association between the memory and the account indicates that the account has access.
In another application, access to other memory space(s) that are not allocated to the account may be granted. In this case, the specific rights of the account are also registered in an authorization database maintained by the authorization module. The kind of access rights may be set according to the specific application. For example, access rights include, but are not limited to, login, logout, browse, edit, add new files, create folders, delete files, change file properties, and the like.
Fig. 8 schematically shows an example of a process for storing a file on a server. In general, when a request for storing a file on a server is generated, authentication is performed with the authentication module 133 at step S801. For example, the authentication module 133 requires an account name and password. If the received account name is pre-recorded in a verification database maintained by the verification module and the accepted password matches a password registered in the verification database in association with the account name, access to the account is granted. Otherwise, the process proceeds to step S804 to perform failure processing in which, for example, the request is rejected or retry verification is required. The authentication database may be previously established by the authentication module 133 or established when the authentication module 131 performs an authentication process. The validation database may be stored in the validation module 133, or in the authorization module 131 separately or in combination with the authorization database, or in other storage devices.
After successful authentication, the file is allowed to be transmitted to the server. In step S802, the file is encrypted by the encryption unit 120 using chaotic encryption before being stored. Based on the account information obtained through the authentication process, the authorization module 131 identifies the storage space allocated to the account, and under the control of the access control module 132, the ciphertext of the file is stored in the identified storage space at step S803.
Fig. 9 schematically shows an example of a process for accessing a file stored in a storage space. In general, when a request for accessing a file on a server is generated, authentication is performed with the authentication module 133 at step S901. When the authentication fails, the process proceeds to step S904 to perform failure processing. These processes are similar to the processes described above with reference to fig. 8.
On the other hand, after the authentication is successful, the access control module 132 checks whether the account is allowed to access the requested file. Specifically, based on the account information obtained by the authentication, authorization module 131 looks up an authorization database for access rights associated with the account. If the account has corresponding access rights, the access control module 132 provides access to the corresponding memory space, e.g. allows the terminal to perform the corresponding access operation. If the request does not have the appropriate access right, the access control module 132 will deny the access request and the process proceeds to step S904 for failure processing.
The communication between the terminal and the server when accessing the memory space may be based on TCP/IP, Remote Procedure Call (RPC), and distributed component Technology (distributed component Technology). For example, a memory service thread on a server for providing remote procedure call services is created and an appropriate protocol (with a named pipe as the default protocol) is selected to receive the remote procedure call. The server then monitors the client remote procedure calls and if a client RPC is received, the authorization of the client RPC can be checked to determine if the client should be allowed to access the file in the storage space.
Since the file is stored in the storage space in the form of a ciphertext, the file should be decrypted when the file is accessed. A decryption unit is provided for decrypting files retrieved from the storage space. Fig. 10 schematically shows one configuration example of the decryption unit.
As shown in fig. 10, the decryption unit 1000 includes a parameter obtaining module 1001 configured to obtain parameters required for decryption, a key generation module 1002 configured to obtain a key sequence for decryption, and a plaintext generation module 1003 configured to decrypt a ciphertext to obtain a plaintext of a file.
The parameter acquisition module 1001 acquires necessary parameters for decryption. In one embodiment, the parameter acquisition module 1001 communicates with the encryption unit of the server and receives information about chaotic mappings, initial values and control parameters for mapping iterations, and encryption algorithms. Using information about the chaotic map, initial values of mapping iterations, and control parameters, the key generation module 1002 generates a key sequence through the same iteration of chaotic map as in encryption.
Alternatively, the key sequence may be obtained by the parameter obtaining module 1001 directly from the encryption unit of the server. In this case, the key generation module 1002 is not necessary.
Then, the plaintext generating module 1003 generates a plaintext of the file according to the ciphertext obtained from the storage space through an inverse operation of the encryption algorithm by using the key sequence.
The decryption unit may be provided in the terminal. In this case, the server transmits the ciphertext of the file to the terminal, where the ciphertext is decrypted.
In another embodiment, the encryption unit is provided as a unit of the server. In this case, the ciphertext is decrypted at the server and the plaintext of the file is then made available for access or transmitted to the terminal.
In the above example, the file is stored in the storage space in the form of ciphertext. However, in another embodiment, only some of the files are encrypted. That is, some files are stored after being encrypted, while other files are stored without being encrypted. In this case, an encryption flag may be added to the file. For example, after the file is encrypted, the encryption unit 120 adds a special flag to the end or the header of the file ciphertext. When the file is fetched, the decryption unit first checks whether the flag is present in the fetched file. If the flag is present, decryption is performed on the fetched file. Otherwise, it is judged that the file is not encrypted, and the decryption process is skipped. With this flag, the necessary decryption and thus the destruction of the file can be prevented.
In another embodiment, the encryption unit also adds the key sequence to a particular location of the file ciphertext. For example, the key sequence is added after the encryption flag, or inserted into a specific position of the ciphertext. When the file is decrypted, the parameter acquisition module of the decryption unit extracts the key sequence embedded in the ciphertext and provides the key sequence to the plaintext generation module.
In another embodiment, the system requests that a key sequence be entered, and the decryption unit does not perform decryption until the entered key sequence matches the key sequence embedded in the ciphertext.
Examples of using storage space are provided above. With this storage space, access to the file is effectively controlled. Accordingly, the files stored in the storage space are available to the authorized and verified accounts.
In another embodiment, a folder structure of the storage space may be specified. Fig. 11 schematically shows a configuration example of the storage space management unit according to the embodiment.
As shown in fig. 11, the storage space management unit 1100 includes a storage space setting module 1101 configured to set a folder structure in a storage space, in addition to the above-described authorization module 131, access control module 132, and authentication module 133.
The folder structure of the storage space may be set arbitrarily or according to a specified rule. For example, the folder structure is set according to different stages of the workflow. For example, for a project of designing a skyscraper, the storage space may have a root folder named "skyscraper", and three subfolders named "preliminary design", "summary design", "construction drawing design", respectively, may be created in the root folder. Further subfolders may be created in the root folder and any subfolders.
In this embodiment, the storage space setting module 1101 sets the folder structure of the storage space in a sense of receiving an instruction from an account to which the storage space is allocated. This provides a customized configuration of memory space.
In another embodiment, version management is provided. Fig. 12 schematically shows an example configuration of the storage space management unit according to the embodiment.
As shown in fig. 12, the storage space management unit 1200 includes a version management module 1201 configured to manage different versions of a file, in addition to the authorization module 131, the access control module 132, and the authentication module 133 described above. The version management module assigns a version number to each file stored in the storage space, and the file is stored with a file name incorporating the version number. For example, the version number is added as a suffix to the file name. When a file is to be changed or updated, a new version number is generated and incorporated into the filename of the updated file. Thus, an old version of a file is not overwritten by a new version of the file. In this way, a complete history of file versions is maintained, and older versions of files can be obtained.
Psa is initially stored, the version management module 1201 automatically generates an initial version number, e.g., V001. The file is then stored in the storage space with the file name abcv001. psd. Thereafter, if the file is edited or when the file is stored with a file name abc.psd or abcv001.psd, the version management module 1201 will generate a new version number, e.g. V002, and the edited file or the new file is stored with the file name abcv002.psd, while the old file abcv001.psd is kept unchanged in the storage space.
The new version may be generated when a file in the storage space is updated or the file is accessed. In the case where a new version is generated when a file is accessed, the file retrieved from storage will have a filename with the new version number. After the file is edited locally, the file can be stored in the storage space without changing the file name.
Typically, the version numbers are generated sequentially and are incremented in chronological order. For example, the version number may be a natural number that is said to be sequentially incremented, or a string that represents the date and time. Any other type of character, number, logo, or indicia may be used as the version number so long as the different versions are distinguished from each other.
The version number may be inserted in any position of the file name as long as the original file name and version number can be recognized.
Other methods of storing different versions of files may also be employed. For example, instead of using filenames of version numbers incorporated therein, in one embodiment, the version management module 1201 creates different folders to hold different versions of files. For example, in a folder for storing files, subfolder V001 is created for storing files of version V001, subfolder V002 is created for storing files of version V002, and so on. In this case, the file name may remain unchanged.
In another embodiment, the version management module 1201 associates all versions of a file and all versions of the file may be accessed at once when requested. This helps to view the history of the file. Version information of the file may be recorded in a database maintained by the version management module 1201.
Some specific embodiments have been described with reference to the accompanying drawings. However, the present invention is not limited to any specific configuration and process in the above-described embodiments. Those skilled in the art can conceive various substitutions, changes or modifications of the above-described configurations, algorithms, operations and processes within the spirit of the present invention.
The above examples embodying various aspects may be combined depending on the particular application. For example, the storage space management unit may include the functions of the storage space setting module shown in fig. 11 and the version management module shown in fig. 12.
The figure shows units and modules. However, the components included in each device are not limited to these units and modules, and the specific configuration may be modified or changed. For example, other known components may be added depending on the particular application. In addition, although the described units and modules are shown as separate blocks in the drawings, any of them may be combined with other units or modules as one component or divided into a plurality of components.
It should be noted that the term "file" used in the present specification should be understood as a broad concept. Which may include any kind of document, file, data or information including, but not limited to, text files, video/audio files, images/charts, etc., for example. Also, the term "terminal" used in the present specification should be understood as a broad concept. It may include any particular terminal, or group of machines, involved in the storage service, or a virtual terminal that functions as a software application.
Elements of the present invention may be implemented as hardware, software, firmware, or a combination thereof, and may be used in their systems, subsystems, components, or subcomponents. When implemented in software, the elements of the invention are the programs or code segments used to perform the required tasks. The program or code segments may be stored in a machine-readable medium or transmitted by a data signal carried in a carrier wave over a transmission medium or a communication link. A "machine-readable medium" may include any medium that can store or transfer information. Examples of a machine-readable medium include electronic circuits, semiconductor memory devices, ROM, flash memory, Erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, Radio Frequency (RF) links, and so forth. The code segments may be downloaded via computer networks such as the internet, intranet, etc.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. For example, the algorithms described in the specific embodiments can be modified as long as the characteristics do not depart from the essential spirit of the present invention. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
There is little distinction left between hardware and software implementations on the part of a system; the use of hardware or software is often (but not always, in some cases it may be important to choose between hardware and software) a design choice reflecting cost/efficiency tradeoffs. There are many means (e.g., hardware, software, and/or firmware) by which the methods and/or systems and/or other techniques described herein can be implemented, and the environments in which the methods and/or systems and/or other techniques reside may vary, as may the preferred means. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt to have hardware and/or firmware based tools; if adaptability is of paramount importance, the implementer may opt to execute in software as the master; the implementer may opt for some combination of hardware, software, and/or firmware.
The foregoing has described in detail through block diagrams, flowcharts, and/or examples that set forth various embodiments of the apparatus and/or methods of the present application. When the block diagrams, flowcharts, and/or embodiments include one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within the block diagrams, flowcharts, and/or embodiments can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, portions of the subject matter described in this specification can be implemented by Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), Digital Signal Processors (DSPs), or other integrated forms. However, those skilled in the art will recognize that some aspects of the embodiments described in this specification can be equivalently implemented in whole or in part in integrated circuits, in the form of one or more computer programs running on one or more computers (e.g., in the form of one or more computer programs running on one or more computer systems), in the form of one or more programs running on one or more processors (e.g., in the form of one or more programs running on one or more microprocessors), in the form of firmware, or in virtually any combination thereof, and, designing the circuitry for the present application and/or writing code for the software and/or firmware of the present application in accordance with the disclosure herein is well within the abilities of one of ordinary skill in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described in this specification are capable of being distributed as a program product in a variety of forms, regardless of the type of signal-bearing media used to actually carry out the distribution, and that an illustrative embodiment of the subject matter described in this specification applies. For example, the medium of the load signal includes, but is not limited to, the following: recordable type media such as floppy disks, hard disks, Compact Disks (CDs), Digital Video Disks (DVDs), digital tapes, computer memories, etc.; a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).
Those skilled in the art will recognize that it is common within the art to describe devices and/or methods in the manner described in this specification, and then to engineer them for incorporation into a data processing system. That is, at least a portion of the devices and/or methods described herein may be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system will typically include one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface and applications, one or more interaction means such as a touch pad or a touch screen, and/or a control system including a feedback loop and control motors (such as feedback to detect position and/or velocity; control motors to move and/or adjust components and/or quantities). A typical data processing system may be implemented using any suitable commercially available components such as those typically found in data computing/communication and/or network computing/communication systems.
The subject matter described in this specification sometimes illustrates different components that are included in or connected to different other components. It is to be understood that such depicted architectures are merely exemplary, and that in fact many other architectures can be used to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively "connected" to achieve the desired functionality. Hence, any two components herein combined to achieve a particular functionality can be seen as "connected" to each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so connected may also be viewed as being "operably connected," i.e., "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so connected may also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to: physically couplable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.
For nearly all terms of plural and/or singular terms used in this specification, those skilled in the art can interpret the plural as singular and/or the singular as plural as appropriate from a context and/or application. For the sake of clarity, various singular/plural permutations are expressly set forth in this specification.
It will be understood by those within the art that, in general, terms used in this application and, in particular, in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the word "including" should be interpreted as "including but not limited to," "having" should be interpreted as "having at least," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such introductory phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to applications containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" or "an" should typically be interpreted to mean "at least one" or "one or more"); the same holds true for the use of definite articles for introducing claims. Furthermore, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, typically means at least two recitations, i.e., two or more recitations). Further, where a convention analogous to "A, B and at least one of C, etc." is used, in general, this convention will be understood by those skilled in the art (e.g., "a system having at least one of A, B and C" will include but not be limited to systems having a only, B only, C only, a and B, a and C, B and C, and/or A, B and C). Where a habitual expression similar to "A, B or at least one of C, etc." is used, in general it is intended that the meaning will be understood by those skilled in the art in view of this conventional expression (e.g., "a system having at least one of A, B or C" would include, but not be limited to, a system having only a, a system having only B, a system having only C, a system having a and B, a system having a and C, a system having B and C, and/or a system having A, B and C, etc.). It will be further understood by those within the art that virtually any selected word and/or phrase capable of providing two or more options, whether in the specification, claims, or drawings, should be understood to contemplate all possibilities of including one of the options, either of the options, or both options. For example, the phrase "a or B" should be understood to include the possibility of "a" or "B" or "a and B".
Various aspects and embodiments of the present application are disclosed herein, and other aspects and embodiments of the present application will be apparent to those skilled in the art. The various aspects and embodiments disclosed in this application are presented by way of example only and not by way of limitation, and the true scope and spirit of the application is to be determined by reference to the appended claims.
Claims (24)
1. A storage system, comprising:
one or more storage spaces adapted to store files;
an encryption unit adapted to perform chaotic encryption on the file before the file is stored in the storage space; and
a storage space management unit adapted to control access to the one or more storage spaces based on a predetermined authorization.
2. The storage system according to claim 1, wherein the encryption unit includes:
a mapping setting module configured to set a chaotic mapping;
an initial parameter setting module configured to set an initial parameter of the chaotic map;
an encryption algorithm setting module configured to set an encryption algorithm;
a key generation module configured to generate a key sequence according to the chaotic map; and
and the ciphertext generating module is configured to generate a ciphertext of the file by using the key sequence and the encryption algorithm.
3. The memory system of claim 1, wherein the encryption unit is configured to perform chaotic encryption using a high-dimensional chaotic map.
4. The storage system of claim 1, wherein the encryption unit is configured to perform chaotic encryption by at least one of the following encryption algorithms:
exclusive or;
adding;
subtraction;
taking the inverse;
shifting; and
and (4) replacement.
5. The storage system of claim 1, wherein the encryption unit is configured to change an encryption algorithm to perform chaotic encryption.
6. The storage system according to claim 1, wherein the encryption unit is configured to perform chaotic encryption using at least one initial parameter containing information derived from a plaintext of a file.
7. The storage system according to claim 1, wherein the encryption unit is configured to add an encryption flag to the ciphertext.
8. The storage system according to claim 1, wherein the storage space management unit includes:
an authorization module configured to allocate the one or more memory spaces and authorize access to the one or more memory spaces;
a verification module configured to verify a request for access to a storage space; and
an access control module configured to control access to the one or more memory spaces based on a result of the verification and the authorization of the request.
9. The storage system according to claim 1, wherein the storage space management unit includes a storage space setting module configured to set a storage structure of a storage space according to a folder structure.
10. The storage system according to claim 1, wherein the storage space management unit includes a version management module configured to generate a new version of the file and maintain an original version of the file when the file is to be updated.
11. The storage system of claim 10, wherein the version management module is configured to incorporate the version number into a filename of the file.
12. The system according to claim 1, further comprising a decryption unit adapted to decrypt one or more encrypted files retrieved from the storage space.
13. A storage method, comprising:
allocating one or more storage spaces, each storage space being suitable for storing a file;
performing chaotic encryption on the file before the file is stored in the storage space; and
access to the one or more memory spaces is controlled based on a predetermined authorization.
14. The storage method of claim 1, wherein performing chaotic encryption comprises:
setting chaotic mapping;
setting initial parameters of the chaotic mapping;
setting an encryption algorithm;
generating a key sequence according to the chaotic mapping; and
and generating a ciphertext of the file by using the key sequence and the encryption algorithm.
15. The storage method of claim 1, wherein the chaotic encryption is performed using a high-dimensional chaotic map.
16. The storage method of claim 1, wherein the chaotic encryption is performed by at least one of the following encryption algorithms:
exclusive or;
adding;
subtraction;
taking the inverse;
shifting; and
and (4) replacement.
17. The storage method of claim 1, wherein the chaotic encryption is performed by changing an encryption algorithm.
18. The storage method according to claim 1, wherein the at least one initial parameter of the chaotic encryption contains information derived from the plaintext of the file.
19. The storage method of claim 1, further comprising adding an encryption flag to the ciphertext.
20. The storage method of claim 1, wherein controlling access comprises:
validating a request for access to a storage space; and
controlling access to the one or more memory spaces based on the authentication result and the authorization of the request.
21. The storage method according to claim 1, further comprising setting a storage structure of the storage space according to a folder structure.
22. The storage method according to claim 1, further comprising generating a new version of the file and maintaining the original version of the file when the file is to be updated.
23. The storage method of claim 10, further comprising incorporating the version number into a file name of the file.
24. The storage method of claim 1, further comprising decrypting the one or more encrypted files retrieved from the storage space.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810173048A CN101727407A (en) | 2008-10-29 | 2008-10-29 | Safe storage system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810173048A CN101727407A (en) | 2008-10-29 | 2008-10-29 | Safe storage system and method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101727407A true CN101727407A (en) | 2010-06-09 |
Family
ID=42448320
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200810173048A Pending CN101727407A (en) | 2008-10-29 | 2008-10-29 | Safe storage system and method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101727407A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104065669A (en) * | 2014-07-08 | 2014-09-24 | 浪潮(山东)电子信息有限公司 | Method for encrypting spatial network |
| CN105846989A (en) * | 2015-01-14 | 2016-08-10 | 深圳市伦琴科技有限公司 | Firmware dynamic encryption and decryption method based on fragment chaotic iteration |
| CN106921482A (en) * | 2017-02-17 | 2017-07-04 | 武汉斗鱼网络科技有限公司 | A kind of method and system that data encrypting and deciphering algorithm is constructed based on ARM instruction |
| CN107911393A (en) * | 2017-12-28 | 2018-04-13 | 北京明朝万达科技股份有限公司 | A kind of data safety management system and method |
| CN108270719A (en) * | 2016-12-30 | 2018-07-10 | 广东精点数据科技股份有限公司 | A kind of data safe transmission method and device based on digital signature |
| CN109861820A (en) * | 2019-02-18 | 2019-06-07 | 吉林大学珠海学院 | Encrypting and decrypting method and device based on random hash and bit arithmetic |
-
2008
- 2008-10-29 CN CN200810173048A patent/CN101727407A/en active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104065669A (en) * | 2014-07-08 | 2014-09-24 | 浪潮(山东)电子信息有限公司 | Method for encrypting spatial network |
| CN104065669B (en) * | 2014-07-08 | 2017-03-01 | 浪潮（苏州）金融技术服务有限公司 | A kind of spatial network encryption method |
| CN105846989A (en) * | 2015-01-14 | 2016-08-10 | 深圳市伦琴科技有限公司 | Firmware dynamic encryption and decryption method based on fragment chaotic iteration |
| CN108270719A (en) * | 2016-12-30 | 2018-07-10 | 广东精点数据科技股份有限公司 | A kind of data safe transmission method and device based on digital signature |
| CN106921482A (en) * | 2017-02-17 | 2017-07-04 | 武汉斗鱼网络科技有限公司 | A kind of method and system that data encrypting and deciphering algorithm is constructed based on ARM instruction |
| CN107911393A (en) * | 2017-12-28 | 2018-04-13 | 北京明朝万达科技股份有限公司 | A kind of data safety management system and method |
| CN109861820A (en) * | 2019-02-18 | 2019-06-07 | 吉林大学珠海学院 | Encrypting and decrypting method and device based on random hash and bit arithmetic |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10324892B2 (en) | Security via data concealment | |
| US10037330B1 (en) | Security via dynamic data movement in a cloud-based environment | |
| US20190303349A1 (en) | Security via data concealment | |
| US9112699B1 (en) | System, processing device, computer program and method, to tranparently encrypt and store data objects such that owners of the data object and permitted viewers are able to view decrypted data objects after entering user selected passwords | |
| US7320076B2 (en) | Method and apparatus for a transaction-based secure storage file system | |
| US7694147B2 (en) | Hashing method and system | |
| US10664439B2 (en) | Security via dynamic data movement in a cloud-based environment | |
| JP2004534333A (en) | Integrated protection method and system for distributed data processing in computer networks | |
| CN102013980A (en) | Random encryption method for decrypting by adopting exhaustion method | |
| CN110868291B (en) | Data encryption transmission method, device, system and storage medium | |
| US20100098246A1 (en) | Smart card based encryption key and password generation and management | |
| CN103946858A (en) | Decryption and encryption of application data | |
| WO2020123926A1 (en) | Decentralized computing systems and methods for performing actions using stored private data | |
| CN101727407A (en) | Safe storage system and method | |
| CN101833625A (en) | File and folder safety protection method based on dynamic password and system thereof | |
| WO2019083379A1 (en) | Data transmission | |
| CN107533613A (en) | Transplant document format file custom field | |
| JP2021507615A (en) | Homomorphic encryption for password authentication | |
| CN116866029B (en) | Random number encryption data transmission method, device, computer equipment and storage medium | |
| WO2020257183A1 (en) | Security via data concealment | |
| CN111008837B (en) | Block chain account private key recovery method and device, computer equipment and storage medium | |
| CN107070648A (en) | A kind of cryptographic key protection method and PKI system | |
| CN108540426A (en) | A kind of method, apparatus and server for realizing data processing | |
| JP5586758B1 (en) | Dynamic encryption key generation system | |
| EP3547197A1 (en) | Security via dynamic data movement in a cloud-based environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20100609 |