JP2004509392A - Software Secure Authenticated Channel - Google Patents

Abstract

A secure authenticated channel for software is provided.
A software maker examines his module and determines the range of addresses in memory occupied by that module. The protected range of addresses in memory is predefined so as not to allow changes such as patching by hackers. Each producer distributes a range of addresses describing the protected area and a known suitable version of the module to all other producers who wish to work together. Other producers return the digital signatures of the protected area and these digital signatures are stored in the module of the first manufacturer. As an equivalent, the other creator does the same for his own module. Thereafter, the modules first pass each other a previously created signature in order to realize a secure communication channel between the two modules. Each module is then patched to the other module through signatures and the use of address ranges in the secure area to ensure that communication with the authentic authorized module is taking place. Inspect that there is no. In addition, each module verifies that all entry points in the other modules to be called are in fact protected. If both modules are verified as trustworthy, they can freely call each other. Each module, when called, must verify that it was called from within the protected area of the other module.
[Selection diagram] FIG.

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to tamper resistance of software. More specifically, the present invention relates to a method and apparatus for establishing a Secure Authenticated Channel between two software modules on a system.
[0002]
[Prior art]
In this disclosure, the manufacturer of the device including the information processing unit is referred to as an entity. Certain types of software applications must protect themselves from hacking. For example, licenses require that DVD video playback devices include protection to prevent users from copying DVD movies using a scrambling scheme. More recently, Secure Digital Music Initiative (SDMI), launched by the American Records Association, has published requirements that can only be met by tamper-resistant software.
[0003]
The SDMI requirements assume that a particular application consists of different software modules from different producers. For example, one creator can create an electronic music distribution system that allows secure download of music over the Internet, such as the IBM Electronic Media Management System ™, and a second creator can use the SONY ( R) Software that supports secure flash memory music playback devices such as Memory Stick Walkman ™ can be created. Consumers want to place purchased and downloaded music on their flash memory music players.
[0004]
The SDMI requirements specification describes the concept of a Secure Authenticated Channel or SAC between two compliant software modules. There, a model has been proposed that describes the communication between two modules, created by two different producers, who wish to securely call each other's entry points on the same machine. FIG. 1 shows a secure authenticated channel (100) including at least two modules (102, 104) loaded into the memory of the same machine (106). These modules are created by different vendors and communicate with each other using published APIs. There is no protection against hacking programs that steal music content between themselves to make illegal copies. For that reason, SDMI requires a mechanism for authentication and a mechanism for securing communications between these two modules (secure authenticated channel).
[0005]
FIG. 2 shows the security content (200) of a prior art software architecture designed in accordance with the SDMI requirements. The software module includes a public key certificate (202), a public key (204), and a private key (206). For example, SAC is implemented as follows.
1. Each module is responsible for its own integrity.
2. Each module has a standard public key certificate (202) proving its public key (204).
3. Each module has a secret key (206) to be kept secret.
4. Create a session key between the modules using a standard public key protocol.
5. Data and controls subsequently exchanged between modules are encrypted using a session key (not shown in FIG. 2) to prevent unauthorized tampering or eavesdropping on the data.
[0006]
[Problems to be solved by the invention]
In essence, this approach is a well-known protocol that secures communication between two parties. Unfortunately, there are some problems with using this approach for SAC. In a secure communication protocol, the attacker would be outside the communication pipeline of the two parties communicating, but not the software. Hackers can see both modules and patch one or both, so keeping private keys secret is a real problem. Similarly, checking self-integrity to make sure that each module has not been patched or tampered with is very difficult. Thus, this protocol is as weak as the weakest link and will break the SAC if one of the secret keys is known or if one module is successfully patched.
[0007]
[Means for Solving the Problems]
The present invention provides a method for peer-to-peer authentication of software modules on a single machine. The method includes the steps of determining a protected range of addresses occupied by a software module, verifying the integrity of the code within the protected range, and all of the function calls performed by the module. Verifying that returns from the range and returns to the range.
[0008]
According to a preferred embodiment of the present invention, there is provided a more efficient and effective method, apparatus and product for securing and verifying the authenticity and security of a connection between two software modules. .
[0009]
Advantageously, there is provided an improved system and method for controlling the distribution of software that allows a module to distinguish between authorized and unauthorized modules.
[0010]
Preferably, the present invention provides a new secure authenticated channel (SAC). According to a preferred embodiment, it is an advantage of this protocol that each module is not responsible for its own integrity, but for the integrity of the other modules. An inherent disadvantage of software communication protocols is that both implementations of SAC are visible to each other and to attackers. Advantageously, according to the invention, the disadvantages can be turned into advantages.
[0011]
According to a preferred embodiment, the invention is implemented by first each software producer testing his module and determining the range of addresses in memory occupied by the module. Determine which ranges of addresses in memory are not allowed to be patched by hackers. Such a range is called a protected area. Typically, a protected area contains all the program code for a module and some of the data required to accomplish the functions of the program code.
[0012]
In modern programming techniques, software modules are often written as location-independent code. Eventually, the address of the module is resolved during the loading of the final product in the memory map. Preferably, because of the location-independent code, the absolute address and length of the protected area are determined at run time. For this reason, it is preferably possible to specify a base address and length using the beginning of the code segment as a relative base. Preferably, if no address range is provided, the entire code segment is defaulted.
[0013]
According to a preferred embodiment, each producer then distributes the known appropriate version of the address range and module describing the protected area to all other producers who wish to cooperate with each other. . Preferably, the other producers return digital signatures of the secure area, and these digital signatures are stored in the module of the first producer. Preferably, a signature is calculated for the protected area machine code instructions. Preferably, all of this is done during manufacturing, before the module is deployed to the field.
[0014]
Preferably, equivalently, other producers do the same for their own modules. To provide a secure communication channel between two modules, modules according to one preferred embodiment of the invention first pass a previously created signature to each other. This can be done when the module actually works in the field, since the signature is not secret. In an alternative preferred embodiment of the present invention, each module contains a copy of the signature of the other module that is expected to communicate during actual operation in the field.
[0015]
Thereafter, in accordance with a preferred embodiment, each module communicates with the other through a signature and use of an address range within the secure area to ensure that communication is taking place with the authentic authorized module. Verify that no other modules have been patched, such as by verifying the digital signature with respect to the address ranges of the modules.
[0016]
Preferably, the modules are free to call each other if both modules are verified as trusted. Preferably, each module, when called, verifies that it was called from within a protected area of another module. Also, in a preferred embodiment of the present invention, before calling an entry point in another module, the module verifies that the function it intends to call is actually in the protected area of the target module. These checks are to prevent the attacker from loading the two modules into memory, waiting for the signature check to complete, and then calling the entry point of any module from within the third module. Things.
[0017]
According to another aspect, the present invention is a computer readable medium comprising instructions for peer-to-peer authentication of a software module on a single machine, wherein the protected range of addresses occupied by the software module. Instructions to verify the integrity of the code within the protected range, and instructions to verify that all function calls performed by the module originate from and return to the range. And a computer readable medium comprising:
[0018]
According to another aspect, the present invention is a system for peer-to-peer authentication of a software module on a single machine, the determining unit determining a protected range of an address occupied by the software module. A verification unit for verifying the integrity of the code within the protected range, and a second verification for verifying that all function calls performed by the module originate from and return to the range. And a system comprising the unit.
[0019]
Preferred embodiments of the present invention will now be described, by way of example only, with reference to the drawings.
[0020]
BEST MODE FOR CARRYING OUT THE INVENTION
Exemplary Embodiment-Secure Authenticated Channel of Software
This embodiment includes a method of detecting tampering and replacement of a module and verifying the integrity of a computer program code module in a computer to prevent hacking of the program module. Specifically, each program module is responsible for verifying the integrity of other program code modules. In other words, independent master modules check each other without a master-slave relationship.
[0021]
In an embodiment of the present invention, a new secure authenticated channel (SAC) is provided. The advantage of this protocol is that each module is not responsible for its own integrity, but for the integrity of the other modules. The inherent disadvantage of traditional software communication protocols, that both sides of the SAC are visible to each other and to other parties, including attackers, is now turned into advantage.
[0022]
FIG. 3 includes a flow diagram (300) illustrating a preferred embodiment of the present invention for generating a module signature. First, each software maker inspects his or her module, either manually or automatically, and determines the range of addresses in memory occupied by the module (302). A determination is made as to which address range in memory must be kept complete due to the possibility of a hacker attack (304). Alternatively, a determination is made as to which range of addresses in the memory contains the main function of the module. This range includes all calls made to other modules utilizing the SAC, and such a range is called a protected area. Typically, a protected area contains all the program code for a module and some of the data required to accomplish the functions of the program code.
[0023]
Next, each producer distributes (306) a known appropriate version of the module and the address range describing the protected area to all other producers who wish to cooperate with each other. Other producers return the digital signature for the secure area (308). Preferably, the signature is generated by hashing the entire storage area and using that hash for the digital signature. Thereafter, the digital signature provided by the other producer of the other module is stored (310) in the module of the first producer, and the revised software module is forwarded to the producer of the software module. Also, the range of addresses is stored in the module of the first producer. This is to allow the signature to be correctly verified and to determine the entry point of the calling routine and the called routine. In other words, the SAC instructs the module to identify its expected entry point and its signed area. Preferably, all of the above steps are performed before the module is deployed to the field during manufacturing. As an equivalent, other producers do the same for their own modules.
[0024]
FIG. 4 illustrates the invention in accordance with a preferred embodiment in a flow diagram (400) illustrating an improved software module peer-to-peer integrity check. Next, description of the basic operation of the integrity check will be described. To implement a secure communication channel between the two modules, the modules first pass each other a previously created signature (402). Each module is then patched to the other module through signatures and the use of address ranges in the secure area to ensure that communication is taking place with the authentic authorized module. It is checked that it has not been performed (404). The signature is based on a hash of the code within the specified address range. Signatures, address ranges, and available APIs are permanently stored in each module and retrieved for signature verification. During verification, recompute the hash for the specified address range. As a result, it is determined whether the code within the specified address range is genuine. If the code is patched, the supplied address range has a different hash and signature verification fails. The starting point of a function call can be easily determined by examining the return address of the function on the stack. In addition, each module verifies that all entry points in the other module to be called are in fact in the protected area of the other module. To accomplish this, all modules search the protected storage of other modules, for example, by incorporating the information into other modules or dynamically querying other modules. If they are not verified as authentic modules, the process ends. Otherwise, if both modules are verified as trustworthy (406), the modules are free to call each other (408). However, each module, when invoked, preferably verifies that it was invoked from within the protected area of another module (410). If the calling module has not called from within the storage protected area, the process ends. Otherwise, if called from the protected area of another module, communication between the modules is continued (412) to accomplish the task. Therefore, all attempts to attack software modules are broken. The called module determines that the calling module is calling from the storage protected area address space by the following processing. All function calls rely on the return address left on the stack. This is how the function returns to the caller. As a result, the return address is used to determine whether the caller is within the specified protected area. In other words, module B can ensure that module A is only called from within the address range verified by module B during the initial signature verification process. This is shown in FIG.
[0025]
FIG. 5 illustrates a memory space (500) of a computer system including space occupied by software modules including a storage protection area according to a preferred embodiment of the present invention. The software module includes, for example, a code space defined by (504) and (506). The module includes a protected area (506) that defines an address range that must be protected from patching by hackers. The function call (508) is shown with the return address left on the stack (510).
[0026]
[About high-level overview]
A high level overview of the present invention is presented in accordance with a preferred embodiment.
1. Due to the nature of the processing, transmission of secret information such as secret keys is not required.
2. Any known cryptographic means may be used to create a digital signature. The term "digital signature" must be interpreted in the broadest sense. Each producer can determine what constitutes a digital signature. The digital signature can be a standard RSA digital signature or a DSA digital signature. In other words, data within the range of the address is hashed using a cryptographic hash such as SHA-1, and the hash is signed. In general, digital signatures only provide a single bit output that indicates the validity of the data in question. Therefore, the code protection provided thereby tends to be broken fairly easily by attackers. Thus, advantageously, the present invention provides an alternative use of what is referred to as a digital signet. Signets provide a string of bits as an output, rather than the usual single bits of a signature, and can be used as an alternative to signatures because they are stronger in code integrity applications. Further, the signet can be part of the code itself, which facilitates code protection. Signet technology is taught in U.S. Patent Nos. 6,038,316 and 5,978,482, the teachings of which are incorporated herein by reference. All such solutions fall within the scope of the invention.
3. Preferably, the present invention includes a tool for converting an old computer program code module into a new program code module that is verified via a new signature.
4. Verification can be performed on a one-way basis. In other words, some modules must be verified as usable without verification. The protocol described herein allows for the proper solution of modules such as compression modules that do not need security on their own, but only need security when connecting to another module.
5. One of the problems associated with digital signatures for address ranges in virtual memory is the fact that operating system loaders may relocate modules to different base addresses in the event of a collision. . During this relocation, the loader performs modifications on some instructions that reference absolute addresses in the code. As a result, there is a need for a special hashing technique that preferably temporarily reverts these changes to normal form, so that the hash of the address range always returns the same value regardless of the absolute base address of the module. This technique is taught in US patent application Ser. No. 09 / 352,285, a copy of which is provided herein.
6. In the preferred embodiment, each module is responsible for the integrity of the other modules. However, this does not mean that there is no self-integrity logic in each module for other reasons. Even a module having self-maintenance is included in the scope of the present invention.
7. The preferred embodiment has no protection against the wrongdoing of the producers who appear in the present invention. Therefore, producers must form a legal relationship with each other, such as by contract, in order to protect their rights to agree to participate in this system.
8. Preferably, there is no session key and there is no overhead associated with encrypting data on one side of the interface and decrypting it on the other side as in the prior art.
9. This protocol is as strong as the strongest link. If one module is successfully hacked, the other complete module will detect that fact because the signatures do not match. In this case, the second module refuses to participate in the data exchange.
[0027]
[Another embodiment-an embodiment of signature generation]
As explained above, the software secure authentication process includes a process where each producer communicates with all other producers to enable this protocol. In order to realize the certification of the module, several embodiments are conceivable. In particular, to assist in the verification process, a certification authority is provided to perform the generation and storage of the signatures in the module on behalf of all producers. Of course, this requires the producer to agree on the technology used for digital signatures. An alternative embodiment includes a distributed signature generation process. In distributed processing, there are multiple certificate authorities and individual producers signing modules using their own signature technology.
[0028]
[Another Embodiment-Conversion Tool]
Unfortunately, some authors may not agree to establish a protocol as described. This possibility is addressed in advance by providing a tool that can convert a non-compliant module into a module that performs the steps required by the protocol. Specifically, the tool adds an additional entry point to the module to perform a cross-module signature exchange and replaces all other entry points in the module with the caller's protected area Convert to an entry point to check to make sure it comes from. Of course, the converted module will be the module to be signed.
[0029]
[Another Embodiment One-Way Integrity Check]
In another embodiment, this protocol is used in a one-way mode. There are certain software modules that do not care about the nature of the calling entity, such as the calling module, for example, a music compression module. There is no security problem with that function, ie, a music compression module that performs music compression for something. On the other hand, in electronic music distribution systems that are entrusted with music and usually require limited copying, the compression module to which the song is about to be transmitted is actually a good compression module and the user's disk It is of interest that the program is not a hacked program that steals additional songs by illegally writing songs to them. In that case, the electronic music distribution module requires a signature from the compression module, but not vice versa.
[0030]
[Another Embodiment Periodic Signature Check]
Although more difficult for hackers, hackers may connect to the running process after the signature check has been performed and then insert their code patch at that time. Thus, in one embodiment, a signature check can be performed to detect newly inserted patches, periodically, randomly, or each time a module is used. This can be done based on elapsed time or based on the actual number of calls / returns across the protected interface. Since many digital signatures are relatively expensive, one embodiment of the present invention further provides for subsequent digital signature verification to be performed by cheaper means, such as simply recording the first hash and determining whether the new hash is different. This can be done by detecting Note that in the broad definition of digital signatures contemplated herein, the first simple check of the hash is not a particularly strong check, but is a type of "digital signature check".
[0031]
[Conclusion]
More efficient (1) to secure and verify the authentication of data files, (2) to establish a secure authenticated channel, and (3) to secure communication between the two modules. Exemplary methods, apparatus, and products have been described in accordance with various embodiments of the present invention that overcome many of the limitations of the prior art.
[0032]
[Discussion of options for hardware and software embodiments]
The invention can be implemented as hardware or software or a combination of hardware and software, as known to those skilled in the art. A system or method according to a preferred embodiment combines separate elements or means to perform the described or claimed individual functions or steps, or combines the execution of any of the described or claimed functions or steps. It can be implemented in a single computer system having one or more elements or means, or located in a distributed computer system interconnected by suitable means known to those of skill in the art.
[0033]
According to a preferred embodiment, the invention is not limited to a particular type of computer system. As is well known to those skilled in the art, the present invention can be used with all general-purpose computers arranged to perform the described functions and method steps. As known to those skilled in the art, such computer operations described above may be through a computer program included in a medium used under the operation or control of the computer. As is known to those skilled in the art, computer readable media that can hold, contain, or be used to distribute computer program products include computer memory products, such as embedded memory. It can be a computer accessory or a portable medium such as a disk.
[0034]
The invention is not limited to any particular computer program or logic or language or instructions, as known to those skilled in the art. The invention can be implemented using any such suitable programs, logic, languages and instructions. Such computer systems include a computer readable medium that allows a computer to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium, limiting the disclosed invention. No, can be included. Computer readable media can include non-volatile memory, such as ROM, flash memory, Flexible Disk®, disk drive memory, CD-ROM, and other persistent storage. In addition, computer readable media may include, for example, volatile storage such as RAM, buffers, cache memory, and network circuits.
[0035]
Further, the computer readable medium may include computer readable information in a temporary state medium, such as a network link and / or a network interface that allows the computer to read the computer readable information, such as a wired or wireless network.
[0036]
In summary, software producers examine their modules and determine the range of addresses in memory that they occupy. The protection range of the addresses in the memory is predefined so as not to allow a hacker to make changes such as patching. Each producer distributes a known good version of the address range and module describing the protected area to all other producers who wish to cooperate. Other producers return the digital signatures of the secure area, and these digital signatures are stored in the first producer's module. As an equivalent, the other producer does the same for his own module. The modules then first pass each other a previously created signature to provide a secure communication channel between the two modules. Each module is then patched to the other module through signatures and the use of address ranges in the secure area to ensure that communication with the authentic authorized module is taking place. Inspect that there is no. In addition, each module verifies that all entry points in the other modules to be called are in fact protected. If both modules are verified as trustworthy, they can freely call each other. However, when called, each module first verifies that it was called from within the protected area of the other module.
[Brief description of the drawings]
FIG.
FIG. 1 shows a secure authenticated channel (100) implemented on a single machine as found in the prior art.
FIG. 2
FIG. 3 is a diagram showing security contents (200) of a software module described in a requirement specification of a conventional SDMI.
FIG. 3
FIG. 7 is a flow diagram (300) of module signature generation according to a preferred embodiment of the present invention.
FIG. 4
FIG. 7 is a flow diagram (400) depicting improved software module peer-to-peer integrity checking according to a preferred embodiment of the present invention.
FIG. 5
FIG. 4 is a diagram illustrating a memory space (500) of a computer system including a space occupied by a software module, including a protected area.

Claims (33)

A method for peer-to-peer authentication of a software module on a single machine, comprising:
Determining a protected address range occupied by the software module;
Verifying the integrity of the code within the protected range;
Verifying that function calls performed by the module originate from and return to the range;
A method that includes The method of claim 1, wherein the authentication method is performed between two modules such that each module authenticates the other module. 3. The method of claim 2, wherein one or both of the modules arrange one or more mechanisms for self-integrity testing. 4. The method according to claim 1, further comprising the step of distributing the protected address ranges and software modules to an entity using the authentication method. The method of claim 4, further comprising receiving a revised software module returned with a digital signature for the protected address range. The method of claim 5, wherein the digital signature comprises a digital signature selected from the group of digital signatures consisting of an RSA signature, a DSA signature, a cryptographic hash such as SHA-1 to be signed, and a digital signet. The method of claim 5 or 6, further comprising a tool for converting non-compliant software modules into compliant software modules. The method of claim 5, further comprising a signature based on a canonical hash independent of the location of the module in memory. The digital signature is verified using a verification technique selected from a group of verification techniques consisting of periodic, random, and each time a module is used, wherein the verification is performed during operation of the software module. 9. The method according to claim 5, which is performed. Module signatures are generated and stored via a plurality of embodiments, which embodiments generate and store the signatures of all producers, and a plurality of certification authorities and producers 10. The method according to any of claims 5 to 9, comprising an embodiment selected from the group of embodiments consisting of distributed embodiments for distributing signature generation and storage between them. The method according to any of the preceding claims, further comprising the step of verifying that all called functions are within the verified protected range. A computer-readable medium containing instructions for peer-to-peer authentication of a software module on a single machine,
Instructions for determining the protected range of addresses occupied by the software module;
Instructions for verifying the integrity of the code within the protected range;
Instructions verifying that a function call performed by the module originates from and returns to the range;
A computer readable medium including: 13. The computer-readable medium of claim 12, wherein the authentication instructions are executed between two modules such that each module authenticates the other module. 14. The computer-readable medium of claim 13, wherein one or both of the modules arrange one or more mechanisms for self-integrity checking. 15. The computer-readable medium of claim 12, further comprising instructions for distributing the protected address range and software module to an entity using the authentication method. The computer-readable medium of claim 15, further comprising instructions for receiving a revised software module returned with a digital signature for the protected address range. 17. The computer-readable medium of claim 16, wherein the digital signature comprises a digital signature selected from the group consisting of a digital hash, such as an RSA signature, a DSA signature, a signed SHA-1 and a digital signet. The computer-readable medium of claim 16 or claim 17, further comprising a tool for converting a non-compliant software module into a compliant software module. 17. The computer-readable medium of claim 16, further comprising a signature based on a canonical hash independent of the location of the module in memory. The digital signature is verified using a verification technique selected from a group of verification techniques consisting of periodic, random, and each time a module is used, wherein the verification is performed during operation of the software module. 20. The computer readable medium according to claim 16 being executed. Module signatures are generated and stored via a plurality of embodiments, which embodiments generate and store the signatures of all producers, and a plurality of certification authorities and producers 21. A computer-readable medium according to any of claims 16 to 20, including an embodiment selected from the group of embodiments consisting of distributed embodiments for distributing signature generation and storage amongst. 22. The computer readable medium of any of claims 12 to 21, further comprising verifying that all called functions are within a verified protected range. A system for peer-to-peer authentication of software modules on a single machine,
A determining unit for determining a protected range of an address occupied by the software module;
A verification unit for verifying the integrity of the code within the protected range;
A second verification unit for verifying that function calls performed by the module originate from and return to the range;
Including the system. 24. The system of claim 23, wherein the authentication is performed between two modules such that each module authenticates the other module. 25. The system of claim 24, wherein one or both of the modules arrange one or more mechanisms for self-integrity checking. 26. The system according to claims 23 to 25, further comprising a sending unit that distributes the protected address range and software module to an entity using the authentication method. 27. The system of claim 26, further comprising a receiving unit for receiving a revised software module returned with a digital signature for the protected address range. 28. The system of claim 27, wherein the digital signature comprises a digital signature selected from the group of digital signatures including an RSA signature, a DSA signature, a cryptographic hash such as SHA-1 to be signed, and a digital signet. 29. The system of claim 27 or claim 28, further comprising a tool unit for converting a non-compliant software module into a compliant software module. 28. The system of claim 27, further comprising a signature based on a regular hash that is independent of the location of the module in memory. The digital signature is verified using a verification technique selected from a group of verification techniques, including periodic, random, and each time a module is used, wherein the verification is performed during operation of the software module. 31. The system according to claims 27 to 30, which is implemented. Module signatures are generated and stored via a plurality of embodiments, which embodiments generate and store the signatures of all producers, and a plurality of certification authorities and producers 32. The system according to any one of claims 27 to 31, comprising an embodiment selected from the group of embodiments consisting of distributed embodiments for distributing signature generation and storage between them. 33. The system according to any of claims 23 to 32, further comprising a verification unit for verifying that all called functions are within the verified protected range.

Images