WO2002021243A2 - Voie authentifiee securisee de logiciel - Google Patents

Voie authentifiee securisee de logiciel Download PDF

Info

Publication number
WO2002021243A2
WO2002021243A2 PCT/GB2001/003962 GB0103962W WO0221243A2 WO 2002021243 A2 WO2002021243 A2 WO 2002021243A2 GB 0103962 W GB0103962 W GB 0103962W WO 0221243 A2 WO0221243 A2 WO 0221243A2
Authority
WO
WIPO (PCT)
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
PCT/GB2001/003962
Other languages
English (en)
Other versions
WO2002021243A3 (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.)
IBM United Kingdom Ltd
International Business Machines Corp
Original Assignee
IBM United Kingdom Ltd
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 IBM United Kingdom Ltd, International Business Machines Corp filed Critical IBM United Kingdom Ltd
Priority to JP2002524793A priority Critical patent/JP2004509392A/ja
Priority to KR1020037003480A priority patent/KR100561497B1/ko
Priority to EP01963228A priority patent/EP1368737A2/fr
Priority to AU2001284259A priority patent/AU2001284259A1/en
Publication of WO2002021243A2 publication Critical patent/WO2002021243A2/fr
Anticipated expiration legal-status Critical
Publication of WO2002021243A3 publication Critical patent/WO2002021243A3/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Circuits Of Receivers In General (AREA)
  • Stereophonic System (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Selon l'invention, des fabricants de logiciels examinent leur module et déterminent un domaine d'adresses mémoire occupées par le module. On prédéfinit, en mémoire, un domaine protégé d'adresses dans lequel les changements ne sont pas permis, tels que des correctifs logiciel de pirates informatiques. Chaque fabricant communique le domaine d'adresses décrivant la zone protégée et une bonne version connue de leur module à d'autres fabricants avec lesquels ils souhaitent travailler. Les autres fabricants retournent des signatures numériques sur la zone protégée, et ces signatures numériques sont stockées dans le premier module du fabricant. Les autres fabricants réalisent, de manière correspondante, la même opération sur leurs propres modules. Alors, de façon à assurer une voie de communication sécurisée entre deux modules, les modules se passent d'abord chacun les signatures préalablement produites. Puis, afin d'assurer que la communication est réalisée à l'aide d'un module autorisé authentique, par l'intermédiaire de l'utilisation de la signature et des domaines d'adresses de la zone protégée, chaque module teste que l'autre module n'a pas reçu de correctif logiciel. De plus, ils vérifient chacun que tous les points d'entrée dans l'autre module qu'ils ont l'intention d'appeler se situent en fait dans la zone protégée. Lorsque les deux modules sont vérifiés comme étant légitimes, ils peuvent alors s'appeler réciproquement sans contrainte. Cependant, lorsqu'il est appelé, chaque module doit vérifier qu'il est appelé à partir de la zone protégée de l'autre module.
PCT/GB2001/003962 2000-09-08 2001-09-05 Voie authentifiee securisee de logiciel Ceased WO2002021243A2 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2002524793A JP2004509392A (ja) 2000-09-08 2001-09-05 ソフトウェアのセキュア認証済チャネル
KR1020037003480A KR100561497B1 (ko) 2000-09-08 2001-09-05 소프트웨어 보안 인증 경로
EP01963228A EP1368737A2 (fr) 2000-09-08 2001-09-05 Voie authentifiee securisee de logiciel
AU2001284259A AU2001284259A1 (en) 2000-09-08 2001-09-05 Software secure authenticated channel

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US65821800A 2000-09-08 2000-09-08
US09/658,218 2000-09-08

Publications (2)

Publication Number Publication Date
WO2002021243A2 true WO2002021243A2 (fr) 2002-03-14
WO2002021243A3 WO2002021243A3 (fr) 2003-10-09

Family

ID=24640397

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2001/003962 Ceased WO2002021243A2 (fr) 2000-09-08 2001-09-05 Voie authentifiee securisee de logiciel

Country Status (6)

Country Link
EP (1) EP1368737A2 (fr)
JP (1) JP2004509392A (fr)
KR (1) KR100561497B1 (fr)
CN (1) CN1516836A (fr)
AU (1) AU2001284259A1 (fr)
WO (1) WO2002021243A2 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2856815A1 (fr) * 2003-06-24 2004-12-31 Omega Technology Ltd Procede d'authentification de donnees contenues dans un objet a memoire
JP2006526219A (ja) * 2003-06-27 2006-11-16 インテル・コーポレーション セキュアなファームウェア格納及びサービスアクセスを提供する方法及び装置
WO2007080144A1 (fr) * 2006-01-11 2007-07-19 International Business Machines Corporation Établissement de confiance mutuelle sur une base par déploiement entre deux modules logiciels
JP2007318731A (ja) * 2006-04-26 2007-12-06 Ricoh Co Ltd 複数のモジュール構成情報を管理できる画像形成装置
EP1859564A4 (fr) * 2005-02-28 2010-10-06 Acresso Software Inc Methode et systeme de communications securisees par logiciel
DE112005002985B4 (de) * 2004-12-02 2011-01-20 Lenovo (Beijing) Ltd. Verfahren zum Einrichten einer vertrauenswürdigen Ablaufumgebung in einem Computer
JP2011048850A (ja) * 2010-10-29 2011-03-10 Fujitsu Ltd ソフトウェアの改竄防止装置及び改竄防止方法
JP2011048851A (ja) * 2010-10-29 2011-03-10 Fujitsu Ltd ソフトウェアの改竄検出装置及び改竄検出方法
CN101405673B (zh) * 2002-12-20 2011-12-14 高通股份有限公司 对设备上的组件进行自动处理的方法和装置
US11876791B2 (en) 2016-04-18 2024-01-16 Amtel Corporation Message authentication with secure code verification
AU2022443675B2 (en) * 2022-02-22 2026-01-22 Ntt, Inc. Authentication system, authentication method, and authentication program

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4728619B2 (ja) * 2004-10-01 2011-07-20 富士通株式会社 ソフトウェアの改竄検出装置、改竄防止装置、改竄検出方法及び改竄防止方法
JP2006260239A (ja) * 2005-03-17 2006-09-28 Murata Mach Ltd 文書管理装置及びそのプログラム
CN101218588B (zh) * 2005-05-05 2010-05-19 塞尔蒂卡姆公司 具有可认证的固件的附件设备及布置和认证该固件的方法
JP4844102B2 (ja) * 2005-11-30 2011-12-28 富士ゼロックス株式会社 サブプログラム及びそのサブプログラムを実行する情報処理装置
WO2007125911A1 (fr) * 2006-04-24 2007-11-08 Panasonic Corporation Dispositif de traitement de donnees, procede, programme, circuit integre, et dispositif de generation de programme
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
DE102017219188A1 (de) * 2017-10-26 2019-05-02 Robert Bosch Gmbh Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks

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

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101405673B (zh) * 2002-12-20 2011-12-14 高通股份有限公司 对设备上的组件进行自动处理的方法和装置
FR2856815A1 (fr) * 2003-06-24 2004-12-31 Omega Technology Ltd Procede d'authentification de donnees contenues dans un objet a memoire
JP2006526219A (ja) * 2003-06-27 2006-11-16 インテル・コーポレーション セキュアなファームウェア格納及びサービスアクセスを提供する方法及び装置
DE112005002985B4 (de) * 2004-12-02 2011-01-20 Lenovo (Beijing) Ltd. Verfahren zum Einrichten einer vertrauenswürdigen Ablaufumgebung in einem Computer
EP1859564A4 (fr) * 2005-02-28 2010-10-06 Acresso Software Inc Methode et systeme de communications securisees par logiciel
WO2007080144A1 (fr) * 2006-01-11 2007-07-19 International Business Machines Corporation Établissement de confiance mutuelle sur une base par déploiement entre deux modules logiciels
JP2007318731A (ja) * 2006-04-26 2007-12-06 Ricoh Co Ltd 複数のモジュール構成情報を管理できる画像形成装置
JP2011048850A (ja) * 2010-10-29 2011-03-10 Fujitsu Ltd ソフトウェアの改竄防止装置及び改竄防止方法
JP2011048851A (ja) * 2010-10-29 2011-03-10 Fujitsu Ltd ソフトウェアの改竄検出装置及び改竄検出方法
US11876791B2 (en) 2016-04-18 2024-01-16 Amtel Corporation Message authentication with secure code verification
AU2022443675B2 (en) * 2022-02-22 2026-01-22 Ntt, Inc. Authentication system, authentication method, and authentication program

Also Published As

Publication number Publication date
CN1516836A (zh) 2004-07-28
WO2002021243A3 (fr) 2003-10-09
AU2001284259A1 (en) 2002-03-22
EP1368737A2 (fr) 2003-12-10
KR20030029957A (ko) 2003-04-16
KR100561497B1 (ko) 2006-03-17
JP2004509392A (ja) 2004-03-25

Similar Documents

Publication Publication Date Title
CA2450844C (fr) Procede servant a securiser un dispositif electronique, systeme de securite et dispositif electronique
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
WO2002021243A2 (fr) Voie authentifiee securisee de logiciel
CN101213814B (zh) 安全修补系统
US20040088541A1 (en) Digital-rights management system
US20070277037A1 (en) Software component authentication via encrypted embedded self-signatures
US7500109B2 (en) System and method for secure authentication of external software modules provided by third parties
JP2006072414A (ja) ソフトウェア無線システム
KR20070017455A (ko) 프로세서 내에서의 보호된 리소스들로의 억세스에 대한안전한 보호 방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2001963228

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2002524793

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020037003480

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2001284259

Country of ref document: AU

Ref document number: 018154034

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 1020037003480

Country of ref document: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 2001963228

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 2001963228

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1020037003480

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 2001963228

Country of ref document: EP