CN107948235A - Cloud data safety management and audit device based on JAR - Google Patents

Abstract

The invention discloses a JAR-based cloud data security management and auditing device, including: a cloud data management module, which is used to realize the data owner's reading, writing and updating of data, update the user list and log audit operations, wherein, in the future Before authorized users view plaintext data, detect and terminate malicious behaviors, and when someone accesses server-side data, trigger automatic logging through JAR access policies; the log security audit module is used to store logs on the CSP through the log format of Attestation , and ensure the security of the log through the overall structure of the chain log, so as to query the data access or query the specified file or user behavior through the access policy of the JAR. The device can provide an automatic and reliable logging mechanism through the access policy of JAR to ensure that data access will generate records and protect data from key abuse attacks, effectively realizing the authenticity and integrity of records and effectively improving data security .

Description

JAR-based cloud data security management and auditing device

technical field

The invention relates to the technical field of cloud storage and data security protection, in particular to a JAR (JavaArchive, Java archive file)-based cloud data security management and auditing device.

Background technique

With the development of cloud services, more and more users start to use cloud storage services. Simply put, cloud storage is an emerging solution that puts storage resources on the cloud for people to access. In terms of data access, the problem with existing cloud storage technologies is whether cloud storage can provide sufficient accessibility if large-scale data requests or data recovery operations are performed. In terms of data security, cloud storage servers have long been the target of hackers. CSP (Content Security Policy, Content Security Policy) has reported data loss and leakage accidents in recent years. Considering the poor reputation of CSP, cloud users worry about losing Unreliable control over its data, CSP and logging raises many issues in cloud storage. Most cloud service providers have prepared security protection solutions, but data security issues in cloud storage still exist objectively and must be resolved.

In related technologies, as a main method to deal with the problem of CSP, log records can track data usage, which is convenient for data security inspection. As a common logging type, logs are generated by CSPs with logging mechanisms and stored in the cloud. In an untrusted cloud, either a malicious user or a CSP has the ability to create false or broken logs, preventing evidence of leaked data. Therefore, how to build automatic and reliable logging in untrusted clouds faces serious challenges. In recent years, research on trusted cloud records in untrusted clouds has focused on the integrity protection of logs. Digital signatures and hash chain mechanisms have been introduced into reliable log record formats. The use of automatic record mechanisms can effectively ensure the integrity of logs. authenticity.

However, there are still some problems in the state-of-the-art automatic logging technology, such as the automatic logging mechanism is designed for distributed storage systems, and does not fully utilize the capabilities of CSP, causing a huge burden on the log communication and storage of data owners; For example, in order to protect user privacy in log content, the log encryption mechanism is inefficient in both space and time, and an untrusted CSP will cause the problem of key abuse attacks. It should be noted that by colluding with the CSP, malicious users can directly access the encrypted data stored on the CSP without generating any records, and use the leaked decryption key to decrypt the data, resulting in low data security and authenticity of the records. Sexuality and integrity are poor.

Contents of the invention

The present invention aims to solve one of the technical problems in the related art at least to a certain extent.

To this end, the object of the present invention is to propose a JAR-based cloud data security management and auditing device, which can ensure that data access will generate records and protect data from abuse of secret keys, effectively realizing the authenticity and integrity of records and effectively improve data security.

In order to achieve the above purpose, the embodiment of the present invention proposes a JAR-based cloud data security management and auditing device, including: a data management module, used to realize the data owner to read, write and update data, update the user list and log audit Operations, where malicious behavior is detected and terminated before unauthorized users view plaintext data, and automatic logging is triggered through JAR access policies when someone accesses server-side data; the log security audit module is used to pass the log format of Attestation The log is stored on the CSP, and the security of the log is guaranteed through the overall structure of the chain log, so as to query the data access or query the specified file or user behavior through the access policy of the JAR.

The JAR-based cloud data security management and auditing device in the embodiment of the present invention can realize functions such as JAR-based data access control, data operation-oriented log generation, log integrity maintenance, and log-based security auditing. Policies provide an automatic and reliable logging mechanism to ensure that data access will generate records and protect data from key abuse attacks, effectively realizing the authenticity and integrity of records and effectively improving data security.

In addition, the JAR-based cloud data security management and auditing device according to the above-mentioned embodiments of the present invention may also have the following additional technical features:

Further, in an embodiment of the present invention, the access policy of the JAR includes: the server side checks the request permission, generates a log in a preset format, and appends the log in a preset format to an existing log Finally, when all the content of the generated log in the preset format is correctly executed, the server generates a corresponding permission or denial message to ensure that all data modifications have log records.

Further, in one embodiment of the present invention, the log format of the Attestation is as follows:

Wherein, the log information is saved at the service provider in plain text, and the operation logs of different data are recorded in a common log file.

Further, in one embodiment of the present invention, the overall structure of the chain log is as follows:

ChainHash = hash(AttestBody, prevChainHash).

Furthermore, in one embodiment of the present invention, when the content of each Attestation changes, the entire log chain is broken, so as to locate malicious behaviors that threaten data security according to the broken location of the hash chain.

Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.

Description of drawings

The above and/or additional aspects and advantages of the present invention will become apparent and easy to understand from the following description of the embodiments in conjunction with the accompanying drawings, wherein:

Fig. 1 is a schematic structural diagram of a JAR-based cloud data security management and auditing device according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of the overall framework of cloud data management and automatic logging tools according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of JAR-based data access control according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of an automatic logging mechanism based on ServerJAR according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of an owner information update process according to an embodiment of the present invention;

FIG. 6 is a schematic diagram of a data access process of a Client according to an embodiment of the present invention;

FIG. 7 is a schematic diagram of an Owner's log query process according to an embodiment of the present invention.

Detailed ways

Embodiments of the present invention are described in detail below, examples of which are shown in the drawings, wherein the same or similar reference numerals designate the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the figures are exemplary and are intended to explain the present invention and should not be construed as limiting the present invention.

In order to achieve reliable cloud data management and automatic logging, it is first necessary to ensure that the network communication protocol and service deployment environment are relatively reliable. For this, the embodiment of the present invention uses SSL (Secure Socket Layer, secure socket layer protocol communication) and Amazon AWS EC2 (EC2, Elastic Compute Cloud, Amazon Elastic Compute Cloud) to deploy cloud service environment. Therefore, before introducing the JAR-based cloud data security management and auditing device, first introduce SSL and AmazonAWS EC2.

Among them, the SSL protocol was developed by Netscape to ensure the security of data transmission on the Internet, and the use of data encryption technology can ensure that data will not be intercepted and eavesdropped during transmission on the network. The SSL protocol is located between the TCP (Transmission Control Protocol, Transmission Control Protocol)/IP (Internet Protocol, a protocol for interconnection between networks) protocol and various application layer protocols, providing security support for data communication. There are many advantages of using SSL protocol for network communication: (1) Provide higher security guarantee. SSL uses data encryption, identity verification and message integrity verification mechanisms to ensure the security of data transmission on the network. (2) Support various application layer protocols. Although the original intention of SSL design is to solve the security problem of the World Wide Web, since SSL is located between the application layer and the transport layer, it can provide security guarantee for any application layer protocol based on reliable connection such as TCP. (3) Deployment is simple. At present, SSL has become a global standard for identifying the identity of websites and web browsers in the network, and encrypting communication between browser users and Web (World Wide Web, global wide area network or World Wide Web) servers.

In addition, AWS EC2 is a system that allows users to rent cloud computers to run required applications. The simple web service interface on AWS EC2 allows users to easily obtain and configure resources. AWS EC2 has the following advantages: (1) Complete control. Users have full control over their instances, have administrator or root access to each instance, and can interact with them like any other machine. The user can save the data in the boot partition while stopping the running instance, and then restart it with a Web service API (Application Programming Interface, application programming interface). It is also possible to restart the instance remotely using the web service API, and also have access to the instance's console output. (2) Reliable operation. Amazon EC2 provides a very reliable environment in which replacement instances can be launched quickly and predictably. The service runs on Amazon's proven network infrastructure and data centers. (3) Safety. Amazon EC2 works with Virtual Private Cloud (VPC) to provide secure and powerful networking functions for users' computing resources. The user's computing instance is located in the Amazon VPC, which has a user-specified IP range. Users can decide which instances are exposed to the Internet and which instances remain private. Security groups and network ACLs (Access Control List, Access Control List) allow users to control inbound and outbound network access to and from their instances. (4) Good scalability. Amazon EC2 can work with Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDS), and Amazon Simple Queue Service (Amazon SQS) to provide a complete computing, query processing, and storage solution for a variety of applications.

The following describes the JAR-based cloud data security management and auditing device according to the embodiments of the present invention with reference to the accompanying drawings.

FIG. 1 is a schematic structural diagram of a JAR-based cloud data security management and auditing device according to an embodiment of the present invention.

As shown in FIG. 1 , the JAR-based cloud data security management and auditing device 10 includes: a cloud data management module 100 and a log security auditing module 200 .

Among them, the cloud data management module 100 is used to implement the data owner to read, write and update data, update the user list and log audit operations, wherein, before unauthorized users view plaintext data, malicious behaviors are detected and terminated, and when someone accesses Automatic logging is triggered by the JAR's access policy when server-side data is accessed. The log security audit module 200 is used to store the log on the CSP through the log format of Attestation, and ensure the security of the log through the overall structure of the chain log, so as to query the data access through the JAR access policy or to specify the file or user Behavior query. The device 10 can provide an automatic and reliable log recording mechanism through the access policy of the JAR to ensure that data access will generate records and protect the data from secret key abuse attacks, effectively realizing the authenticity and integrity of the records, and effectively improving the security of the data .

It can be understood that the device 10 in the embodiment of the present invention can use a programmable Java JAR file coupled with data to encapsulate the access policy, so as to ensure that data access through the JAR will trigger authentication and automatic logging of the local JAR, and achieve cloud Effective management of data. At the same time, a reliable log format called "Attestation" is designed in the log-based security audit tool to make cloud storage more reliable.

Specifically, the device 10 of the embodiment of the present invention is based on a programmable Java JAR, and a cloud data security management and audit tool for a data sharing environment is designed. The device 10 is divided into two modules: a cloud data management module 100 and a log security audit module 200 . Among them, in the cloud data management module 100, the embodiment of the present invention defines users as three different identities: data owner (Owner), service provider (CSP), and sharing user (User). The cloud data management module 100 can implement the owner to read, write and update data, update the user list and log audit operations. At the same time, legitimate users have read access to data, can apply for access to a file or a part of a file, and can also update their identity to assist in secure data access.

That is to say, as shown in FIG. 2, the cloud data management module 100 is supported by an automatic and reliable logging mechanism, and can use a programmable Java JAR file coupled with data to encapsulate the access policy, ensuring that data access through the JAR will trigger local Authentication and automatic logging of JARs. In the embodiment of the present invention, users in the data sharing environment are defined as three different identities, namely data owner (Owner), service provider (CSP) and shared user (User), and according to user identities, behaviors of different identities are analyzed. definition. The embodiment of the present invention uses the SSL protocol for data communication, because SSL can guarantee the security and integrity of data transmission. Three different identities, namely data owner (Owner), service provider (CSP) and shared user (User), are described in detail below.

First, as shown in Figure 3, the data owner: the owner side consists of an owner.jar and a resource resource file. Owner encrypts data and generates JAR for data access and management. Owner-side functions include: updating data files, updating user access control lists, auditing server data, and obtaining server activity data. The Owner has write permission to the data and can update the information stored in the cloud. The information updated by the Owner can be further divided into two categories: the data block stored on the server side and the user list in the Server JAR. The update process of the two types of information is the same, and the difference only exists in the process of the owner generating a new version of information, and the update process of the server after receiving the new version of information.

Secondly, as shown in Figure 3, the shared user: the client consists of a client_10.jar and resource file. The client uses the JAR corresponding to its own role to access data, but cannot obtain full permissions to the data. Client functions include: requesting data and updating versions. The deployment of the Client JAR is mainly completed by public network transmission. You can use the method of writing the data decryption key (asymmetric encryption) in the Client JAR code, and use Java's own protection mechanism for the code instead of passing the asymmetric encryption key through symmetric encryption. The method of using a key achieves data encryption performance similar to the combination of previous symmetric-asymmetric encryption. A legitimate client has the right to read the data. In the data request module, the client sends a request to the server, and after being authenticated by the server, the client can obtain the data file uploaded by the file owner on the server. Clients can request access to a file or part of a file, and can update their identity to assist in secure data access. Whenever the file owner updates the version of the JAR, customers can update their own JAR files by updating the version module. After being authenticated by the server, the new HashID of the client can be obtained.

Finally, as shown in Figure 3, service provider: the functional program on the server side is server.jar, which provides a cloud environment for data storage, and manages the access and update of data through the JAR corresponding to its own role. Record log information. The service functions for the client include: sending data service and updating client service. The service functions on the data owner side include: file data update service, user access control list update service, statistical user activity service and statistical server activity service. The device 10 of the embodiment of the present invention deploys the server on Amazon AWS EC2 (Amazon Elastic Computing Cloud).

Further, in order to solve the problem that CSP colludes with malicious users and skips the Server JAR and directly sends data to unauthorized users, the embodiment of the present invention proposes a request permission checking process, which detects and terminates the data before the unauthorized users can actually view the plaintext data. malicious behavior. At the same time, in order to ensure that when the user accesses the data on the server side, automatic recording is inevitably triggered and automatic log recording is realized, the embodiment of the present invention designs a JAR-based access strategy. In addition, in the log security audit module 200, the embodiment of the present invention designs a reliable log format called "Attestation", which can directly store a large number of logs on the CSP without encryption. At the same time, the embodiment of the present invention designs and implements a chained overall log structure to ensure the security of the log. The log security audit module 200 is based on the access policy encapsulated by JAR, and can realize two kinds of log query functions, namely data access query function and specified file or user behavior query function.

Further, in one embodiment of the present invention, the JAR access strategy includes: the server side checks the request authority, generates a log in a preset format, and appends the log in a preset format to the existing log, so as to After all the contents of the generated log in the preset format are correctly executed, the server generates a corresponding permission or denial message to ensure that all data modifications have log records.

That is to say, the server executes the request permission checking process, and at the same time generates a log with a fixed format, which is appended to the existing log. The server can generate the corresponding permission or denial message only after all the contents of the generated log are executed correctly, which ensures that all data modifications have log records for review.

Specifically, as shown in FIG. 4 , the automatic log recording mechanism of the embodiment of the present invention needs to go through the process of request permission check, and encapsulate the access policy through JAR. When the user accesses the data on the server side, automatic recording will inevitably be triggered. The access strategy in ServerJAR mainly consists of the following steps: accept request, check permissions, get data, generate logs, return permission and data or denial.

First, the owner or client sends a request for data access or log audit request. Second, the server receives the request and wakes up for authentication, and the server authorizes by checking whether the user hashID is before the expiration date and whether the user is in the shared user list. Finally, when the Server JAR reads the request and identifies the authorized user, it triggers automatic logging, generates an Attestation related to this "request-permission", and after passing the verification, generates a permission message and sends it to the requesting end before continuing the data Access or log audit operations. Additionally, if a user or CSP attempts to violate the protocol by circumventing the JAR, data access will fail. If the access user does not have permission, a denial message will be sent to the requester after the log is generated.

Optionally, in one embodiment of the present invention, the log format of Attestation is as follows:

Wherein, the log information is saved at the service provider in plain text, and the operation logs of different data are recorded in a common log file.

That is to say, the log information is saved at the service provider in plain text, and the operation logs of different data are recorded in a common log file. The generation of log information is closely related to the interaction mechanism to ensure that the log mechanism can accurately record the data operation behavior within the entire data security framework.

Specifically, the embodiment of the present invention designs a reliable log format called "Attestation", which can directly store a large number of logs on the CSP without encryption. The plaintext authentication format reduces storage costs, and the flexible generation and authorization process helps to access data quickly. At the same time, the embodiment of the present invention designs and implements an overall chain log structure based on hash chains to ensure log security. sex and integrity. The log security audit module 200 is based on the access policy encapsulated by JAR, and can realize two kinds of log query functions, namely data access query function and specified file or user behavior query function.

Among them, the generation of logs is based on the "request-permission" mechanism of data access control. The log data format named "Attestation" is as follows:

It should be noted that in the Attestation structure, the "ACT" field is used to record the behavior type, and "blockHash" is the hash value of the data block involved in this operation, which can match the log with the current data. "UserInfo&DataInfo" is used to specify the object of the behavior, and the field content can be the data file name, data block name, or user name according to the different behavior types. "User HashID" indicates the source of the behavior, that is, the requester of the data operation. The three fields of ACT, blockHash, UserInfo&DataInfo come from the body of the request information, which are the same as the corresponding request information. "Time of Access" is the service provider system time when the log information is generated. "ChainHash" is a field designed to ensure the safety and reliability of log data. "Signature" is the digital signature of the service provider that generated this log record. When CSP stores log records, "#" is used as a separator between fields.

Among them, the log information is saved at the service provider in plain text, mainly because the structure of Attestation itself ensures its own robustness. Secondly, the log is mainly used to record data security events in the framework. Since the sensitive information in the log, such as user identity information and data information, is represented by a hash value, the leakage of the log information itself does not cause data security problems. Finally, the ciphertext search technology under the current technology has high requirements on computing resources. For scenarios that may require frequent log queries, plaintext representation has better usability. In addition, the operation logs of different data are recorded in a common log file. This is mainly due to the following two considerations: first, public log storage can reduce the computing resource requirements brought by file reading during log query; second, a large number of Attestation will form a longer hash chain, which makes It becomes difficult for malicious users or service providers to hide malicious behavior by modifying logs. The log information is closely related to the data operation request, not to the specific data operation behavior, so that the illegal data operation intention can still be completely recorded by the log mechanism, which also allows the data owner to find potential malicious users and users through the log. malicious behavior.

Optionally, the overall structure of the chained log is as follows:

ChainHash = hash(AttestBody, prevChainHash).

Among them, in the log recording tool, the integrity and tamper-proof of log information is the key to ensure that the log can accurately describe data security events and achieve the purpose of maintaining data security. The embodiment of the present invention designs and implements a chained overall log structure to ensure log security. In Attestation, a ChainHash field is designed to maintain the overall security of the log. ChainHash uses the ACT, UserID, BlockID, Nonce, and Time fields of the log information body and the ChainHash field in the previous Attestation to add and perform a hash transformation to obtain the ChainHash value of this log record. The latest ChainHash will be kept in the Server JAR as a parameter to calculate the chainHash value of the next attestation. It is finally signed by the Server JAR, and then the chainHash is appended to the end of the existing attestation under the Server JAR run directory. in,

ChainHash = hash(AttestBody, prevChainHash).

Optionally, in an embodiment of the present invention, when the content of each Attestation is changed, the entire log chain is broken, so as to locate the malicious behavior that threatens data security according to the broken position of the hash chain.

In other words, this kind of log chain structure closely related to the context will cause the entire log chain to break when the content of each Attestation changes. However, the embodiment of the present invention can locate malicious behaviors that threaten data security according to the location where the hash chain is broken.

Specifically, in the log-based security audit, two log query functions are designed and implemented on the data management platform, namely, data access query function and specified file or user behavior query function. These two functions correspond to the module of obtaining server activity data and auditing server data on the owner side respectively. The file owner can obtain the latest activity data on the server by obtaining the server activity data module, including the number and time of customer request data on the server, the user and time of the last request, and the number and time of illegal requests. The result of a data access query is a data security brief. The data owner can request the server to send a data security briefing. Through the data security briefing, he can have an intuitive understanding of the data security situation and decide whether it is necessary to conduct detailed inquiries on data security events. When the data owner believes that the data security is threatened, or needs to view the complete operation log of the data for other reasons, it is necessary to request the service provider to query the log according to the interaction mechanism. This is the audit server data module on the owner side. The file owner can audit the activity information of specific files and specific users on the server.

It should be noted that the embodiment of the present invention uses a file storage method to store data, log information, and related information for log query and log integrity maintenance, and the information is stored in the resource folder of the server. Create a folder with the same name for each data in the resource folder. For example, the data content and related information of the data file myFile are stored in the myFile folder.

Among them, the blocks folder stores all encrypted data blocks of the file. The userkey folder is used to store the user's public-key. Used to verify user identity on the server side. attest.txt is used to store data operation logs related to the current data. last_chain.txt is used to store the ChainHash in the latest attestation information, and is used to generate the ChainHash in the next attestation information without reading the relatively large attest.txt file again. myFile.txt is used to store the data block information of the myFile file response. permission.txt is used to store the response information of the CSP to the data access request, because the response information contains the body of the request information, so there is no need to additionally save the request information. query.txt is used to store the result of the query log requested by the data owner.

In addition, the communication scheme adopted by the device 10 of the embodiment of the present invention includes: (1) The sendMessage() method of the Owner, through WritableByteChannel, each time sending no more than 1024 bytes until the end of the content. (2) The ReceivePermissionMessage() of the Owner reads a maximum of 1024 bytes from the cache each time through the ReadableByteChannel. The former is used to receive the permission sent by the client, stop when it reads "end", and returns the permission string. (3) The receiveFile() method is used to receive the query result file sent by the owner, delete the FILE, FILE-END identifiers, and return the file content in the form of a string. (4) The sendFile() and sendMessage() methods of Server send no more than 1024 bytes each time through WritableByteChannel until the content ends. (5) The receiveFiles() and receiveMessage() methods of the Server read a maximum of 1024 bytes from the cache each time through the ReadableByteChannel until the end of the content, and return the received data in the form of a string. (6) The sendMessage() method of Client sends no more than 1024 bytes each time through WritableByteChannel until the content ends. (7) The receiveServerData() method of the Client reads up to 1024 bytes from the cache each time through the ReadableByteChannel, stops when the "end" identifier is received, and returns the received permission and data in a string of a specific format, or denial .

In addition, in a specific embodiment of the present invention, the specific implementation steps of data management include:

(1) As shown in Figure 5, the Owner information update process includes:

①Initialization. Load the certificate, create and initialize the SSLContext instance, and establish the connection between the owner and the server.

② Send request. The Owner actively sends a request message to the server through the SendMessage() method. The fixed format of Request is: ACT#ownerID#dataID#nonce#signature, where "#" is a delimiter, which divides the request into 5 fields. If a request is made to update a data block, the value of the ACT field is UPDATE, and the value of the dataID field is filename_blockID; if a request is made to update the user list, the value of the ACT field is ACL, and the value of the dataID field is filename_user_version, where "_" is a separator within a field of the request symbol. The nonce is a 6-digit random number, and the signature is the signature of the owner.

③ Reply to the request. The server receives the request through the receiveMessage() method and enters the attest_and_permit stage, namely: verify the legitimacy of the request, generate attestation and permission for the legal request, add the attestation to the relevant chain, record the permission to the server locally, and then pass The sendMessage() method replies the permission to the owner, sends the "end" flag, and the permission content ends. The format of permission is PERMIT_ACT#ownerID#blockID#nonce#signature, where "#" is a delimiter. The values of ACT, ownerID, blockID and nonce are the same as those of request, and signature is the signature of CSP.

④ Receive permission. The Owner receives the permission sent back by the server through the ReceivePermissionMessage() method, and the internal program verifies whether the permission signature is correct.

⑤Upload update. If the owner's internal program confirms that the permission signature is correct, then the content of this update will be presented in the form of a file. At this point, the upload button on the owner interface is activated, click it to upload the updated content through the SendMessage() method.

⑥Update JAR. After verification, the server receives the update content and signature uploaded by the owner through the receiveFiles() and receiveMessage() methods respectively. The server verifies the message signature, and if it is correct, updates the corresponding information. The whole process of the Owner updating the information ends.

(2) As shown in Figure 6, the data access process of Client includes:

①Initialization. Load the certificate, create and initialize the SSLContext instance, and establish the connection between the client and the server.

② Send request. The client sends the request field to the server through the sendMessage() method. The fixed format of the request is: ACT#clientID_version#blockID#nonce#signature. Among them, "#" is the delimiter between the request fields; "_" is the delimiter inside the user identity field, indicating that the user's identity is identified by both clientID and version. If requesting data access, the value of the ACT field is READ, the clientID uses a secure hashID, and version is the version number of the current hashID; if requesting identity update, the value of the ACT field is VERSION, the clientID uses a specific userID, and the version is still the current version number of the user. The version number of the hashID. The nonce is a 6-digit random number, and the signature is the signature of the client.

③ Verify the request. The server receives the request through the receiveMessage() method, extracts the user identity, and checks whether the signature of the request is correct. For data access requests, it is also necessary to check whether the request comes from a legitimate user.

④ Respond to the request. If the signature is correct and the user subject in the data access request is a legal user, the server program generates attestation and permission, adds the attestation to the relevant chain, records the permission locally on the server, and then replies the permission to the client through the sendMessage() method , followed by sending the requested data. If the server program identifies that the client is not a valid user, the server generates denial information, which will be stored and sent to the client through sendMessage(), and the sent information ends with "end".

⑤ Receive reply. The client receives the permission and data sent back by the server through the receiveServerData() method, or receives the denial, and the internal program continues to process it.

(3) As shown in Figure 7, the owner's log query process includes:

①Initialization. Load the certificate, create and initialize the SSLContext instance, and establish the connection between the owner and the server.

② Send request. The Owner actively sends the request field to the server through the SendMessage() method. The fixed format of the request is ACT#ownerID#target#nonce#signature, and "#" is the separator between fields. If it is a data access query, the value of ACT is ACCESS, and the value of target is filename; if it is a specified file or user behavior query, the value of ACT is QUERY, the value of target is userInfo&dataInfo, and "&" is the connector inside the target field.

③ Reply to the request. The server receives the request through the receiveMessage() method, and executes the corresponding program according to the content of the request, namely: verify the legitimacy of the request, generate attestation and permission for the legal request, add the attestation to the relevant chain, and record the permission to the server locally , and then reply the permission to the owner through the sendMessage() method, and send "end" to mark the end of the permission content.

④ Reply to inquiries. The JAR program of the Server also executes the query process and temporarily stores the query results in a local file. Subsequently, the server sends the query result through the sendMessage() method, and the format is "FILE" + query result file content + "FILE-END".

⑤ Receive permission. The Owner receives the permission sent back by the server through the ReceivePermissionMessage() method, and then continues to receive the query results from the communication link through the receiveFile() method, and stops after receiving "FILE-END". The internal program then verifies that the signature of the permission and query result is correct. If it is correct, the view button on the owner interface is activated, and you can click to get readable query results. The entire process of owner querying access logs ends.

Further, in another specific embodiment of the present invention, the steps of implementing JAR-based cloud data security management and auditing include:

(1) Owner's data block update. Since the data is stored in blocks on the server side, when the data is modified in a small range, the owner can only upload the affected data blocks. The Owner records the number of the data block that needs to be rewritten in the request. During the upload and update process, the modified plaintext data is encrypted by AES (Advanced Encryption Standard, Advanced Encryption Standard) on the owner side and then sent to the server. When the server updates a data block, it will replace the original data with a new encrypted data block. In addition, for each new block, the server program will also update the block Hash information in the ServerJAR.

(2) The Owner's user list is updated. The Owner authorizes new users or revokes the access rights of existing users by updating the user list. The first line of the user list is a summary of the sharing group information, including the version number, total number of users, and number of legitimate users. From the second row onwards, the records in each row represent the permissions of users whose userID is the row number minus 2. For example, the records in the second row represent the permissions of users whose userID is 0. If it is a legitimate user, the value of this record is the hashID of the user, and if it is an illegal user, the value of this record is REVOKED. During the upload update process, the new user list is sent to the server, and the server replaces the user list record in the server JAR with the new user list content.

(3) The server's attest_and_permit module can only generate the corresponding permission when all the content of makeAttest() is executed correctly for legal data upload or download requests, which ensures that all data modifications have log records for reference. In the makeAttest() method,

i. The program first extracts ACT, data information and request body from the request;

ii. Then calculate the hash of the corresponding data through the data information, which is recorded as blockHash;

iii. Add time, calculate chainHash and signature, and generate an attestation in a fixed format;

iv. Finally, the attestation is stored locally, appended to the existing log.

(4) Server user identity authentication. After the server authenticates the user's identity, it sends back a permission or denial message to the user. In the message structure of permission and denial, "#" is the separator between fields; "_" is the separator inside the user identity field, and the characters connected before and after it together form a complete permission or denial field. The user identity, data, and nonce fields of Permission and denial are consistent with the request.

If the request is data access, the permission format is:

PERMIT_READ#hashID_version#blockID#nonce#signature.

If the request is an identity update, the permission format is:

PERMIT_VERSION#userID_version#blockID#nonce#signature.

If the user subject in the data access request is not a valid user, the server generates denial information. If the user principal in the request provides the latest hashID and the identity does not exist in the user list, the format of the denial information is:

REF_READ#FORBIDDEN_hashID_userVer#dataIndex#nonce#signature.

If the user principal in the request uses an outdated hashID, the format of the denial information is:

REF_READ#OBSOLETE_hashID_userVer#dataIndex#nonce#signature.

(5) During the data access of the Client, during the process of receiving the reply, the data following the permission is the encrypted data blocks specified in the request. The client program will use the key information in the program to decrypt and display the decrypted data block to the user. If the denial information with the OBSOLETE field is received, the program will prompt the user to request an identity update from the server; if the denial information with the FORBIDDEN field is received, the program will prompt that there is no access right, and then exit automatically.

(6) Client's identity update. In the process of receiving the reply, the data immediately following the permission is the latest hashID encrypted with the public key corresponding to the userID in the request, and the client JAR uses the user's private key to decrypt the message, and the format is: userID#version#hashID,"#" is the separator between fields. The program verifies whether the decrypted userID is consistent with the userID in the client JAR. After passing the verification, the program replaces the local userID file with the received reply message.

(7) Query data access. In the corresponding request, the value of ACT is ACCESS. The server program extracts the target file name from the request, and then queries the attestation and denial records corresponding to the file. In the attestation, the record with the ACT value of "READ" is a successful data access, and the summary of the unallowed data access request is stored in the denial. The statistical content of the server includes: the number of times the file is accessed, the total number of users accessing the file, the last visitor, the last access time, the number of times the file was denied access, and the time when the last access was denied. The statistical content is stored in the accessReport file in plain text and sent to the owner. Through the above content, the data owner can grasp the legal and illegal use of data within a period of time.

(8) Query the specified file or user behavior. In the corresponding request, the value of ACT is QUERY. The server program extracts the target file name and target user name in the request, retrieves all related records in the attestation, and then generates the attest file and sends it to the owner. The Owner's program translates this file into a format that is easy to read, including: deleting verification information such as signatures, and converting the user's hashID to userID.

According to the JAR-based cloud data security management and auditing device proposed in the embodiment of the present invention, functions such as JAR-based data access control, data operation-oriented log generation, log integrity maintenance, and log-based security auditing can be realized. The access policy provides an automatic and reliable logging mechanism to ensure that data access will generate records and protect data from key abuse attacks, effectively realizing the authenticity and integrity of records and effectively improving data security.

In describing the present invention, it should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", " Back", "Left", "Right", "Vertical", "Horizontal", "Top", "Bottom", "Inner", "Outer", "Clockwise", "Counterclockwise", "Axial", The orientation or positional relationship indicated by "radial", "circumferential", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying the referred device or element Must be in a particular orientation, be constructed in a particular orientation, and operate in a particular orientation, and therefore should not be construed as limiting the invention.

In addition, the terms "first" and "second" are used for descriptive purposes only, and cannot be interpreted as indicating or implying relative importance or implicitly specifying the quantity of indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include at least one of these features. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

In the present invention, unless otherwise clearly specified and limited, terms such as "installation", "connection", "connection" and "fixation" should be understood in a broad sense, for example, it can be a fixed connection or a detachable connection , or integrated; it may be mechanically connected or electrically connected; it may be directly connected or indirectly connected through an intermediary, and it may be the internal communication of two components or the interaction relationship between two components, unless otherwise specified limit. Those of ordinary skill in the art can understand the specific meanings of the above terms in the present invention according to specific situations.

In the present invention, unless otherwise clearly specified and limited, the first feature may be in direct contact with the first feature or the first and second feature may be in direct contact with the second feature through an intermediary. touch. Moreover, "above", "above" and "above" the first feature on the second feature may mean that the first feature is directly above or obliquely above the second feature, or simply means that the first feature is higher in level than the second feature. "Below", "beneath" and "beneath" the first feature may mean that the first feature is directly below or obliquely below the second feature, or simply means that the first feature is less horizontally than the second feature.

In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structure, material or characteristic is included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other.

Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention, those skilled in the art can make the above-mentioned The embodiments are subject to changes, modifications, substitutions and variations.

Claims (5)

1. A cloud data security management and audit device based on JAR is characterized by comprising the following components:

the cloud data management module is used for reading, writing and updating data by a data owner, updating a user list and performing log audit operation, wherein malicious behaviors are detected and terminated before an unauthorized user views plaintext data, and when someone accesses the data of the server, automatic log recording is triggered through an access strategy of JAR;

and the log security audit module is used for storing the log on the CSP through the log format of the Attestation, and ensuring the security of the log through the whole structure of the chain log so as to inquire data access or inquire an appointed file or user behavior through the access strategy of the JAR.

2. The JAR-based cloud data security management and auditing apparatus according to claim 1, where the JAR's access policy includes: the server side checks the request authority, generates a log in a preset format, and after the log in the preset format is added to the existing log, the server generates a corresponding permission or alias message after the complete execution of all the contents of the generated log in the preset format is completed, so as to ensure that all data modification has log records.

3. The JAR-based cloud data security management and auditing apparatus according to claim 1, where the Attestation's log format is as follows:

wherein the log information is kept in plain text at the service provider and the operation logs of the different data are recorded in a common log file.

4. The JAR-based cloud data security management and auditing apparatus according to claim 1, where the chain-like log overall structure is as follows:

ChainHash＝hash(AttestBody,prevChainHash)。

5. the JAR-based cloud data security management and auditing apparatus according to claim 4 where each Attestation content changes, causing the entire log chain to break, thereby locating malicious behavior that threatens data security based on the location of the hash chain break.