EP1368737A2 - Software für einen gesicherten authentifizierten kanal - Google Patents
Software für einen gesicherten authentifizierten kanalInfo
- Publication number
- EP1368737A2 EP1368737A2 EP01963228A EP01963228A EP1368737A2 EP 1368737 A2 EP1368737 A2 EP 1368737A2 EP 01963228 A EP01963228 A EP 01963228A EP 01963228 A EP01963228 A EP 01963228A EP 1368737 A2 EP1368737 A2 EP 1368737A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- module
- modules
- range
- signatures
- signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
- 238000000034 method Methods 0.000 claims description 43
- 230000006870 function Effects 0.000 claims description 22
- 238000012795 verification Methods 0.000 claims description 13
- 238000003860 storage Methods 0.000 claims description 6
- 230000007246 mechanism Effects 0.000 claims description 5
- 230000000737 periodic effect Effects 0.000 claims description 5
- 238000004891 communication Methods 0.000 abstract description 15
- 230000000694 effects Effects 0.000 abstract description 4
- 230000008569 process Effects 0.000 description 10
- 230000006835 compression Effects 0.000 description 6
- 238000007906 compression Methods 0.000 description 6
- 238000004590 computer program Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000009826 distribution Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 239000012467 final product Substances 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
-
- 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
- G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
Definitions
- the invention relates to so tware tamper resistance . More particularly, the invention provides a method and apparatus for establishing a Secure Authenticated Channel between two software modules on a system.
- SDMI Secure Digital Music Initiative
- one manufacturer might produce an electronic music distribution system that allows the secure downloading of music over the Internet, like the IBM Electronic Media Management System TM.
- a second manufacturer might produce software supporting a secure flash memory music player, like the Sony Memory Stick Walkman TM. The consumer would like the music he has purchased and downloaded to be placed on his flash memory music player.
- FIG. 1 illustrates a Secure Authenticated Channel (100) which comprises at least two modules (102, 104) loaded into memory on the same machine (106) .
- modules are created by different vendors and communicate which each other using their public APIs.
- SDMI requires a mechanism of authentication and a mechanism to secure the communication between these two modules - the Secure Authenticated Channel .
- FIG. 2 illustrates the security contents (200) of a prior art software architecture that have been designed in response to SDMI requirements .
- the software module contains a public key certificate (202) , a public key (204) and a private key (206) .
- the SAC is implemented as follows:
- Each module is responsible for its own integrity.
- Each module has a standard public-key certificate (202) that certifies its public key (204) .
- Each module has a private key (206) which it must keep secret.
- a standard public-key protocol is used to establish a session key between the modules .
- Subsequent data and control passed between the modules is encrypted with a session key (not shown in FIG. 2) to prevent illegal tampering with the data, or eavesdropping.
- the invention provides a method for peer to peer authentication of a software module on a single machine, the method comprising the steps of; determining a protected range of addresses that a software module occupies; verifying the integrity of code in said protected range; and verifying that all function calls performed by that module originate from and return to that range.
- An improved system and method for controlling distribution of software is preferably provided that enables the modules to distinguish between authorized and unauthorized modules .
- the invention preferably provides a new Secure Authenticated Channel or SAC.
- the strength of this protocol is that each module, rather than being responsible for its integrity, is responsible for the integrity of other modules.
- the fundamental weakness of a software communication protocol is that both implementations of the SAC are visible to each other and to an attacker. Therefore, the invention preferably converts what would be a weakness into a strength.
- the invention is implemented in accordance with a preferred embodiment firstly by each software manufacturer examining their module and determining the range of addresses in memory which the module occupies. A decision is made about which ranges of addresses in memory should not be allowed to be patched by hackers. Such a range is called a protected area. Typically, the protected area contains all the program code of the module, and some of the data necessary to accomplish the functions of the program code.
- the other manufacturers preferably do the same with their own modules.
- the modules In order to effect a secure communication channel between two modules, the modules, according to one preferred embodiment of the present invention, first pass each other the signatures previously produced. This can happen when the modules are actually run in the field, because the signatures are not secret .
- each module contains copies of the signatures of the other modules that it expects to communicate with during actual run in the field.
- each module checks that the other module has not been patched by verifying the digital signature, such as with respect to the address range of the other module .
- each module when it is called preferably verifies that it was called from within the protected area of the other module.
- a module makes sure that the function it intends to call is in fact within the protected area of the target module.
- the invention provides a computer readable medium comprising instructions for peer to peer authentication of a software module on a single machine, the computer readable medium comprising instructions for: determining a protected range of addresses that a software module occupies ; verifying the integrity of code in said protected range; and verifying that all function calls performed by that module originate from and return to that range.
- the invention provides a system for peer to peer authentication of a software module on a single machine, the system comprising: a determination unit for determining a protected range of addresses that a software module occupies; a verification unit for verifying the integrity of code in said protected range; and a second verification unit for verifying that all function calls performed by that module originate from and return to that range .
- FIG. 1 illustrates a Secure Authenticated Channel (100) implemented on a single machine as found in the prior art .
- FIG. 2 illustrates the security contents (200) of a software module as described in the prior art SDMI specification.
- FIG. 3 is a flow diagram (300) for generation of module signatures in accordance with a preferred embodiment of the present invention.
- FIG. 4 is a flow diagram (400) showing the improved software module peer to peer integrity checking in accordance with a preferred embodiment of the present invention.
- FIG. 5 illustrates the memory space (500) of a computer system including the space occupied by a software module including a protected area.
- the embodiment comprises a method of verifying the integrity of a computer program code module within a computer to detect tampering or substitution of the module, and thus to prevent hacking of the program module.
- each program module is responsible for the verification of the integrity of the other program code modules.
- independent peer modules check each other without a master-slave relationship .
- the embodiment of the present invention provides a new Secure Authenticated Channel or SAC.
- SAC Secure Authenticated Channel
- the strength of this protocol is that each module, rather than being responsible for its integrity, is responsible for the integrity of other modules.
- a traditionally fundamental weakness of a software communication protocol is now turned into a strength in that both sides of the SAC are visible to each other and to other parties, including even an attacker.
- FIG. 3 comprises a flow diagram (300) illustrating a preferred embodiment of the present invention for generation of module signatures .
- each software manufacturer either manually or automatically examines their module and determines the range of addresses (302) in memory which the module occupies .
- a determination is made about which ranges of addresses in memory should be kept intact (304) because of the potential for damaging attacks by hackers.
- a determination is made about which ranges of addresses in memory comprises the main functionality of the module.
- This range includes all outgoing calls to other modules which make use of the SAC.
- Such a range is called a protected area.
- the protected area contains all the program code of the module, and some of the data necessary to accomplish the functions of the program code .
- each manufacturer delivers the range of addresses describing the protected area and a known good version of their module (306) to every other manufacturer they want to interoperate with.
- the other manufacturers return digital signatures (308) on the protected area.
- the signatures are preferably generated by hashing the entire protected area and using that hash for a digital signature .
- these digital signatures are stored in the first manufacturer's module (310) as supplied by the other manufacturers of the other modules and the amended software module is forwarded back to the manufacturer of the software module.
- the range of addresses is stored in the first manufacturer's module. This is so that it is possible to correctly verify the signature, and determine the entry points of the calling and called routines.
- the SAC preferably directs a module to reveal its exported entry points and its signed area. All of the preceding steps preferably occur at manufacturing time and before the modules have been deployed in the field.
- the other manufacturers do the same with their own other modules .
- FIG. 4 illustrates the invention according to a preferred embodiment in a flow diagram (400) showing improved software module peer to peer integrity checking.
- a description of the basic operation of the integrity checking will be described.
- each module checks (404) that the other module has not been patched.
- the signature is based on the hash of the code in the specified address ranges.
- the signature, the address ranges and the available APIs are permanently stored in each module and are retrieved for signature verification. During verification, the hash on the specified address range is recalculated.
- the modules each further verify that, all the entry points in the other module they intend to call are in fact within the protected area of the other module. In order to accomplish this, every module retrieves the other module's protected area - for example by having that information built in or by dynamically querying the other module. If they are not verified as being authentic modules then the process terminates. Otherwise, in the event that both modules are verified (406) as being trustworthy, the modules now can call each other freely (408) .
- each module when it is called preferably verifies that it was called from within the protected area of the other module (410) . If the calling module is not calling from its protected area then the process terminates. Otherwise, if called from the protected area of the other module, then communication continues (412) between the modules to accomplish a task. Therefore, any attempt to attack the software modules is defeated.
- a called module determines that a ' calling module is calling from the protected area address space by the following process. Every function call depends on a return address being left on a stack. This is how a function returns to a caller. As a consequence, that return address is used to make sure that the caller is within the specified protected area. In other words, module B can make sure that it is called by module A only from within the address range that module B verified during the initial signature verification piocess. This is shown in FIG. 5.
- FIG. 5 illustrates the memory space (500) of a computer system including the space occupied by a software module including a protected area in accordance with a preferred embodiment of the present invention.
- the software module comprises a code space defined by (504) and (506) for example.
- the module contains a protected area (506) that defines an address range that must be protected against being patched by hackers.
- a function call (508) is shown with a return address being left on a stack (510) .
- digital signature should be interpreted most broadly. Each manufacturer may decide for themselves what constitutes a digital signature. It could be a standard RSA or DSA digital signature, in other words, the data in the range of addresses are hashed with a cryptographic hash such as SHA-1, and the hash would then-bs signed. Because digital signatures generally produce only a single bit output indicating the validity of the suspect data, the code protection they provide tends to be defeated fairly easily by attackers. Hence, the invention preferably provides for an alternative use of what is called a digital signet.
- a signet may be used instead of signatures, because signets are stronger in code integrity applications as they provide a string of bits as output, rather than the typical single bit of the signature.
- signets may be part of the code itself which furthers the code protection function. Signet technology is taught in US Patents 6,038,316 and 5,978,482, the teachings of which are incorporated herein by reference . All such solutions are within the scope of thirf invention.
- the invention preferably includes a tool to convert old computer program code modules to new verified program code modules via a new signature .
- the verification can be performed on a one-way basis. In other words, some modules may be used without verification, while others must be verified.
- the protocol described herein allows for a sensible solution for modules like compression modules, that need no security for themselves, but need it only when connected to another module .
- One problem related to digital signatures on address ranges in virtual memory is the fact that the operating system loader might relocate a module to a different base address in case of a collision. During this relocation, the loader performs fix-ups on certain instructions in the code which reference absolute addresses. As a consequence, a special hashing technique is preferably required which temporarily reverts these changes to a canonical form so that a hash of an address range always returns the same value, no matter what the absolute base address of the module .
- each module is responsible for the integrity of the other, that is not to say that there is no self-integrity logic for other reasons. Modules also having self-integrity are certainly within the scope of the present invention.
- the software secure authentication process comprises a process wherein each manufacturer has to communicate with every other manufacturer to enable the protocol .
- a certifying agency is provided that performs the generation and storage of signatures in the modules on behalf of all manufacturers. Of course, this requires that manufacturers agree on the technology used for the digital signatures .
- An alternate implementation comprises a distributed signature generation process.
- a distributed process provides for a plurality of certifying agencies and individual manufacturers signing modules for themselves with their own signing technologies.
- the protocol As described. Therefore, this possibility is anticipated and by providing a tool that can transform a non-compliant module into one that performs the necessary steps in the protocol.
- the tool adds an additional entry point to the module to perform the cross module signature swapping, and also transforms all the other entry points in the module into entry points that check to make sure their caller is coming from the other module's protected area.
- the transformed module would be the one that would be signed.
- the protocol is used in a one-way mode.
- music compression modules that are unconcerned with the nature of the calling entity, such as a calling module.
- music compression modules performing their function, i.e., compressing music for anyone.
- an electronic music distribution system which has been entrusted with music and typically wants to enforce limited copying, is concerned that the compression module it is about to send a song to is, in fact, a good compression module and not some hacked program that will additionally steal the song by illicitly writing the song on the user's disk.
- the electronic music distribution module needs a signature from the compression module, but the reverse is not necessarily true.
- a signature check may be performed to detect newly inserted patches. This may be done based on elapsed time, or based on the number of actual call/returns across the protected interface. Since many digital signatures are relatively expensive, one embodiment of the invention further allows that the subsequent digital signaturing checking may be done with less expensive means, for example, by_simply recording the first hash and detecting whether or not a new hash is ever, different. Note, that in broad definition of digital signature as contemplated herein, simply checking the hash in the first place would be a type of "digital signature check", although not a particularly strong one .
- the present invention could be produced in ' hardware or software, or in a combination of hardware and software.
- the system, or method, according to the preferred embodiment may be produced in a single computer system having separate elements or means for performing the individual functions or steps described or claimed or one or more elements or means combining the performance of any of the functions or steps disclosed or claimed, or may be arranged in a distributed computer system, interconnected by any suitable means as would be known by one of ordinary skill in art .
- the invention is not limited to any particular kind of computer system but may be used with any general purpose computer, as would be known to one of ordinary skill in the art, arranged to perform the functions described and the method steps described.
- the operations of such a computer, as described above, may be according to a computer program contained on a medium for use in the operation or control of the computer, as would be known to one of ordinary skill in the art.
- the computer readable medium which may be used to hold or contain or deliver the computer program product, may be a fixture of the computer such as an embedded memory or may be on a transportable medium such as- a disk, as would be known to one of ordinary skill in the art .
- any such computing system can include, inter alia, at least a computer readable medium allowing a computer to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium.
- the computer readable medium may include nonvolatile memory, such as ROM, Flash memory, floppy disk, Disk drive memory, CD-ROM, and other permanent storage. Additionally, a computer readable medium may include, for example, volatile storage such as RAM, buffers, cache memory, and network circuits.
- the computer readable medium may include computer readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a computer to read such computer readable information.
- a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a computer to read such computer readable information.
- each module checks that the other module has not been patched. They each further verify that all the entry points in the other module they intend to call are in fact within the protected area. In the event that both modules are verified as being trustworthy, the modules now call each other freely. However, each module, when it is called first verifies that it was called from within the protected area of the other module .
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Storage Device Security (AREA)
- Stereophonic System (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Circuits Of Receivers In General (AREA)
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US65821800A | 2000-09-08 | 2000-09-08 | |
US658218 | 2000-09-08 | ||
PCT/GB2001/003962 WO2002021243A2 (en) | 2000-09-08 | 2001-09-05 | Software secure authenticated channel |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1368737A2 true EP1368737A2 (de) | 2003-12-10 |
Family
ID=24640397
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP01963228A Ceased EP1368737A2 (de) | 2000-09-08 | 2001-09-05 | Software für einen gesicherten authentifizierten kanal |
Country Status (6)
Country | Link |
---|---|
EP (1) | EP1368737A2 (de) |
JP (1) | JP2004509392A (de) |
KR (1) | KR100561497B1 (de) |
CN (1) | CN1516836A (de) |
AU (1) | AU2001284259A1 (de) |
WO (1) | WO2002021243A2 (de) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101405673B (zh) * | 2002-12-20 | 2011-12-14 | 高通股份有限公司 | 对设备上的组件进行自动处理的方法和装置 |
FR2856815B1 (fr) * | 2003-06-24 | 2005-09-16 | Omega Technology Ltd | Procede d'authentification de donnees contenues dans un objet a memoire |
US7328340B2 (en) * | 2003-06-27 | 2008-02-05 | Intel Corporation | Methods and apparatus to provide secure firmware storage and service access |
JP4728619B2 (ja) * | 2004-10-01 | 2011-07-20 | 富士通株式会社 | ソフトウェアの改竄検出装置、改竄防止装置、改竄検出方法及び改竄防止方法 |
CN100489728C (zh) * | 2004-12-02 | 2009-05-20 | 联想(北京)有限公司 | 一种建立计算机中可信任运行环境的方法 |
US20060195689A1 (en) * | 2005-02-28 | 2006-08-31 | Carsten Blecken | Authenticated and confidential communication between software components executing in un-trusted environments |
JP2006260239A (ja) * | 2005-03-17 | 2006-09-28 | Murata Mach Ltd | 文書管理装置及びそのプログラム |
EP1877947A4 (de) * | 2005-05-05 | 2009-11-25 | Certicom Corp | Nachträgliches ausstatten von firmware mit authentifikation |
JP4844102B2 (ja) * | 2005-11-30 | 2011-12-28 | 富士ゼロックス株式会社 | サブプログラム及びそのサブプログラムを実行する情報処理装置 |
US7900046B2 (en) * | 2006-01-11 | 2011-03-01 | International Business Machines Corporation | System and method for establishing mutual trust on a per-deployment basis between two software modules |
EP2023248B1 (de) * | 2006-04-24 | 2018-10-24 | Panasonic Intellectual Property Management Co., Ltd. | Datenverarbeitungseinrichtung, verfahren, programm, integrierte schaltung und programmerzeugungseinrichtung |
JP4822544B2 (ja) * | 2006-04-26 | 2011-11-24 | 株式会社リコー | 複数のモジュール構成情報を管理できる画像形成装置 |
US7877602B2 (en) * | 2007-07-27 | 2011-01-25 | International Business Machines Corporation | Transparent aware data transformation at file system level for efficient encryption and integrity validation of network files |
JP5177206B2 (ja) * | 2010-10-29 | 2013-04-03 | 富士通株式会社 | ソフトウェアの改竄検出装置及び改竄検出方法 |
JP5177205B2 (ja) * | 2010-10-29 | 2013-04-03 | 富士通株式会社 | ソフトウェアの改竄防止装置及び改竄防止方法 |
US10616197B2 (en) | 2016-04-18 | 2020-04-07 | Atmel Corporation | Message authentication with secure code verification |
WO2023162048A1 (ja) * | 2022-02-22 | 2023-08-31 | 日本電信電話株式会社 | 認証システム、生成装置、生成方法および生成プログラム |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5757914A (en) * | 1995-10-26 | 1998-05-26 | Sun Microsystems, Inc. | System and method for protecting use of dynamically linked executable modules |
US6105137A (en) * | 1998-07-02 | 2000-08-15 | Intel Corporation | Method and apparatus for integrity verification, authentication, and secure linkage of software modules |
-
2001
- 2001-09-05 JP JP2002524793A patent/JP2004509392A/ja active Pending
- 2001-09-05 CN CNA018154034A patent/CN1516836A/zh active Pending
- 2001-09-05 AU AU2001284259A patent/AU2001284259A1/en not_active Abandoned
- 2001-09-05 KR KR1020037003480A patent/KR100561497B1/ko not_active IP Right Cessation
- 2001-09-05 WO PCT/GB2001/003962 patent/WO2002021243A2/en not_active Application Discontinuation
- 2001-09-05 EP EP01963228A patent/EP1368737A2/de not_active Ceased
Non-Patent Citations (1)
Title |
---|
See references of WO0221243A2 * |
Also Published As
Publication number | Publication date |
---|---|
KR20030029957A (ko) | 2003-04-16 |
WO2002021243A3 (en) | 2003-10-09 |
KR100561497B1 (ko) | 2006-03-17 |
WO2002021243A2 (en) | 2002-03-14 |
AU2001284259A1 (en) | 2002-03-22 |
CN1516836A (zh) | 2004-07-28 |
JP2004509392A (ja) | 2004-03-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2450844C (en) | A method for securing an electronic device, a security system and an electronic device | |
US7539868B2 (en) | Run-time firmware authentication | |
JP4996817B2 (ja) | 装置に結合されたフラッシュ動作/起動動作によるクローン作成防止方法 | |
JP4912879B2 (ja) | プロセッサの保護された資源へのアクセスに対するセキュリティ保護方法 | |
US7721098B2 (en) | System and method for guaranteeing software integrity via combined hardware and software authentication | |
US20040088541A1 (en) | Digital-rights management system | |
EP1368737A2 (de) | Software für einen gesicherten authentifizierten kanal | |
US7500109B2 (en) | System and method for secure authentication of external software modules provided by third parties | |
US20070277037A1 (en) | Software component authentication via encrypted embedded self-signatures | |
JP2006072414A (ja) | ソフトウェア無線システム | |
KR20070017455A (ko) | 프로세서 내에서의 보호된 리소스들로의 억세스에 대한안전한 보호 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20030221 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO SI |
|
17Q | First examination report despatched |
Effective date: 20040820 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20051218 |