WO2013013562A1 - 驱动保护方法及系统 - Google Patents

驱动保护方法及系统 Download PDF

Info

Publication number
WO2013013562A1
WO2013013562A1 PCT/CN2012/078041 CN2012078041W WO2013013562A1 WO 2013013562 A1 WO2013013562 A1 WO 2013013562A1 CN 2012078041 W CN2012078041 W CN 2012078041W WO 2013013562 A1 WO2013013562 A1 WO 2013013562A1
Authority
WO
WIPO (PCT)
Prior art keywords
program file
encrypted
input
encrypted program
request packet
Prior art date
Application number
PCT/CN2012/078041
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 WO2013013562A1 publication Critical patent/WO2013013562A1/zh
Priority to US14/156,540 priority Critical patent/US9317707B2/en

Links

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
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062—Securing storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0653—Monitoring storage devices or systems

Definitions

  • the present invention relates to the field of drive protection, and in particular, to a drive protection method and system. Background of the invention
  • the IRP (I/O Request Package) is a data structure in the Windows kernel that is related to input and output.
  • the application communicates with the underlying driver layer, the application sends an I/O request, and the operating system translates the I/O request into the corresponding IRP data.
  • Different types of IRP data are passed to different dispatch functions according to the type.
  • IRP has two basic properties, one is the main function (MajorFunction), which is used to record the main type of IRP, the main type of IRP is associated with the dispatch function, and the other is the sub-function function (MinorFunction), used to record the IRP sub- Types of.
  • MajorFunction which is used to record the main type of IRP
  • MinorFunction sub-function function
  • the operating system dispatches the IRP to different dispatch functions according to MajorFunction, and in the dispatch function, it can continue to determine which MinorFunction the IRP belongs to.
  • File I/O related functions such as: create file kernel object (CreateFile), read file (ReadFile), write file (WriteFile), etc., will create the corresponding creation type of input and output request packet (IRP_MJ_CREATE), read type IRP such as input/output request packet (IRP_MJ_READ), write type I/O request packet (IRP of IRP_MJ_WRITE). These IRPs are passed to the dispatch function of the driver layer.
  • CreateFile create file kernel object
  • ReadFile read file
  • WriteFile write file
  • IRP_MJ_CREATE creation type of input and output request packet
  • IRP_MJ_READ input/output request packet
  • IRP of IRP_MJ_WRITE write type I/O request packet
  • the function CreateFile is used to create or open an object, and returns a handle that can be used to access the object;
  • the function ReadFile is used to read data from a location pointed to by the file pointer into a file, and supports synchronous and asynchronous;
  • function WriteFile Used to write data to a file.
  • the application wants to open the driver layer.
  • IRP_MJ_CREATE needs to be sent to the driver layer.
  • the driver layer returns the sentence after the corresponding dispatch function.
  • Handle is an integer value, which is used to mark different objects in the application layer and different instances of the same type in the application layer, such as a window, button, icon, scroll bar, output device, control or file, etc., the application layer can Access the corresponding driver layer through the handle.
  • the third-party program can send the I/O channel management function (IOCTL) in the device driver layer to the driver layer directly. Control the purpose of the driver layer. If the third party program is malware, it can be vandalized on the user's computer. Summary of the invention
  • Embodiments of the present invention provide a drive protection method that can improve the safety of a drive layer.
  • a method of driving protection includes the following steps:
  • Encrypting the program file and transmitting the input/output request packet and the encrypted program file; receiving the input/output request packet and the encrypted program file, and decrypting the encrypted program file, and decrypting the encrypted program file
  • the program file is verified. If the verification is passed, the handle is returned, otherwise the handle is not returned.
  • the embodiment of the invention also provides a drive protection system capable of improving the safety of the drive layer.
  • a drive protection system including:
  • An application layer module including an encryption submodule and a first communication submodule, the encryption submodule is configured to encrypt a program file, and the first communication submodule is configured to send an input and output request packet and an encrypted program file;
  • a driver layer module comprising: a decryption verification submodule and a second communication submodule, wherein the second communication submodule is configured to receive the input and output request packet and the encrypted program file, where the decryption verification submodule is used to Decrypting the encrypted program file, and verifying the decrypted program file, if the verification is passed, the second communication sub-module returns a handle to the first communication sub-module, and if the verification fails, the first The second communication submodule does not return a handle to The first communication submodule.
  • the above-mentioned drive protection method and system use the program file of the application layer to be encrypted, and send the encrypted program file when the input/output request packet is sent, and the driver layer decrypts the encrypted program file, and returns the handle after the verification is passed.
  • the application layer can access the driver layer according to the handle. If the verification fails, the driver layer will deny access to the application layer, ensuring that the legal application layer communicates with the driver layer, preventing the suspicious program from accessing the driver layer, and improving the Drive layer security.
  • FIG. 1 is a flow chart of a drive protection method in an embodiment
  • FIG. 2 is a specific flowchart of encrypting a program file in an embodiment
  • FIG. 3 is a specific flowchart of decrypting and verifying an encrypted program file in an embodiment
  • FIG. 4 is a schematic diagram showing the internal structure of a drive protection system in an embodiment. Mode for carrying out the invention
  • a driving protection method includes the following steps:
  • Step S110 encrypting the program file, and transmitting the input and output request packet and the encrypted program file.
  • the program file of the application layer is asymmetrically encrypted, that is, the application file is asymmetrically encrypted.
  • the asymmetric encryption uses an RSA algorithm.
  • asymmetric encryption means that the same key is used for encryption and decryption.
  • Public “Key” means that it can be publicly announced, and "private key” cannot. It can only be known by the holder.
  • the RSA public key encryption algorithm is an asymmetric encryption algorithm developed by Ron Rivest, Adi Shamirh and LenAdleman in 1977. It is used for data encryption and can also be used for digital signature algorithms. It is easy to understand and operate. And the RSA algorithm has high encryption security and is not easy to be cracked.
  • the application layer needs to send an I/O request when accessing the driver layer.
  • the I/O request is converted into an input and output request packet (IRP), and the encrypted program file is sent at the same time, so that the driver layer verifies the identity of the application layer.
  • IRP input and output request packet
  • the step of sending the input/output request packet and the encrypted program file is specifically: sending an input/output request packet through the process, wherein the identity (PID) of the process has a correspondence with the path of the encrypted program file.
  • the step of sending the input/output request packet and the encrypted program file is specifically: sending, by the process, an input/output request packet, wherein the path of the encrypted program file is stored in the process structure of the process (EPROCESS) .
  • the application layer sends an access request through the I/O related function CreateFile, which creates an IRP of the corresponding IRP_MJ_CREATE, which is dispatched to the dispatch function in the driver layer.
  • Step S120 receiving the input/output request packet and the encrypted program file, decrypting the encrypted program file, and verifying the decrypted program file.
  • the receiving the input/output request packet and the encrypted program file in step S120 are specifically: receiving the input/output request packet by a process, and parsing a path of the corresponding encrypted program file according to the PID of the process; After the path of the program file, the encrypted program file is obtained.
  • the input/output request packet is sent by the process in step S110, where the path of the encrypted program file is stored in the process structure body (EPROCESS) of the process:
  • the step S120 receives the input/output request packet and the encrypted program file, specifically: receiving, by the process, the input/output request packet, and parsing the path of the encrypted program file from the EPROCESS of the process; After the path of the program file, the encrypted program file is obtained.
  • the driver layer After receiving the program file of the IRP and the encrypted application layer, the driver layer decrypts the encrypted application file of the application layer.
  • the program file of the encrypted application layer is decrypted by the RSA algorithm. Then, the program file of the decrypted application layer is verified. If the verification is passed, the handle of the driver layer is returned to the application layer, and the application layer can access the driver layer according to the handle. If the verification fails, the driver layer rejects the application layer. access.
  • Step S130 it is judged whether the verification is passed, and if so, step S140 is performed, otherwise step S150 is performed.
  • Step S140 returning the handle. Returns the handle of the driver layer.
  • step S150 the handle is not returned.
  • the step of encrypting the program file is specifically as follows:
  • Step S210 reading a program file.
  • the program file of the application layer is read out.
  • the program file of the application layer is in the portable executable (PE, Portable Execute) format
  • part of the contents other than the DOS header, the PE header, and the block table of the PE file are read. .
  • Step S220 calculating a message digest value of the program file.
  • the information digest value of the read contents other than the DOS header, the PE header, and the block table of the PE file is calculated.
  • the information digest value is generally adopted. MD5 value.
  • Step S230 asymmetrically encrypting the information digest value.
  • Step S240 writing the asymmetrically encrypted information digest value to the end of the application file of the application layer.
  • the encrypted message digest value is written to the end of the application layer's program file for transmission with the application layer's program file.
  • the encrypted program file is decrypted, and the decrypted program file is verified. If the verification is passed, the handle is returned. Otherwise, the end step is specifically as follows:
  • Step S310 reading the asymmetrically encrypted information digest value, and decrypting the information digest value to obtain the information digest value.
  • the program file of the application layer is obtained, and the tail of the program file is read, so that the information digest value of the asymmetric encryption is read, and the RSA algorithm is used for decryption to obtain the information digest value.
  • Step S320 Calculate the information digest value of the program file, and compare the calculated information digest value with the decrypted information digest value.
  • the driver layer calculates the information digest value of the application file of the application layer. If the program file of the application layer is a PE file, the PE file includes a DOS header, a PE file flag bit, an image file, and an optional image header, and the PE file flag bit is a PE header.
  • the image file is the basic information of the PE file, and the optional image header is a block table, and the information digest value of the partial content except the PE file DOS header, the PE header, and the block table is calculated, and the calculated information digest value and the decrypted value are obtained.
  • the obtained information digest values are compared. If the two are the same, the handle of the driver layer is returned to the application layer, and the application layer can access the driver layer according to the handle. If the two are different, the driver layer denies the application layer from accessing.
  • step S330 it is determined whether the two information digest values are the same. If yes, step S340 is performed, otherwise step S350 is performed. Step S340, returning the handle.
  • step S350 the handle is not returned.
  • a drive protection system includes an application layer module 410 and a drive layer module 420.
  • the application layer module 410 is an application.
  • the application layer module 410 includes a concatenated encryption submodule 411 and a first communication submodule 413.
  • the encryption sub-module 411 is used to encrypt the program file
  • the first communication sub-module 413 is configured to send the input/output request packet and the encrypted program file to the driver layer module 420.
  • the encryption sub-module 411 asymmetrically encrypts the program file of the application layer.
  • the asymmetric encryption can adopt the RSA algorithm.
  • the application layer module 410 accesses the driver layer module 420, it needs to send an I/O request through the first communication submodule 413, and the I/O request is converted into an input/output request packet (IRP), and the first communication submodule 413 sends the encrypted
  • IRP input/output request packet
  • the application layer module 410 sends an access request through the I/O correlation function CreateFile, which creates an IRP of the corresponding creation type input and output request packet (IRP_MJ_CREATE), which is dispatched to the dispatcher in the driver layer module 420.
  • IRP_MJ_CREATE creation type input and output request packet
  • the driver layer module 420 is a driver.
  • the driver layer module 420 includes a connected second communication submodule 421 and a decryption verification submodule 423.
  • the second communication sub-module 421 is configured to receive the input/output request packet and the encrypted program file.
  • the first communication sub-module 413 is configured to send an input/output request packet by using a process, where an identity (PID) of the process has a corresponding relationship with a path of the encrypted program file.
  • the second communication sub-module 421 is configured to receive the station through the process. The input/output request packet is described, and a path of the corresponding encrypted program file is parsed according to the PID of the process; and the encrypted program file is obtained according to the path of the encrypted program file.
  • the first communication sub-module 413 is configured to send an input and output request packet through a process, wherein a path of the encrypted program file is stored in a process structure (EPROCESS) of the process.
  • the second communication sub-module 421 is configured to receive the input/output request packet by using the process, and parse the path of the encrypted program file from the EPROCESS of the process; and obtain the location according to the path of the encrypted program file.
  • the encrypted program file is configured to send an input and output request packet through a process, wherein a path of the encrypted program file is stored in a process structure (EPROCESS) of the process.
  • EPROCESS process structure
  • the decryption verification sub-module 423 is configured to decrypt the encrypted program file and verify the decrypted program file. When the verification is passed, the second communication sub-module 421 returns the handle to the first communication element of the application layer module 410. Module 413, when the verification fails, the second communication sub-module 421 does not return a handle to the first communication sub-module 413.
  • the second communication submodule 421 of the driver layer module 420 After receiving the IRP and the encrypted application layer program file, the second communication submodule 421 of the driver layer module 420 sends the program file to the decryption verification submodule 423, and the decryption verification submodule 423 decrypts the encrypted application layer program file.
  • the program file of the encrypted application layer can be decrypted by the RS A algorithm.
  • the decryption verification sub-module 423 verifies the decrypted application layer program file, and if the verification passes, returns a handle to the application layer module 410, and the application layer module 410 can access the driver layer module 420 according to the handle, if the verification fails
  • the driver layer module 420 will deny the application layer module 410 access.
  • the encryption submodule 411 is further configured to read a program file, calculate a message digest value of the program file, and asymmetrically encrypt the information digest value, and write an asymmetrically encrypted information digest value to the program digest value. The end of the program file.
  • the encryption sub-module 411 first reads out the program file of the application layer, and the program file of the application layer is a portable executable (PE, Portable Execute) file, wherein the PE file includes DOS header, PE file flag, image file and optional image header, PE file flag is PE header, image file is basic information of PE file, and optional image header is block table.
  • the encryption sub-module 411 reads part of the content except the DOS header, the PE header, and the block table of the PE file, and then calculates the information digest value of the part of the content except the DOS header, the PE header, and the block table of the PE file. Then, the calculated information digest value is asymmetrically encrypted, and finally the encrypted information digest value is written to the end of the application layer application file.
  • asymmetric encryption can be encrypted by RSA algorithm.
  • the decryption verification sub-module 423 is further configured to read the asymmetrically encrypted information digest value, decrypt the information digest value, calculate the information digest value of the program file, and calculate the calculated information digest value. Comparing with the decrypted information digest value, when the two are the same, the second communication sub-module 421 of the driver layer module 420 returns the handle to the first communication sub-module 413 of the application layer module 410. When the two are different, the driver layer The second communication sub-module 421 of the module 420 does not return a handle to the first communication sub-module 413 of the application layer module 410.
  • the decryption verification sub-module 423 is also used to acquire the program file of the application layer, read the tail of the program file, thereby reading out the asymmetrically encrypted information digest value, and decrypting by using the RSA algorithm to obtain the information digest value.
  • the decryption verification sub-module 423 calculates the information digest value of the program file of the application layer. If the program file of the application layer is in the PE format, the information digest value of the partial content except the DOS header, the PE header and the block table of the PE file is calculated. And comparing the calculated information digest value with the decrypted information digest value.
  • the second communication sub-module 421 returns the handle to the first communication sub-module 413 of the application layer module 410, and the application layer module 410 According to the handle, the driver layer module 420 can be accessed. If the two are different, the driver layer module 420 will reject the application layer module 410 for access.
  • the decryption verification submodule 423 is further configured to decrypt the encrypted program file and decrypt the decrypted program in the input type input and output request packet (IRP_MJ_CREATE) of the created type.
  • the sequence file is verified.
  • the application layer module 410 accesses the driver layer module 420 through the handle, and can read and write the input type request packet (IRP_MJ_READ) and the write type corresponding to the read file (ReadFile) and the write file (WriteFile) through the I/O related function.
  • the IRP of the I/O request packet (IRP_MJ_WRITE), and the IRP of IRP_MJ_READ and IRP_MJ_WRITE are dispatched to the dispatch function of the driver layer module 420, and the driver layer can be read and written.
  • the above-mentioned drive protection method and system use the program file of the application layer to be encrypted, and send the encrypted program file when the input/output request packet is sent, and the driver layer decrypts the encrypted program file, and returns the handle after the verification is passed.
  • the application layer can access the driver layer according to the handle. If the verification fails, the driver layer will deny access to the application layer, ensuring that the legal application layer communicates with the driver layer, preventing the suspicious program from accessing the driver layer, and improving the Drive layer security.
  • the information digest value of the calculation program file the information digest value calculated by the application layer and the information digest value calculated by the driver layer are compared, and the verification operation is convenient; the RSA asymmetric encryption or decryption is adopted, and the security is high.
  • the invention is not to be construed as limiting the scope of the invention. It should be noted that a number of variations and modifications may be made by those skilled in the art without departing from the spirit and scope of the invention. Therefore, the scope of the invention should be determined by the appended claims.

Abstract

本发明实施方式涉及一种驱动保护方法及系统。该驱动保护方法包括以下步骤：对程序文件进行加密，并发送输入输出请求包及加密后的程序文件；接收所述输入输出请求包及加密后的程序文件，并对所述加密后的程序文件进行解密，以及对解密后的程序文件进行验证，若验证通过，则返回句柄，否则不返回句柄。本发明实施方式对应用层的程序文件进行加密，并发送输入输出请求包时发送加密后的程序文件，驱动层对加密后的程序文件进行解密验证，验证通过后，才返回句柄给应用层，应用层根据该句柄可访问驱动层，若验证不通过，则驱动层将拒绝应用层的访问，保证了合法的应用层与驱动层进行通信，防止可疑程序访问驱动层，提高了驱动层的安全性。

Description

驱动保护方法及系统
技术领域
本发明涉及驱动防护领域， 特别涉及一种驱动保护方法及系统。 发明背景
输入输出请求包（ IRP, I/O Request Package )为 Windows内核中的 一种数据结构，它与输入输出相关。上层应用程序与底层驱动层通信时， 应用程序会发送 I/O请求，操作系统将 I/O请求转化为相应的 IRP数据， 不同类型的 IRP数据会根据类型传递到不同的派遣函数中。
IRP具有两个基本属性， 一个是主功能函数（MajorFunction ), 用于 记录 IRP的主要类型， 将 IRP的主要类型与派遣函数相关联， 另一个是 子功能函数（MinorFunction ), 用于记录 IRP 子类型。 操作系统根据 MajorFunction将 IRP派遣到不同的派遣函数中，在派遣函数中还可以继 续判断这个 IRP属于哪种 MinorFunction。 文件 I/O的相关函数， 比如： 创建文件内核对象（ CreateFile )、读文件（ ReadFile )、写文件（ WriteFile ) 等， 会创建相对应的创建类型的输入输出请求包（ IRP_MJ_CREATE )、 读类型的输入输出请求包（ IRP_MJ_READ )、 写类型的输入输出请求包 ( IRP_MJ_WRITE的 IRP )等 IRP。 这些 IRP会被传递到驱动层的派遣 函数中。 其中， 函数 CreateFile用于创建或打开对象， 并返回一个可用 来访问该对象的句柄； 函数 ReadFile用于从文件指针指向的位置开始将 数据读出到一个文件中， 且支持同步和异步； 函数 WriteFile用于将数据 写入一个文件。
在操作系统中， 应用程序想要打开驱动层， 首先需要发送 IRP_MJ_CREATE给驱动层， 驱动层经过相应的派遣函数处理后返回句 柄。 其中， 句柄为一个整数值， 用于标志应用层中应用程序的不同对象 和同类对象中的不同的实例， 如一个窗口、 钮、 图标、 滚动条、 输出设 备、 控件或者文件等， 应用层能够通过句柄访问相应的驱动层。
然而， 若有第三方程序通过工具查看到句柄， 然后通过该句柄打开 驱动层， 如此， 第三方程序就可以向驱动层发送设备驱动层中对 I/O通 道管理的函数（IOCTL ), 达到直接控制驱动层的目的。 若该第三方程序 是恶意软件， 其可在用户电脑上肆意破坏。 发明内容
本发明实施方式提供一种能提高驱动层安全性的驱动保护方法。 一种驱动保护方法， 包括以下步骤：
对程序文件进行加密，并发送输入输出请求包及加密后的程序文件； 接收所述输入输出请求包及加密后的程序文件， 并对所述加密后的 程序文件进行解密， 以及对解密后的程序文件进行验证， 若验证通过， 则返回句柄， 否则不返回句柄。
本发明实施方式还提供一种能提高驱动层安全性的驱动保护系统。 一种驱动保护系统， 包括：
应用层模块， 包括加密子模块和第一通信子模块， 所述加密子模块 用于对程序文件进行加密， 所述第一通信子模块用于发送输入输出请求 包及加密后的程序文件；
驱动层模块， 包括解密验证子模块和第二通信子模块， 所述第二通 信子模块用于接收所述输入输出请求包及加密后的程序文件， 所述解密 验证子模块用于对所述加密后的程序文件进行解密， 以及对解密后的程 序文件进行验证， 若验证通过， 则所述第二通信子模块返回句柄到所述 第一通信子模块， 若验证不通过， 则所述第二通信子模块不返回句柄到 所述第一通信子模块。
上述驱动保护方法及系统， 采用对应用层的程序文件进行加密， 并 发送输入输出请求包时发送加密后的程序文件， 驱动层对加密后的程序 文件进行解密验证， 验证通过后， 才返回句柄给应用层， 应用层根据该 句柄可访问驱动层， 若验证不通过， 则驱动层将拒绝应用层的访问， 保 证了合法的应用层与驱动层进行通信， 防止可疑程序访问驱动层， 提高 了驱动层的安全性。 附图简要说明
图 1为一个实施方式中驱动保护方法的流程图；
图 2为一个实施方式中对程序文件进行加密的具体流程图； 图 3为一个实施方式中对加密后的程序文件进行解密及验证的具体 流程图；
图 4为一个实施方式中驱动保护系统的内部结构示意图。 实施本发明的方式
下面结合具体的实施方式及附图对技术方案进行详细的描述。
如图 1所示， 在一个实施方式中， 一种驱动保护方法， 包括以下步 骤：
步骤 S110, 对程序文件进行加密， 并发送输入输出请求包及加密后 的程序文件。
对应用层的程序文件进行非对称加密， 即对应用程序文件进行非对 称加密。 该实施方式中， 该非对称加密采用 RSA算法。 其中， 非对称加 密就是加密和解密所使用的不是同一个密钥，通常有两个密钥，称为 "公 钥" 和 "私钥"， 它们两个必需配对使用， 否则不能打开加密文件。 "公 钥" 是指可以对外公布的， "私钥" 则不能， 只能由持有人一个人知道。
RSA公钥加密算法就是一个非对称加密算法，它是 1977年由 Ron Rivest、 Adi Shamirh和 LenAdleman开发的， 用于数据加密， 同时也能用于数字 签名的算法， 易于理解和操作， 应用十分广泛， 且 RSA算法加密安全性 高， 不易被破解。
应用层访问驱动层时需发送 I/O请求， 该 I/O请求被转化为输入输 出请求包（IRP ), 同时发送加密后的程序文件， 以便驱动层对该应用层 身份进行验证。
在一个实施方式中， 发送输入输出请求包及加密后的程序文件的步 骤具体为：通过进程发送输入输出请求包，其中该进程的身份标识（PID ) 与加密后程序文件的路径具有对应关系。
在一个实施方式中， 发送输入输出请求包及加密后的程序文件的步 骤具体为： 通过进程发送输入输出请求包， 其中在该进程的进程结构体 ( EPROCESS ) 中存储有加密后程序文件的路径。
应用层通过 I/O相关函数 CreateFile发送访问请求，会创建相对应的 IRP_MJ_CREATE的 IRP, 该 IRP_MJ_CREATE派遣到驱动层中的派遣 函数中。
步骤 S120, 接收该输入输出请求包及加密后的程序文件， 并对该加 密后的程序文件进行解密， 以及对解密后的程序文件进行验证。
在一个实施方式中， 当步骤 S110中通过进程发送输入输出请求包， 而且其中该进程的 PID与加密后程序文件的路径具有对应关系时：
相应地，步骤 S120中接收输入输出请求包及加密后的程序文件具体 为： 通过进程接收所述输入输出请求包， 并且根据该进程的 PID解析出 相对应的加密后程序文件的路径； 根据加密后程序文件的路径， 获取所 述加密后的程序文件。 在一个实施方式中， 当步骤 S110中通过进程发送输入输出请求包， 其中在该进程的进程结构体（EPROCESS ) 中存储有加密后程序文件的 路径时：
相应地， 步骤 S120接收输入输出请求包及加密后的程序文件具体 为： 通过该进程接收所述输入输出请求包， 并且从该进程的 EPROCESS 中解析出加密后程序文件的路径； 根据所述加密后程序文件的路径， 获 取所述加密后的程序文件。
驱动层接收到 IRP及加密后的应用层的程序文件后， 对加密后的应 用层的程序文件进行解密。通过 RSA算法对加密的应用层的程序文件进 行解密。 然后对解密后的应用层的程序文件进行验证， 若验证通过， 则 返回驱动层的句柄到应用层， 应用层根据该句柄可访问驱动层， 若验证 不通过， 则驱动层将拒绝应用层进行访问。
步骤 S130, 判断验证是否通过， 若是， 则执行步骤 S140, 否则执 行步骤 S150。
步骤 S 140, 返回句柄。 返回驱动层的句柄。
步骤 S150, 不返回句柄。
在一个实施方式中， 如图 2所示， 对程序文件进行加密的步骤具体 为：
步骤 S210, 读取程序文件。
首先读取出应用层的程序文件， 该应用层的程序文件为可移植可执 行体 ( PE, Portable Execute )格式时， 读取除 PE文件 DOS头、 PE头 和区块表之外的部分内容。
步骤 S220, 计算该程序文件的信息摘要值。
若应用层的程序文件为 PE格式，则计算读取的除 PE文件 DOS头、 PE 头和区块表之外的部分内容的信息摘要值。 该信息摘要值一般采用 MD5值。
步骤 S230, 对信息摘要值进行非对称加密。
对计算得到的信息摘要值进行非对称加密， 如通过 RSA算法加密。 步骤 S240,将非对称加密的信息摘要值写入到该应用层的程序文件 尾部。
将加密后的信息摘要值写入到应用层的程序文件尾部， 以便和应用 层的程序文件一起发送。
在一个实施方式中， 如图 3所示， 对加密后的程序文件进行解密， 对解密后的程序文件进行验证， 若验证通过， 则返回句柄， 否则结束的 步骤具体为：
步骤 S310, 读取非对称加密后的信息摘要值， 对其进行解密得到信 息摘要值。
获取应用层的程序文件， 读取程序文件尾部， 从而读取出非对称加 密后的信息摘要值， 采用 RSA算法进行解密， 得到信息摘要值。
步骤 S320, 计算程序文件的信息摘要值， 将计算得到的信息摘要值 与解密得到的信息摘要值进行比较。
驱动层计算应用层的程序文件的信息摘要值， 若应用层的程序文件 为 PE文件， PE文件包括 DOS头、 PE文件标志位、 映像文件和可选映 像头， PE文件标志位为 PE头， 映像文件为 PE文件的基本信息， 可选 映像头为区块表， 计算除了 PE文件 DOS头、 PE头和区块表之外的部 分内容的信息摘要值， 将计算得到的信息摘要值与解密得到的信息摘要 值进行比较， 若两者相同， 则返回驱动层的句柄到应用层， 应用层根据 该句柄可访问驱动层， 若两者不同， 则驱动层将拒绝应用层进行访问。
步骤 S330,判断两个信息摘要值是否相同，若是，则执行步骤 S340, 否则执行步骤 S350。 步骤 S340, 返回句柄。
步骤 S350, 不返回句柄。
如图 4所示， 在一个实施方式中， 一种驱动保护系统， 包括应用层 模块 410和驱动层模块 420。
应用层模块 410为应用程序。 应用层模块 410包括相连的加密子模 块 411和第一通信子模块 413。 加密子模块 411用于对程序文件进行加 密， 第一通信子模块 413用于发送输入输出请求包及加密后的程序文件 到驱动层模块 420。
加密子模块 411对应用层的程序文件进行非对称加密， 该实施方式 中， 该非对称加密可以采用 RSA算法。
应用层模块 410访问驱动层模块 420时需通过第一通信子模块 413 发送 I/O请求， 该 I/O请求被转化为输入输出请求包（ IRP ), 同时第一 通信子模块 413发送加密后的程序文件， 以便驱动层模块 420对该应用 层模块 410身份进行验证。
在一个实施方式中， 应用层模块 410通过 I/O相关函数 CreateFile 发送访问请求， 会创建相对应的创建类型的输入输出请求包 ( IRP_MJ_CREATE ) 的 IRP, 该 IRP_MJ_CREATE派遣到驱动层模块 420中的派遣函数中。
驱动层模块 420为驱动程序。 驱动层模块 420包括相连的第二通信 子模块 421和解密验证子模块 423。
第二通信子模块 421用于接收该输入输出请求包及加密后的程序文 件。
在一个实施方式中， 第一通信子模块 413用于通过进程发送输入输 出请求包， 其中该进程的身份标识（PID ) 与所述加密后程序文件的路 径具有对应关系。 相应地， 第二通信子模块 421用于通过该进程接收所 述输入输出请求包， 并且根据该进程的 PID解析出相对应的加密后程序 文件的路径； 根据所述加密后程序文件的路径， 获取所述加密后的程序 文件。
在一个实施方式中， 第一通信子模块 413用于通过进程发送输入输 出请求包， 其中在该进程的进程结构体（EPROCESS ) 中存储有加密后 程序文件的路径。 相应地， 第二通信子模块 421用于通过该进程接收所 述输入输出请求包，并且从该进程的 EPROCESS中解析出加密后程序文 件的路径； 根据所述加密后程序文件的路径， 获取所述加密后的程序文 件。
解密验证子模块 423用于对该加密后的程序文件进行解密， 以及对 解密后的程序文件进行验证， 当验证通过时， 第二通信子模块 421返回 句柄到应用层模块 410的第一通信子模块 413, 当验证不通过时， 第二 通信子模块 421不返回句柄到第一通信子模块 413。
驱动层模块 420的第二通信子模块 421接收到 IRP及加密后的应用 层的程序文件后， 发送给解密验证子模块 423, 解密验证子模块 423对 加密后的应用层的程序文件进行解密，具体可以通过 RS A算法对加密的 应用层的程序文件进行解密。 然后， 解密验证子模块 423对解密后的应 用层的程序文件进行验证， 若验证通过， 则返回句柄到应用层模块 410, 应用层模块 410根据该句柄可访问驱动层模块 420, 若验证不通过， 则 驱动层模块 420将拒绝应用层模块 410进行访问。
优选的实施方式中， 加密子模块 411还用于读取程序文件， 计算程 序文件的信息摘要值， 并对该信息摘要值进行非对称加密， 以及将非对 称加密的信息摘要值写入到该程序文件尾部。
加密子模块 411首先读取出应用层的程序文件， 该应用层的程序文 件为可移植可执行体（PE, Portable Execute )文件， 其中， PE文件包括 DOS头、 PE文件标志位、 映像文件和可选映像头， PE文件标志位为 PE 头， 映像文件为 PE文件的基本信息， 可选映像头为区块表。 加密子模 块 411读取除 PE文件 DOS头、 PE头和区块表之外的部分内容， 再计 算读取的除 PE文件 DOS头、 PE头和区块表之外的部分内容的信息摘 要值， 再对计算得到的信息摘要值进行非对称加密， 最后将加密后的信 息摘要值写入到应用层的程序文件尾部。 其中， 非对称加密可采用 RSA 算法加密。
优选的实施方式中， 解密验证子模块 423还用于读取非对称加密后 的信息摘要值， 对其进行解密得到信息摘要值， 计算该程序文件的信息 摘要值， 将计算得到的信息摘要值与解密得到的信息摘要值进行比较， 当两者相同时， 驱动层模块 420的第二通信子模块 421返回句柄到应用 层模块 410的第一通信子模块 413, 当两者不同时， 驱动层模块 420的 第二通信子模块 421 不返回句柄到应用层模块 410 的第一通信子模块 413。
解密验证子模块 423还用于获取应用层的程序文件， 读取程序文件 尾部，从而读取出非对称加密后的信息摘要值，采用 RSA算法进行解密， 得到信息摘要值。 解密验证子模块 423计算应用层的程序文件的信息摘 要值， 若应用层的程序文件为 PE格式， 则计算除了除 PE文件 DOS头、 PE头和区块表之外的部分内容的信息摘要值，将计算得到的信息摘要值 与解密得到的信息摘要值进行比较， 若两者相同， 则通过第二通信子模 块 421返回句柄到应用层模块 410的第一通信子模块 413, 应用层模块 410 ^据该句柄可访问驱动层模块 420, 若两者不同时， 则驱动层模块 420将拒绝应用层模块 410进行访问。
解密验证子模块 423 还用于在创建类型的输入输出请求包 ( IRP_MJ_CREATE ) 中对加密后的程序文件进行解密及对解密后的程 序文件进行验证。 验证通过后， 应用层模块 410通过句柄访问驱动层模 块 420, 可通过 I/O相关函数读文件（ReadFile )、 写文件 （WriteFile ) 对应的创建读类型的输入输出请求包（ IRP_MJ_READ )和写类型的输 入输出请求包 （ IRP_MJ_WRITE ) 的 IRP , 并将 IRP_MJ_READ 和 IRP_MJ_WRITE的 IRP派遣到驱动层模块 420的派遣函数中，可对驱动 层进行读写操作。
上述驱动保护方法及系统， 采用对应用层的程序文件进行加密， 并 发送输入输出请求包时发送加密后的程序文件， 驱动层对加密后的程序 文件进行解密验证， 验证通过后， 才返回句柄给应用层， 应用层根据该 句柄可访问驱动层， 若验证不通过， 则驱动层将拒绝应用层的访问， 保 证了合法的应用层与驱动层进行通信， 防止可疑程序访问驱动层， 提高 了驱动层的安全性。
另外， 采用计算程序文件的信息摘要值， 比较应用层计算得到的信 息摘要值与驱动层计算得到的信息摘要值，验证操作方便；采用 RSA非 对称加密或解密， 安全性高。 体和详细， 但并不能因此而理解为对本发明专利范围的限制。 应当指出 的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下， 还可以做出若干变形和改进， 这些都属于本发明的保护范围。 因此， 本 发明专利的保护范围应以所附权利要求为准。

Claims

权利要求书
1、 一种驱动保护方法， 包括以下步骤：
对程序文件进行加密，并发送输入输出请求包及加密后的程序文件； 接收所述输入输出请求包及加密后的程序文件， 并对所述加密后的 程序文件进行解密， 以及对解密后的程序文件进行验证， 若验证通过， 则返回句柄， 否则不返回句柄。
2、根据权利要求 1所述的驱动保护方法， 其特征在于， 所述发送输 入输出请求包及加密后的程序文件的步骤具体为：
通过进程发送输入输出请求包， 其中该进程的身份标识（ PID ) 与 所述加密后程序文件的路径具有对应关系；
所述接收输入输出请求包及加密后的程序文件的步骤具体为： 通过该进程接收所述输入输出请求包， 并且根据该进程的 PID解析 出相对应的加密后程序文件的路径；
根据所述加密后程序文件的路径， 获取所述加密后的程序文件。
3、根据权利要求 1所述的驱动保护方法， 其特征在于， 所述发送输 入输出请求包及加密后的程序文件的步骤具体为：
通过进程发送输入输出请求包， 其中在该进程的进程结构体 ( EPROCESS ) 中存储有加密后程序文件的路径；
所述接收输入输出请求包及加密后的程序文件的步骤具体为： 通过该进程接收所述输入输出请求包， 并且从该进程的 EPROCESS 中解析出加密后程序文件的路径；
根据所述加密后程序文件的路径， 获取所述加密后的程序文件。
4、根据权利要求 1所述的驱动保护方法， 其特征在于， 所述对程序 文件进行加密的步骤具体为：
读取程序文件； 计算所述程序文件的信息摘要值；
对所述信息摘要值进行非对称加密；
将非对称加密的信息摘要值写入到所述程序文件尾部。
5、根据权利要求 4所述的驱动保护方法， 其特征在于， 对所述加密 后的程序文件进行解密， 对解密后的程序文件进行验证， 若验证通过， 则返回句柄， 否则不返回句柄的步骤具体为：
读取非对称加密后的信息摘要值， 对其进行解密得到信息摘要值； 计算所述程序文件的信息摘要值， 将计算得到的信息摘要值与解密 得到的信息摘要值进行比较， 若两者相同， 则返回句柄， 否则不返回句 柄。
6、根据权利要求 5所述的驱动保护方法， 其特征在于， 所述非对称 加密或解密采用 RSA算法。
7、根据权利要求 1所述的驱动保护方法， 其特征在于， 对所述加密 后的程序文件进行解密， 以及对解密后的程序文件进行验证的步骤具体 为： 在创建类型的输入输出请求包中对加密后的程序文件进行解密及对 解密后的程序文件进行验证。
8、 一种驱动保护系统， 其特征在于， 包括：
应用层模块， 包括加密子模块和第一通信子模块， 所述加密子模块 用于对程序文件进行加密， 所述第一通信子模块用于发送输入输出请求 包及加密后的程序文件；
驱动层模块， 包括解密验证子模块和第二通信子模块， 所述第二通 信子模块用于接收所述输入输出请求包及加密后的程序文件， 所述解密 验证子模块用于对所述加密后的程序文件进行解密， 以及对解密后的程 序文件进行验证， 若验证通过， 则所述第二通信子模块返回句柄到所述 第一通信子模块， 若验证不通过， 则所述第二通信子模块不返回句柄到 所述第一通信子模块。
9、 根据权利要求 8所述的驱动保护系统， 其特征在于，
所述第一通信子模块用于通过进程发送输入输出请求包， 其中该进 程的身份标识（PID )与所述加密后程序文件的路径具有对应关系； 所述第二通信子模块用于通过该进程接收所述输入输出请求包， 并 且根据该进程的 PID解析出相对应的加密后程序文件的路径； 根据所述 加密后程序文件的路径， 获取所述加密后的程序文件。
10、 根据权利要求 8所述的驱动保护系统， 其特征在于， 所述第一通信子模块用于通过进程发送输入输出请求包， 其中在该 进程的进程结构体（EPROCESS ) 中存储有加密后程序文件的路径； 所述第二通信子模块用于通过该进程接收所述输入输出请求包， 并 且从该进程的 EPROCESS中解析出加密后程序文件的路径；根据所述加 密后程序文件的路径， 获取所述加密后的程序文件。
11、 根据权利要求 8所述的驱动保护系统， 其特征在于， 所述加密 子模块还用于读取程序文件， 计算所述程序文件的信息摘要值， 并对所 述信息摘要值进行非对称加密， 以及将非对称加密的信息摘要值写入到 所述程序文件尾部。
12、根据权利要求 11所述的驱动保护系统， 其特征在于， 所述解密 验证子模块还用于读取非对称加密后的信息摘要值， 对其进行解密得到 信息摘要值， 计算所述程序文件的信息摘要值， 将计算得到的信息摘要 值与解密得到的信息摘要值进行比较， 当两者相同时， 所述第二通信子 模块返回句柄到所述第一通信子模块， 当两者不同时， 所述第二通信子 模块不返回句柄到所述第一通信子模块。
13、根据权利要求 12所述的驱动保护系统， 其特征在于， 所述非对 称加密或解密采用 RSA算法。
14、根据权利要求 12所述的驱动保护系统， 其特征在于， 所述解密 验证子模块还用于在创建类型的输入输出请求包中对加密后的程序文 件进行解密及对解密后的程序文件进行验证。
PCT/CN2012/078041 2011-07-28 2012-07-02 驱动保护方法及系统 WO2013013562A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/156,540 US9317707B2 (en) 2011-07-28 2014-01-16 Method and system for protecting a driver

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2011102139104A CN102902910B (zh) 2011-07-28 2011-07-28 驱动保护方法及系统
CN201110213910.4 2011-07-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/156,540 Continuation US9317707B2 (en) 2011-07-28 2014-01-16 Method and system for protecting a driver

Publications (1)

Publication Number Publication Date
WO2013013562A1 true WO2013013562A1 (zh) 2013-01-31

Family

ID=47575137

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/078041 WO2013013562A1 (zh) 2011-07-28 2012-07-02 驱动保护方法及系统

Country Status (3)

Country Link
US (1) US9317707B2 (zh)
CN (1) CN102902910B (zh)
WO (1) WO2013013562A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105844159A (zh) * 2016-06-21 2016-08-10 北京金山安全软件有限公司 驱动程序隐藏方法、装置和设备
US10990371B2 (en) 2018-01-17 2021-04-27 Crowdstrike, Inc. Device driver non-volatile backing-store installation
US11423186B2 (en) * 2018-01-17 2022-08-23 Crowdstrike, Inc. Verified inter-module communications interface
CN109240713A (zh) * 2018-08-27 2019-01-18 郑州云海信息技术有限公司 驱动安装程序的加密方法、驱动程序的安装方法及装置
CN110378110A (zh) * 2019-06-28 2019-10-25 北京威努特技术有限公司 软件加密处理方法、软件验证方法及装置
CN113032041A (zh) * 2021-03-16 2021-06-25 广州虎牙科技有限公司 一种编码方法、装置、电子设备以及计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1591329A (zh) * 2003-08-25 2005-03-09 联想(北京)有限公司 一种软硬件智能识别和保护方法
US20060069692A1 (en) * 2004-09-28 2006-03-30 Exobox Technologies Corp Electronic computer system secured from unauthorized access to and manipulation of data
CN101008974A (zh) * 2007-01-26 2007-08-01 北京飞天诚信科技有限公司 一种电子文件保护方法及系统
US20080209563A1 (en) * 2007-02-27 2008-08-28 Microsoft Corporation Runtime Security and Exception Handler Protection
US7577985B1 (en) * 2005-02-01 2009-08-18 Symantec Corporation Trusted handler and data association

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7003702B2 (en) * 2002-03-18 2006-02-21 Emc Corporation End-to-end checksumming for read operations
US7024593B1 (en) * 2002-03-18 2006-04-04 Emc Corporation End-to-end checksumming for database environments
US7603484B2 (en) * 2005-04-21 2009-10-13 Microsoft Corporation Protocol for communication with a user-mode device driver
JP4647392B2 (ja) * 2005-05-23 2011-03-09 京セラ株式会社 デバイス制御装置、デバイス制御方法およびプログラム
CN100481101C (zh) * 2006-07-19 2009-04-22 谢朝霞 计算机安全启动的方法
KR100985076B1 (ko) * 2008-04-16 2010-10-04 주식회사 안철수연구소 Ｕｓｂ 디바이스 보안 장치 및 방법
CN101447007B (zh) * 2008-10-31 2011-06-22 东莞市智盾电子技术有限公司 主动式数据安全存储设备的安全对外通讯方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1591329A (zh) * 2003-08-25 2005-03-09 联想(北京)有限公司 一种软硬件智能识别和保护方法
US20060069692A1 (en) * 2004-09-28 2006-03-30 Exobox Technologies Corp Electronic computer system secured from unauthorized access to and manipulation of data
US7577985B1 (en) * 2005-02-01 2009-08-18 Symantec Corporation Trusted handler and data association
CN101008974A (zh) * 2007-01-26 2007-08-01 北京飞天诚信科技有限公司 一种电子文件保护方法及系统
US20080209563A1 (en) * 2007-02-27 2008-08-28 Microsoft Corporation Runtime Security and Exception Handler Protection

Also Published As

Publication number Publication date
US9317707B2 (en) 2016-04-19
CN102902910A (zh) 2013-01-30
CN102902910B (zh) 2013-10-23
US20140129846A1 (en) 2014-05-08

Similar Documents

Publication Publication Date Title
US10652015B2 (en) Confidential communication management
JP4366037B2 (ja) 暗号化された媒体へのアクセス権を制御・行使するシステム及び方法
US8275134B2 (en) Method for guaranteeing security of critical data, terminal and secured chip
US8271804B2 (en) Information processing device, log management apparatus, and log management program product
WO2013013562A1 (zh) 驱动保护方法及系统
JP4501349B2 (ja) システムモジュール実行装置
US20090049307A1 (en) System and Method for Providing a Multifunction Computer Security USB Token Device
US8473740B2 (en) Method and system for secured management of online XML document services through structure-preserving asymmetric encryption
US20100306635A1 (en) Method for Verifying Correct Encryption Key Utilization
US20070255659A1 (en) System and method for DRM translation
TW200832438A (en) Secure co-processing memory controller integrated into an embedded memory subsystem
JP2006209803A5 (zh)
KR20040094724A (ko) 멀티-토큰 실 및 실 해제
TW200816767A (en) System and method for trusted data processing
JP2009087035A (ja) 暗号クライアント装置、暗号パッケージ配信システム、暗号コンテナ配信システム、暗号管理サーバ装置、ソフトウェアモジュール管理装置、ソフトウェアモジュール管理プログラム
JP2005099948A (ja) 情報処理装置、印刷装置、印刷データ送信方法、印刷方法、印刷データ送信プログラム及び記録媒体
US10878113B2 (en) Multiple mailbox secure circuit
JP2008544710A (ja) 暗号化を実現する方法及び装置
US8391495B2 (en) Secure shell used to open a user's encrypted file system keystore
US20230289089A1 (en) Multiple authorization requests from a data storage device
US20230289456A1 (en) Certificates in data storage devices
US20230291548A1 (en) Authorization requests from a data storage device to multiple manager devices
JP5391756B2 (ja) 画像形成装置、情報管理方法、及びプログラム
WO2022206502A1 (zh) 访问数据库的方法和装置
JP4703668B2 (ja) コンテンツ転送方法

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: 12818144

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 16/07/2014)

122 Ep: pct application non-entry in european phase

Ref document number: 12818144

Country of ref document: EP

Kind code of ref document: A1