FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION (See section 10, rule 13)
“VERIFICATION OF MAC CODE WITHOUT DISCLOSURE”
VIACCESS;
of Les Collines de l'Arche Tour Opéra C, 76, route de la Demi-Lune, F-92057 PARIS LA DEFENSE Cedex (France)
The following specification particularly describes the invention and the manner in which it is to be performed.

MAC code verification without disclosure
Technical field
The present invention relates to the security of the messages exchanged between remote entities, notably on verifying the authenticity and/or the integrity of such messages. It applies advantageously but in a nonlimiting way to the field of access to protected multimedia contents.
State of the art
In this field, depending on the nature of a network supporting multimedia content communication and of a type of service offered, the content protection systems implemented can typically be access control systems (or CAS, for "Conditional Access Systems"), or even Digital Rights Management systems (DRM).
Typical applications include, for example:
- the sending/receiving of multimedia data broadcast in real time (or "TV live"),
- or the reading of multimedia data stored by a terminal digital recorder (often based on a hard disk) available to a user (or PVR for "Personal Video Recorder"),
- or even Video On Demand (VOD) applications.
The security of such systems relies in particular on assuring (and therefore verifying) the authenticity and the integrity of the access control messages.
Such messages can typically be, in an access control context CAS, specific access control messages, called "EMM messages" (EMM standing for "Entitlement Management Message") and "ECM messages" (ECM standing for "Entitlement

Control Message"). The description of Figure 1 given hereinbelow explains one exemplary context of use of such messages.
An exhaustive description of the access control systems can be found in the document:
"FUNCTIONAL MODEL OF A CONDITIONAL ACCESS SYSTEM", EBU REVIEW-TECHNICAL EUROPEAN BROADCASTING UNION. BRUSSELS, BE, no 266 21 December 1995.
In a DRM management context, such messages can typically be licenses. The description of Figure 2 given hereinbelow explains one exemplary context of use of such messages.
In the access control systems (CAS), or even DRM management systems, implementing a symmetrical cryptography with secret keys, the cryptographic redundancy, transmitted with the EMM, ECM-type messages (for the access control) or respectively license messages, to guarantee their authenticity and integrity, is conventionally implemented by means of an MAC ("Message Authentication Code" code).
The invention nevertheless applies to any context where an attacker can have access to a device performing the verification of a "Message Authentication Code" (MAC).
The intervention of such an MAC verification is described hereinbelow in an access control context CAS, then in a DRM management context.
Access control context CAS
The access control system CAS often work according to architectural principles and a kinematic summarized in Figure 1. As illustrated in Figure 1, the protection of a content such as an audiovisual program (or the protection of a component of such a program) during its transport and the control of its access by a subscriber implement, on the one hand, a program scrambling/descrambling function and, on the other hand, a subscriber access authorization check based on a distribution of authorizations

managed remotely by the operator.
Scrambling 10
The scrambling (reference 10 in Figure 1) is used to render the program unintelligible during its transport but the program can nevertheless be picked up without restriction. Various scrambling/descrambling solutions can be implemented. These are proprietary or standardized encryption/decryption algorithms, chosen according to the context.
In order the scrambling to be unpredictable and therefore make chance descrambling almost impossible, the encryption/decryption algorithms use a key commonly called "control word" (reference CW in Figure 1). It is common practice to modify the value of the control word randomly, according to variable strategies chosen according to the context. For example, a control word can be modified every ten seconds, conventionally, in broadcast television or, in the extreme case, on each film only for example in a VOD context with individual particularization per subscriber.
A conditional access system, notably of the Applicant, does not include a scrambling/descrambling solution but is compatible with any scrambling solution provided that it can be initialized by a control word.
Access control
The implementation of the scrambling/descrambling particularized by a dynamic control word requires the scrambler and the descrambler (reference 11 in Figure 1) to be synchronized accurately as to the value of the current control word CW and as to the instant when the latter changes.
Furthermore, the control by the operator on the access to a program by a user is performed by making the access to the control word conditional on the availability of a "commercial" authorization. The operator assigns the program an access condition that must be satisfied by the subscriber to be able to descramble this program.
The transmission of the control words and the description of an access condition are two of the features of a typical conditional access system, notably of the Applicant.

They are embodied by specific access control messages, called "ECM messages", computed by the "Operation" subsystem 12 of Figure 1. These ECM messages are intended to be processed by the security processor 13 cooperating with a descrambler terminal 11 (often mistakenly called "decoder"). In practice, the security processor 13 is often embodied in a chip card available to a subscriber and cooperating with the terminal 11.
In the reception part, therefore with the terminal-security processor assembly, an ECM message is checked as to its security (authenticity, integrity), then the access condition is compared to the access credentials present in the non-volatile memory of the security processor. If the access condition is satisfied by one of these access credentials, the security processor uses decryption to restore the control word and supplies it to the terminal, so enabling the descrambling.
Access credential management
The subscriber can fulfil a program access condition if he has an access credential that satisfies this condition, such as a subscription credential, the reference of a program acquired in advance or in real time, or other. Obviously, other criteria can be involved in the conformity of the subscriber to an access condition, such as a geographic reference, a moral level compliance, or other criteria.
The access credentials or the means of acquiring the access credentials (for example, "tokens" for an impulsive PPV - PPV standing for "Pay Per View") are therefore managed by the operator and then remotely written into the non-volatile memory (reference 15) of the subscriber's security processor 13.
The remote actions by the operator on the access credentials of a subscriber constitute another set of functionalities of the conditional access system of Figure 1. They are embodied in specific access control messages, called "EMM messages", computed by the "Management" subsystem (reference 14) of Figure 1, and by the security processor 13.

Cryptographic security
An access control system however fulfils its role only if it is not compromised or circumvented. In particular, the messages intended for the reception system (ECM and EMM messages) must be able to be generated and operated only by devices that are duly authorized by the service operator.
This fundamental restriction is ensured by protecting the messages intended for the reception system by cryptographic procedures guaranteeing the integrity of these messages, their authenticity and the confidentiality of the sensitive data that can be included in them. In particular, the authenticity and the integrity of the messages are protected by associating with each message its own cryptographic redundancy.
These cryptographic procedures implement specific algorithms parameterized by keys. Modifying the key values is one additional means of reinforcing the security of the system. The updating of these keys is handled by security-specific EMM management messages.
Processing of access control messages by the reception system
Most of the operational solutions for access control systems are based on a reception system consisting of two elements:
- the terminal 11 handling in particular the reception of the signal containing the service or services, its demultiplexing, the descrambling and the decoding of the components of the service chosen by the user,
- the security processor 13, supporting the access control functions with the associated cryptographic processing operations.
The security processor 13 processes the EMM and ECM messages to control access to the services, store/manage/verify the rights of access to these services, store/manage/operate the cryptographic secrets and apply to the received messages the security processing operations and cryptographic checks.
The receiving terminal 11 and the security processor 13 dialogue via an interface that

often complies with the ISO 7816 standard.
In this architecture, certain functions associated with the access control can be handled by the terminal 11 in collaboration with the security processor 13. These are, in particular, functions for selecting the ECM and EMM messages to be processed, functions for dialoguing with the user and communication with the part of the terminal that includes a descrambling module.
This architectural principle, in which the invention can be applied, is also found when an access control and descrambling module external to the terminal is used, in accordance, for example, with the module with common interface defined by the DVB ("Digital Video Broadcast") standard. Such a module is naturally considered to be part of the description of the present invention.
DRM management context
The current DRM management systems operate according to architectural principles and a kinematic that are summarized in Figure 2 in which:
• a server 21 provides a formatting (or "packaging") of a multimedia content in the "DRM format" and distributes the protected contents (for example, in "streaming" mode or in individual download mode),
• a license server 22 is used to manage and control usages: a license (or RO, standing for "Rights Object") corresponds to the juxtaposition of information on the content, notably its identifier and, possibly, the cryptographic key with which to descramble it, and information on the authorizations and constraints on use of the content (number of playbacks authorized, burning rights, usage limit data, usage duration, or other factors),
• A DRM client 23 on the terminal of the client authorizes access to the protected content and handles the checking of the licence (or even its renewal, if necessary), and

• Finally, a "player" 24 downstream of the DRM client 23 handles the displaying or the playing of the uncoded content.
In most current DRM management systems, the usage license RO, encrypted using a unique key specific to the DRM client (more often than not obtained by public key infrastructure (PKI mechanisms), is therefore legible/valid only for the DRM client 23 concerned. In other words, a usage license is structurally linked to the "identity" of a terminal (in which the DRM client 23 is embedded). The concept of "identity" should be understood here to mean the use of an encryption key (secret or private) specific to the terminal.
One important element of the usage license is the rights description language (or REL, standing for "Rights Expression Language"), paired with a rights dictionary, which is used to express the constraints/conditions and the particular permissions associated with the use of a content.
A detailed description of a DRM system (for example OMA-DRM) can be found in the documents cited by the "Open Mobile Alliance" consortium, such as:
- "OMA DRM Approved Version 2.0 - 23" (March 2007), or even
- "OMA DRM Specification V2.0 Draft Version 2.0 – 21" (June 2004).
MAC code computation
An MAC code is conventionally computed using a function E for encryption in blocks of length L. This is a block and chaining encryption, or "CBC-MAC" (CBC standing for "Cipher Block Chaining"). In addition to the message M, of any length, to be protected, this function takes as input a symmetrical key K and an initialization vector IV of length L. The data items K and IV are shared by the network termination and by the terminal part, the data item K being secret and the data item IV being public.
The computation of the MAC code then consists in the complementing of M with a length that is a multiple of L, then in applying, to the duly obtained message M', the

CBC mode encryption. The MAC code of the message M is the last encrypted block obtained in this way. A computation algorithm that is performed can therefore be of the type:
Temp2=IV
For i ranging from 1 to n, do:
Temp1 = Temp2 XOR M’i
Temp2 = E(K,Temp1)
End for
MAC = Temp2
where n is the number of blocks of length L.
The message M' therefore consists of the concatenation of these n blocks and the MAC code obtained is as follows:
MAC = E(K, M’n XOR E(K, M’n-1 XOR … E(K, M’2 XOR E(K, M’1 XOR IV))…))
This method of computing the MAC code is represented in Figure 3, where the message M’ is assumed to comprise the concatenation of n blocks (with n=4 in the example represented) of length L and denoted M’1, M’2, M’3 and M’4.
MAC code verification
To check the authenticity and the integrity of a message M, the received MAC code is checked with this message M.
This verification of the MAC code conventionally consists in a new computation of this MAC code, then in the comparison of the duly (re)computed MAC code value with that received with the message M. If these values match, the received message is authentic and trustworthy.

The new computation, by a receiving entity, of the MAC code of a message M, is performed based on the message M, the key K and the initialization vector IV, according to the same algorithm as by the entity sending the message M, that is, according to the method illustrated by Figure 3.
Problems
The conventional algorithm for verifying the MAC code of a message, based on a (re)computation of the MAC code, necessarily provokes the disclosure, in and by the receiving entity, of the correct value of the MAC code of the message concerned.
This revelation obviously takes place in all cases, including those where the message concerned has been received with an erroneous MAC code.
This disclosure then makes it possible (provided, however, that a prior attack on the system has succeeded, making it possible to extract from the system the correct (re)computed MAC code value) for a message of choice to be submitted with an MAC code that is arbitrary but has the length L, to obtain therefrom the correct MAC code value. The message can then be resubmitted, with this correct MAC code value, to the receiving system, and therefore be taken into account by the receiving system.
Such an attack can, for example, consist in provoking disturbances ("glitches") on the component so as to recover an image (or "dump") of the volatile memory of the system containing the MAC code computation buffer memory.
Such an attack can, in particular, be conducted in any context, notably that of broadcast pay TV, where an attacker can have access to a device performing the MAC code verification.
A remedy to this drawback would then force unscrupulous users (or "pirates") to determine as far as the key and the encryption cryptographic function to access the MAC code, the cost of this operation obviously being greater than that of the abovementioned attack.

DESCRIPTION OF THE INVENTION
The present invention improves the situation by proposing to prevent the disclosure of the correct MAC code value for a given message.
To this end, it proposes a method, implemented by computer means, of checking the authenticity and/or the integrity of a message transmitted, with a cryptographic redundancy, from a sending entity to a receiving entity.
In this method, the cryptographic redundancy is a message authentication code (or MAC) computed from at least one first encryption, by a block encryption function and using a key, of a combination of an initialization vector and a first block representative of at least one first part of message data.
The encryption key and the initialization vector have values stored by the sending and receiving entities.
The verification by the receiving entity of the cryptographic redundancy accompanying a received message comprises, according to the invention, the following steps:
a) application to the cryptographic redundancy of at least one first decryption, by a decryption function that is the counterpart of the encryption function and using the key,
b) combination of the result of this first decryption with a first block representative of at least one first part of received message data,
c) comparison of the result of the combination of the step b) to the secret value stored by the receiving entity,
d) and decision to accept the received message as authentic and/or trustworthy when the values compared in the step c) match.
The abovementioned combinations preferably comprise the application of the

"Exclusive OR" (or "XOR") Boolean function.
Advantageously, the block encryption involves more than one block and the computation of the message authentication code then comprises at least one second encryption, by the encryption function and using the key, of a combination of the result of the first encryption and of a second block representative of a second part of message data.
Preferably, the step b) according to the invention then also comprises at least the following operations:
b1) application, to the combination between the result of the first decryption and the first block, of at least one second decryption, by the decryption function and using the key, and
b2) combination of the result of this second decryption with a second block representative of at least one second part of received message data.
In the advantageous case of a block encryption involving a plurality of blocks and in which the encryption function is of block length L, the computation of the message authentication code comprises:
- a transformation of a message to be sent by adding or deleting data so that the size of the transformed message is equal to nL, n being a chosen integer greater than or equal to 2,
- a subdivision of the transformed message into n successive blocks of length L, according to a first chosen succession,
- a first encryption of a combination between the initialization vector and a first block of said first succession, and
- at least one encryption following the combination between the result of the first encryption and a second block that follows the first block in the first succession.

Preferably, the steps a) and b) according to the invention then comprise:
- a transformation of a received message by adding or deleting data so that the size of the transformed message is equal to nL,
- a subdivision of the transformed message into n successive blocks of length L, according to a second chosen succession,
- a combination between a first decryption of the received cryptographic redundancy and a first block of said second succession, and
- at least one decryption following the combination between the result of the first decryption and a second block that follows the first block in said second succession.
Advantageously, the invention implements a CBC ("Cipher Block Chaining") mode encryption, the computation of the message authentication code then comprising:
- the application to the message to be sent of a complementing of a length that is a
multiple of the length L to obtain a transformed message consisting of a
concatenation of n blocks each of length L, n being an integer greater than or equal
to 2, and
- the application to the transformed message of a block encryption in CBC mode,
Preferably, the computation of the initialization vector then comprises:
- a complementing of the received message with a length that is a multiple of the length L to obtain a transformed message consisting of a concatenation of n blocks each of length L, n being an integer greater than or equal to 2, and
- a block decryption, in CBC mode, of the transformed message.
It should be stated however that the method can be applied to any algorithm for verifying MAC code by reversible construction, so as to verify a syntactic property on the original message (for example, processes designated by XCBC-MAC, OMAC, EMAC, or others).

In an advantageous embodiment, for the computation of the message authentication code, the first block of the abovementioned first succession results from the application to the message of a one-way function.
The result of the application of the one-way function is then sent to the receiving entity, with the message, preferably in the form of a concatenation:
- of the result of the application to the message of the one-way function, and
- of the message itself.
The one-way function is preferably a hashing function and the result of its application is of length greater than or equal to the length L.
As a complement or as a variant, in the case where the message is likely to be transmitted in fragments, from the sending entity to the receiving entity, the first succession of blocks and the second succession of blocks are preferably reversed, so that the receiving entity can begin the computation of the initialization vector as soon as it receives a first message fragment.
In an access control context (CAS), in particular for access to televisual data, one advantageous application of the method aims to verify the cryptographic redundancy accompanying the access control messages such as, in particular, the ECM and EMM messages.
In a digital rights management (DRM) context, in particular regarding audio and/or video contents, an advantageous application of the method aims to verify the cryptographic redundancy accompanying the licenses to said contents.
BRIEF DESCRIPTION OF THE DRAWINGS
Other characteristics and advantages of the invention will become apparent from studying the detailed description given below, and the appended drawings in which:
- Figure 1, described hereinabove, diagrammatically illustrates the access control

CAS architectural principles,
- Figure 2, described hereinabove, diagrammatically illustrates the DRM management architectural principles,
- Figure 3, described hereinabove, diagrammatically illustrates an MAC code computation, as it is performed in the prior art also for verification of this MAC code,
- Figure 4 illustrates the computation, according to the invention, of an initialization vector for the retro-verification of MAC code,
- Figure 5 illustrates the computation of message MAC code prefixed by a one-way function which can advantageously be implemented by a sending entity, in one embodiment of the invention,
- Figure 6 illustrates the retro-verification of an MAC code computed as illustrated in Figure 5, with message prefixing by a one-way function, this retro-verification being implemented by a receiving entity in the example represented,
- Figure 7 illustrates a reverse computation of MAC code which can advantageously be implemented by a sending entity, in one embodiment of the invention,
- Figure 8 illustrates the reverse retro-verification of MAC code computed as illustrated in Figure 7, this reverse retro-verification being implemented by a receiving entity in the example represented,
- Figures 9a and 9b compare the respective implementations of the prior art (Figure 9a) and according to the invention (Figure 9b).
DETAILED DESCRIPTION
The invention therefore proposes a refinement to the message verification mechanism, this mechanism implementing MAC codes. It makes it possible in particular to verify the MAC code of a message, without specifically (re)computing the MAC code itself,

so as not to risk supplying the latter.
In the context presented previously with reference to Figure 3, but applied to the context of the invention, it is not the MAC code that is (re)computed, but the value of the initialization vector IV, based on the received message and its MAC code value, and the key K. This (re)computation in particular implements a decryption function D associated with the encryption function E (Figure 4).
If the (re)computed initialization vector IV is equal to that used by the sending entity to compute the MAC code, then this received MAC code is diagnosed as correct, and therefore the message is determined to be authentic and trustworthy.
It is then sufficient, for the implementation of the invention, for the correct value of the initialization vector to be constant, of predefined syntax, or implicit. The attacker must then choose a correct value of the initialization vector, to associate it with the received MAC code value, then generate a syntactically correct message which could be submitted to the access control system.
It is, however, proven that the obtaining, by the attacker, of a correct initialization vector can be made as improbable as the probability of generating a valid MAC code for a message of his choice, and that the knowledge of the intermediate results that the access control system could disclose does not favour the attacker in the aim of achieving this correct message generation.
Referring to Figure 4, given the same assumptions and with the same notations as those of Figure 3, the retro-verification of MAC code is based on the (re)computation of an initialization vector value IV', where MAC designates the transmitted MAC code.
Thus, the inputs of Figure 4 are the MAC code and the message M, while the output gives an initialization vector value IV' to be verified, whereas the inputs of Figure 3, for the (re)computation and the verification of the MAC code according to the prior art, were the known value IV of the initialization vector and the message M, while the output gave an MAC code value to be verified.

Referring to Figure 4, the computation, according to the invention, of the value IV' then consists in the complementing of M with a length that is a multiple of L, then in the application, to the duly obtained message M, of the CBC mode decryption using the decryption function D associated with the encryption function E of Figure 3. The initialization vector is the last encrypted block obtained in this way.
An algorithm corresponding to the processing operation represented in Figure 4 according to the invention can then be of the type:
Temp1 = MAC
For i ranging from 0 to n-1, do:
Temp2 = D(K,Temp1)
Temp1 = Temp2 XOR M’n-i
End for
IV’ = Temp1
The initialization vector value obtained is then given by:
IV’ = M’1 XOR D(K, M’2 XOR … D(K, M’n-1 XOR D(K, M’n XOR D(K, MAC))) …)
In Figure 4 representing an example of this initialization vector computation for retro-verification of the MAC code, the message M' therefore consists of the concatenation of n blocks (with n=4 in the example represented) of length L and denoted M’1, M’2, M’3 and M’4.
The value IV’ obtained is the one that the receiving entity ought to use to compute the MAC of the received message so as to obtain therefrom the same value as that transmitted by the sender.
The retro-verification of MAC code then consists in comparing the found initialization vector value IV’ with the shared initialization vector value IV which, in principle, was used by the sending entity to compute the MAC code value transmitted with the

received message. If these values match, the received message is authentic and trustworthy.
Notwithstanding the comparison of the inputs and outputs of Figures 3 and 4 given hereinabove, it should be indicated that the sending entity retain a configuration similar to that of Figure 3 to construct the MAC code. However, enhancements to this configuration are presented hereinbelow.
The term "retro-verification of the MAC code" is used hereinafter to denote the operation, according to the invention, consisting in verifying the value IV' of the initialization vector. This verification conducted by the receiving entity is identical to that presented in Figure 4. It consists in (re)computing the value IV' of the initialization vector according to the received message and its MAC code, and in comparing it with the expected value IV of the initialization vector.
A remaining weakness that the processing operation according to the invention would a priori present is the disclosure in the access control system of the correct IV and (re)computed IV' initialization vector values, and therefore their possible extraction by a system attacker.
Thus:
- by submitting to the system a message M of his choice with an arbitrary MAC code,
- by extracting these values,
- then by replacing the first block M1 of his message with the quantity:
N = M1 XOR IV’ XOR IV,
the attacker obtains a message [N M2 … Mn] that can be successfully submitted to the system with the chosen arbitrary MAC code, that is, the one for which the (re)computation of the initialization vector gives the expected result IV.
The retro-verification of the MAC code would then be positive, and the received

message would then be taken into account.
However, the result IV' of the above computation is not a priori controlled by the attacker, so no longer is that of the quantity N, such that it is largely improbable that the syntax of the new message [N M2 … Mn] would be that of a valid message.
The fact that the results of the computations of the value IV' and of the quantity N are not controlled also means that the arbitrary MAC code cannot be modified in light of the above erroneous first results, to obtain a new message [N M2 … Mn] with valid syntax.
In any case, in an advantageous embodiment, the possibility of safeguarding, at the outset, against the residual weakness described hereinabove is available.
To this end, provision is made for prefixing the message to be sent by the sending entity with the result of its own processing with a one-way function, such as a hashing function (or one-way cryptographic function).
This prefixing can be:
- "implicit": the prefix is then taken into account only for the computation of the MAC code and its verification through the computation of the value IV' (hereinafter called "retro-verification") with the receiving entity, but not transmitted with the message,
- or "explicit": the prefix is then also transmitted with the message and the MAC code.
The use of a one-way function H involves computing:
• the quantity H(M) || M, where " || " designates the concatenation operator;
• the MAC code of the duly obtained concatenated message.
The message M’ = (M’1, M’2, …, M’n) is obtained by complementing (or "padding") the quantity H(M) || M.

The MAC code computation itself is then performed subsequently in a way similar to that illustrated in Figure 3.
It should be noted that the security of the processing operation is weakened if the length of the expression H(M) is less than the length L. A one-way function H will advantageously be chosen for the expression H(M) to be a length greater than or equal to the length L.
In particular, M’1 = H(M) applies in the case where the expression H(M) is of length L. In this advantageous case, the block lengths can remain unchanged and do not have to be modified by adding or deleting data.
The MAC code computation that is performed is then of the type:
Temp2 = E(K, IV XOR H(M))
For i ranging from 2 to n, do:
Temp1 = Temp2 XOR M’i
Temp2 = E(K,Temp1)
End for
MAC = Temp2
where n is the number of blocks of length L. The message M' consists of the concatenation of these blocks and the MAC code obtained is given by:
MAC = E(K, M’n XOR E(K, M’n-1 XOR … E(K, M’2 XOR E(K, M’2 XOR E(K, IV XOR H(M))))…))
This computation of the MAC code is illustrated in Figure 5, where the message M' is assumed to consist of the concatenation of n blocks (with n=5 in the example represented) of length L and denoted H(M)=M’1, M’2, M’3, M’4 and M’5.
The sending entity then transmits:

• the value of the initialization vector IV, where appropriate the message M in the abovementioned "implicit" embodiment, and the duly calculated MAC code;
• the value of the initialization vector IV, where appropriate the concatenation H(M) || M in the abovementioned "explicit" embodiment, and the duly calculated MAC code.
Obviously, the cases where the expression H(M) is of a length that is a multiple of the length L are also advantageous.
In the other cases, an additional "padding" is useful.
With the receiving entity, subsequently, the retro-verification of the MAC code aiming to verify the value IV' of the initialization vector, follows the same principle as that illustrated in Figure 4. It consists in recomputing the value IV' of the initialization vector according to the received message and its MAC code, and in comparing it with the expected value IV of the initialization vector.
An example of retro-verification algorithm is then as follows:
Temp1 = MAC
For i ranging from 0 to n-1, do:
Temp2 = D(K,Temp1)
Temp1 = Temp2 XOR M’n-i
End for
IV’ = H(M) XOR D(K, Temp1)
The initialization vector value obtained is therefore:
IV’ = H(M) XOR D(K, M’1 XOR D(K, M’2 XOR … D(K, M’n-1 XOR D(K, M’n XOR D(K, MAC))) …))

This initialization vector computation for retro-verification of the MAC code is represented in Figure 6, where the message M' is assumed to comprise the concatenation of n blocks (n=4 in the example represented) of length L and denoted M’1, M’2, M’3 and M’4.
Here, this verification is also complemented with the verification of the result of the processing of the message by the one-way function H. This verification is done in a way similar to that known in the prior art of an MAC code by (re)computation of this result and comparison with the received value. If the two values match, the message is trustworthy.
This second verification would then prevent an attacker from modifying the start of the message M as explained previously, the abovementioned remaining weakness thus being overcome. Indeed, the modification of the start of the message M, even if it were to be correct, would result in another modification, itself uncontrolled, of the quantity H(M).
There follows hereinbelow a description of an advantageous embodiment in a context (common in access control CAS or in DRM management) where a message can, for various reasons, be transmitted piecemeal.
It is then appropriate to be able to perform the (retro)-verification of the MAC code of the message, as and when it is received, and ultimately requiring only an intermediate result to be stored rather than all the pieces of the message already received.
To this end, the MAC code of the message needs to be able to be transmitted with its first block, so that its (retro)-verification can begin immediately after reception of this first block. The MAC code is thus typically transmitted followed by the message and then by the initialization vector.
For an advantageous implementation of the invention, all that is then required is to reverse the order of the blocks of the message before calculating its MAC code, to be able to begin its subsequent (retro)-verification simply based on the first block.
The MAC code computation to be performed is thus reversed:

Temp2=IV
For i ranging from 0 to n-1, do:
Temp1 = Temp2 XOR M’n-i
Temp2 = E(K,Temp1)
End for
MAC = Temp2
where n is the number of blocks of length L. The message M’ consists of the concatenation of these n blocks M' = [M’1 M’2 … M’n] and the MAC code obtained is given, here, by:
MAC = E(K, M’1 XOR E(K, M’2 XOR … E(K, M’n-1 XOR E(K, M’n XOR IV))…))
whereas normally, it is given by:
MAC = E(K, M’n XOR E(K, M’n-1 XOR … E(K, M’2 XOR E(K, M’1 XOR IV))…))
This computation of the MAC code is illustrated in Figure 7, where the message M' is assumed to consist of the concatenation of n blocks (n=4 in the example represented) of length L and denoted M’1, M’2, M’3 and M’4.
The retro-verification to be performed for an MAC code that has been computed in the reverse mode described hereinabove can, for example, follow the algorithm below:
Temp1 = MAC
For i ranging from 1 to n, do:
Temp2 = D(K,Temp1)
Temp1 = Temp2 XOR M’i End for

IV’ = Temp1
The value of the initialization vector that is obtained is then given by:
IV’ = M’n XOR D(K, M’n-1 XOR … D(K, M’2 XOR D(K, M’1 XOR D(K, MAC))) …)
This initialization vector computation for the reverse retro-verification of the MAC code is represented in Figure 8, where the message M' is assumed to consist of the concatenation of n blocks (n=4 in the example represented) of length L and denoted M’1, M’2, M’3 and M’4.
It is possible to combine the embodiment targeting the use of a one-way function with the embodiment targeting the reversal of the order of the blocks.
The position of the result H(M) of the one-way function H can be transmitted in any chosen position: as a prefix, or even as a suffix, in the middle of the blocks, and so on.
The prefix and suffix positions are nevertheless preferred.
In the "explicit" case where the value H(M) is transmitted and verified, in order to enable the computation as and when message fragments are received by the receiving entity, the value H(M) is transmitted by the sending entity preferably last (therefore as prefix as represented in Figure 5) to be taken into account by the receiving entity just before the last verification operation relating to the received MAC code (that is, just before the computation giving the presumed value of the initialization vector as represented in Figure 6).
In the "implicit" case where the value H(M) is computed by the receiving entity, the position of the result H(M) is chosen indiscriminately because the order of the blocks is reversed.
Moreover, for the implementation of the invention, the few precautions hereinbelow are recommended.
Referring to Figure 3, when the MAC code was recomputed by the receiving entity as according to the prior art, only the encryption function E was used, whereas in the

verification of the initialization vector by the receiving entity according to the invention (Figure 4), the decryption function D is used. With the MAC code retro-verification requiring the decryption of the transmitted MAC code, then of the successive blocks modulo a result by the XOR operator in each step, it is then necessary to protect the system against an attack that might use an MAC code retro-verification computation module as decryption oracle, that is, the decryption function D to be able to access confidential information that would notably have been encrypted with the function E.
Such an attack would involve submitting, to the MAC code retro-verification module, an empty message, and the confidential data cryptogram, in place of the MAC code, to be able to extract this confidential data uncoded from the verification system.
In the advantageous application context of the broadcasting of multimedia contents protected by a CAS system, this confidential data can typically be the content decryption control word CW of Figure 1. In the contexts where the protection of the contents is handled by a DRM system (Figure 2), this confidential data can typically be the content decryption key.
Advantageously, provision is made, in this respect, to have the decryption operations implemented for the retro-verification of the MAC code and for the lifting of the confidentiality of the information transported by the message, to be different.
To this end, it is possible, and in descending order of preference:
• to partition the algorithms and the keys used for the processing of the MAC code, on the one hand, and for that of the confidentiality, on the other hand, by imposing two different algorithms;
• to use the cryptographic function in decryption mode for the MAC code computation, and therefore in encryption mode for the MAC code retro-verification, and for the confidentiality computation;
• or to partition the algorithms and the keys used for the processing of the MAC

code, on the one hand, and for that of the confidentiality, on the other hand, by imposing different dedicated keys.
Thus, in more generic terms, in the case where the message to be transmitted includes encrypted confidential data, the decryption key K and/or the decryption function D used for the verification of the cryptographic redundancy thus form means that are preferably different from the confidential data decryption means.
Figures 9a and 9b very diagrammatically summarize the processing differences between the methods according to the prior art (Figure 9a) and the method according to the invention (Figure 9b).
In these two Figures 9a and 9b, the sending entities (respectively referenced 91 and 95) have the same function, namely to compute, using means such as a computation processor PROC and a working memory (not represented), the MAC code using:
- the message M to be sent,
- the initialization vector IV,
- and by applying the key K and the encryption function E.
It should, however, be borne in mind that the sending entity 95 (Figure 9b), in a preferred embodiment of the invention, applies a one-way function to the message M as described previously. To this end, the present invention also targets such a sending entity 95 of messages M, each sent with a cryptographic redundancy and comprising means PROC of computing a message authentication code accompanying each message to be sent, in accordance with this embodiment. The present invention also targets a computer program, intended to be stored in memory of the sending entity 95 and comprising instructions for implementing this embodiment, when they are executed by the processor PROC of the sending entity 95. Examples of algorithms of such a program have been given hereinabove.
Referring once again to Figures 9a and 9b, the message M and the MAC code are then sent to a receiving entity, for example via a network 90. In the methods of the prior art

(Figure 9a), the receiving entity 92 recomputes an MAC' code, based on the received message M, of the initialization vector IV, and by applying the key K and the encryption function E. Then, the receiving entity 92 compares the duly computed MAC' code with the received MAC code and decides that the received message M is valid if there is a match between the compared codes.
In a different approach according to the invention, the receiving entity 96 (Figure 9b) uses means such as a computation processor PROC and a working memory (not represented) to compute a value of the initialization vector IV', based on the message M and the MAC code received and by applying the key K and the decryption function D. Then, the receiving entity 96 compares the duly computed value IV' to a reference value IV stored in memory. The receiving entity 96 then decides that the received message M is valid if there is a match between the compared values.
To this end, the present invention also targets a receiving entity 96 (Figure 9b) of messages, each received with a cryptographic redundancy MAC and then including means, such as the processor PROC, of verifying the cryptographic redundancy accompanying a received message M.
In an advantageous application of the invention to an access control system (CAS), the receiving entity can, for example, be a descrambler receiving messages, for example of EMM or ECM type, with a cryptographic redundancy such as an MAC code. In this case, the security processor 13 (Figure 1) of such a system includes means (a processor, a working memory, or others) for verifying the cryptographic redundancy accompanying a received message, in accordance with the method according to the invention. To this end, the present invention also targets such a security processor.
The present invention also targets a computer program, intended to be stored in memory of the receiving entity 96 of Figure 9b or of a security processor according to the invention and then comprising instructions for implementing the method according to the invention when they are executed by a processor PROC of the receiving entity or of the security processor. Examples of algorithms of such a program have been given hereinabove.

CLAIMS
1. Method, implemented by computer means, of checking the authenticity and/or the
integrity of a message (EMM, ECM; RO) transmitted, with a cryptographic
redundancy (MAC), from a sending entity (10; 22) to a receiving entity (11; 23),
in which the cryptographic redundancy is a message authentication code (MAC) computed from at least one first encryption, by a block encryption function (E) and using a key (K), of a combination (XOR) of an initialization vector (IV) and a first block (M’1) representative of at least one first part of message data,
the encryption key (K) and the initialization vector (IV) having values stored by the sending and receiving entities,
characterized in that the verification by the receiving entity of the cryptographic redundancy accompanying a received message comprises the following steps:
a) application to the cryptographic redundancy (MAC) of at least one first decryption, by a decryption function (D) that is the counterpart of the encryption function (E) and using the key (K),
b) combination (XOR) of the result of this first decryption with a first block (M’n) representative of at least one first part of received message data,
c) comparison of the result of the combination of the step b) to the secret value (IV’) stored by the receiving entity,
d) and decision to accept the received message as authentic and/or trustworthy when the values compared in the step c) match.
2. Method according to Claim 1, in which the computation of the message
authentication code (MAC) comprises at least one second encryption, by the
encryption function (E) and using the key (K), of a combination (XOR) of the result of

the first encryption and of a second block (M’2) representative of a second part of message data,
characterized in that the step b) also comprises at least the following operations:
b1) application, to the combination between the result of the first decryption and the first block (M’n), of at least one second decryption, by the decryption function (D) and using the key (K), and
b2) combination (XOR) of the result of this second decryption with a second block (M’n-1) representative of at least one second part of received message data.
3. Method according to Claim 2, in which the encryption function (E) is of block length L,
and the computation of the message authentication code (MAC) comprises:
- a transformation of a message (M) to be sent by adding or deleting data so that the size of the transformed message (M’) is equal to nL, n being a chosen integer greater than or equal to 2,
- a subdivision of the transformed message (M’) into n successive blocks of length L, according to a first chosen succession,
- a first encryption of a combination (XOR) between the initialization vector (IV) and a first block (M’1; M’4) of said first succession, and
- at least one encryption following the combination (XOR) between the result of the first encryption and a second block (M’2; M’3) that follows the first block in the first succession,
characterized in that the steps a) and b) comprise:
- a transformation of a received message (M) by adding or deleting data so that the
size of the transformed message (M’) is equal to nL,

- a subdivision of the transformed message (M’) into n successive blocks of length L, according to a second chosen succession,
- a combination (XOR) between a first decryption of the received cryptographic redundancy (MAC) and a first block (M’1) of said second succession, and
- at least one decryption following the combination (XOR) between the result of the first decryption and a second block (M’2) that follows the first block (M’1) in said second succession.
4. Method according to Claim 3, in which the computation of the message
authentication code (MAC) comprises:
- the application to the message to be sent (M) of a complementing of a length that is a multiple of the length L to obtain a transformed message (M’) consisting of a concatenation of n blocks (M’1, M’2, M’3, M’4) each of length L, n being an integer greater than or equal to 2, and
- the application to the transformed message (M’) of a block encryption in CBC mode,
characterized in that the computation of the initialization vector comprises:
- a complementing of the received message (M) with a length that is a multiple of the length L to obtain a transformed message (M’) consisting of a concatenation of n blocks (M’1, M’2, M’3, M’4) each of length L, n being an integer greater than or equal to 2, and
- a block decryption, in CBC mode, of the transformed message (M’).
5. Method according to one of Claims 3 and 4, characterized in that, for the
computation of the message authentication code (MAC), said first block (H(M)), in the
first succession, results from the application to the message (M) of a one-way function.

6. Method according to Claim 5, characterized in that the result of the application of
the one-way function is sent to the receiving entity, with the message (M), in the form
of a concatenation (H(M)||M):
- of the result of the application to the message (M) of the one-way function, and
- of said message (M).

7. Method according to one of Claims 5 and 6, characterized in that the one-way function is a hashing function and the result of its application (H(M)) is of length greater than or equal to the length L.
8. Method according to one of Claims 3 to 7, in which the message is likely to be transmitted in fragments, from the sending entity to the receiving entity,
characterized in that the first succession of blocks (M’4, M’3, M’2, M’1) and the second succession of blocks (M’1, M’2, M’3, M’4) are reversed,
and in that the receiving entity begins the computation of the initialization vector as soon as it receives a first message fragment.
9. Method according to one of the preceding claims, characterized in that said
combinations include the application of the "Exclusive OR" (XOR) Boolean function.
10. Method according to one of the preceding claims, in which the message to be
transmitted comprises encrypted confidential data (CW) characterized in that the
decryption key (K) and/or the decryption function (D) used to verify the cryptographic
redundancy form means that are different from the means of decrypting the

confidential data (CW).
11. Method according to one of the preceding claims, characterized in that it is applied, in an access control context (CAS), in particular to televisual data, to the verification of the cryptographic redundancy accompanying the access control messages (ECM, EMM).
12. Method according to one of Claims 1 to 10, characterized in that it is applied, in a digital rights management (DRM) context, in particular regarding audio and/or video contents, to the verification of the cryptographic redundancy accompanying the licences to said contents (RO).
13. Receiving entity for messages (EMM, ECM; RO) each received with a cryptographic redundancy (MAC), characterized in that it comprises means of verifying the cryptographic redundancy accompanying a received message, in accordance with the method according to one of the preceding claims.
14. Security processor in a receiving entity of an access control system (CAS), the receiving entity receiving messages (EMM, ECM) with a cryptographic redundancy (MAC), characterized in that the security processor (13) comprises means of verifying the cryptographic redundancy accompanying a received message, in accordance with the method according to Claim 11.
15. Computer program intended to be stored in memory of a receiving entity according to Claim 13 or of a security processor according to Claim 14, characterized in that it comprises instructions for implementing the method according to one of Claims 1 to

12 when they are executed by a processor of said receiving entity or of said security processor (13).
16. Sending entity for messages (EMM, ECM; RO) each sent with a cryptographic redundancy (MAC), characterized in that it comprises means of computing the message authentication code accompanying each message to be sent, in accordance with the method according to one of Claims 5 to 8.
17. Computer program, intended to be stored in memory of a sending entity according to Claim 16, characterized in that it comprises instructions for implementing the method according to one of Claims 5 to 8 when they are executed by a processor of said sending entity.