EP1368737A2 - Software für einen gesicherten authentifizierten kanal - Google Patents

Software für einen gesicherten authentifizierten kanal

Info

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
Application number
EP01963228A
Other languages
English (en)
French (fr)
Inventor
Jeffrey Lotspiech
Stefan Nusser
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of EP1368737A2 publication Critical patent/EP1368737A2/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • G06F21/445Program 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)
EP01963228A 2000-09-08 2001-09-05 Software für einen gesicherten authentifizierten kanal Ceased EP1368737A2 (de)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
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