WO2007094857A1 - Méthode et appareil pour sécuriser des données numériques - Google Patents

Méthode et appareil pour sécuriser des données numériques Download PDF

Info

Publication number
WO2007094857A1
WO2007094857A1 PCT/US2006/048218 US2006048218W WO2007094857A1 WO 2007094857 A1 WO2007094857 A1 WO 2007094857A1 US 2006048218 W US2006048218 W US 2006048218W WO 2007094857 A1 WO2007094857 A1 WO 2007094857A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
stored
authentication value
data
processor
Prior art date
Application number
PCT/US2006/048218
Other languages
English (en)
Inventor
David Jay Duffield
Original Assignee
Thomson Licensing
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 Thomson Licensing filed Critical Thomson Licensing
Publication of WO2007094857A1 publication Critical patent/WO2007094857A1/fr

Links

Classifications

    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • 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

Definitions

  • the present invention relates generally to digital content delivery systems, and more particularly to digital content receivers.
  • FIG. 1 shows a conventional digital set-top box (STB) architecture 10.
  • Architecture 10 includes a processor 20, along with non-volatile memory 30 and volatile memory 35.
  • "Processor” refers generally to a computing device including a Central Processing Unit (CPU), such as a microprocessor.
  • CPU Central Processing Unit
  • a CPU generally includes an arithmetic logic unit (ALU) 1 which performs arithmetic and logical operations, and a control unit, which extracts instructions (e.g., a computer program incorporating code) from memory and decodes and executes the instructions, calling on the ALU when necessary.
  • ALU arithmetic logic unit
  • Memory refers generally to one or more devices capable of storing data, such as in the form of chips, tapes, disks or drives.
  • Memory may take the form of one or more random-access memory (RAM), read-only memory (ROM), programmable readonly memory (PROM), erasable programmable read-only memory (EPROM), or electrically erasable programmable read-only memory (EEPROM) chips, by way of example only.
  • RAM random-access memory
  • ROM read-only memory
  • PROM programmable readonly memory
  • EPROM erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • Memory may be internal or external to an integrated unit, e.g. an integrated circuit (IC), including a processor.
  • IC integrated circuit
  • digital content is received using input 40.
  • Input 40 may take the form of a satellite receiver, Internet Protocol (IP) receiver or digital cable television receiver, for example.
  • IP Internet Protocol
  • the received content is decoded using decoder 50 responsively to processor 20 executing software instructions, e.g., processor executable code, accessed via memory bus 25.
  • Power-up and reset circuitry 60 is used to operate, boot and/or re-boot architecture 10 in a conventional manner. Such architecture is well understoodi by those possessing an ordinary skill in the pertinent arts.
  • One drawback of architecture 10 of FIG.1 is its susceptibility to hacking.
  • a hacker can replace the original equipment manufacturer's (OEMs) or other authorized software, such as processor executable code being stored in memory 30 and/or 35, with unauthorized, or modified software, for the purposes of copying or stealing digital content or for other illegal or unauthorized purposes.
  • OEMs original equipment manufacturer's
  • processor executable code being stored in memory 30 and/or 35
  • a method for continuously checking data integrity including: generating a random number; retrieving data; generating an authentication value in response to the random number and the retrieved data; storing the data and the authentication value; generating a subsequent authentication value from the stored data and the random number; comparing the stored authentication value with the subsequent authentication value to check data integrity.
  • FIG. 1 illustrates a block diagram of a conventional digital set-top box (STB) architecture
  • FIG. 2 illustrates a block diagram of a digital set-top box (STB) architecture according to an embodiment of the present invention.
  • FIGS. 3-6 illustrate flow diagrams depicting process flows associated with the secure processor, main processor and memory in accordance with an embodiment of the invention.
  • FIG. 2 shows a block diagram of a digital content receiver architecture 100 according to an embodiment of the present invention.
  • Architecture 100 may be embodied as a set-top box analogous to that of Fig. 1.
  • architecture 100 may be included in another device, such as a personal video recorder (PVR) or a digital television, for example.
  • PVR personal video recorder
  • Architecture 100 additionally includes secure processor 110 with embedded memory 120.
  • Memory 120 may include both volatile and non-volatile memory. Volatile memory used as part of memory 120 and/or 35 may take the form of DDR RAM memory.
  • Non-volatile memory used as part of memory 120 and/or 30 may take the form of boot ROM and/or flash memory.
  • Secure processor 110 may take the form of a conventional secure microprocessor, or integrated circuit (IC) incorporating a microprocessor, for example.
  • processors 20, 110 may be embedded within a common integrated circuit, for example.
  • processor 20, .110 may be embedded within a common integrated circuit with decoder 50, for example.
  • Architecture 100 may support direct memory access (DMA), and allow for DMA data transfers.
  • DMA data transfer essentially copies a block of memory from one device to another. The transfer may be performed by a DMA controller, which is incorporated into the secure processor 110.
  • bus mastering DMA where the device takes control of the bus and performs the transfer itself, may be utilized.
  • FIG. 3 there is shown a flow diagram of a process according to an embodiment of the present invention, and suitable for use with architecture 100 of Fig. 2.
  • secure processor 110 Upon boot-up, or reset, secure processor 110 unpacks processor 20 executable code from non-volatile memory 120 at block 310.
  • Unpacking generally refers to un-compressing.
  • the secure processor 110 transfer of processor 20 executable code at block 310 may include decrypting, where the processor code is stored in memory 120 in an encrypted form.
  • the code may be unpacked to memory 120, for example.
  • the packed and/or unpacked code is initially checked for validity by secure processor 110, such as by verifying the integrity of an image or at least a portion thereof, at block 320.
  • image may refer to the code or a portion of the code. If validated, secure processor 110 stores the processor 20 executable code in volatile memory 35, and the main processor 20 is permitted to operate, e.g., boot, using the secure processor 110 volatile memory 35 loaded boot data, at block 330.
  • the code stored in memory 35 is rechecked for validity, at block 340.
  • a re-check may occur periodically, or aperiodically, such as upon the occurrence of a predetermined event, or substantially randomly. If the code stored in volatile memory 35 is determined to be valid by a re-check, architecture 100 continues to operate in a normal fashion, e.g., analogous to operation of STB architecture 10. If the stored code is determined to be invalid at either block 320 or block 340, architecture 100 may be reset, such that processing returns to block 310.
  • a secure boot is performed.
  • FIG. 4 there is shown a flow diagram of one embodiment of secure boot actions taken at blocks 310, 320.
  • secure processor 110 identifies non-volatile memory 30, such as by checking a jumper configuration, at block 311.
  • an initial security state may be established by setting one or more registers to a default condition.
  • One such register may be incorporated within secure processor memory 120 or within memory 35, for example, such that the register is coupled to a reset pin of processor 20. and set to a default value that inhibits operation of processor 20.
  • secure processor 110 boots, such as by using code stored within a boot sector of memory 120.
  • secure processor 110 selects a key to authenticate processor 20 executable code stored in non-volatile memory 30.
  • the key may take the form of any data suitable for authenticating code stored in memory 30.
  • the selected key may take the form of a Rivest, Shamir, and Adelman (RSA) algorithm compatible public key.
  • the key may be stored in memory 120.
  • more than one key may be stored in memory 120, and one of the stored keys selected in any conventional manner; as long as the selected key is a public key that corresponds to a private key used to digitally sign the memory 30 boot block stored data, or a portion thereof.
  • Block 315 secure processor 110 reads the boot block from memory 30.
  • Block 315 may include the operation of identifying the boot block location in nonvolatile memory 30 using a pointer, and loading the boot block stored data (e.g., a 7 kilobyte data portion) into memory 120.
  • secure processor 110 authenticates the memory 30 read boot block using the selected key.
  • the read boot block may be verified as being created by a party in possession of the private key corresponding to the public key selected at block 314, by verifying the authenticity of a digital signature incorporated with the boot block data using the selected key.
  • processor 20 executable code stored in non-volatile memory 120 is transferred to volatile memory 35, for subsequent use by processor 20.
  • processor 20 executable code stored in memory 30 may be encrypted prior to unpacking, to prevent or frustrate unauthorized attempts to operate processor 20.
  • block 317 may involve decrypting the processor executable code stored in non-volatile memory 30 and transferring it to volatile memory 120. Where the same RSA private key used to digitally sign the boot block is used to encrypt the processor executable code, the same selected key may be used to decrypt the processor executable code.
  • processor 20 is booted at block 330.
  • block 330 involves secure processor 110 changing the default security configuration (e.g., setting or resetting the register coupled to the processor 20 reset pin), to enable processor 20 to boot.
  • any suitable sec.ure boot methodology may be utilized.
  • the software is again validated at block 340.
  • a random number is generated and stored.
  • An authentication value indicative of the software (using the random number as a seed value) is also generated and stored in memory.
  • the authentication value is again calculated (i.e., recalculated) at block 340. If the software has not been tampered with, the re-calculated authentication value will match the stored authentication value. If the software has been tampered with or replaced, these authentication values will not match.
  • the software may continue to be validated. If the authentication values do not match, architecture 100 (Fig. 2) may be reset, so as to re-initialize the software to a valid condition, such as by secure processor 110 setting or resetting a register coupled to the reset pin of processor 20.
  • primitive cryptographic functions can be used to provide a suitable authentication value or code for the processor 20 executable software.
  • One such example may be implemented utilizing a cryptographic hash function.
  • Another such example is implemented utilizing a message authentication code generating function, such as cipher block chaining, where a cryptographic block cipher is used, like DES,
  • a flow diagram of a process 500 that may be used at blocks 320, 340 (Fig. 3).
  • a random number may be determined at block 510.
  • an authentication value of at least a portion of the processor 20 executable code and the random number is generated.
  • "Authentication value” generally refers to a small digital value akin to a "fingerprint" of data.
  • An authentication value is commonly represented as a short string of random-looking letters and numbers.
  • hash functions may be used to generate the authentication value. Examples of conventional hash functions include: HAVAL, MD2, MD.4, MD5, PANAMA, RIPEMD, SHA-x, Tiger(2) and WHIRLPOOL.
  • the authentication value may be stored at block 530.
  • the authentication value may be stored in memory 120 of secure processor 110 (Fig. 2), to frustrate unauthorized efforts to. alter it, for example.
  • the random number determined at block 510 may also be stored in memory 120.
  • a subsequent authentication value is determined at block 550.
  • the random number determined at block 510 is recovered from memory 120 (Fig. 2) and used in combination with the processor 110 executable code then stored in memory 120 to determine a subsequent authentication value using the same methodology as was used at block 520.
  • the authentication value stored at block 530 and subsequent authentication value determined at block 550 are then compared at block 560. If the processor 20 executable code has not been tampered with, the subsequently determined and stored authentication values will, match. If the processor 20 executable code has been tampered with or replaced, the authentication values will not match.
  • processor 20 executable code may continue to be validated. If the authentication values do not match, processor 20 may be reset at block 570, so as to re-initialize the software to a valid condition. If the authentication values do match, processing may return to block 540.
  • a memory address is determined using the random number determined at block 510 (Fig. 5).
  • the random number is converted to a physical address in volatile memory 35. This may be accomplished in any suitable manner, such as by truncating a number of most significant bits of the random number (if necessary), and adding the remaining least significant bits portion to a given physical address, such as the lowest physical address, in memory 35.
  • a given physical address such as the lowest physical address, in memory 35.
  • another physical address may alternatively be used as a starting point.
  • an authentication value of the data content of the memory address determined at block 620 is calculated.
  • an encrypting DMA transfer of the data content of the memory address determined at block 620 to a register may be used.
  • the key used in the encrypting DMA transfer may be the same public key that was used to initially authenticate the processor executable code, or may take the form of a different key. Such an encrypting DMA transfer may be accomplished by the DMA engine itself, for example.
  • another address in memory 35 is determined at block 620.
  • the subsequent address locations in memory 35 may be determined in a pseudorandom fashion. This may be, accomplished by performing an encrypting DMA transfer in place using the previous address and a key. Again, the key used may be the same public key that was used to initially authenticate the processor executable code, or may take the form of a different key. Such an encrypting DMA transfer may be accomplished by the DMA engine itself, for example.
  • a new authentication value is determined at block 630. This may be accomplished by exclusive OR'ing the data contents of the currently determined memory address with the prior determined authentication value, and again performing an encrypting DMA transfer of the resultant in place in an authentication value storing register.

Landscapes

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

Abstract

L'invention concerne une méthode pour vérifier de manière continue l'intégrité des données. Elle comprend les étapes consistant à générer un nombre aléatoire ; récupérer des données ; générer une valeur d'authentification correspondant au nombre aléatoire et aux données récupérées ; stocker les données et la valeur d'authentification ; générer une valeur d'authentification subséquente à partir des données stockées et du nombre aléatoire; et comparer la valeur d'authentification stockée avec la valeur d'authentification subséquente afin de vérifier l'intégrité des données.
PCT/US2006/048218 2006-02-09 2006-12-18 Méthode et appareil pour sécuriser des données numériques WO2007094857A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US77169206P 2006-02-09 2006-02-09
US60/771,692 2006-02-09

Publications (1)

Publication Number Publication Date
WO2007094857A1 true WO2007094857A1 (fr) 2007-08-23

Family

ID=38093455

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2006/048218 WO2007094857A1 (fr) 2006-02-09 2006-12-18 Méthode et appareil pour sécuriser des données numériques

Country Status (1)

Country Link
WO (1) WO2007094857A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009034019A1 (fr) * 2007-09-10 2009-03-19 Continental Automotive Gmbh Procédé et dispositif de codage de mots de données
WO2010039405A1 (fr) * 2008-09-23 2010-04-08 Atmel Corporation Interface de communication sécurisée destinée à un système multiprocesseur sécurisé
US7984301B2 (en) 2006-08-17 2011-07-19 Inside Contactless S.A. Bi-processor architecture for secure systems
TWI721602B (zh) * 2019-06-17 2021-03-11 旺宏電子股份有限公司 記憶體裝置及其安全讀取方法
US20220121750A1 (en) * 2020-10-15 2022-04-21 Electronics And Telecommunications Research Institute Method for secure booting using route switchover function for boot memory bus and apparatus using the same

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5757919A (en) * 1996-12-12 1998-05-26 Intel Corporation Cryptographically protected paging subsystem
WO2005091108A1 (fr) * 2004-03-19 2005-09-29 Nokia Corporation Memoire commandee en mode securise

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5757919A (en) * 1996-12-12 1998-05-26 Intel Corporation Cryptographically protected paging subsystem
WO2005091108A1 (fr) * 2004-03-19 2005-09-29 Nokia Corporation Memoire commandee en mode securise

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MENEZES A J ET AL: "HASH FUNCTIONS AND DATA INTEGRITY", HANDBOOK OF APPLIED CRYPTOGRAPHY, CRC PRESS SERIES ON DISCRETE MATHEMATICES AND ITS APPLICATIONS, BOCA RATON, FL, CRC PRESS, US, 1997, pages 321 - 383, XP002275660, ISBN: 0-8493-8523-7 *
TCG: "TCG Specification Architecture Overview, Specification Revision 1.2", TCG SPECIFICATION ARCHITECTURE OVERVIEW, TRUSTED COMPUTING GROUP, US, 28 April 2004 (2004-04-28), pages 1 - 54, XP002413737 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7984301B2 (en) 2006-08-17 2011-07-19 Inside Contactless S.A. Bi-processor architecture for secure systems
WO2009034019A1 (fr) * 2007-09-10 2009-03-19 Continental Automotive Gmbh Procédé et dispositif de codage de mots de données
RU2485584C2 (ru) * 2007-09-10 2013-06-20 Континенталь Аутомотиве Гмбх Способ и устройство для кодирования слов данных
WO2010039405A1 (fr) * 2008-09-23 2010-04-08 Atmel Corporation Interface de communication sécurisée destinée à un système multiprocesseur sécurisé
TWI721602B (zh) * 2019-06-17 2021-03-11 旺宏電子股份有限公司 記憶體裝置及其安全讀取方法
US20220121750A1 (en) * 2020-10-15 2022-04-21 Electronics And Telecommunications Research Institute Method for secure booting using route switchover function for boot memory bus and apparatus using the same
US11556651B2 (en) * 2020-10-15 2023-01-17 Electronics And Telecommunications Research Institute Method for secure booting using route switchover function for boot memory bus and apparatus using the same

Similar Documents

Publication Publication Date Title
US6385727B1 (en) Apparatus for providing a secure processing environment
US9177152B2 (en) Firmware authentication and deciphering for secure TV receiver
US7237121B2 (en) Secure bootloader for securing digital devices
US6438666B2 (en) Method and apparatus for controlling access to confidential data by analyzing property inherent in data
US8006095B2 (en) Configurable signature for authenticating data or program code
KR100851631B1 (ko) 보안 모드 제어 메모리
US6711683B1 (en) Compresses video decompression system with encryption of compressed data stored in video buffer
US20060272022A1 (en) Securely configuring a system
EP1273996A2 (fr) Chargeur-amorce securise pur la securisation de un dispositif numeriques
JP2002507307A (ja) プログラムをプロセッサに読み込むための装置および方法
US20120331303A1 (en) Method and system for preventing execution of malware
KR19990037007A (ko) 블록 연쇄화 및 블록 재정렬을 이용한 외부 메모리를 갖춘 보안프로세서
WO2011109780A2 (fr) Téléchargement de code et pare-feu pour application sécurisée intégrée
JP2004164491A (ja) プログラム更新方法およびサーバ
US20080098418A1 (en) Electronic module for digital television receiver
CN113656086A (zh) 安全存储及加载固件的方法及电子装置
AU743775B2 (en) An apparatus for providing a secure processing environment
WO2007094857A1 (fr) Méthode et appareil pour sécuriser des données numériques
KR101266251B1 (ko) 디지털 콘텐츠의 보안유지 방법 및 장치
EP1465038B1 (fr) Dispositif de mémoire sécurisée pour des environnements logiciel flexibles
AU750573B2 (en) Method and apparatus for controlling access to confidential data
JP2007272923A (ja) サーバ
MXPA00005081A (en) An apparatus for providing a secure processing environment
JP2010044792A (ja) セキュアデバイス、集積回路および暗号化方法
MXPA98008403A (en) Security processor with external memory that uses blocking and block reordering

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06847735

Country of ref document: EP

Kind code of ref document: A1