[go: up one dir, main page]

WO2012005565A1 - Procédé de résistance aux outils de dissimulation d'activité sur la base d'une puce sécurisée - Google Patents

Procédé de résistance aux outils de dissimulation d'activité sur la base d'une puce sécurisée Download PDF

Info

Publication number
WO2012005565A1
WO2012005565A1 PCT/MY2010/000229 MY2010000229W WO2012005565A1 WO 2012005565 A1 WO2012005565 A1 WO 2012005565A1 MY 2010000229 W MY2010000229 W MY 2010000229W WO 2012005565 A1 WO2012005565 A1 WO 2012005565A1
Authority
WO
WIPO (PCT)
Prior art keywords
sat
trusted chip
blocks
trusted
module
Prior art date
Application number
PCT/MY2010/000229
Other languages
English (en)
Inventor
Ahmad Abdu Muthana Abdulrahman
Abd Manan Jamalul-Lail
Bin Shamsuddin Solahuddin
Faizal Bin Mubarak Mohd
Ahmad Zaid
Abdul Kadir Azimah
Original Assignee
Mimos Berhad
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 Mimos Berhad filed Critical Mimos Berhad
Publication of WO2012005565A1 publication Critical patent/WO2012005565A1/fr

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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/80—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in storage media based on magnetic or optical technology, e.g. disks with sectors
    • G06F21/805—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in storage media based on magnetic or optical technology, e.g. disks with sectors using a security table for the storage sub-system
    • 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
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/80—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in storage media based on magnetic or optical technology, e.g. disks with sectors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2121—Chip on media, e.g. a disk or tape with a chip embedded in its case

Definitions

  • the present invention relates generally to computer security. More particularly, the invention relates to utilizing Trusted Platform Module (TPM) functionalities to prevent rootkits from being persistent by modifying system area.
  • TPM Trusted Platform Module
  • a rootkit being a malicious program exploits operating system vulnerabilities to gain control of victim host in order to abuse data and resources of the users.
  • a rootkit may lead to compromising the computer system by giving unauthorized users administrative access to the computer. As a result, an unauthorized user may use the computer, any of the functions or information to perform malicious activities.
  • a rootkit may be installed by authorized users unknowingly or installed deliberately by users having access to the computer.
  • a rootkit may also be installed through network if a computer has a connection to the network. Recovering from rootkit is a tedious task. In some cases, the only possible way to get rid of rootkit is to erase all the data by formatting the disk and reinstall the software.
  • a rootkit may hide as a part of kernel level code.
  • the kernel level code is trusted by the computer and thus the rootkit may not be detected.
  • a rootkit infects the system image (binaries and configuration files) it becomes persistent and exists across reboots.
  • a persistent rootkit may prevent successful patches and system repair from being successfully applied.
  • one existing method which includes preventing installation of rootkits on a standalone computer i.e. when a computer is operating in a normal mode and rebooting the computer into a safe mode wherein network connections of the computer are disabled.
  • installation of software is allowed only in safe mode after granting permission from master computer.
  • an external rootkit detection tool may be provided.
  • the tool may include external static memory with input/output (I/O) port interface to an external I/O port on target computing platform.
  • the tool further may include a boot image disposed in the external static storage, and rootkit detection and remediation logic disposed in the external static memory and referenced by the boot image.
  • the external static memory may include a universal serial bus (USB) key and, correspondingly, the I/O port may include an external USB port.
  • USB universal serial bus
  • an anti-virus based on a security chip is provided.
  • the detection or prevention may not be persistence process because it verifies the integrity of key files during boot time only
  • the present invention proposes a method for protection of disk from persistent rootkit based on a trusted chip (34).
  • the present invention includes a system and method for rootkit resistance based on a trusted chip (34), which is a major need for the hardware industry. It is therefore an object of the instant invention to provide an efficient method and system for preventing installation of rootkits in system image in normal mode and thus preventing rootkits from being persistent by intercepting writing commands to hard disk.
  • it may include an ability to prevent unauthorized modification of system image.
  • it allows trusted chip (34) to play an important role in protecting system image against rootkits.
  • the table containing the information about status of disk blocks termed as System Area Table ⁇ SAT (36) ⁇ may be protected by the trusted chip (34) and its integrity value may be stored securely in the memory of the trusted chip (34).
  • restriction of unauthorized modification of system image neither needs an external storage or physical token to maintain information about status of disk blocks nor needs another machine to grant a permission to update the system image.
  • Fig. 1 is a flow chart illustrating a method to resist rootkit based on a trusted chip (34), in accordance with an aspect of the present technique
  • Fig. 2 is a block diagram illustrating a method to resist rootkit based on a trusted chip (34), in accordance with an aspect of the present technique
  • Fig. 3 shows an illustrative diagram showing a system for rootkit resistance based on a trusted chip (34);
  • Fig. 4 shows an illustrative diagram showing communication between Trusted Monitoring Service ⁇ TMS (32) ⁇ and trusted chip (34) in accordance with an aspect of the present technique
  • Fig. 5 is a flowchart illustrating a method for rootkit resistance based on a trusted chip (34) in accordance with an aspect of the present technique.
  • the present invention proposes method to resist rootkit based on a trusted chip (34), in accordance with an aspect of the present technique.
  • a rootkit is a malicious program that may be user level process and kernel level process.
  • User level rootkit may grant unauthorized user a privileged access to computer system. Once unauthorized user is granted the privileges he/she can exploits this access to steal confidential data, modifying data, or using computer resources in malicious activities, for example to attack another machine or machines on the network.
  • the damage may be complicated when it comes to kernel level rootkits or what is called persistent rootkits.
  • This type of rootkits may be very difficult to detect and/or remove. They hide themselves as part of operating system kernel code and thus the disk located in H.D.D 30 (hereinafter referred to as 'disk') of the host machine becomes persistent-infected.
  • Kernel rootkits may be especially difficult to detect and remove, because they operate at the same level as the operating system itself, and are thus able to intercept or subvert any operation made by the operating system. Any software, such as antivirus software, running on the compromised system may be easily subverted. In a situation such as this, the whole system can no longer be trusted while it is running.
  • Fig. 1 is a flow chart illustrating a method to resist rootkit based on a trusted chip (34).
  • labeling the blocks in the disk may take place at step 300.
  • the disk blocks are labeled as immutable (read-only) blocks and mutable (read/write) blocks. It has been illustrated in Fig. 3 system 8. According to this arrangement, disk blocks occupied by the system image (binaries and configurations) may be considered immutable while remaining disk blocks may be considered as mutable blocks. Immutable blocks may not be illegally modified.
  • SAT (36) may be created once operating system is installed and encrypted.
  • the Labeled information may be stored in SAT (36).
  • SAT (36) may be stored locally on the same hard disk partition containing the operating system and may be fully protected by trusted chip (34).
  • the trusted chip (34) at least may be of TPM or any other equivalent trusted chip (34).
  • TPM chip may be a trusted hardware; TPM chips can compute and securely store integrity measurements of a software stack. Any attempt to modify SAT (36) may be noticed by the trusted chip (34).
  • Using a local file protected by trusted chip (34) for labelling information has another advantage, it may eliminate the need for external storage for example, physical token or another machine.
  • encrypting and verifying integrity of SAT (36) may be advantageous in the manner that it may provide a protection for SAT (36) and may allow detection of any unauthorized attempt to corrupt it.
  • the integral value may be computed.
  • the integrity of the SAT (36) may be measured by the trusted chip (34) at least through hashing operation.
  • the integrity value may be stored in the memory of the trusted chip (34).
  • SAT (36) may be encrypted and its integrity value may be computed and stored in the memory of the trusted chip (34). In other embodiments, only the integrity value of SAT (36) may be stored in the memory of trusted chip (34).
  • SAT 36 may be created containing labelling information of disk blocks in which the blocks occupied by operating system binaries are labelled as immutable blocks and the rest blocks are labelled as mutable blocks.
  • the integral value of the SAT (36) may be verified.
  • Fig. 5 shows an embodiment wherein the integrity value of SAT (36) may be stored in memory of trusted chip (34).
  • step 202 Whenever a disk operation is detected (step 202) it may be checked to determine whether it is writing operation (step 204). Having detected a writing command the integrity of SAT (36) may be verified to determine whether it has been compromised or not (step 206). As a result the writing command may be denied if SAT (36) found not to be integral (“No” in step 208) and the user may be motivated to restore the original SAT (36) protected by trusted chip (34) or if it is integral (“Yes” in step 208) the process may proceed by checking whether the target blocks of writing command belong to system area (step 210). Writing to user area blocks may be allowed ("No” in step 210) while writing to system area blocks ("Yes” in step 210) requires further verification in order to verify the validity of the writing command (step 212).
  • the writing command may allow proceeding for valid writing commands (step 216) while invalid and unauthorized writing commands may be denied ("No" in step 214).
  • Fig. 2 is a block diagram illustrating the method to resist rootkit based on a trusted chip. As illustrated, methodology starts at storing module (SM) (400).
  • SM module
  • Storing blocks into SAT (36) may take place in the Storing Module (SM) (400).
  • SM Storing Module
  • the Labeled information may be stored in SAT (36).
  • SAT (36) may be stored locally on the same hard disk partition containing the operating system and fully protected by trusted chip (34).
  • the trusted chip (34) at least may be of TPM or any other equivalent trusted chip.
  • TPM chip may be a trusted hardware; TPM chips may compute and securely store integrity measurements of a software stack.
  • SAT (36) Any attempt to modify SAT (36) may be noticed by the trusted chip (34).
  • Using a local file protected by trusted chip (34) for labelling information has another advantage in the manner that it may eliminate the need for external storage for example, physical token or another machine.
  • encrypting and verifying integrity of SAT (36) may be advantageous in the manner that it provides a protection for SAT (36) and may allow detection of any unauthorized attempt to corrupt it.
  • the integral value may be computed or measured in the Measuring Module (MM) (402).
  • the integrity of the SAT36 may be measured by the trusted chip (34) at least through hashing operation.
  • the integrity value may be stored in the memory of the trusted chip (34) in the loading module (LM) (404).
  • SAT (36) may be encrypted and its integrity value may be computed and stored in the memory of the trusted chip (34). In other embodiments, only the integrity value of SAT (36) may be stored in the memory of trusted chip (34).
  • SAT (36) may be created containing labelling information of disk blocks in which the blocks occupied by operating system binaries are labelled as immutable blocks and the rest blocks are labelled as mutable blocks.
  • TMS (32) Trusted Monitoring Service
  • IM Interception module
  • Fig. 4 illustrates the communication between trusted monitoring services TMS (32) with trusted chip (34) during normal mode.
  • the TMS (32) may be a kernel level service, which may be capable of intercepting all writing requests to the hard disk. It may be tamper-proof code protected with obfuscation techniques. It may be capable of measuring the integrity of SAT (36) loaded on the memory and communicating with trusted chip (34). The integrity of TMS (32) may be measured as part of chain of trust every time the computer system is powered up in order to maintain its integrity.
  • the integral value of the SAT (36) may be verified in the Verification Module (VM) (408).
  • Fig. 5 shows an embodiment wherein the integrity value of SAT (36) is stored in Measuring Module (memory of the trusted chip (34)).
  • Measuring Module memory of the trusted chip (34)
  • the writing command may be denied if SAT (36) is found not to be integral (“No” in step 208) and the user may motivated to restore the original SAT (36) protected by trusted chip (34) or if it is integral ("Yes” in step 208) the process proceeds by checking whether the target blocks of writing command belong to system area (step 210).
  • Writing to user area blocks may be allowed ("No” in step 210) while writing to system area blocks ("Yes” in step 210) may requires further verification in order to verify the validity of the writing command (step 212).
  • the writing command may be allowed to proceed for valid writing commands (step 216) while invalid and unauthorized writing commands may be denied ("No" in step 214).
  • FIG. 3 is an illustrative diagram showing a system for rootkit resistance based on a trusted chip (34). It shows an illustrative system 8 for preventing persistent rootkits.
  • the disk blocks are labelled as immutable (read-only) blocks and mutable (read/write) blocks. According to this arrangement, disk blocks occupied by the system image (binaries and configurations) may be considered immutable while remaining disk blocks may be considered as mutable blocks. Immutable blocks may not be illegally modified. Labelling information may be stored in SAT (36).
  • SAT (36) is created once operating system is installed encrypted and its integrity value is computed and stored in the memory of the trusted chip (34).
  • SAT (36) is stored locally on the same hard disk partition containing the operating system and fully protected by trusted chip (34). Any attempt to modify SAT (36) may be noticed by the trusted chip (34). Using a local file protected by trusted chip (34) for labelling information has another advantage in the manner that it eliminates the need for external storage for example, physical token or another machine. Furthermore, encrypting and verifying integrity of SAT (36) may be advantageous in the manner that it may provide a protection for SAT (36) and may allow detection of any attempt to corrupt it. In certain embodiments, the system area SAT (36) may be stored entirely in the memory of trusted chip (34). In other embodiments, only the integrity value of SAT (36) may be stored in the memory of trusted chip (34). Upon completion of installation process SAT (36) may be created containing labelling information of disk blocks in which the blocks occupied by operating system binaries may be labelled as immutable blocks and the rest blocks may be labelled as mutable blocks.
  • FIG. 4 is an illustrative diagram showing the communication between TMS (32) with trusted chip (34).
  • Fig. 4 illustrates the communication between trusted monitoring services TMS (32) with trusted chip (34) during normal mode.
  • the TMS (32) may be a kernel level service, which may be capable of intercepting all writing requests to the hard disk. It may be tamper-proof code protected with obfuscation techniques. It may be capable of measuring the integrity of SAT (36) loaded on the memory and communicating with trusted chip (34). The integrity of TMS (32) may be measured as part of chain of trust every time the computer system is powered up in order to maintain its integrity.
  • Fig. 5 is a flowchart illustrating a method for rootkit resistance based on a trusted chip (34).
  • SAT (36) is stored in Measuring Module ⁇ memory of trusted chip (34) ⁇ .
  • a disk operation is detected (step 202) it may be checked to determine whether it is writing operation (step 204). Having detected a writing command the integrity of SAT (36) may be verified to determine whether it has been compromised or not (step 206). As a result the writing command may be denied if SAT (36) is found not to be integral ("No" in step 208) and the user may motivated to restore the original SAT (36) protected by trusted chip (34) or if it is integral ("Yes" in step 208) the process proceeds by checking whether the target blocks of writing command belong to system area (step 210).
  • Writing to user area blocks may be allowed ("No” in step 210) while writing to system area blocks ("Yes” in step 210) may requires further verification in order to verify the validity of the writing command (step 212).
  • the writing command may be allowed to proceed for valid writing commands (step 216) while invalid and unauthorized writing commands may be denied (“No” in step 214).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention porte sur un procédé et un système de protection de disque contre des outils de dissimulation d'activité persistants. Le procédé consiste à protéger un disque contre des outils de dissimulation d'activité persistants (des outils de dissimulation d'activité qui tentent de modifier l'image système) sur la base d'une puce sécurisée (34). En outre, le procédé offre une protection en temps réel pour empêcher l'écriture d'outils de dissimulation d'activité dans une image système. Le présent procédé sert à protéger un disque contre des outils de dissimulation d'activité persistants (des outils de dissimulation d'activité qui tentent de modifier l'image système) sur la base de la puce sécurisée (34). Le procédé étiquette tous les blocs dans le disque, les fichiers système étant étiquetés comme étant des blocs de zone système et les blocs restants comme étant des blocs de zone utilisateur. Les blocs étiquetés sont stockés dans une table protégée par la puce sécurisée intégrée sur la machine hôte. Durant le processus normal, toutes les opérations d'écriture dans une zone système sont vérifiées avant qu'une écriture ne soit effectuée dans les blocs de zone système.
PCT/MY2010/000229 2010-07-06 2010-10-28 Procédé de résistance aux outils de dissimulation d'activité sur la base d'une puce sécurisée WO2012005565A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
MYPI2010003209A MY150351A (en) 2010-07-06 2010-07-06 A method for rootkit resistance based on a trusted chip
MYPI2010003209 2010-07-06

Publications (1)

Publication Number Publication Date
WO2012005565A1 true WO2012005565A1 (fr) 2012-01-12

Family

ID=45441388

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/MY2010/000229 WO2012005565A1 (fr) 2010-07-06 2010-10-28 Procédé de résistance aux outils de dissimulation d'activité sur la base d'une puce sécurisée

Country Status (2)

Country Link
MY (1) MY150351A (fr)
WO (1) WO2012005565A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6948165B1 (en) * 2001-02-28 2005-09-20 Western Digital Ventures, Inc. Method for installing an application program, to be executed during each bootload of a computer system for presenting a user with content options prior to conventional system startup presentation, without requiring a user's participation to install the program
US20070143623A1 (en) * 2000-02-15 2007-06-21 Silverbrook Research Pty Ltd Method of validating consumable authentication chip
KR100762973B1 (ko) * 2007-02-07 2007-10-02 (주)노애드 컴퓨터의 악성코드 탐지 및 제거 방법과 그 장치, 그방법을 컴퓨터에서 실행시키기 위한 프로그램 코드를기록한 기록매체
US20100058041A1 (en) * 2008-08-26 2010-03-04 Texas Digital And Multimedia Systems Method and Apparatus for Secure Instantly-On Computer System

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070143623A1 (en) * 2000-02-15 2007-06-21 Silverbrook Research Pty Ltd Method of validating consumable authentication chip
US6948165B1 (en) * 2001-02-28 2005-09-20 Western Digital Ventures, Inc. Method for installing an application program, to be executed during each bootload of a computer system for presenting a user with content options prior to conventional system startup presentation, without requiring a user's participation to install the program
KR100762973B1 (ko) * 2007-02-07 2007-10-02 (주)노애드 컴퓨터의 악성코드 탐지 및 제거 방법과 그 장치, 그방법을 컴퓨터에서 실행시키기 위한 프로그램 코드를기록한 기록매체
US20100058041A1 (en) * 2008-08-26 2010-03-04 Texas Digital And Multimedia Systems Method and Apparatus for Secure Instantly-On Computer System

Also Published As

Publication number Publication date
MY150351A (en) 2013-12-31

Similar Documents

Publication Publication Date Title
US10635808B2 (en) Method and system for preventing and detecting security threats
KR101219857B1 (ko) 하드웨어 보안 모듈을 구비한 컴퓨터를 보안 부팅하기 위한시스템, 방법 및 컴퓨터 판독 가능 매체
EP3207485B1 (fr) Authentification de pointeur code pour commande de flux de matériel
KR101176646B1 (ko) 상태 검증을 사용하는 보호된 오퍼레이팅 시스템 부팅을 위한 시스템 및 방법
US8850212B2 (en) Extending an integrity measurement
US8213618B2 (en) Protecting content on client platforms
US20100115625A1 (en) Policy enforcement in trusted platforms
CN107066311A (zh) 一种内核数据访问控制方法与系统
US20160004859A1 (en) Method and system for platform and user application security on a device
EP2126770A2 (fr) Entités informatiques de confiance
WO2012005565A1 (fr) Procédé de résistance aux outils de dissimulation d'activité sur la base d'une puce sécurisée
CN106355085B (zh) 一种可信应用运行安全控制方法
JP5355351B2 (ja) コンピュータ
Slaviero et al. Attacking Signed Binaries.
HK1087216B (en) System and method for protected operating systems boot using state validation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10854500

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10854500

Country of ref document: EP

Kind code of ref document: A1