FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
and
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
[Section 10; rule 13]
TITLE OF THE INVENTION
METHOD FOR LOADING A CODE OF AT LEAST ONE SOFTWARE MODULE
APPLICANT
Name: Viaccess,
Address: Les Collines de l'Arche,
Tour Operera C
92057 PARIS L a Défense
France
Nationality: A Company based in FRANCE
INVENTOR
Name: HAMON Vincent,
Address: 60 Mail Francois Miterrand,
F 35000 Rennes,
France
Nationality: A Citizen of FRANCE
PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the nature of the invention and the manner
in which it is to be performed.
1
[001] The invention pertains to a method for loading a code of at least one software module
into a main memory by means of a security processor.
[002] An object of the invention is also:
- a method for receiving scrambled multimedia content,
- an information-recording medium for implementing these methods,
- a terminal for implementing these methods.
[003] The main memory is also known as a “random-access memory” designated by
the acronym RAM. It is generally a volatile memory, i.e. a memory where the information
elements are erased by powering off. The main memory enables rapid read and write access.
This is why, the instructions of a program to be executed by the security processor are loaded
into this memory from one or more mass memories in which they are initially recorded. Mass
memories are generally non-volatile memories that have large information storage capacities
but are slow in read and write modes. It is therefore not possible to execute a program directly
from instructions in mass memories.
[004] The invention can be applied especially in the field of access control for
providing paid-for multimedia programs as in pay television.
[005] In this description, the term “multimedia content” more specifically designates
an audio and/or visual content to be rendered in a form that is directly perceptible and
comprehensible to a human being. Typically, a multimedia content corresponds to a
succession of images forming a film, a television broadcast or an advertisement. A multimedia
content may also be an interactive content such as a game.
[006] To secure the viewing of multimedia contents and subject this viewing to
certain terms, such as taking out a paid subscription for example, the multimedia contents are
broadcast in scrambled form and not in unencrypted or plain form. In this description, the
channel is said to be “scrambled” when the multimedia content broadcast on this channel is
scrambled.
[007] More specifically, each multimedia content is divided into a succession of
cryptoperiods. Throughout the duration of a cryptoperiod, the conditions of access to the
scrambled multimedia content remain unchanged. In particular, throughout the duration of a
cryptoperiod, the multimedia content is scrambled with the same control word. In general, the
control word varies from one cryptoperiod to another.
[008] Furthermore, the control word is generally specific to a multimedia content, this
control word being drawn randomly or pseudo-randomly. Thus if, at a given instant, N
2
multimedia contents are broadcast simultaneously on N channels, there are N different and
independent control words, each used to scramble one of the multimedia contents.
[009] Here, the terms “to scramble” and “to encrypt” are considered to be synonyms.
This is also the case for the terms “to descramble” and “to decrypt”.
[0010] The plain multimedia content corresponds to the multimedia content
before it is scrambled. This content can be made directly comprehensible to a human being
without recourse to operations of descrambling and without making the viewing subject to
certain terms and conditions.
[0011] The control words needed to descramble multimedia contents are
transmitted in synchronism with the multimedia contents. For example, the control words
needed to descramble the tth cryptoperiod are received by each terminal during the (t-1)th
cryptoperiod. To this end, for example, the control words are multiplexed with the scrambled
multimedia content.
[0012] To secure the transmission of the control words, these words are
transmitted to the terminal in a form of cryptograms contained in ECMs (Entitlement Control
Messages).
[0013] Here below, the term “cryptogram” of a piece of data designates a piece
of information that is not sufficient on its own to retrieve the piece of data in unencrypted or
plain form. To retrieve the piece of plain data, for example the control word that can be used
to directly descramble the multimedia content, its cryptogram must be combined with a piece
of secret information. For example, the cryptogram of a piece of data is obtained by encrypting
the piece of plain data with a cryptographic key. In this case, the piece of secret information is
the cryptographic key used to decrypt this cryptogram. A cryptogram can also be a reference
to a piece of data stored in a table containing a multitude of possible data elements. In this
case; the piece of secret information is the table associating a piece of plain data with each
reference.
[0014] The piece of secret information must be kept in a secure place. To this
end, it has already been proposed to store the piece of secret information in security
processors such as smart cards directly connected to each of the terminals.
[0015] However, the use of smart cards presents a certain number of
drawbacks. In particular, if a major security flaw is discovered in the smart cards, then they
have to be physically replaced by new smart cards. This is difficult to implement on a large
scale.
3
[0016] To overcome this drawback, it has been proposed to replace the
terminals equipped with smart cards by cardless terminals.
[0017] In these terminals, the smart card can be replaced by a software module
executed by a terminal security processor of the terminal. These known terminals can be
equipped with:
- a main memory,
- a security processor taking the form of an integrated circuit in which there is implemented a
microprocessor capable of executing instructions recorded in the main memory, a security
coprocessor, a non-volatile memory and a random-access memory accessible solely to the
security coprocessor, this processor being connected to the main memory by means of a data
bus,
- a code of a multitask operating system capable of scheduling the simultaneous execution of
several user programs when it is executed by the processor,
- a code of a boot loader capable of loading the code of the multitask operating system into
the main memory, and then launching the execution of this operating system from this main
memory when it is executed by the processor,
- instructions of a boot code which loads the code of the boot loader into the main memory
when these instructions are executed by the processor, these instructions being recorded in
the non-volatile memory of the coprocessor starting with the first address to which an ordinal
counter of the processor points immediately after each resetting of this processor,
- one or more non-volatile memories containing the code of the software module.
[0018] These terminals therefore have an architecture close to that of a
conventional computer. In particular, so that it can be executed, the code of the software
module must be loaded into the main memory of the terminal. The term “code” designates the
code executable or interpretable either by the native interpreter or by a low-level virtual
machine implemented in the security processor.
[0019] To this end, in the known methods, the security processor executes:
- the boot code which loads the code of the boot loader into the main memory and then
launches the execution of this boot loader from the main memory, then
- the code of the boot loader to load the code of the multitask operating system into the main
memory, this operating system being configured to use only one reduced range of addresses
of the main memory and then launch the execution of this operating system from this main
memory,
4
- the operating system to schedule the simultaneous execution of several user programs by
this processor.
[0020] Then, the operating system launches the execution of the software
module and sets up securing mechanisms to prevent the code of the software module from
being corrupted or falsified.
[0021] Operating systems are becoming increasingly complex. There is
therefore a great probability of dysfunctions existing in these operating systems. These
dysfunctions are known as bugs. Such a dysfunction can be exploited to remove the security
mechanisms that protect the software module. It is therefore difficult to guarantee that there
is no security flaw when the software module is loaded by an operating system. This guarantee
is all the more difficult to provide as the people who develop operating systems are different
from those who develop the software module. Moreover, attempts at crypto-analysis of the
software module must be made more difficult.
[0022] The prior art is also known from the following documents:
US2009/257595A1, EP1868127A1, US2009/193230A1, US2007/113088A1.
[0023] The invention seeks to overcome at least one of these drawbacks. An
object of the invention therefore is a method for loading a code of at least one software
module into a main memory wherein:
- the boot loader loads, also into the main memory, the code of the software module before
launching the execution of the operating system in a range of addresses of the main memory
situated outside the range of addresses useable by the operating system, and
- after it has been launched, the operating system re-routes a call to this software module from
a user program towards the address of the main memory where the code of this software
module was loaded before the launching of the execution of the operating system in using a
specific file system of the operating system which automatically associates the address of the
software module in the virtual memory space of the user program with the physical address of
the software module in the main memory.
[0024] In the above method, the responsibility for loading the software module
is not left to the operating system. This ensures that dysfunctions in the operating system
cannot be exploited to prevent the loading of this software module or again to load a modified
software module into the main memory.
[0025] Furthermore, the software module is recorded in a range of addresses
that cannot be used by the operating system. This means that no user program can access the
code of the software module without going through the specific file system. Indeed, if a user
5
program tries to read or write outside the range of addresses useable by the operating system
without using the specific file system, this routinely prompts an error which prevents such
reading or writing. The access to the code of the software module is therefore protected by the
operating system itself. In particular, bugs in the operating system can no longer be exploited
to access the code of the software module. The crypto-analysis of the code of the software
module is therefore made more difficult.
[0026] The embodiments of this loading method can comprise one or more of
the following characteristics:
 before the launching of the execution of the boot loader, the boot code
executed by the processor verifies the authenticity of the code of the boot loader on
the basis of a signature of this code and a cryptographic key, and launches the
execution of this boot loader only if the code is authentic;
 during its execution, the boot loader configures a security coprocessor, present
within the integrated circuit of the processor so that it verifies the authenticity of the
code of the software module on the basis of a signature given with the code of this
module and a cryptographic key, after the launching of the execution of the
exploitation system, the security coprocessor automatically and at predefined intervals
verifies the authenticity of the loaded code of the software module and the execution
of the software module is prevented if it is not authentic, this coprocessor using to this
effect its own non-volatile memory and its own random-access memory to execute,
without recourse to the main memory, this verification of the authenticity of the code
of the software module, this non-volatile memory and this random-access memory
being accessible solely to the security coprocessor;
 the boot loader configures a security coprocessor, present within the integrated
circuit constituting the processor, to conceal instructions recorded in a first range of
addresses of the main memory where the code of the software module has been
loaded, the concealment consisting in keeping in encrypted form, with a cryptographic
key Koc1, the instructions of the code of the software module recorded in this range of
addresses and after the launching of the execution of the exploitation system, the
security coprocessor, with the key Koc1, automatically decrypts each instruction read in
this first range of addresses before it is executed by the processor, the coprocessor
using to this effect its own non-volatile memory and its own random-access memory
to execute, without recourse to the main memory, this decryption with the key Koc1,
6
this non-volatile memory and this random-access memory being accessible solely to
the security coprocessor;
 the method comprises the recording of the executable code of the software
module in encrypted form with the key Koc1 in a non-volatile memory and the boot
loader loads this code of the software module encrypted with the key Koc1 directly into
the main memory;
 the boot loader configures a security coprocessor present inside the integrated
circuit of the processor, to conceal data recorded in a second range of addresses of the
main memory, the concealment consisting of the encryption of this data and then,
during its execution, after the launching of the operating system, the software module
records data in this second range of address and, in response, the security coprocessor
encrypts each piece of data to be recorded in this second range of addresses before it is
deposited in a data bus connecting the processor to the main memory and decrypts
each piece of data read by the processor in this second range of addresses when it is
received by the processor in the data bus before its use by the processor so that each
piece of data recorded in the second range of addresses of the main memory is present
solely in encrypted form outside the integrated circuit constituting the processor, the
coprocessor using, to this effect, its own non-volatile memory and its own randomaccess
memory to execute, without recourse to the main memory, this encryption and
this decryption, this non-volatile memory and this random-access memory being
accessible solely to the security processor;
 during its execution, the boot loader configures a security coprocessor, present
inside the integrated circuit of the processor, so that it verifies the authenticity of the
loaded code of the operating system on the basis of a signature provided with the code
of this operating system and a cryptographic key, and after the launching of the
execution of the operating system, the security coprocessor automatically and at
predefined intervals verifies the authenticity of the code of the operating system and
the execution of the operating system is prevented if this code is not authentic, this
coprocessor using to this effect its own non-volatile memory and its own randomaccess
memory to execute, without recourse to the main memory, this verification of
the authenticity of the code of the operating system, this non-volatile memory and this
random-access memory being accessible solely to the security coprocessor;
 the boot loader loads the code of the software module into a continuous range
of addresses of the main memory not paginated by the operating system;
7
 the code of the boot loader is no longer executed after the launching of the
operating system, and this is the case so long as the security processor is not reset;
 the operating system launched sets up a virtual memory mechanism between a
user sub-section of the main memory and one or more mass memories;
 the software module includes pieces of data or the code of a conditional access
library, these pieces of data or this code enabling the decryption of a cryptogram of a
control word present in an ECM (entitlement control message).
[0027] These embodiments of the loading method furthermore have the
following advantages:
- the fact that the boot code recorded in a non-modifiable memory authenticates the boot
loader makes it difficult to carry out any attempt to modify the boot loader;
- the fact that the boot loader, which has itself been authenticated preliminarily by the boot
code, activates the authentication of the software module makes it very difficult to carry out
any malicious modification of the code of the software module;
- the fact that the instructions of the code of the software module recorded in the main
memory are decrypted only within the integrated circuit of the processor preserves the
confidentiality of this code;
- the fact of recording, in a mass memory, the software module directly in encrypted form with
the key used to conceal the code of this software module prevents an operation of decryption
during the loading of the code of the software module of the mass memory into the main
memory;
- the fact that the pieces of data generated by the software module during its execution are
recorded in the main memory in a range of addresses concealed by the coprocessor preserves
the confidentiality of this data;
- the fact that the boot loader, which has itself been authenticated preliminarily by the boot
code, activates the authentication of the code of the operating system makes it very difficult to
carry out any malicious modification of this operating system in order to replace calls to the
software module by calls to another software program;
- loading the code of the software module into a continuous range of addresses facilitates the
verification of its authenticity and the concealment of its code into the main memory.
[0028] An object of the invention is also a method for receiving scrambled
multimedia content scrambled with the control word CWi,t, this method comprising:
- the reception of an ECM (entitlement control message) containing a cryptogram CW*i,t of the
control word CWi,t;
8
- the loading of a software module into a main memory of a reception terminal, this software
module being capable of decrypting the cryptogram CW*i,t to obtain the control word CWi,t,
when it is executed by a processor connected to the main memory by a data bus;
- the execution by the processor of the software module to decrypt the cryptogram CW*i,t;
- the descrambling of the multimedia contents scrambled by means of the control word in
plain form CWi,t;
this method comprising the loading of the software module according to the above loading
method.
[0029] An object of the invention is also an information-recording medium
comprising instructions for implementing one of the above methods, when these instructions
are executed by an electronic security processor.
[0030] An object of the invention is also a terminal equipped with: :
- a main memory,
- a security processor taking the form of an integrated circuit in which there is implemented a
microprocessor capable of executing instructions recorded in the main memory, a security
coprocessor, a non-volatile memory and a random-access memory accessible solely through
the security coprocessor, this processor being connected to the main memory by means of a
data bus,
- a code of a multitask operating system capable of scheduling the simultaneous execution of
several user programs when it is executed by the processor,
- a code of a boot loader capable of loading, into the main memory, the code of the multitask
operating system, and then launching the execution of this operating system from this main
memory when it is executed by the processor,
- instructions of a boot code which loads the code of the boot loader into the main memory
when these instructions are executed by the processor, these instructions being recorded in
the non-volatile memory of the coprocessor starting with the first address to which an ordinal
counter of the processor points immediately after each resetting of this processor,
- one or more non-volatile memories containing the code of a software module
wherein
- the boot loader is also capable of loading the code of the software module into the main
memory before the launching of the execution of the operating system when it is executed by
a processor, and
- after it has been launched, the operating system is capable of re-routing a call to this
software module from a user program towards the address of the main memory where the
9
code of this software module was loaded before the launching of the execution of the
operating system when it is executed by the microprocessor.
[0031] The embodiments of this terminal can comprise the following
characteristic:
- the terminal comprises an ECM receiver,
- the software module is capable of receiving an ECM, decrypting the cryptogram CW*i,t to
obtain the control word CWi,t, contained in the ECM when it is executed by the processor, and
- the terminal comprises a descrambler capable of descrambling a multimedia content
scrambled by means of the control word CWi,t decrypted by the software module.
[0032] Other features and advantages of the invention shall appear clearly from the following
description given purely by way of an indication that is in no way exhaustive and made with
reference to the appended drawings, of which:
• Figure 1 is a schematic illustration of a system for sending and receiving scrambled
multimedia content;
• Figure 2 is a schematic illustration of a central processing unit implemented in the
system of figure 1;
• Figure 3 is a flowchart of a method for loading a code of a software module in a main
memory of the central processing unit of figure 2;
• Figure 4 is a flowchart of a method for receiving scrambled multimedia content; and
• Figure 5 is a flowchart of a variant of the method of figure 3.
[0033] In these figures, the same references are used to designate the same elements.
[0034] In the rest of this description, the characteristics and functions well
known to those skilled in the art are not described in detail. In addition, the terminology used
is that of conditional access systems for access to multimedia contents. For more information
on this terminology, the reader may refer to the following document:
“Functional Model of Conditional Access System”, EBU Review, Technical European
Broadcasting Union, Brussels, BE, n° 266, 21 December 1995.
[0035] Figure 1 shows a system 2 for sending and receiving scrambled
multimedia contents. The multimedia contents sent are linearized multimedia contents. For
example, a multimedia content corresponds to a sequence of an audiovisual program such as a
television broadcast or a film.
[0036] The plain multimedia contents are generated by one or more sources 4
and transmitted to a broadcasting device. The device 6 broadcasts the multimedia contents
simultaneously to a multitude of reception terminals through an information-transmission
10
network 8. The broadcast multimedia contents are synchronized in time with one another so
as to, for example, comply with a pre-set program schedule.
[0037] The network 8 is typically a long-distance information transmission
network such as the Internet or a satellite network or any other broadcasting network such as
the one used for the transmission of digital terrestrial television (DTTV).
[0038] To simplify figure 1, only three reception terminals 10 to 12 have been
shown.
[0039] The device 6 comprises an encoder 16 which compresses the
multimedia contents that it receives. The encoder 16 processes the digital multimedia
contents. For example, this encoder works according to the MPEG2 (moving picture expert
group – 2) standard or the UIT-T H264 standard.
[0040] The compressed multimedia contents are directed to an input 20 of a
scrambler 22. The scrambler 22 scrambles each compressed multimedia content so as to make
its viewing conditional on certain terms such as the purchase of an access title by the users of
the reception terminals. The scrambled multimedia contents are rendered at an output 24
connected to the input of a multiplexer 26.
[0041] The scrambler 22 scrambles each compressed multimedia content by
means of a control word CWi,t which is provided to it, as well as to a conditional access system
28, by a key generator 32. The conditional access system 28 is also known by its acronym CAS.
The index i is an identifier of the channel on which the scrambled multimedia content is
broadcast and the index t is an order number identifying the cryptoperiod scrambled with this
control word.
[0042] Typically, this scrambler is compliant with a standard such as the DVBCSA
(digital video broadcasting – common scrambling algorithm), ISMA Cryp (Internet
streaming media alliance Cryp), SRTP (secure real-time transport protocol), AES (advanced
encryption standard), ... etc.
[0043] For each channel i, the system 28 generates ECMs (entitlement control
messages) denoted as ECMi,t containing at least the preliminarily computed cryptogram CW*i,t
of the control word CWi,t generated by the generator 32 and used by the scrambler 22 to
scramble the cryptoperiod t of the channel i. These messages and the scrambled multimedia
contents are multiplexed by the multiplexer 26, the latter being respectively provided by the
conditional access system 28 and by the scrambler 22 and then transmitted on the network 8.
[0044] The system 28 also inserts the following into each ECM:
11
- the cryptograms CW*i,t et CW*i,t+1, computed by the system 28, of the control words
CWi,t and CWi,t+1 enabling descrambling the immediately consecutive cryptoperiods t and
t+1 of the channel i,
- access conditions CA to be compared with the access titles acquired by the user, and
- a MAC cryptographic signature or redundancy used to verify the integrity of the ECM.
[0045] The ECM containing the pair of control words CWi,t/CWi,t+1 is denoted as
ECMi,t in the rest of the description.
[0046] Here, the index t also identifies the cryptoperiod CPi,t that can be
descrambled by means of the control word CWi,t contained in the message ECMi,t. The index t is
unique for each cryptoperiod CPi,t.
[0047] By way of an illustration, here the scrambling and the multiplexing of
the multimedia contents comply with the DVB-Simulcrypt (ETSI TS 103 197) protocol.
[0048] In the example, the terminals 10 to 12 are identical. Thus, here below,
only the terminal 10 is described in greater detail.
[0049] The terminal 10 is herein described in the particular case where it is
capable of simultaneously descrambling a single channel i. To this end, the terminal 10
comprises:
- a central processing unit 60 to descramble the channel i, and
- a receiver 70 of broadcast multimedia contents
[0050] The unit 60 descrambles the channel i to display it on a display unit 84.
[0051] For example, the display unit 84 is a television set, a computer or again a
landline telephone or a cell phone. Here, the display unit is a television set.
[0052] In figure 1, the different functions of the unit 60 are represented in the
form of functional blocks. The hardware architecture of the unit 60 used to make these
different functional blocks is described with reference to figure 2. The unit 60 comprises a
demultiplexer 70 which transmits, on the one hand, the multimedia content to a descrambler
74 and, on the other hand, the messages ECMi,t and the EMM (entitlement management
message) to a module 76 for conditional access to the multimedia content.
[0053] The descrambler 74 descrambles the scrambled multimedia content
with the control word transmitted by the module 76. The descrambled multimedia content is
transmitted to a decoder 80 which decodes it. The decompressed or decoded multimedia
content is transmitted to a graphic card 82 which drives the display of this multimedia content
on the display unit 84 equipped with a screen 86.
12
[0054] The display unit 84 displays the multimedia content in plain form on the
screen 86.
[0055] The unit 76 processes inter alia confidential information such as
cryptographic keys. To preserve the confidentiality of this information, it is designed to be as
robust as possible against attempted attacks by computer hackers.
[0056] The unit 60 is connected to a mass memory 78 in which there are
recorded, in non-volatile form, especially data and codes of different programs to be executed
in order to decrypt the cryptograms CW*i,t.
[0057] Figure 2 shows a more detailed view of the unit 60. Here, the unit 60
comprises:
- an electronic safety processor 90,
- a main memory 92,
- a non-volatile memory 94,
- a data and address bus 96 connecting the processor 90 to the memories 78, 92, 94 and to the
receiver 70.
[0058] The processor 90 is a programmable processor capable of executing instructions
recorded in the memory 78. To this end, the processor 90 incorporates a main microprocessor
19 and different coprocessors, each dedicated to a specific task.
[0059] In this embodiment, by way of an illustration, the processor 90 comprises a specific
coprocessor for each of the functional blocks 72, 74, 80 and 82 of figure 1. In figure 2, these
coprocessors carry the same numerical references as the functional block corresponding to
figure 1. Thus, the processor 90 comprises:
- a coprocessor 72 for the multiplexing of the multimedia streams received by the receiver 70,
- a coprocessor 74 for the descrambling of the multimedia contents,
- a coprocessor 80 for the decoding of the multimedia contents, and
- a coprocessor 82 for the video display.
[0060] Each of these coprocessors is capable of executing instructions in parallel to those
executed by the microprocessor 99. Thus, such coprocessors enable the execution of tasks
more rapidly than if only one microprocessor 99 were to be used.
[0061] Here, the processor 90 takes the form of a single integrated circuit on which there are
made the microprocessor 99 as well as the different coprocessors. This integrated circuit is
housed in a single pack. Typically, the microprocessor 99 and the different coprocessors are
etched on the same piece of silicon. Such a coprocessor is also known as a “system on chip” or
SoC.
13
[0062] The microprocessor 99 has all the elements of a classic microprocessor. In particular,
the microprocessor 99 incorporates an arithmetic and logic unit and various registers to
execute instructions recorded in the main memory 92. One of these registers contains the
address of the next instruction to be executed. This register is also known as an ordinal
counter.
[0063] The processor 90 is herein qualified as a security processor because it also incorporates
a security coprocessor 100. An example of a security coprocessor is described in the patent
application US20050169468.
[0064] The coprocessor 100 can be configured to autonomously execute a certain number of
tasks such as the execution of cryptographic functions. For example, this coprocessor 100 is
equipped to this effect with:
- its own arithmetic and logic unit,
- a non-volatile memory 102 accessible in read mode only, and
- a random-access memory 103.
[0065] The memories 102 and 103 are accessible solely to the coprocessor 100. In particular,
no program executed by the processor 90, the code of which is loaded from an external
memory to the processor 90, can access the content of these memories 102 and 103.
[0066] The memory 102 contains cryptographic keys and the executable codes of the
cryptographic functions used during the implementation of the method of figure 3.
[0067] Here, the memory 102 contains especially the following cryptographic keys:
- keys Koc1 and Koc2 used to respectively conceal a first range and second range of the memory
92,
- a key KACS to decrypt the code of an ACS module,
- public keys KPubOS, KPubBL and KPubACS corresponding respectively to private keys KPrivOS, KPrivBL and
KPrivACS used to verify signatures.
[0068] The memory 102 comprises especially executable codes in order to:
- authenticate a content of the main memory 92 or of the memory 78 and 94, and
- conceal a content of the main memory 92.
[0069] More specifically, the memory 102 comprises an executable code enabling the booting
of the system and the authentication of the content of a data page stored in the memory 92 or
94 when it is executed by this coprocessor 100. This function, which herein is called a dynamic
integrity check, takes especially the following as input parameters:
- the starting and ending physical addresses of the range of pieces of data in the memory, and
14
- the address in which the signature used to verify the authenticity of the data included
between the starting and ending addresses is located.
[0070] The dynamic integrity check returns the value “true” if the content of the data range
between the starting and ending addresses corresponds effectively to the signature indicated.
If not, this function returns the value “false”.
[0071] Once parameterized, the execution of the dynamic integrity check is activated at
regular intervals by the coprocessor 100. When this function has been configured and
activated, it is said that the range of data identified by its starting and ending addresses in the
memory has been subjected to a dynamic integrity check.
[0072] The memory 102 comprises the executable code of a function of concealment of the
data contained in a continuous range of addresses in the main memory 92. This concealment
function accepts especially as an input parameter the starting and ending addresses of the
range. When this function is activated, whenever the processor 90 writes a piece of data in this
range of addresses, the concealment function is executed by the coprocessor 100 to encrypt
this piece of data before it is deposited in the bus 96. This piece of data is then recorded in
enciphered form in the memory 92. Thus, only the encrypted data circulates outside the
processor 90. Similarly, whenever the processor 90 reads a piece of data in this range of
addresses, the coprocessor 100 decrypts the encrypted data received by means of the bus 96
before it is transmitted for processing, for example to the microprocessor 99 or to one of the
coprocessors 72, 74, 80 and 82.
[0073] The fact that a range of data is concealed by the coprocessor 100 is therefore totally
transparent to the microprocessor 99 and to any other coprocessor of the processor 90.
Indeed, the microprocessor 99, like the other coprocessors, is totally discharged from these
operations of encryption and decryption of the data written or read in the memory 92. The
concealment of the data contained in the main memory makes it possible to preserve the
confidentiality of this data even if the main memory can be read by any spy software.
[0074] When the coprocessor 100 is configured to conceal a range of data, then this range or
section of memory is said to be concealed.
[0075] The codes and data recorded in the memory 102 are protected because they are
recorded in a read-only memory and this memory is non-volatile. Furthermore, the content of
the memory 102 does not need to be copied out into the main memory 92 to enable the
execution of these encryption and decryption algorithms. Indeed, the coprocessor 100
internally has all the components needed to enable the execution of the executable codes
15
recorded in the memory 102 without its being necessary for this purpose to copy it out into
another external memory such as for example the main memory 92.
[0076] The memory 94 is a non-volatile memory. For example, it is a flash memory. This
memory 94 herein contains the code 104 of a boot loader as well as the signature 106 of this
boot loader by means of the private key KPrivBL. The boot loader 104 is described in greater
detail with reference to figure 3.
[0077] The main memory 92 is typically a RAM (random-access memory). This memory 92 is
also typically volatile.
[0078] The main memory 92 contains the instructions and the data executed by the processor
90.
[0079] In figure 2, a particular partition of the memory 92 is shown. More specifically, the
memory 92 is partitioned into:
- a section 110 reserved for the operating system,
- a section 112 reserved for the recording therein of the code of an ACS module which is
described in greater detail with reference to figures 3 and 4.
- a section 114 reserved for the storage of the data generated by the ACS module during its
execution, and
- as the case may be, one or more additional sections 116 used for other applications such as
video processing operations.
[0080] The section 110 is itself partitioned into two sub-sections 118 and 120. The sub-section
118 contains the code of the kernel. The sub-section 120 is used for the operating system to
meet the different memory requirements especially those of the user programs.
[0081] The memory 78 is a mass memory or mass storage device such as a hard disk drive or
other similar device. It is a non-volatile memory from which it is not possible to directly
execute the executable code of a program.
[0082] Here, this memory 78 comprises:
- the code 126 of the ACS module,
- the code 128 of the operating system,
- a signature 130 of the code 126 of the ACS module obtained by means of the private key
KPrivACS, and
- a signature 132 of the code 128 obtained with the private key KPrivOS.
[0083] In the memory 78, the code 126 is recorded in encrypted form by means of the key
KACS.
16
[0084] Here, the operating system is a Linux® operating system version 2.6.23 integrating
different functions which shall now be described. These functions require no modification at
all of the existing sources of the Linux kernel. They may be added to the kernel by
recompilation or in the form of Linux kernel modules.
[0085] The Linux operating system manages a virtual memory mechanism. Such mechanisms
are well known and only some explanations are given here. Typically, this virtual memory
mechanism is herein a pagination mechanism for the main memory 92. Indeed, the addresses
of the data of a program user are encoded on N bits so that the virtual addressing space of a
program extends from 0 to 2N, where N is an integer. Generally, N is an integer greater than or
equal to 16 or 32. Thus, the virtual addressing space is far greater than the number of physical
addresses available in the main memory 92. To overcome this drawback, the operating system
loads from the memory 78 to the main memory 92 only those pages in which there are pieces
of data or instructions required by the user program being executed. The other data pages
forming the user program remain in the memory 78. More specifically, in Linux, the pages of
programs are loaded solely into the user sub-section 120. The programs that get executed
from the user sub-section are herein called user programs.
[0086] The pagination mechanism therefore takes charge of:
- automatically loading the pages required to execute the user program into the main
memory, and
- converting the virtual addresses, expressed in the virtual addressing space of the user
program, into physical addresses in the memory 92 in which the required data is located.
[0087] When a page is required by a program, the pagination mechanism allocates a free
physical page in a non-deterministic way and copies out the data from the page stored in the
memory 78 to the allocated memory page.
[0088] Thus, when a user program is executed from an operating system, it is difficult to
predict in advance where in the main memory the different segments forming such a program
would be located. It is therefore very difficult to use the coprocessor 100 to conceal only these
segments, conceal these segments differently from the other segments or place these
segments under dynamic integrity check.
[0089] By way of an illustration, in Linux, the virtual addressing space of a user program is
partitioned into five segments:
- a “text” segment containing the executable code of the program. This segment is accessible
only in execution and in reading;
17
- a “data” segment containing the initialized data of the program. This segment is accessible in
reading and in writing;
- a “bss” segment containing the non-initialized data of the program;
- a “heap” segment of variable size used to allocate memory to the program to be executed;
and
- a “stack” segment used to stack the local variables of the program.
[0090] The operating system also has a scheduler capable of automatically scheduling the
execution of the different user programs in time. For example, on the terminal 10, the
scheduler shares the time of use of the microprocessor 99 between the different user
programs to simulate a simultaneous execution of these user programs.
[0091] Finally, like any operating system, this one has one or more file systems or systems of
files. A file system associates, with an access path and a file name, the content of this file on an
information storage device such as the memory 78. The operating system such as Linux also
make it possible to define file systems which are not necessarily associated with a hardware
device for data storage.
[0092] This faculty is exploited here to define a particular file system, herein called the
“VMAPPER file system” in addition to the traditional file systems used to access the content of
the memory 78. The code of the VMAPPER file system is integrated into the code 128 of the
operating system. It is therefore loaded at the same time as the operating system in the
section 118 of the memory 92.
[0093] This VMAPPER file system places the following in correspondence:
- an access path and the name of a file « LibACS » with the memory section 112, and
- the address and the name of a file « DataACS » with the memory section 114.
[0094] This VMAPPER file system manages the opening and closing of these two files LibACS
and DataACS as well as the writing and reading in these files. Furthermore, the VMAPPER file
system can also manage rights of access to these files. An example of an embodiment of this
file system is described in greater detail with reference to figure 3.
[0095] The code 126 of the ACS module is herein specifically written so as to exploit the file
DataACS to write and read therein the data generated during its execution. To this end, in the
code 126 of the ACS module, the functions of writing and management of the memory are
overloaded or rewritten. By way of an illustration, when the ACS module is written in C
language, the “malloc” and “free” functions are replaced respectively by proprietary functions
VA-OS-alloc() and VA-OS-free(). These latter two functions can make it possible to allocate a
memory zone in the file DataACS to write pieces of data therein and then release them. These
18
functions VA-OS-alloc() and VA-OS-free() make it possible therefore to use section 114 of the
memory 92 to manage the heap of the ACS module. Thus, the heap of the ACS module is
physically localized in the section 114.
[0096] The loading of the code 126 of the ACS module into the memory 92 shall now be
described with reference to figure 3.
[0097] Initially, at a step 150, the terminal 10 is powered on or reset.
[0098] In response, during a step 152, the ordinal counter of the coprocessor 100 is initialized.
When it is initialized, it points to the first row of instruction of the boot code recorded in the
memory 102 of the coprocessor. This first row therefore corresponds to the initial default value
of the ordinal counter.
[0099] At a phase 154, the boot code is therefore executed before any other software by the
coprocessor 100. To this end, the coprocessor 100 keeps the microprocessor 99 inactive. For
example, it maintains a pin for resetting the microprocessor 99 in a reset state.
[00100] The execution of the boot code by the coprocessor 100 leads it to perform the
following steps.
[00101] At a step 156, the coprocessor 100 loads the code 104 of the boot loader and a
signature 106 in the memory 92.
[00102] Then, at a step 158, it checks the authenticity of the code 104 loaded into the
memory 92. To this end, at the step 158, the boot code has a predefined format which gives
the coprocessor 100 the starting and ending addresses of the range of addresses in which the
code 104 has been recorded in the memory 92 as well as the address of the signature 106.
[00103] The checking of the authenticity of a range of data is for example done as
follows. First of all, the coprocessor applies a predetermined hash function to the data
contained in the range of addresses specified to obtain a first imprint of this data. Then, the
coprocessor 100 using a public key decrypts the signature specified to obtain a second imprint.
Then, the coprocessor compares the first and second imprints. If these imprints are identical,
the content of the range of data is considered to be authenticated. If not, the content of this
range of data is not accurately authenticated. To verify the authenticity of the code 104, the
coprocessor 100 uses the key KPubBL.
[00104] When the content of the range of data is not accurately authenticated, the
terminal 10 is reset and the method returns to the step 150.
[00105] Then at a step 162, if the code 104 is properly authenticated, the coprocessor
100 initializes the microprocessor 99 so that it executes the boot loader that has just been
authenticated in the main memory. To this end, for example, it places the ordinal counter of
19
the microprocessor 99 at the address in the physical memory of the first instruction of the boot
loader and releases the resetting pin of the microprocessor 99.
[00106] From this instant onwards, there starts a stage 166 in which the code of the
boot loader is executed by the microprocessor 99.
[00107] Initially, at a step 168, the boot loader configures the coprocessor 100 to
conceal the sections 112 and 114 of the memory 92. In this particular case, the encryption
algorithm chosen to conceal the section 112 is more robust than the one chosen to conceal the
section 114. However, the most robust encryption algorithm also has a greater number of
instructions to be executed to encrypt and decrypt a piece of data. It is therefore longer in its
execution. Here, the encryption elements used to conceal the sections 112 and 114 are
respectively the keys Koc1 and Koc2.
[00108] Then, at a step 170, the boot loader loads the code 126 of the ACS module into
the memory 92.
[00109] At an operation 172, the boot loader decrypts the code 126 loaded into the
memory 92 with the key KACS and copies out the executable code thus decrypted to the section
112. Typically, the decryption operations with the key KACS are done by the coprocessor 100.
[00110] Since the section 112 is concealed, the coprocessor 100, using the key Koc1
encrypts each instruction decrypted with the key KACS and then copies it into the section 112.
Thus, at the end of the step 172, the executable code of the ACS module is recorded in the
section 112 in an encrypted form with the key Koc1.
[00111] At a step 176, the boot loader configures the coprocessor 100 to place the
section 112 under dynamic integrity check. To this end, the starting and ending addresses of
the section 112 as well as the address of the signature 130 are given to the coprocessor 100.
[00112] At a step 178, the coprocessor 100, thus configured, checks the authenticity of
the code of the ACS module contained in the section 112. At each check, the coprocessor 100:
- decrypts the code of the ACS module with the key Koc1, then
- applies a predetermined hash function to obtain a first imprint of the code 126, and finally
- compares this first imprint of the code of the ACS module with a second imprint obtained by
decrypting the signature 130 by means of the public key KPubACS.
[00113] If the code of the ACS module in the section 112 is not authentic, the method
returns to the step 150. If the opposite is the case, the methods continues. It will be noted that
the step 178 is automatically reiterated at regular intervals by the coprocessor 100. This
ensures the authenticity of the code of the ACS module so long as it remains loaded in the
memory 92.
20
[00114] At a step 180, the boot loader loads the code 128 of the operating system into
the section 118. The section 118 is distinct from the sections 112 and 114.
[00115] At a step 182, the boot loader configures the coprocessor 100 to place the
section 118 under dynamic integrity check. To this end, the starting and ending addresses of
this section as well as the address of the signature 132 are given to the coprocessor 100.
[00116] At a step 184, the coprocessor 100 checks the authenticity of the code 128
loaded into the section 118 by means of the signature 132 and the public key KPubOS stored in
the memory 102. Since the VMAPPER file system is incorporated into the code 128, this step for
checking the authenticity of the code 128 also makes it possible to check the authenticity of
the VMAPPER file system. It is automatically reiterated at predetermined intervals by the
coprocessor 100 so as to make sure of the integrity of the code 128 so long as it is loaded into
the section 118.
[00117] If the code 128 loaded into the section 118 is not authentic, the terminal is reset
and the method returns to the step 150.
[00118] If the opposite is the case, the method continues with a step 186. At the step
186, the boot loader launches the execution of the operating system in passing the size and
the location of the sections 112 and 114 and 120 as parameters into the main memory. Thus,
the operating system defines the user space in the section 120 and outside the sections 112,
114 and outside the section 116 too. After this, the boot loader is not used so long as the
terminal is not reset, i.e. so long as there is no return to the step 150. Thus, preferably, to
release space in the memory 92, the code of the boot loader is erased or the space occupied by
the code of the boot loader is made available in write mode so that other applications can
write information therein and thus erase all or part of this code.
[00119] There then begins a new phase 190 in which the operating system is executed.
[00120] At a step 192, the operating system loads the VMAPPER file system. The
description of this operation is done in the particular case where the operating system is Linux
2, version 2.6.23. It is done with reference to functions and primitives known to this operating
system. These primitives and functions are shown in bold here below and shall not be
explained in detail. In this example, the function provided by the VMAPPER file system is
compiled in the kernel. The step 192 is therefore activated by the initialization of the kernel.
[00121] The step 192 starts with the recording of the file system defined in the
VMAPPER file system. This file system is recorded in the operating system Linux by a call to the
function register_filesystem().
21
[00122] The member get_sb of the structure file_system_type which is passed as a
parameter of the function register_filesystem() is placed at get_sb_single. This generic
function of Linux is used to declare that the file system can be set up only once. This ensures
that only one instance of this file system exists in the operating system.
[00123] Then, the file system is set up. To this end, a function defined in the code of the
file system VMAPPER called V_fill_super() is passed as a parameter of get_sb_single and then
called.
[00124] The function V_fill_super() fills a super_block type structure and places the
member s_flags of this structure at the value MS_RDONLY and places the member s_op of this
structure so that the renewed setting up of this file system keeps it in read-only mode.
[00125] The function V_fill_super() creates a new inode with the function new_inode.
This inode represents the root directory.
[00126] The function V_fill_super() creates a new code with the function new_inode.
This inode corresponds to the section 112 and therefore to the ACS module. Here, it carries the
file name “LibACS”. Only the reading rights are given in this file. Furthermore, only four
operations are authorized on the file LibACS: opening, reading, the MMAP function and the
“release” function.
[00127] When it is used, some bytes of the file LibACS containing the ACS module must
be read. To this end, the function “read” enables the reading of the file LibACS from the Linux
operating system. During this reading operation, the section 112 is made to correspond with a
range of addresses of the section of the operating system by means of the function ioremap.
The content of the first bytes of the section 112 is copied out by means of the function
memcpy_fromio. Then, the previously established correspondence of addresses is eliminated
by means of calls to function iounmap. This enables retrieval of the first bytes of the file LibACS
to obtain the information needed to load the ACS module.
[00128] Finally, the code of the ACS module is loaded. The loading of the code of the
ACS module is prompted typically when a user program is loaded and when it declares
dependence on the file LibACS.
[00129] At the step 194, the user program is loaded by the program loader. The
program loader declares the library LibACS to be present in the virtual space of the program by
calling mmap. This call is implemented in the VMAPPER file system by means of the function
remap_pfn_range. The VMAPPER file system thus associates the virtual range of addresses
reserved by the program loader for the library LibACS with the range of physical addresses in
the section 112 where the ACS module is copied out. Thus, whenever the user program calls
22
the ACS module, this module is indicated as being in the main memory. This therefore does
not prompt any page defect and therefore any attempt on the part of the operating system to
reload the code 126 into a page of the section 120. Thus, although the code 126 has been
loaded into the main memory before the execution of the operating system, the user
programs can launch the execution of this ACS module as if it had been loaded by the
operating system. To this end, the user programs call the file LibACS.
[00130] Furthermore, here the ACS module is under dynamic integrity check and is code
is concealed. The security of the terminal 10 is therefore boosted. Finally, the fact that the ACS
module is loaded before the start of execution of the operating system ensures that the ACS
module is loaded even if there are security flaws in the operating system and that the
mechanisms for protecting the code 126 are properly set up.
[00131] The V_fill_super() also creates a new inode with the function new_inode
corresponding to the heap segment. This inode carries the name of the file “DataACS” and
corresponds to the section 114. Only three operations are authorized in this inode, namely
opening, closing and the MMAP function.
[00132] At the execution of the ACS module, the pieces of sensitive data generated by
the ACS module are recorded and read from the heap by means of the functions VA-OS-alloc()
and VA-OS-free(). These functions VA-OS-Alloc() and VA-OS-free() enable a memory block to
be allocated and to be released in the file DataACS. Thus, the pieces of sensitive data
generated by the ACS module are recorded in the section 114 and are therefore protected
since they are automatically concealed by the coprocessor 100.
[00133] Figure 4 gives a more detailed description of an example of operation of the
ACS module when it is executed by the processor 90.
[00134] At a step 200, the ACS module receives an message ECMi,t. At a step 202, it
compares the access rights contained in this ECM with pre-recorded access rights contained for
example in its code 126. If the access rights do not correspond to the access titles, the method
returns to the step 200 to receive the next message ECMi,t. If the opposite is the case, the
method continues with a step 204. At the step 204, the ACS module extracts the cryptogram
CW*i,t contained in the message ECMi,t received. At a step 206, the ACS module decrypts the
cryptogram CW*i,t to obtain the control word in plain mode CWi,t. To this end, for example the
ACS module uses a key recorded in the processor 90. At a step 208, this control word in plain
form CWi,t is transmitted to the coprocessor 74.
23
[00135] Thereafter, the coprocessor 74 uses this control word in plain form to
descramble the scrambled multimedia content. This enables the display of this scrambled
multimedia content in plain form on the screen 86.
[00136] Figure 5 represents an alternative mode of the method of figure 3. To
implement the method of figure 5, the terminal 10 is identical to the one described with
reference to figures 1 and 2 except that the operating system comprises a modified VMAPPER
file system as well as a new program loader VBinLoader. These two functions are integrated
into the executable code of the kernel of the operating system. Thus, they are loaded at the
same time as the operating system into the section 118.
[00137] The VBinLoader function is a program loader designed to load the program
calling the ACS module when its execution is requested. A program loader are designed to
place the data of the program in the main memory in the right memory segment. Such a
program loader is capable of understanding the location of the information in the file of the
program which says where the executable code, the data and other elements are located. It is
also capable of copying the program into the main memory and initializing the registers and
launching the execution of this program.
[00138] Here, the program loader VBinLoader does not copy the ACS module into the
main memory but:
- associates the virtual address of the executable code (segment “text”) in the virtual memory
spaces of the user program which calls the ACS module with an address in a section 112 in
which the executable code of the ACS module is located,
- associates the address of the segment “bss” in the virtual memory space of the user program
with a range of physical addresses in section 114, and
- associates the address of the stack in the virtual memory space of the user program with a
range of physical addresses in the section 114.
[00139] Thus, at the execution of the ACS module, all the pieces of data that must be
recorded in the segment “bss” or in the stack are automatically recorded in the section 114 and
therefore concealed.
[00140] The VMAPPER file system is simplified to put only the name of the file LibACS in
correspondence with the section 112. In this embodiment, it is not necessary to put the name
of a file DataACS in correspondence with the memory section 114.
[00141] Besides, the code 126 is modified so that the sensitive variables initialized are in
read-only mode. For example, they are declared in the code as being constants by means of
the instruction “const”.
24
[00142] The code 126 is also modified to allocate a large-sized variable herein called
VTas in the segment “bss”. Furthermore, all the functions of allocating and releasing memory
in the heap, such as the functions malloc, free, and others used in the code of the ACS module
are replaced by functions that allocate memory in the memory zone reserved for the variable
VTas. Thus, even the pieces of data recorded in the heap by the ACS module are protected
since they are recorded in the variable VTas of the section 114. Such modifications are used to
protect the heap without making it necessary to modify the operating system to manage the
heap differently from what is usually planned.
[00143] The method of figure 5 is identical to the figure of figure 3 except that the steps
192 and 194 are replaced respectively by the steps 220 and 222.
[00144] At the step 220, the operating system initializes both the modified VMAPPER
file system and the program loader VBinLoader.
[00145] At the step 222, when the execution of the ACS module is called by a user
program, the program loader VBinLoader associates the ranges of virtual addresses reserved
for the segment “bss” and for the stack in the virtual memory space of the user program with
address ranges in the section 114. Thus, during the execution of the ACS module, the pieces of
data generated by this module are recorded in the section 114 and therefore automatically
concealed by the coprocessor 100. Thus, their confidentiality is preserved.
[00146] The program loader VBinLoader also associates the addresses of the ACS
module in the virtual addressing space of the user program with the addresses of the section
112.
[00147] Many other embodiments are possible. For example, as a variant, the code 126
is recorded in a non-volatile memory in encrypted form with the key Koc1. Thus, the boot loader
can directly copy the code thus encrypted into the section 112. The steps for decrypting the
code 126 with the key KACS before recording it in this section 112 can therefore be omitted.
Indeed, since the code 126 is directly encrypted with the key Koc1, this code is already
concealed, including in the memory 78.
[00148] The operating system can also be stored in encrypted form and then decrypted
by the boot loader.
[00149] The operating system can contain, in its code, the size and location of the
sections 112 and 114. Thus, it is not necessary to pass these pieces of information as
parameters when launching the operating system.
[00150] The memory 102 can be replaced by several non-volatile memories distributed
within the integrated circuit forming the processor 90.
25
[00151] Similarly, the coprocessor 100 can be implemented in the form of an association
of several coprocessors distributed within the integrated circuit forming the processor 90. For
example, the coprocessor 100 can include a sub-coprocessor to conceal data in the main
memory and another sub-coprocessor to set up the dynamic integrity check of the data. Each
of these sub-coprocessors can comprise its own arithmetic and logic unit so as to execute
instructions in parallel with those of the main microprocessor 99.
[00152] In another embodiment, the totality or at least a part of the functions of the
coprocessor 100 are executed by using the arithmetic and logic unit of the microprocessor 99.
In this embodiment, it is therefore the microprocessor 99 which, for example, carries out the
dynamic integrity check and/or concealment of the data. To this end, the code of the
corresponding functions is loaded into the memory 92. If the code is loaded into the memory
92, the authenticity of this code must be checked. The verification of the authenticity of this
code is done:
- by means of the boot code, or
- by means of the functions themselves authenticated by the boot code.
[00153] Indeed, it is the fact that the boot code is not accessible from the exterior of the
integrated circuit and that it is executed solely within the processor 90, without making use of
external memories, that makes it possible to obtain a high level of security.
[00154] The sections 112 and 114 are not necessarily contiguous in a main memory.
Similarly, the sections 112, 114, 118, 120 and 116 do not need to be contiguous. These sections
can also be laid out in a order different from that shown in figure 2 in the memory 92.
[00155] If the coprocessor 100 is replaced by a security coprocessor capable of
concealing a discontinuous range of addresses or placing it under dynamic integrity checks,
then it is not necessary that the sections 112 and 114 should each correspond to a continuous
range of physical addresses in the main memory.
[00156] The public keys used to verify the signatures can be recorded in any memory
whatsoever and not solely in the memory 102. For example, these public keys are recorded in
the memory 78. In the latter case, preferably the public keys are signed with a private key, the
corresponding public key of which is recorded in the memory 102.
[00157] In another embodiment, instead of using public keys to check the signatures, it
is the secret cryptographic keys that are used. For example, a redundancy of the code is
enciphered by means of a symmetrical cryptographic algorithm and the secret key.
[00158] The code 104 can also be recorded in the memory 78 and not in the memory 94.
Reciprocally, the code 126 can be recorded in the memory 94 instead of the memory 78. These
26
codes 104 and 126 can also be recorded if necessary in the memory 102. The code 104 or 126
can also be directly executed from the memory 94.
[00159] In the method of figure 5, it is not necessary to overload or rewrite the function
of the code of the ACS module to use a heap situated in the section 114. Indeed, as a variant,
the code of the ACS module is written in such a way that the sensitive data, generated by the
ACS module during its execution, are recorded solely either in the stack or in the segment
“bss”.
[00160] What has been described here above in the particular case of the ACS module
can be applied to any software module for which it is desirable to:
- make sure that it is correctly loaded into the main memory,
- make sure of its authenticity,
- make sure of the authenticity of the code really executed by the processor and not a copy of
the code and/or
- preserve the confidentiality of its code.
[00161] Thus, this mode of loading a software module can be applied in other technical
fields such as the field of digital rights management (DRM) or antivirus programs.
[00162] Finally, the integrity check of the software module can be implemented
independently of the concealment of the code and of the data of this software module.
27
We Claim:
1. Method for loading a code of at least one software module into a main memory by
means of a security processor, wherein the security processor executes:
- a boot code which loads (156) the code of a boot loader into a main memory and then
launches (162) the execution of this boot loader from the main memory, the boot code being
recorded in a non-volatile, read-only memory of the processor starting with the first address to
which an ordinal counter of the processor points immediately after its resetting, then
- the code of the boot loader to load (180), into the main memory, the code of the multitask
operating system configured to use only one reduced range of addresses of the main memory
and then launch the execution of this operating system from this main memory,
- the operating system to schedule the simultaneous execution of several user programs by
this processor,
characterized in that
- the boot loader loads (170), also into the main memory, the code of the software module
before launching the execution of the operating system in a range of addresses of the main
memory situated outside the range of addresses useable by the operating system, and
- after it has been launched, the operating system re-routes (194) a call to this software
module from a user program towards the address of the main memory where the code of this
software module was loaded before the launching of the execution of the operating system in
using a specific file system of the operating system which automatically associates the address
of the software module in the virtual memory space of the user program with the physical
address of the software module in the main memory
2. Method according to claim 1 wherein, before the launching of the execution of the
boot loader, the boot code executed by the processor verifies (158) the authenticity of the
code of the boot loader on the basis of a signature of this code and a cryptographic key, and
launches the execution of this boot loader only if the code is authentic.
3. Method according to claim 2, wherein:
- during its execution, the boot loader configures (176) a security coprocessor present within
the integrated circuit of the processor so that it verifies the authenticity of the code of the
software module on the basis of a signature provided with the code of this module and a
cryptographic key,
28
- after the launching of the execution of the exploitation system, the security coprocessor,
automatically and at predefined intervals, verifies (178) the authenticity of the loaded code of
the software module and the execution of the software module is prevented if it is not
authentic, this coprocessor using to this effect its own non-volatile memory and its own
random-access memory to execute, without recourse to the main memory, this verification of
the authenticity of the code of the software module, this non-volatile memory and this
random-access memory being accessible solely to the security coprocessor.
4. Method according to any one of the claims 2 to 3, wherein :
- the boot loader configures (168) a security coprocessor, present within the integrated circuit
constituting the processor, to conceal instructions recorded in a first range of addresses of the
main memory where the code of the software module has been loaded, the concealment
consisting in keeping in encrypted form, with a cryptographic key Koc1, the instructions of the
code of the software module recorded in this range of addresses, and
- after the launching of the execution of the exploitation system, the security coprocessor, with
the key Koc1, automatically decrypts each instruction read in this first range of addresses before
it is executed by the processor, the coprocessor using to this effect its own non-volatile
memory and its own random-access memory to execute, without recourse to the main
memory, this decryption with the key Koc1, this non-volatile memory and this random-access
memory being accessible solely to the security coprocessor.
5. Method according to claim 4, wherein the method comprises the recording of the
executable code of the software module in encrypted form with the key Koc1 in a non-volatile
memory and the boot loader loads this code of the software module encrypted with the key
Koc1 directly into the main memory.
6. Method according to any one of the claims 2 to 5, wherein :
- the boot loader configures (168) a security coprocessor present inside the integrated circuit of
the processor, to conceal data recorded in a second range of addresses of the main memory,
the concealment consisting of the encryption of this data and then,
- during its execution (194), after the launching of the operating system, the software module
records data in this second range of address, and
- in response, the security coprocessor encrypts each piece of data to be recorded in this
second range of addresses before it is deposited in a data bus connecting the processor to the
29
main memory and decrypts each piece of data read by the processor in this second range of
addresses when it is received by the processor in the data bus before its use by the processor
so that each piece of data recorded in the second range of addresses of the main memory is
present solely in encrypted form outside the integrated circuit constituting the processor, the
coprocessor using, to this effect, its own non-volatile memory and its own random-access
memory to execute, without recourse to the main memory, this encryption and this
decryption, this non-volatile memory and this random-access memory being accessible solely
to the security coprocessor.
7. Method according to any one of the claims 2 to 6, wherein :
- during its execution, the boot loader configures (182) a security coprocessor, present inside
the integrated circuit of the processor, so that it verifies the authenticity of the loaded code of
the operating system based on a signature provided with the code of this operating system
and a cryptographic key,
- after the launching of the execution of the operating system, the security coprocessor
automatically and at predefined intervals verifies the authenticity of the code of the operating
system and the execution of the operating system is prevented if this code is not authentic,
this coprocessor using to this effect its own non-volatile memory and its own random-access
memory to execute, without recourse to the main memory, this verification of the authenticity
of the code of the operating system, this non-volatile memory and this random-access
memory being accessible solely to the security coprocessor.
8. Method according to any one of the above claims, wherein the boot loader loads (170)
the code of the software module into a continuous range of addresses of the main memory not
paginated by the operating system.
9. Method according to any one of the above claims, wherein the code of the boot loader
is no longer executed after the launching of the operating system, and this is the case so long
as the security processor is not reset.
10. Method according to any one of the above claims, wherein the operating system
launched sets up a virtual memory mechanism between a user sub-section of the main
memory and one or more mass memories.
30
11. Method according to any one of the above claims, wherein the software module
includes pieces of data or a code of a conditional access library, these pieces of data or this
code enabling the decryption of a cryptogram of a control word present in an ECM
(entitlement control message).
12. Method for receiving a scrambled multimedia content scrambled with the control
words CWi,t, this method comprising:
- the reception (200) of an ECM (entitlement control message) containing a cryptogram CW*i,t
of the control word CWi,t;
- the loading of a software module into a main memory of a reception terminal, this software
module being capable of decrypting the cryptogram CW*i,t to obtain the control word CWi,t,
when it is executed by a processor connected to the main memory by a data bus;
- the execution by the processor of the software module to decrypt (200) the cryptogram
CW*i,t;
- the descrambling of the multimedia contents scrambled by means of the control word in
plain form CWi,t;
characterized in that the method comprises the loading of the software module according to
any one of the above claims.
13. Information-recording medium (78, 94, 102), characterized in that it comprises
instructions for implementing a method according to any one of the above claims, when said
instructions are executed by an electronic security processor.
14. Terminal equipped with:
- a main memory (92)
- a security processor (90) taking the form of an integrated circuit in which there is
implemented a microprocessor (99) capable of executing instructions recorded in the main
memory, a security coprocessor (100), a non-volatile memory (102) and a random-access
memory (103) accessible solely to the security coprocessor, this processor being connected to
the main memory by means of a data bus,
- a code (128) of a multitask operating system capable of scheduling the simultaneous
execution of several user programs when it is executed by the processor,
- a code (104) of a boot loader capable of loading, into the main memory, the code of the
multitask operating system, configured to use only one reduced range of addresses of the
31
main memory and then launch the execution of this operating system from this main memory
when it is executed by the processor,
- instructions of a boot code which loads the code of the boot loader into the main memory
when these instructions are executed by the processor, these instructions being recorded in
the non-volatile memory (102) of the coprocessor starting with the first address to which an
ordinal counter of the processor points immediately after each resetting of this processor,
- one or more non-volatile memories (73, 74) containing the code (125) of a software module,
characterized in that the boot loader (104) is also capable of loading the code of the software
module into the main memory before the launching of the execution of the operating system,
in a range of addresses of the main memory situated outside the range of addresses useable by
the operating system, when it is executed by the processor, and
- after it has been launched, the operating system (128) is capable of re-routing a call to this
software module from a user program towards the address of the main memory where the
code of this software module was loaded before the launching of the execution of the
operating system, in using a specific file system of the operating system which automatically
associates the address of the software module in the virtual memory space of the user program
with the physical address of the software module in the main memory, when it is executed by
the microprocessor.
15. Terminal according to claim 14, wherein:
- the terminal comprises an ECM receiver (70),
- the software module (126) is capable of receiving an ECM, decrypting the cryptogram CW*i,t
to obtain the control word CWi,t, contained in the ECM when it is executed by the processor,
and
- the terminal comprises a descrambler capable of descrambling a multimedia content
scrambled by means of the control word CWi,t decrypted by the software module.