WO2016112799A1 - 一种文件处理方法和装置 - Google Patents

一种文件处理方法和装置 Download PDF

Info

Publication number
WO2016112799A1
WO2016112799A1 PCT/CN2016/070169 CN2016070169W WO2016112799A1 WO 2016112799 A1 WO2016112799 A1 WO 2016112799A1 CN 2016070169 W CN2016070169 W CN 2016070169W WO 2016112799 A1 WO2016112799 A1 WO 2016112799A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
application
encryption
temporary
information
Prior art date
Application number
PCT/CN2016/070169
Other languages
English (en)
French (fr)
Inventor
黄小林
Original Assignee
阿里巴巴集团控股有限公司
黄小林
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司, 黄小林 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2016112799A1 publication Critical patent/WO2016112799A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the present application relates to the field of data processing technologies, and in particular, to a file processing method and a file processing apparatus.
  • Android Android
  • Android is increasingly connected to personal privacy and business activities, but they also bring data security and privacy protection issues.
  • the data of the Android system is divided into the data in the internal SQLite database and the data of the external storage card.
  • the data of the external memory card is mainly stored in the form of a file on a Secure Digital Memory Card (SD).
  • SD Secure Digital Memory Card
  • the Android system has too much granular access to the file in the SD card. Only the access control and the access control cannot be accessed.
  • An application can read and tamper with most of the files in the SD card as long as it has applied for access to the SD card. In short, an application can freely read and tamper with files saved by another application on the SD card.
  • applications such as App A, App B, and App C respectively generate their own files File A, File B, and File C, and File A, File B, and File C are stored in the SD card.
  • Malicious programs can access and tamper with these files as long as they have applied for access to the SD card, which can easily lead to the leakage of private data such as photos and notepads.
  • the technical problem to be solved by the embodiments of the present application is to provide a file processing method, which can improve the security of a file stored in a memory card.
  • the embodiment of the present application further provides a file processing apparatus for ensuring the foregoing method. Implementation and application.
  • a file processing method including:
  • the method further includes:
  • the method further includes:
  • the encryption request further includes the rights verification information of the first application, where the rights verification information is an encryption permission that the first application applies to the encryption authority auditing platform to encrypt the first file.
  • the information returned by the encryption authority auditing platform and approved by the encryption authority is returned;
  • the verifying whether the first application has an encryption right for encrypting the first file includes:
  • processing the first file and/or the temporary file including:
  • the operation of the temporary file by the first application is a read operation, then in the first application After reading the temporary file, deleting the temporary file;
  • the application also provides a file processing apparatus, including:
  • the first request receiving unit is configured to receive an access request of the first application to the first file, where the access request includes decryption information for decrypting the first file;
  • a decryption unit configured to decrypt the first file according to the decryption information
  • a file generating unit configured to create a temporary file of the first file according to the decrypted first file
  • a file output unit configured to output a temporary file of the first file
  • the file processing unit is configured to process the first file and/or the temporary file according to the operation of the temporary file by the first application.
  • the device further includes:
  • the second request receiving unit is configured to receive an encryption request of the first application for the first file, the encryption request, before the first request receiving unit receives an access request of the first application to the first file Included in the encrypted information for encrypting the first file;
  • the device further includes:
  • a rights verification unit configured to verify, before the encryption unit encrypts the first file according to the encryption information, whether the first application has an encryption authority for encrypting the first file
  • the encryption unit is configured to, when the rights verification unit verifies that the first application has an encryption authority for encrypting the first file, encrypt the first file according to the encryption information.
  • the encryption request further includes the rights verification information of the first application, where the rights verification information is an encryption permission that the first application applies to the encryption authority auditing platform to encrypt the first file.
  • the information returned by the encryption authority auditing platform and approved by the encryption authority is returned;
  • the authority verification unit is configured to verify, according to the rights verification information, whether the first application has an encryption right to encrypt the first file.
  • the file processing unit is configured to, when the operation of the temporary file by the first application is a read operation, delete the temporary file after the first application reads the temporary file; When the operation of the temporary file by the first application is a content update operation, the updated temporary file is encrypted and the first file is replaced.
  • the embodiments of the present application include the following advantages:
  • the embodiment of the present application protects the running file of the application, so that when the application accesses the file, only the corresponding application, that is, the "host" application of the file can decrypt the file, and the plaintext of the file can be accessed.
  • the content thereby reducing the data security problem and privacy leakage caused by the malicious program in the prior art by scanning the file in the memory card to obtain the file content, the method improves the security of the file stored in the memory card.
  • FIG. 1 is a flow chart showing the steps of an embodiment of a file processing method of the present application
  • FIG. 2 is a flow chart showing the steps of another embodiment of the file processing method of the present application.
  • FIG. 4 is a structural block diagram of another embodiment of a file processing apparatus of the present application.
  • FIG. 1 a flow chart of steps of an embodiment of a file processing method of the present application is shown, which may specifically include the following steps:
  • Step 101 Receive an access request of the first application to the first file, where the access request includes decryption information for decrypting the first file.
  • the file processing device may be an operating system itself or a device disposed in an operating system, and the operating system may be an Android system.
  • the file processing device has a function of implementing file encryption protection, for example, the storage file in the SD card can be encrypted and protected.
  • This function can be implemented by opening an API (Application Programming Interface) for implementing file encryption and decryption in the application layer of the operating system.
  • the developer of the application can implement the application running by calling the API.
  • the file is encrypted and decrypted.
  • the API can be specifically implemented by modifying the source code of the operating system.
  • the file processing apparatus may encrypt the content of the file generated by the application running actively or based on the request of the developer of the application, wherein the encrypted information and the decrypted information (such as the encryption key and the decryption key) of the file content may be used by the file.
  • the encrypted information and the decrypted information such as the encryption key and the decryption key
  • One of the developers of the processing device and the application program determines and informs the other party, and may also be determined by mutual agreement.
  • the file processing apparatus encrypts the first file generated by the first application operation in advance.
  • the encryption algorithm may be an AES encryption algorithm or other encryption algorithms such as DES.
  • Step 102 Decrypt the first file according to the decrypted information.
  • Step 103 Create a temporary file of the first file according to the decrypted first file.
  • the file processing apparatus further creates or generates a temporary file of the same type as the first file according to the plaintext of the first file.
  • the first application's access to the first file becomes access to the temporary file.
  • Step 104 Output a temporary file of the first file.
  • Step 105 Process the first file and/or the temporary file according to the operation of the temporary file by the first application.
  • the file processing device processes the first file or the temporary file, or the first file and the temporary file according to the operation of the temporary file by the first application.
  • the file processing apparatus deletes the temporary file after the first application reads the temporary file.
  • the file processing apparatus deletes the first file and encrypts the updated temporary file to replace the first file.
  • the embodiment of the present application protects the running file of the application, so that when the application accesses the file, only the corresponding application, that is, the "host" application of the file can decrypt the file, and the plaintext of the file can be accessed.
  • the content thereby reducing the data security problem and privacy leakage caused by the malicious program in the prior art by scanning the file in the memory card to obtain the file content, the method improves the security of the file stored in the memory card.
  • the file processing apparatus may further include:
  • the first file is encrypted according to the encrypted information.
  • the developer of the first application may decide whether to invoke the API for file encryption according to the level of privacy of the content stored in the file generated by the first application running, and if so, initiate an encryption request for the first file, and include in the encryption request Encrypted information used to encrypt the first file, such as a developer private key.
  • the file processing device After receiving the encryption request, the file processing device can encrypt the first file according to the encrypted information therein.
  • the original application program is unreadable to the file, and the file processing device does not perform the file after receiving the encryption request. Encrypt, but before doing the following steps:
  • the file processing device encrypts the first file based on the encrypted information.
  • an encryption authority auditing platform that is, a file encryption API permission auditing platform, may be added, and the auditing platform is used to audit the application to invoke the API. Request for permission to encrypt files and facilitate verification of the application during subsequent encryption.
  • the first application first initiates an application for encrypting the first file to the encryption authority auditing platform, and substantially applies the permission to use the API.
  • the application may include related content of the first application, such as a public key certificate, identity information, and an introduction to the app.
  • the encryption authority auditing platform reviews the related content of the first application to determine whether it passes the verification. If the verification is passed, the first application is granted the encryption permission for encrypting the first file, that is, the first application is granted.
  • the authority of the above API also returns the authority verification information, which is used by the file processing apparatus to verify whether the first application has the right to encrypt the first file when the first application requests to encrypt the first file.
  • the encryption request may include the rights verification information in addition to the encrypted information, so that the file processing device encrypts the first file according to the encrypted information.
  • the encryption request may include the rights verification information in addition to the encrypted information, so that the file processing device encrypts the first file according to the encrypted information.
  • it could include:
  • the first file is encrypted according to the encrypted information.
  • the malicious program can be prevented from using the encryption API to maliciously encrypt the unencrypted file on the memory card, thereby causing the original application to be unreadable to the file, thereby ensuring the validity of the file encryption protection method and feasibility.
  • FIG. 2 a flow chart of steps of another embodiment of the file processing method of the present application is shown, which may specifically include the following steps:
  • Step 201 Set an API for file encryption and decryption in the Android system.
  • the API can specifically implement the file encryption and decryption API by modifying and compiling the Android system source code, and increase the transparent encryption and decryption function of the Android system SD card file.
  • the encryption and decryption function can be added in the source part of the Framework layer file system.
  • Javax.crypto contains classes and interfaces that implement encryption algorithms, decryption algorithms, and key negotiation. Import the classes into File.java in the libcore/luni/src/main/java/java/io directory, and The encryption function encryptionFileByAES(sourceFile, encryptedSignature, developerKey, certificateFilePath) is added to the File class to encrypt the file.
  • the SDK is compiled.
  • the Android image file is an Android system that supports SD card file encryption and decryption functions, and the image can be loaded into an Android smart terminal.
  • the SDK file is a development kit that provides an SD card file encryption and decryption API. Android application developers can use the SDK to quickly develop an application that encrypts and protects the files stored in the SD card.
  • Step 203 After the application for verification is passed, the encryption authority auditing platform grants the first application the encryption authority for encrypting the first file, and returns the authority verification information.
  • the auditing platform grants the first application the encryption permission to encrypt the first file, that is, grants the first application the right to use the file encryption and decryption API, and assigns an AppID and AppKey to the first application, and the audit platform Sign the AppID and AppKey with their own private key, and then encrypt the AppID, AppKey and corresponding signature with the developer's public key, and finally use the ciphertext and the platform's public key certificate as the first application's permission verification information. Issued to the first application.
  • Step 204 The system receives an encryption request of the first application for the first file, where the encryption request includes encryption information and permission verification information for encrypting the first file.
  • the developer of the first application sends its own private key, the ciphertext of the auditing platform and the file path of the platform's public key certificate, and the password required for encryption to the Android system to initiate an encryption request for the first file.
  • Step 205 The system determines, according to the authority verification information, whether the first application has an encryption authority for encrypting the first file.
  • the Android system first uses the private key of the first application developer to decrypt the ciphertext sent by the audit platform to obtain the decrypted AppID, AppKey and signature information, and then reads the public key certificate of the audit platform to obtain the valid public key of the audit platform, and after verifying the decryption AppID, AppKey and signature information to determine whether the developer has been authorized by the audit platform, and has the right to use the file encryption and decryption API.
  • the system calls isAuthorized (encryptedSignature, developerKey, certificateFilePath), the function uses the developer private key to decrypt the encryptedSignature to obtain the plaintext AppID, AppKey, and signature signature, and then reads the public key certificate issued by the platform to obtain the public key of the platform, using the platform The public key, AppID, AppKey, and signature perform RSA signature verification. The function finally assigns the authorization variable orAuthorizedApp according to the verification result.
  • isAuthorized EncryptedSignature, developerKey, certificateFilePath
  • the function uses the developer private key to decrypt the encryptedSignature to obtain the plaintext AppID, AppKey, and signature signature, and then reads the public key certificate issued by the platform to obtain the public key of the platform, using the platform
  • the public key, AppID, AppKey, and signature perform RSA signature verification.
  • the function finally assigns the authorization variable orAuthorizedApp according to the verification result.
  • step 206 is executed, and the encryption and decryption API is normally called to encrypt the file; if the signature verification is not passed, The encryption operation is performed and the original file is directly returned as a result to the first application.
  • Step 206 Call the encryption and decryption API to encrypt the first file according to the encrypted information.
  • the process of encrypting the first file by the calling encryption and decryption API may be: first, the encryption function encryptFileByAES (sourceFile, encryptedSignature, developerKey, certificateFilePath, sourceFileKey) determines whether the value of the isAuthorizedApp is based on the value of the above isAuthorizedApp Encrypt the first file.
  • encryptFileByAES sourceFile, encryptedSignature, developerKey, certificateFilePath, sourceFileKey
  • the encryption key is initialized with the developer private key
  • the encryption function encrypts the original file of the first file to 1024 bytes.
  • the loop is read into the inputStream, and then the inputStream is encrypted into the encrypted data stream cipherInputStream with the already initialized encryption key cipher, and then the encrypted data stream is written into the temporary file before encryption, and the original file is deleted and the temporary file is encrypted. Renamed the file name of the original file to obtain the encrypted first file.
  • Step 207 The system receives an access request of the first application to the first file, where the access request includes decryption information for decrypting the first file.
  • the decryption information may be the private key of the first application developer.
  • Step 208 calling the encryption and decryption API to decrypt the first file according to the decryption information.
  • the process of decrypting the first file by calling the encryption and decryption API may be: first, the decryption key may be initialized by the developer private key, and the decryption function decryptFileByAES(sourceFile, key) will decrypt the first file to be 1024 bytes.
  • the unit loop is read into the inputStream, and then decrypted by the cipherOutputStream with the initialized decryption key.
  • Step 209 Create a temporary file of the first file according to the decrypted first file.
  • Step 210 Output a temporary file of the first file.
  • Step 211 Process the first file and/or the temporary file according to the operation of the temporary file by the first application.
  • steps 207 to 211 are similar to the steps 101 to 105 in the foregoing embodiment, and are not described herein again.
  • the platform authentication, platform authorization, and self-identification are used to manage the encryption and decryption API of the SD card file of the Android system. If the application developer wants to use the encryption and decryption API, it must apply to the platform. After the audit, the platform grants the addition.
  • the decryption authority in the process of encrypting and decrypting the file, the Android system will verify whether the application developer has the call permission of the SD card encryption and decryption API, and then encrypt and decrypt the file under the condition of having the authority.
  • the SD card file system with the encryption function added is integrated into the original ecology of the Android system, and the calling authority of the API is managed through the audit platform, and the developer needs to apply to the platform. Permissions, you can also communicate with each other on this platform, the platform can also add new similar features to form a developer interaction community based on Android system.
  • the embodiment of the present application can protect the privacy of the user for the user, and can protect the core data of the application for the application developer. For example, if App A invokes the encryption API to encrypt File A, File B, App C, and other programs read File A are the ciphertext content of File A, but File A is transparent to App A itself. App A can read the plain text of File A. This is isolated between the apps, so that you can not directly access the other party's files, unless you get the key of the other party's app, thus effectively protecting user privacy and data security.
  • FIG. 3 a structural block diagram of an embodiment of a file processing apparatus of the present application is shown, which may specifically include the following units:
  • the first request receiving unit 301 is configured to receive an access request of the first application to the first file, where the access request includes decryption information for decrypting the first file.
  • the decryption unit 302 is configured to decrypt the first file according to the decryption information.
  • the file generating unit 303 is configured to create a temporary file of the first file according to the decrypted first file.
  • the file output unit 304 is configured to output a temporary file of the first file.
  • the file processing unit 305 is configured to process the first file and/or the temporary file according to the operation of the temporary file by the first application.
  • the embodiment of the present application protects the running file of the application, so that when the application accesses the file, only the corresponding application, that is, the "host" application of the file can decrypt the file, and the plaintext of the file can be accessed.
  • the content thereby reducing the data security problem and privacy leakage caused by the malicious program in the prior art by scanning the file in the memory card to obtain the file content, the device improves the security of the file stored in the memory card.
  • the device may include, in addition to the first request receiving unit 301, the decryption unit 302, the file generating unit 303, the file output unit 304, and the file processing unit 305,
  • the second request receiving unit 401 is configured to receive an encryption request of the first application for the first file, before the first request receiving unit receives an access request of the first application to the first file, the encryption The request includes encrypted information for encrypting the first file;
  • the encryption unit 402 is configured to encrypt the first file according to the encrypted information.
  • the apparatus may further include a rights verification unit 403 configured to verify whether the first application has the first file encrypted before the encryption unit 402 encrypts the first file according to the encryption information Encryption authority;
  • the encryption unit 402 is configured to, when the right verification unit 403 determines that the first application has an encryption authority for encrypting the first file, encrypt the first file according to the encryption information. .
  • the cryptographic request further includes the privilege verification information of the first application, where the privilege verification information is when the first application applies to the cryptographic authority auditing platform for the encryption permission for encrypting the first file, The information that the encryption authority auditing platform audits and passes after granting the encryption authority;
  • the authority verification unit 403 is configured to verify, according to the rights verification information, whether the first application has an encryption right to encrypt the first file.
  • the embodiment of the present application further discloses an electronic device, including a data bus, a memory and a processor, wherein the memory stores a running program code, and the processor acquires the program code in the memory through the data bus, and performs the following steps:
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • embodiments of the embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, embodiments of the present application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cassette, magnetic tape storage or other magnetic storage device or any of its He is a non-transport medium that can be used to store information that can be accessed by a computing device.
  • computer readable media does not include non-persistent computer readable media, such as modulated data signals and carrier waves.
  • Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
  • These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing terminal device to produce a machine such that instructions are executed by a processor of a computer or other programmable data processing terminal device
  • Means are provided for implementing the functions specified in one or more of the flow or in one or more blocks of the flow chart.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the instruction device implements the functions specified in one or more blocks of the flowchart or in a flow or block of the flowchart.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例提供了一种文件处理方法及装置。该文件处理方法包括：接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；根据所述解密信息对所述第一文件进行解密；根据解密后的所述第一文件创建所述第一文件的临时文件；输出所述第一文件的临时文件；根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序才能实现对文件的解密，访问到文件的明文内容，从而减少了数据安全问题和隐私泄露情况，该方法提高了存储卡中存储文件的安全性。

Description

一种文件处理方法和装置 技术领域
本申请涉及数据处理技术领域，特别是涉及一种文件处理方法和一种文件处理装置。
背景技术
随着现代通信的不断发展和移动终端自身性能的不断提高，手机等移动终端已经进入了智能数字时代，Android(安卓)系统凭借其开放性和易用性成为了当今移动设备的主流操作系统之一。Android手机与个人的生活隐私、商业活动的联系越来越紧密，但随之也带来了数据安全和隐私保护的问题。
根据数据储存的位置不同，Android系统的数据分为内部SQLite数据库中的数据和外部储存卡的数据。外部储存卡的数据主要是以文件形式储存在安全数码卡(Secure Digital Memory Card，SD)中。但是Android系统对SD卡中的文件访问权限粒度过大，只有访问与不能访问的权限控制，某个应用程序只要申请到了访问SD卡的权限就可以任意读取、篡改SD卡里的大部分文件，简而言之，一个应用程序可以随意读取、篡改另一个应用程序在SD卡中保存的文件。例如，App A、App B、App C等应用程序都在运行过程中分别产生了各自的文件File A、File B、File C，且File A、File B、File C存储在SD卡中，某一恶意程序只要申请了访问该SD卡的权限就可以访问并篡改这些文件，这样就很容易造成用户的照片、记事本等隐私数据的泄露。
因此，目前需要本领域技术人员迫切解决的一个技术问题就是：如何提高存储卡中存储文件的安全性。
发明内容
本申请实施例所要解决的技术问题是提供一种文件处理方法，能够提高存储卡中存储文件的安全性。
相应的，本申请实施例还提供了一种文件处理装置，用以保证上述方法 的实现及应用。
为了解决上述问题，本申请公开了一种文件处理方法，包括：
接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；
根据所述解密信息对所述第一文件进行解密；
根据解密后的所述第一文件创建所述第一文件的临时文件；
输出所述第一文件的临时文件；
根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。
进一步，在所述接收第一应用对第一文件的访问请求之前，所述方法还包括：
接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；
根据所述加密信息对所述第一文件进行加密。
进一步，在所述接收对所述第一文件的加密请求之前，所述方法还包括：
验证所述第一应用是否具有对所述第一文件进行加密的加密权限；
若是，再根据所述加密信息对所述第一文件进行加密。
进一步，所述加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；
所述验证所述第一应用是否具有对所述第一文件进行加密的加密权限，包括：
根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。
进一步，所述根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理，包括：
若所述第一应用对所述临时文件的操作为读取操作，则在所述第一应用 读取所述临时文件后，删除所述临时文件；
若所述第一应用对所述临时文件的操作为内容更新操作，则对更新后的所述临时文件进行加密后替换所述第一文件。
本申请还提供了一种文件处理装置，包括：
第一请求接收单元，被配置为接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；
解密单元，被配置为根据所述解密信息对所述第一文件进行解密；
文件生成单元，被配置为根据解密后的所述第一文件创建所述第一文件的临时文件；
文件输出单元，被配置为输出所述第一文件的临时文件；
文件处理单元，被配置为根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。
进一步，所述装置还包括：
第二请求接收单元，被配置为在所述第一请求接收单元接收第一应用对第一文件的访问请求之前，接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；
加密单元，被配置为根据所述加密信息对所述第一文件进行加密。
进一步，所述装置还包括：
权限验证单元，被配置为在所述加密单元根据所述加密信息对所述第一文件进行加密之前，验证所述第一应用是否具有对所述第一文件进行加密的加密权限；
所述加密单元，被配置为当所述权限验证单元验证所述第一应用具有对所述第一文件进行加密的加密权限时，再根据所述加密信息对所述第一文件进行加密。
进一步，所述加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；
所述权限验证单元，被配置为根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。10、根据权利要求6至9中任意一项所述的装置，其特征在于，
所述文件处理单元，被配置为当所述第一应用对所述临时文件的操作为读取操作时，在所述第一应用读取所述临时文件后，删除所述临时文件；当所述第一应用对所述临时文件的操作为内容更新操作时，对更新后的所述临时文件进行加密后替换所述第一文件。
与现有技术相比，本申请实施例包括以下优点：
本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序也即文件的“宿主”应用才能实现对文件的解密，才能访问到文件的明文内容，从而减少了现有技术中恶意程序通过扫描存储卡里的文件即可获得文件内容而造成数据安全问题和隐私泄露情况，该方法提高了存储卡中存储文件的安全性。
附图说明
图1是本申请的一种文件处理方法实施例的步骤流程图；
图2是本申请的另一种文件处理方法实施例的步骤流程图；
图3是本申请的一种文件处理装置实施例的结构框图；
图4是本申请的另一种文件处理装置实施例的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
参照图1，示出了本申请的一种文件处理方法实施例的步骤流程图，具体可以包括如下步骤：
步骤101，接收第一应用对第一文件的访问请求，该访问请求中包括用于对第一文件进行解密的解密信息。
本申请实施例中，该文件处理装置可以是操作系统本身或设置在操作系统中的装置，该操作系统可以是Android系统。
该文件处理装置具有实现文件加密保护的功能，例如可以对SD卡中的存储文件进行加密保护。该功能可以通过在操作系统的应用层开放一个用于实现文件加解密的API(Application Programming Interface，应用程序编程接口)来实现，应用程序的开发方可以通过调用该API实现对其应用程序运行产生的文件进行加解密。其中，该API具体可以通过修改操作系统的源代码来实现。
该文件处理装置可以主动或者基于应用程序的开发方的请求对应用程序运行产生的文件的内容进行加密，其中该文件内容的加密信息和解密信息(如加密密钥和解密密钥)可以由文件处理装置和应用程序的开发方中的一方确定并告知另一方，也可以由双方协商确定。
本实施例中，该文件处理装置预先对第一应用运行产生的第一文件进行加密。其中，加密算法可以是AES加密算法，或者DES等其他加密算法。
当第一应用需要访问其第一文件时发起访问请求，并在该访问请求中包含用于对第一文件进行解密的解密信息，例如该第一应用开发方的私钥，或某一口令等。
该文件处理装置在接收到该访问请求后，获取其中的解密信息，执行步骤102。
步骤102，根据解密信息对第一文件进行解密。
该文件处理装置根据该解密信息，例如第一应用开发方的私钥，对第一文件进行解密，获得解密后的第一文件，也即第一文件的明文。
步骤103，根据解密后的第一文件创建第一文件的临时文件。
该文件处理装置进一步根据第一文件的明文创建或生成与第一文件同类型的临时文件。第一应用对第一文件的访问就变成了对临时文件的访问。
步骤104，输出第一文件的临时文件。
该文件处理装置向第一应用返回第一文件的临时文件，以供第一应用使用。
步骤105，根据第一应用对临时文件的操作，对第一文件和/或临时文件进行处理。
文件处理装置会根据第一应用对临时文件的操作情况，对第一文件或临时文件，或第一文件及临时文件进行处理。
例如，若第一应用对临时文件的操作仅为读取操作，则在第一应用读取临时文件后，文件处理装置删除该临时文件。
若第一应用对临时文件的操作为内容更新操作，例如，删除或增加或修改等，则文件处理装置会删除第一文件，并对更新后的临时文件进行加密以替换第一文件。
本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序也即文件的“宿主”应用才能实现对文件的解密，才能访问到文件的明文内容，从而减少了现有技术中恶意程序通过扫描存储卡里的文件即可获得文件内容而造成数据安全问题和隐私泄露情况，该方法提高了存储卡中存储文件的安全性。
在本申请的另一实施例中，在文件处理装置接收到第一应用对第一文件的访问请求之前，还可以首先包括：
接收第一应用对第一文件的加密请求，该加密请求中包括用于对第一文件进行加密的加密信息；
根据加密信息对第一文件进行加密。
第一应用的开发方可以根据第一应用运行产生的文件中所存内容隐私级别的高低来决定是否调用API进行文件加密，若是，则发起对第一文件的加密请求，并在该加密请求中包含用于对第一文件进行加密的加密信息，例如开发方私钥等。
文件处理装置在接收到该加密请求后即可根据其中的加密信息对该第一文件进行加密。
在另一实施例中，为了防止恶意程序利用该加密API对存储卡中未加密的文件进行恶意加密而造成原应用程序对文件的不可读，文件处理装置不是在接收到加密请求后即进行文件加密，而是在之前先进行以下步骤：
验证第一应用是否具有对第一文件进行加密的加密权限；
若是，文件处理装置再根据加密信息对第一文件进行加密。
在另一实施例中，为了验证第一应用是否具有对第一文件进行加密的加密权限，可以增设加密权限审核平台，即文件加密API权限审核平台，该审核平台用于审核应用程序对调用API进行文件加密的权限申请，并有助于后续加密过程中对应用程序的验证。
第一应用首先向该加密权限审核平台发起对第一文件进行加密的加密权限的申请，实质也即申请对上述API的使用权限。该申请中可以包含第一应用的相关内容，例如公钥证书、身份资料以及App简介等。
加密权限审核平台在接收到该申请后，审查第一应用的相关内容，确定是否通过验证，若通过验证，则授予第一应用对第一文件进行加密的加密权限，也即授予第一应用使用上述API的权限，同时还会返回权限验证信息，该权限验证信息用于后续第一应用请求对第一文件进行加密时，文件处理装置验证该第一应用是否具有对第一文件加密的权限。
这样，在第一应用向文件处理装置请求对第一文件进行加密时，其中加密请求中除了包括加密信息还可以包括该权限验证信息，这样，在文件处理装置根据加密信息对第一文件进行加密之前，可以包括：
根据权限验证信息验证第一应用是否具有对所述第一文件进行加密的加密权限；
若是，再根据加密信息对第一文件进行加密。
通过增加该加密过程和验证过程，可以防止恶意程序利用该加密API对存储卡中未加密的文件进行恶意加密而造成原应用程序对文件的不可读，保证了该文件加密保护方法的有效性和可行性。
下面以对Android系统中SD卡中的文件进行处理为例进行说明。
参照图2，示出了本申请的另一种文件处理方法实施例的步骤流程图，具体可以包括如下步骤：
步骤201，在Android系统中设置文件加解密的API。
该API具体可以通过修改并编译Android系统源码的方式来实现文件加解密的API，增加Android系统SD卡文件的透明加解密功能。具体的，可以在Framework层文件系统源码部分中增加加解密功能。
由于Android的API均由Framework层向应用层提供，而Framework层主要使用Java语言编写，所以本方案采用在Framework层的File类中引入Java加密相关的类库javax.crypto。javax.crypto中包含实现了加密算法、解密算法以及密钥协商的类和接口，将其中的类导入到libcore/luni/src/main/java/java/io目录下的File.java中，并在File类中新增加密函数encryptFileByAES(sourceFile,encryptedSignature,developerKey,certificateFilePath)实现文件的加密。
修改系统源码完毕后，利用编译Android系统及SDK的方法编译出具有SD卡文件加密的Android系统和Android SDK。
首先，修改Android系统的配置文件。
可以采用32位的Ubuntu操作系统进行的编译工作，需要以下几个Android.mk文件(备注：android_src表示Android源码根目录)：
(1)android_src/external/clearsilver/cgi/Android.mk
(2)android_src/external/clearsilver/java-jni/Android.mk
(3)android_src/external/clearsilver/util/Android.mk
(4)android_src/external/clearsilver/cs/Android.mk
将以上文件中的m64修改为m32。
另外，将android_src/build/core/main.mk中的ifneq(64,$(findstring 64,$(build_arch)))修改为：ifneq(i686,$(findstring i686,$(build_arch)))。
然后，编译修改源码后的Android系统。
在Android源码的根目录下执行make命令开始编译Android源码。另外，为了缩短编译时间，可以在拥有多CPU、多核、超线程的PC上使用-jn命令行参数，例如4核PC可以使用makej4来加快编译速度。执行make之后会新建一些重要的目录来存放编译结果，make之后会在android_src/out/target/product/generic目录下生成system.img、userdata.img以及ramdisk.img等镜像文件，这些镜像文件即为编译的成果，用它们就可以启动一个新的Android系统。
再然后，在成功编译Android系统的基础上，进行SDK的编译。
在编译Android源码时会生成在两种平台运行Android所需要的Libraries和tools，一种是在PC端直接运行Android需要的库和工具，存放在out/host目录中；另一种是直接运行在Android平台上的库和工具(基于ARM架构)，存放在out/target目录中。本申请修改源码后编译SDK可以在android_src/out/host/linux-x86/sdk/目录下生成SDK的原文件及其压缩包。android-sdk_eng.root_linux-x86文件夹是新的SDK文件，android-sdk_eng.root_linux-x86.zip是SDK的压缩包。
Android镜像文件为支持SD卡文件加解密功能的Android系统，该镜像可装入Android智能终端。SDK文件为提供了SD卡文件加解密API的开发工具包，Android应用程序开发者可使用该SDK快速开发出具有加密保护其存入SD卡中的文件功能的应用程序。
步骤202，加密权限审核平台接收第一应用对第一文件进行加密的加密权限的申请。
本实施例中，可以建立Android系统SD卡文件加密API权限审核平台，记为加密权限审核平台。第一应用的开发方将自己的公钥证书、身份资料以及App简介提交给审核平台对文件加解密API的使用权限进行实名申请。
步骤203，加密权限审核平台对申请验证通过后，授予第一应用对第一文件进行加密的加密权限，并返回权限验证信息。
审核通过后，审核平台授予第一应用对第一文件进行加密的加密权限，也即授予第一应用对对文件加解密API的使用权限，并会给第一应用分配一个AppID以及AppKey，审核平台用自己的私钥对AppID和AppKey进行签名，然后再用开发方的公钥对AppID、AppKey以及相应的签名进行加密，最后将密文及平台的公钥证书作为该第一应用的权限验证信息颁发给第一应用。
该密文及公钥证书的存储路径就是文件加密API encryptFileByAES(File sourceFile,String encryptedSignature,String developerKey,String certificateFilePath,String sourceFileKey)所需的参数，其中sourceFile是要被加密的文件，developerKey是开发者的私钥，该私钥将作为解密 encryptedSignature的密钥，sourceFileKey是通过验证以后对sourceFile进行AES加密所需的加密口令。
上述步骤201与步骤202～203之间的步骤顺序可以根据需要进行调整。
步骤204，系统接收第一应用对第一文件的加密请求，该加密请求中包括用于对第一文件进行加密的加密信息及权限验证信息。
第一应用的开发方将自己的私钥，审核平台颁发的密文及平台的公钥证书的文件路径，以及加密所需的口令发送至Android系统，以发起对第一文件的加密请求。
步骤205，系统根据权限验证信息判断第一应用是否具有对第一文件进行加密的加密权限。
Android系统首先利用第一应用开发方的私钥解密审核平台发送的密文获得解密后的AppID、AppKey以及签名信息，然后读取审核平台的公钥证书获得审核平台的有效公钥，验证解密后的AppID、AppKey以及签名信息来判断开发方是否已被审核平台授权，并具有文件加解密API的使用权限。
具体的，系统调用isAuthorized(encryptedSignature,developerKey,certificateFilePath)，该函数利用开发方私钥解密encryptedSignature获得明文AppID、AppKey以及签名signature，再读取平台颁发的公钥证书获得平台的公钥，利用平台的公钥、AppID、AppKey以及signature进行RSA的签名验证，函数最后会根据验证结果对授权与否的标记变量isAuthorizedApp进行赋值。
如果通过上述签名验证，判定第一应用已被审核平台授权，并具有文件加解密API的使用权限，则执行步骤206，正常调用加解密API对文件进行加密；如果未通过上述签名验证，则不进行加密操作并直接将原文件作为结果返回给第一应用。
步骤206，调用加解密API根据加密信息对第一文件进行加密。
该调用加解密API对第一文件进行加密过程可以是：首先，加密函数encryptFileByAES(sourceFile,encryptedSignature,developerKey,certificateFilePath,sourceFileKey)根据上述isAuthorizedApp的值来判断是否 对第一文件进行加密。
若对第一文件进行加密，则建立一个与第一文件同类型的加密前临时文件，并用开发方私钥初始化加密密钥，加密函数将欲加密的第一文件的原文件以1024个字节循环读取到inputStream中，再将inputStream用已经初始化的加密密钥cipher加密成加密数据流cipherInputStream，然后将加密数据流写入到该加密前临时文件中，最后删除原文件并将加密前临时文件更名为原文件的文件名，从而获得加密了的第一文件。
步骤207，系统接收第一应用对第一文件的访问请求，访问请求中包括用于对第一文件进行解密的解密信息。
该解密信息可以是第一应用开发方的私钥。
步骤208，调用加解密API根据解密信息对第一文件进行解密。
本步骤中，调用加解密API对第一文件进行解密过程可以是：可以首先用开发方私钥初始化解密密钥，解密函数decryptFileByAES(sourceFile,key)将欲解密的第一文件以1024字节为单位循环读入到inputStream中，然后由cipherOutputStream用初始化了的解密密钥进行解密。
步骤209，根据解密后的第一文件创建第一文件的临时文件。
将解密后的数据流写到临时文件中。
步骤210，输出第一文件的临时文件。
步骤211，根据第一应用对临时文件的操作，对第一文件和/或临时文件进行处理。
上述步骤207～211与前述实施例中的步骤101～105类似，此处不再赘述。
本实施例中采用平台审核、平台授权、自行鉴别的方式来管理Android系统SD卡文件的加解密API，应用开发方若要使用该加解密API必须向平台申请，通过审核后，平台授予其加解密权限，在对文件进行加解密的过程中，Android系统会校验该应用开发方是否具有SD卡加解密API的调用权限，然后再具有权限的条件下进行文件的加解密。
本实施例将增加了加密功能的SD卡文件系统融入Android系统的原有生态，并通过审核平台来管理该API的调用权限，开发方需要到该平台申请 权限，还可以在此平台相互交流，该平台还可以增加新的类似功能，从而形成一个基于Android系统的开发者互动社区。
本申请实施例对于用户而言可以保护用户的隐私，对于应用开发方而言可以保护应用程序的核心数据。例如，若App A调用了加密API对File A进行了加密，App B、App C以及其它程序读取到的File A均为File A的密文内容，但是File A对于App A本身却是透明的，App A可以读取到File A的明文。这样就在App之间进行了隔离，使得大家不能直接访问对方的文件，除非获得对方App的密钥，从而有效保障了用户隐私和数据安全。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
参照图3，示出了本申请一种文件处理装置实施例的结构框图，具体可以包括如下单元：
第一请求接收单元301，被配置为接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息。
解密单元302，被配置为根据所述解密信息对所述第一文件进行解密。
文件生成单元303，被配置为根据解密后的所述第一文件创建所述第一文件的临时文件。
文件输出单元304，被配置为输出所述第一文件的临时文件。
文件处理单元305，被配置为根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。
本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序也即文件的“宿主”应用才能实现对文件的解密，才能访问到文件的明文内容，从而减少了现有技术中恶意程序通过扫描存储卡里的文件即可获得文件内容而造成数据安全问题和隐私泄露情况，该装置提高了存储卡中存储文件的安全性。
在另一实施例中，如图4所示，该装置除了包括第一请求接收单元301，解密单元302，文件生成单元303，文件输出单元304，文件处理单元305之外，还可以包括：
第二请求接收单元401，被配置为在所述第一请求接收单元接收第一应用对第一文件的访问请求之前，接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；
加密单元402，被配置为根据所述加密信息对所述第一文件进行加密。
该装置还可以包括权限验证单元403，被配置为在所述加密单元402根据所述加密信息对所述第一文件进行加密之前，验证所述第一应用是否具有对所述第一文件进行加密的加密权限；
所述加密单元402，被配置为当所述权限验证单元403判定所述第一应用具有对所述第一文件进行加密的加密权限时，再根据所述加密信息对所述第一文件进行加密。
加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；
所述权限验证单元403，被配置为根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。
在本申请的另一实施例中，文件处理单元305，可以被配置为当所述第一应用对所述临时文件的操作为读取操作时，在所述第一应用读取所述临时文件后，删除所述临时文件；当所述第一应用对所述临时文件的操作为内容更新操作时，对更新后的所述临时文件进行加密后替换所述第一文件。
本申请实施例还公开了一种电子设备，包括数据总线，存储器和处理器，其中，存储器中存储有一段运行程序代码，处理器通过数据总线获取存储器中的程序代码，并执行以下步骤：
接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；
根据所述解密信息对所述第一文件进行解密；
根据解密后的所述第一文件创建所述第一文件的临时文件；
输出所述第一文件的临时文件；
根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其 他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得 包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种文件处理方法和一种文件处理装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

  1. 一种文件处理方法，其特征在于，包括：
    接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；
    根据所述解密信息对所述第一文件进行解密；
    根据解密后的所述第一文件创建所述第一文件的临时文件；
    输出所述第一文件的临时文件；
    根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。
  2. 根据权利要求1所述的方法，其特征在于，在所述接收第一应用对第一文件的访问请求之前，所述方法还包括：
    接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；
    根据所述加密信息对所述第一文件进行加密。
  3. 根据权利要求2所述的方法，其特征在于，在所述接收对所述第一文件的加密请求之前，所述方法还包括：
    验证所述第一应用是否具有对所述第一文件进行加密的加密权限；
    若是，再根据所述加密信息对所述第一文件进行加密。
  4. 根据权利要求3所述的方法，其特征在于，所述加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；
    所述验证所述第一应用是否具有对所述第一文件进行加密的加密权限，包括：
    根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。
  5. 根据权利要求1至4中任意一项所述的方法，其特征在于，所述根 据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理，包括：
    若所述第一应用对所述临时文件的操作为读取操作，则在所述第一应用读取所述临时文件后，删除所述临时文件；
    若所述第一应用对所述临时文件的操作为内容更新操作，则对更新后的所述临时文件进行加密后替换所述第一文件。
  6. 一种文件处理装置，其特征在于，包括：
    第一请求接收单元，被配置为接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；
    解密单元，被配置为根据所述解密信息对所述第一文件进行解密；
    文件生成单元，被配置为根据解密后的所述第一文件创建所述第一文件的临时文件；
    文件输出单元，被配置为输出所述第一文件的临时文件；
    文件处理单元，被配置为根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。
  7. 根据权利要求6所述的装置，其特征在于，所述装置还包括：
    第二请求接收单元，被配置为在所述第一请求接收单元接收第一应用对第一文件的访问请求之前，接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；
    加密单元，被配置为根据所述加密信息对所述第一文件进行加密。
  8. 根据权利要求7所述的装置，其特征在于，所述装置还包括：
    权限验证单元，被配置为在所述加密单元根据所述加密信息对所述第一文件进行加密之前，验证所述第一应用是否具有对所述第一文件进行加密的加密权限；
    所述加密单元，被配置为当所述权限验证单元验证所述第一应用具有对所述第一文件进行加密的加密权限时，再根据所述加密信息对所述第一文件进行加密。
  9. 根据权利要求8所述的装置，其特征在于，所述加密请求中还包括 所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；
    所述权限验证单元，被配置为根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。
  10. 根据权利要求6至9中任意一项所述的装置，其特征在于，
    所述文件处理单元，被配置为当所述第一应用对所述临时文件的操作为读取操作时，在所述第一应用读取所述临时文件后，删除所述临时文件；当所述第一应用对所述临时文件的操作为内容更新操作时，对更新后的所述临时文件进行加密后替换所述第一文件。
PCT/CN2016/070169 2015-01-16 2016-01-05 一种文件处理方法和装置 WO2016112799A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510024398.7A CN105844170A (zh) 2015-01-16 2015-01-16 一种文件处理方法和装置
CN201510024398.7 2015-01-16

Publications (1)

Publication Number Publication Date
WO2016112799A1 true WO2016112799A1 (zh) 2016-07-21

Family

ID=56405241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/070169 WO2016112799A1 (zh) 2015-01-16 2016-01-05 一种文件处理方法和装置

Country Status (2)

Country Link
CN (1) CN105844170A (zh)
WO (1) WO2016112799A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106407838A (zh) * 2016-09-21 2017-02-15 乐视控股（北京）有限公司 便签信息管理方法和装置
CN109495444B (zh) * 2018-09-30 2022-02-22 北京工业职业技术学院 一种加密请求处理方法
CN110851805A (zh) * 2019-10-14 2020-02-28 深圳市非零无限科技有限公司 一种sdk验证用户访问授权的方法、系统及可读存储介质
CN112738219B (zh) * 2020-12-28 2022-06-10 中国第一汽车股份有限公司 程序运行方法、装置、车辆及存储介质
CN113326540B (zh) * 2021-06-29 2023-12-22 深圳世纪前沿量化科技有限公司 微服务的调用权限控制方法、装置、服务器、系统及介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101802833A (zh) * 2007-09-27 2010-08-11 奥多比公司 向在应用执行环境中运行的应用提供本地存储服务
CN101971186A (zh) * 2008-04-10 2011-02-09 日本电气株式会社 信息泄露防止装置和方法及其程序
US8191162B1 (en) * 2007-04-10 2012-05-29 Zafesoft Inc. System and method for securing and tracking files
CN103106372A (zh) * 2013-01-17 2013-05-15 上海交通大学 用于Android系统的轻量级隐私数据加密方法及系统
CN103218575A (zh) * 2013-04-17 2013-07-24 武汉元昊科技有限公司 一种主机文件安全监控方法
CN104331644A (zh) * 2014-11-24 2015-02-04 北京邮电大学 一种智能终端文件的透明加解密方法
US20150227753A1 (en) * 2014-02-09 2015-08-13 Microsoft Corporation Content item encryption on mobile devices

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101853363B (zh) * 2010-05-07 2012-08-08 飞天诚信科技股份有限公司 一种文件保护方法及系统
CN103455520A (zh) * 2012-06-04 2013-12-18 北京三星通信技术研究有限公司 安卓数据库访问的方法及设备
CN103246850A (zh) * 2013-05-23 2013-08-14 福建伊时代信息科技股份有限公司 文件处理方法和装置
CN103686716B (zh) * 2013-12-19 2017-01-11 复旦大学 安卓系统机密性完整性增强访问控制系统
CN104217175B (zh) * 2014-09-05 2018-04-20 北京邮电大学 一种数据读写方法和装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8191162B1 (en) * 2007-04-10 2012-05-29 Zafesoft Inc. System and method for securing and tracking files
CN101802833A (zh) * 2007-09-27 2010-08-11 奥多比公司 向在应用执行环境中运行的应用提供本地存储服务
CN101971186A (zh) * 2008-04-10 2011-02-09 日本电气株式会社 信息泄露防止装置和方法及其程序
CN103106372A (zh) * 2013-01-17 2013-05-15 上海交通大学 用于Android系统的轻量级隐私数据加密方法及系统
CN103218575A (zh) * 2013-04-17 2013-07-24 武汉元昊科技有限公司 一种主机文件安全监控方法
US20150227753A1 (en) * 2014-02-09 2015-08-13 Microsoft Corporation Content item encryption on mobile devices
CN104331644A (zh) * 2014-11-24 2015-02-04 北京邮电大学 一种智能终端文件的透明加解密方法

Also Published As

Publication number Publication date
CN105844170A (zh) 2016-08-10

Similar Documents

Publication Publication Date Title
US10708051B2 (en) Controlled access to data in a sandboxed environment
US11126754B2 (en) Personalized and cryptographically secure access control in operating systems
KR101608510B1 (ko) 글로벌 플랫폼 규격을 사용하는 발행자 보안 도메인에 대한 키 관리 시스템 및 방법
KR100996784B1 (ko) 공개 키 암호화에 기초한 데이터의 저장 및 검색을 위한, 컴퓨팅 장치에서 구현되는 방법, 시스템 및 복수의 명령어를 저장하는 하나 이상의 컴퓨터 판독가능 매체
US20140380058A1 (en) Process Authentication and Resource Permissions
WO2016112799A1 (zh) 一种文件处理方法和装置
CN109992987B (zh) 基于Nginx的脚本文件保护方法、装置及终端设备
WO2017129138A1 (zh) 数据仓库中的数据保护方法及装置
CN111310213A (zh) 一种业务数据保护方法、装置、设备及可读存储介质
TW201530344A (zh) 應用程式存取保護方法及應用程式存取保護裝置
WO2017181968A1 (zh) 应用文件的处理方法、访问方法及装置、存储介质
WO2015117523A1 (zh) 访问控制方法及装置
CN105303074A (zh) 一种保护Web应用程序安全的方法
EP3048553B1 (en) Method for distributing applets, and entities for distributing applets
CN114547648A (zh) 一种数据匿踪查询方法及系统
US10771249B2 (en) Apparatus and method for providing secure execution environment for mobile cloud
WO2019210471A1 (zh) 一种数据调用方法及数据调用装置
WO2015154469A1 (zh) 数据库的操作方法及装置
KR101473656B1 (ko) 모바일 데이터 보안 장치 및 방법
US20070263868A1 (en) Method and apparatus for securely executing a background process
KR101711024B1 (ko) 부정조작방지 장치 접근 방법 및 그 방법을 채용한 단말 장치
Park et al. CAFE: A virtualization-based approach to protecting sensitive cloud application logic confidentiality
Philip et al. An Overview About the Security Architecture of the Mobile
Focardi et al. A formally verified configuration for hardware security modules in the cloud
CN113468610A (zh) 去中心化可信访问控制框架及其运行方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16737025

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16737025

Country of ref document: EP

Kind code of ref document: A1