Title of Invention	SECURE METHOD TO TRANSMIT A MESSAGE CONTAINING A PROGRAM BLOCK TO A SECURITY MODULE
Abstract	The aim of this invention is to propose a transmission method of a message containing a program block that allows to avoid the consequences of a possible malicious decryption of this message. This aim is achived through a secure method to update software embedded in a security module, this method comprising the following steps: - formation of a first updating program block (PBI) - determination of a targrt memory zone of said security module, - determiniation through said security module, of a pre-registered content (MM_Ref) in said target memory zone, - formation of a second program block (SBI) obtained by the mixing of all or a part of the pre-registered content with the first program block (PBI), - transmission of the second program block(PBI) to the security module, - reception of the second block by the secutity module, - reading of the target memory zone (MEM), - obtaining and writing in the target memory zone block by the inverse mixing of all or part of the second block and of the target memory zone content.

Title of Invention

SECURE METHOD TO TRANSMIT A MESSAGE CONTAINING A PROGRAM BLOCK TO A SECURITY MODULE

Abstract

The aim of this invention is to propose a transmission method of a message containing a program block that allows to avoid the consequences of a possible malicious decryption of this message. This aim is achived through a secure method to update software embedded in a security module, this method comprising the following steps: - formation of a first updating program block (PBI) - determination of a targrt memory zone of said security module, - determiniation through said security module, of a pre-registered content (MM_Ref) in said target memory zone, - formation of a second program block (SBI) obtained by the mixing of all or a part of the pre-registered content with the first program block (PBI), - transmission of the second program block(PBI) to the security module, - reception of the second block by the secutity module, - reading of the target memory zone (MEM), - obtaining and writing in the target memory zone block by the inverse mixing of all or part of the second block and of the target memory zone content.

Full Text	FORM 2 THE PATENTS ACT, 1970 (39 OF 1970) As amended by the Patents (Amendment) Act, 2005 & The Patents Rules, 2003 As amended by the Patents (Amendment) Rules, 2006 COMPLETE SPECIFICATION (See section 10 and rule 13) TITLE OF THE INVENTION Method of securely updating a program block in a security module. APPLICANT Name : NAGRACARD SA Address : Route de Geneve 22, CH-1033 Cheseaux-sur-Lausanne, Switzerland Nationality : a Swiss Company INVENTOR Name : OSEN Karl Address : Route du Mandement 453, CH-1282 Dardagny, Switzerland Nationality : Swiss PREAMBLE TO THE DESCRIPTION The following specification particularly describes the nature of this invention and the manner in which it is to be performed : The block prepared in this way is encrypted by one or several keys pertaining to the security modules. It is possible to encrypt this block either using a global key, common to all the security modules, or using a personal key, pertaining to each module. In the latter case, it will be necessary to prepare the same number of messages as they are different security modules. The message is then sent to the management centre that disposes of transmission means towards the modules. In a unidirectional system, the message is repeated during a given period in order to ensure that each module has received it. The man skilled in the art is placed in a difficult position when a security leak is detected because he/she must evaluate the risk of this type of message being analyzed by a third party and the risk of leaving this leak open. At times this dilemma led to the situation in which one has forbidden himself to correct a fault of the programme because the risk of comprehension of the substitute programme was too great. The updating of programs in a Pay-TV decoder is well known and described, for example, in the document US2004/107349. The program modules are sent to the decoder encrypted by a key that is used once. This is the principle of the strike list which is applied here. Once the programme module has been received it is stored in the memory of the decoder and activated according to a usual protocol (diversion of an address towards the patch). Brief Description of the Invention The aim of this invention is to allow the man skilled in the art to transmit a message containing a program block in a message without having to worry about the result of a malicious decryption of this message. This aim is achieved by a secure method to update software in a security module, this method comprising the following steps: - formation of a first updating program block (PB1), - determination of a target memory zone of said security module, 3 - determination through said security module, of a pre-registered content (MM_Ref) in said target memory zone, - formation of a second program block (SB1) obtained by the mixing of all or a part of the pre-registered content with the first program block (PB1), - transmission of the second program block (SB1) to the security module, - reception of the second block by the security module, - reading of the target memory zone (MEM), - obtaining and writing in the target memory zone of the first block by the inverse mixing of all or part of the second block and of the target memory zone content. Therefore, thanks to the invention, the transmitted code (second block) has no relation with the first block for those who has no knowledge of the content of the target memory. A third party succeeding to decipher the message will learn nothing more about the functioning of the security module. This method can apply to the sending of the same message to all the security modules and in this case, it is considered that the content of the target memory zone is the same for all the modules. If individual addressing is carried out, it is possible that the content of each memory is different. Once the first program block has been generated, it is mixed with the data of each security module to create the same number of second programme blocks. Brief Description of the Drawings The invention will be better understood thanks to the following detailed description that refers to the enclosed drawings that are given as a non-limitative example, namely: - Figure 1 shows the generation process of the second block, - Figure 2 shows the writing process in the memory of the security module. Detailed Description According to a first embodiment, the content of the target memory is pre-registered with quasi-random values. At the time of the personalization of this type of module, randomly 4 generated data MM_Ref is stored on one hand in the security module MEM and on the other hand at the management centre. According to a second embodiment, the pre-registered data is made up of a program code that could be executed by the processor of the security module. In fact, this code is never executed and serves as an initialization value of the updating region. As in the preceding example, all the modules can have the same dummy program or each module receives a different program. Figure 1 shows the process of formation of a second program block intended for diffusion. When a program block PB1 is ready to be diffused, the method of the invention consists in determining the future localization of this block in the security module. Once this localization is known, it is possible to find the content that had been programmed at the time of the personalization thanks to data stored in the management centre. Once this data is known, the operation consists of mixing this data with the program block PB1 in order to obtain a new data block SBI. This mixing operation can be of different kinds. The simplest way is to use a XOR function between the program block PB1 and the pre-registered data MM_Ref. A second example of mixing consists in enciphering each memory location of the program block PB1 with the content of the pre-registered data MM_Ref. The result of this mixing forms the second program block SBI. This block composed in this way can be transmitted to the related security module, according to the communication mode available between the management centre and the security module. It is enciphered by encryption keys of the system according to known methods. Figure 2 shows the writing process in the memory of the security module. The writing operation of the new program block in the memory of the security module, once the second block has been received, passes through a reading operation of the content of the target memory location. According to our example, each memory location i 5 of the target area MEM is read and processed (or mixed) according to the chosen algorithm. In this example, each memory location is mixed with the corresponding location i of the second block SB1 of the program. The result is registered in the memory of the security module. It should be noted that the program block to be updated is accompanied by verification data according to known modes (hash, CRC etc). Once the program is stored in the module memory, and has been duly verified, it can generally be activated by the modification of a part of the program in the main area. This process can be recurrent, that is to say that if one wishes to modify a part in the program area that has already received a program, the former program functions as a pre-registered value. According to one example wherein the new program would occupy more space, the management centre takes the contents of the previous program as pre-registered values, and for memory space still not used, would use the pre-registered values generated at the time of personalization. In practice, the management centre will preserve a virtual security module whose content represents the content of the security module in the location. All the programs intended for the security modules are also introduced into the virtual module. According to a variant of the embodiment, only one part of the target zone is pre-registered by specific values, for example one location in three. The rest are left blank. Therefore, the mixture will be executed only on one location in three, the other locations being left without modification. 6 We Claim: 1. Secure method to update software embedded in a security module, this method comprising the following steps: formation of a first updating program block (PB1), - determination of a target memory zone of said security module, determination through said security module, of a pre-registered content (MM_Ref) in said target memory zone , - formation of a second program block (SB1) obtained by the mixing of all or a part of the pre-registered content with the first program block (PB1), - transmission of the second program block (SB1) to the security module, - reception of the second block by the security module, - reading of the target memory zone (MEM), obtaining and writing in the target memory zone of the first block by the inverse mixing of all or part of the second block and of the target memory zone content. 2. Method according to claim 1, characterized in that the target memory zone is pre-registered by randomly generated values. 3. Method according to claim 1 implementing a module that includes a microprocessor, characterized in that the target memory zone is pre-registered by a dummy programme not executed by the microprocessor of the security module. 4. Method according to claims 1 to 3, characterized in that the mixing operation is an exclusive OR function. 5. Method according to claims 1 to 3, characterized in that the mixing operation is an encryption function with the content of the pre-registered memory as the encryption key. Dated this 2nd day of January 2007 7 ABSTRACT The aim of this invention is to propose a transmission method of a message containing a program block that allows to avoid the consequences of a possible malicious decryption of this message. This aim is achieved through a secure method to update software embedded in a security module, this method comprising the following steps: - formation of a first updating program block (PB1), - determination of a target memory zone of said security module, - determination through said security module, of a pre-registered content (MM_Ref) in said target memory zone , - formation of a second program block (SB1) obtained by the mixing of all or a part of the pre-registered content with the first program block (PB1), - transmission of the second program block (SB1) to the security module, - reception of the second block by the security module, reading of the target memory zone (MEM), - obtaining and writing in the target memory zone of the first block by the inverse mixing of all or part of the second block and of the target memory zone content.

Full Text

FORM 2 THE PATENTS ACT, 1970
(39 OF 1970)
As amended by the Patents (Amendment) Act, 2005
&
The Patents Rules, 2003
As amended by the Patents (Amendment) Rules, 2006
COMPLETE SPECIFICATION
(See section 10 and rule 13)
TITLE OF THE INVENTION
Method of securely updating a program block in a security module.
APPLICANT
Name : NAGRACARD SA
Address : Route de Geneve 22, CH-1033 Cheseaux-sur-Lausanne,
Switzerland Nationality : a Swiss Company
INVENTOR
Name : OSEN Karl
Address : Route du Mandement 453, CH-1282 Dardagny, Switzerland
Nationality : Swiss
PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the nature of this invention and the manner in which it is to be performed :

The block prepared in this way is encrypted by one or several keys pertaining to the security modules. It is possible to encrypt this block either using a global key, common to
all the security modules, or using a personal key, pertaining to each module. In the latter case, it will be necessary to prepare the same number of messages as they are different security modules.
The message is then sent to the management centre that disposes of transmission means towards the modules. In a unidirectional system, the message is repeated during a given period in order to ensure that each module has received it.
The man skilled in the art is placed in a difficult position when a security leak is detected because he/she must evaluate the risk of this type of message being analyzed by a third party and the risk of leaving this leak open. At times this dilemma led to the situation in which one has forbidden himself to correct a fault of the programme because the risk of comprehension of the substitute programme was too great.
The updating of programs in a Pay-TV decoder is well known and described, for example, in the document US2004/107349. The program modules are sent to the decoder encrypted by a key that is used once. This is the principle of the strike list which is applied here. Once the programme module has been received it is stored in the memory of the decoder and activated according to a usual protocol (diversion of an address towards the patch).
Brief Description of the Invention
The aim of this invention is to allow the man skilled in the art to transmit a message containing a program block in a message without having to worry about the result of a malicious decryption of this message.
This aim is achieved by a secure method to update software in a security module, this method comprising the following steps:
- formation of a first updating program block (PB1),
- determination of a target memory zone of said security module,
3

- determination through said security module, of a pre-registered content (MM_Ref) in said target memory zone,
- formation of a second program block (SB1) obtained by the mixing of all or a part of the pre-registered content with the first program block (PB1),
- transmission of the second program block (SB1) to the security module,
- reception of the second block by the security module,
- reading of the target memory zone (MEM),
- obtaining and writing in the target memory zone of the first block by the inverse mixing of all or part of the second block and of the target memory zone content.
Therefore, thanks to the invention, the transmitted code (second block) has no relation with the first block for those who has no knowledge of the content of the target memory.
A third party succeeding to decipher the message will learn nothing more about the functioning of the security module.
This method can apply to the sending of the same message to all the security modules and in this case, it is considered that the content of the target memory zone is the same for all the modules. If individual addressing is carried out, it is possible that the content of each memory is different. Once the first program block has been generated, it is mixed with the data of each security module to create the same number of second programme blocks.
Brief Description of the Drawings
The invention will be better understood thanks to the following detailed description that refers to the enclosed drawings that are given as a non-limitative example, namely:
- Figure 1 shows the generation process of the second block,
- Figure 2 shows the writing process in the memory of the security module.
Detailed Description
According to a first embodiment, the content of the target memory is pre-registered with quasi-random values. At the time of the personalization of this type of module, randomly
4

generated data MM_Ref is stored on one hand in the security module MEM and on the other hand at the management centre.
According to a second embodiment, the pre-registered data is made up of a program code that could be executed by the processor of the security module. In fact, this code is never executed and serves as an initialization value of the updating region. As in the preceding example, all the modules can have the same dummy program or each module receives a different program.
Figure 1 shows the process of formation of a second program block intended for diffusion.
When a program block PB1 is ready to be diffused, the method of the invention consists in determining the future localization of this block in the security module. Once this localization is known, it is possible to find the content that had been programmed at the time of the personalization thanks to data stored in the management centre. Once this data is known, the operation consists of mixing this data with the program block PB1 in order to obtain a new data block SBI.
This mixing operation can be of different kinds. The simplest way is to use a XOR function between the program block PB1 and the pre-registered data MM_Ref.
A second example of mixing consists in enciphering each memory location of the program block PB1 with the content of the pre-registered data MM_Ref.
The result of this mixing forms the second program block SBI. This block composed in this way can be transmitted to the related security module, according to the communication mode available between the management centre and the security module. It is enciphered by encryption keys of the system according to known methods.
Figure 2 shows the writing process in the memory of the security module.
The writing operation of the new program block in the memory of the security module, once the second block has been received, passes through a reading operation of the content of the target memory location. According to our example, each memory location i
5

of the target area MEM is read and processed (or mixed) according to the chosen algorithm. In this example, each memory location is mixed with the corresponding
location i of the second block SB1 of the program. The result is registered in the memory of the security module.
It should be noted that the program block to be updated is accompanied by verification data according to known modes (hash, CRC etc). Once the program is stored in the module memory, and has been duly verified, it can generally be activated by the modification of a part of the program in the main area.
This process can be recurrent, that is to say that if one wishes to modify a part in the program area that has already received a program, the former program functions as a pre-registered value. According to one example wherein the new program would occupy more space, the management centre takes the contents of the previous program as pre-registered values, and for memory space still not used, would use the pre-registered values generated at the time of personalization.
In practice, the management centre will preserve a virtual security module whose content represents the content of the security module in the location. All the programs intended for the security modules are also introduced into the virtual module.
According to a variant of the embodiment, only one part of the target zone is pre-registered by specific values, for example one location in three. The rest are left blank. Therefore, the mixture will be executed only on one location in three, the other locations being left without modification.
6

We Claim:
1. Secure method to update software embedded in a security module, this method comprising the following steps:
formation of a first updating program block (PB1),
- determination of a target memory zone of said security module,
determination through said security module, of a pre-registered content (MM_Ref) in said target memory zone ,
- formation of a second program block (SB1) obtained by the mixing of all or a part of the pre-registered content with the first program block (PB1),
- transmission of the second program block (SB1) to the security module,
- reception of the second block by the security module,
- reading of the target memory zone (MEM),
obtaining and writing in the target memory zone of the first block by the inverse mixing of all or part of the second block and of the target memory zone content.
2. Method according to claim 1, characterized in that the target memory zone is pre-registered by randomly generated values.
3. Method according to claim 1 implementing a module that includes a microprocessor, characterized in that the target memory zone is pre-registered by a dummy programme not executed by the microprocessor of the security module.
4. Method according to claims 1 to 3, characterized in that the mixing operation is an exclusive OR function.
5. Method according to claims 1 to 3, characterized in that the mixing operation is an encryption function with the content of the pre-registered memory as the encryption

key.

Dated this 2nd day of January 2007

7

ABSTRACT
The aim of this invention is to propose a transmission method of a message containing a program block that allows to avoid the consequences of a possible malicious decryption of this message.
This aim is achieved through a secure method to update software embedded in a security module, this method comprising the following steps:
- formation of a first updating program block (PB1),
- determination of a target memory zone of said security module,
- determination through said security module, of a pre-registered content (MM_Ref) in said target memory zone ,
- formation of a second program block (SB1) obtained by the mixing of all or a part of the pre-registered content with the first program block (PB1),
- transmission of the second program block (SB1) to the security module,
- reception of the second block by the security module, reading of the target memory zone (MEM),
- obtaining and writing in the target memory zone of the first block by the inverse mixing of all or part of the second block and of the target memory zone content.

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=QlQAmTskv1VikleOppudOg==&loc=vsnutRQWHdTHa1EUofPtPQ==

« Previous Patent

Next Patent »

Patent Number

269437

Indian Patent Application Number

4/MUMNP/2007

PG Journal Number

44/2015

Publication Date

30-Oct-2015

Grant Date

21-Oct-2015

Date of Filing

02-Jan-2007

Name of Patentee

NAGRAVISION SA

Applicant Address

ROUTE DE GENEVE 22CH-1033 CHESEAUX-SUR-LAUSANNE,

Inventors:

#	Inventor's Name	Inventor's Address
1	OSEN KARL	ROUTE DU MANDEMENT 453 1282 DARDAGNY

PCT International Classification Number

G06F1/00,G06F9/445

PCT International Application Number

PCT/EP2005/052797

PCT International Filing date

2005-06-16

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	EP 04102768.1	2004-06-17	EUROPEAN UNION