WO2008149029A2 - Delegation de signature numerique - Google Patents

Delegation de signature numerique Download PDF

Info

Publication number
WO2008149029A2
WO2008149029A2 PCT/FR2008/050873 FR2008050873W WO2008149029A2 WO 2008149029 A2 WO2008149029 A2 WO 2008149029A2 FR 2008050873 W FR2008050873 W FR 2008050873W WO 2008149029 A2 WO2008149029 A2 WO 2008149029A2
Authority
WO
WIPO (PCT)
Prior art keywords
signature
file
data
signatory
license
Prior art date
Application number
PCT/FR2008/050873
Other languages
English (en)
Other versions
WO2008149029A3 (fr
Inventor
Michel Milhau
Sébastien CANARD
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2008149029A2 publication Critical patent/WO2008149029A2/fr
Publication of WO2008149029A3 publication Critical patent/WO2008149029A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/603—Digital right managament [DRM]

Definitions

  • the invention relates to the field of digital communications. More specifically, the invention relates to the receipt of a signed file, and the modification for the transmission of this file.
  • the file may for example include a license granting rights to content separate from this license.
  • the invention may thus, for example and without limitation, relate to the protection of digital content, and in particular digital rights management (DRM) systems (eg "Digital Rights Management”) such as defined in the OMA DRM standard.
  • DRM digital rights management
  • the signature is typically obtained by applying a cryptographic function by means of a private key associated with the signer to a fingerprint of the file to be signed.
  • the fingerprint can be obtained by applying a hash function to the file.
  • the signer can send to an intermediate server device the file and the signature of this file.
  • the intermediate server can modify the file, sign the modified file, and transmit the modified file and its signature to a recipient device.
  • the destination device for example a terminal implementing a conventional signature verification method, is then only able to verify that the file received from the intermediate server has been sent by the intermediate server.
  • An object of the invention is to enable a recipient device implementing a conventional signature verification method to verify the origin of the file.
  • the subject of the invention is a method intended to be implemented by an intermediate server device, comprising the steps of:
  • the recipient device thus receives the file modified by the intermediate server, and recognizes the modified file as having been generated by the signatory device. The recipient device can thus ensure the origin of the received file.
  • the signatory device transmits to the intermediate server a file comprising a text in a given language.
  • the intermediate server performs an automatic translation of this text into another language, and sends the translated text, with appropriate signature data, to a destination terminal.
  • the signature data is such that the terminal recognizes the translated text as signed by the signatory device.
  • the file may include portions of text relating to amounts in a given currency, and the intermediate server performs a currency conversion.
  • the terminal receiving the modified file is only able to verify that this file comes from the currency converter.
  • the invention enables the terminal to recognize the file as being derived from the signatory device.
  • the invention is not limited by the nature of the modification made to the file.
  • the modification made to the file by the intermediate server can for example consist of a format change so that the file is readable by the recipient device, in a compression of this file, in a decompression of this file, in a marking ("watermark" in English), in a filtering of the file etc.
  • the file from the signatory device may have been generated by the signatory device, or the signatory device has itself received from another device.
  • the invention can make it transparent to the recipient that the file has been modified by an intermediate server. It is of course preferable that the intermediate server is secure.
  • the intermediate server receives at least one delegation datum from the signatory device and at least one first adjustment datum from the signatory device.
  • This delegation and adjustment data is used when determining the signature data.
  • the signing device authorizes the intermediate server to modify the file, while allowing the recipient device to recognize this file as signed by the signatory device, and without substantial modification of the signature recognition method implemented by the recipient device.
  • the signer can send delegation and / or adjustment data to the intermediate server each time a file is sent, or at one time, during an initialization phase.
  • the signature data may comprise the signature received from the signatory device and the identifiers of the modifications made to the file by the server device.
  • the recipient device is thus able to find a fingerprint of the file before modification and thus to check the validity of the signature.
  • the signature data comprises the signature received from the signatory device, as well as at least one second adjustment datum. It is this second adjustment data that allows the recipient device to recognize the modified file as the origin of the signature.
  • the signature issuing from the signatory device is obtained by applying a cryptographic function to a fingerprint, and the second adjustment datum is determined so as to make it possible to recalculate this fingerprint.
  • a chameleon hashing function and preferably a chameleon hashing function based on the identity as defined in the document "Identity-based chameleon hash and application", by G. Ateniese, B. de Medeiros ( Financial Crypto 2004, volume 3110 of LNCS 1 pages 164-180, Springer-Verlag, 2004).
  • the chameleon hash function allows a first device receiving a second device a document and a signature thus obtained for this document, to sign any document by suggesting that it comes from the second device.
  • the first device is unable to prove to a third party that the received document actually originates from the second device. Only the second device is able to demonstrate a usurpation or non-usurpation.
  • the file from the signatory device includes a license granting rights to content separate from this license.
  • the intermediary server modifies the license according to the recipient device.
  • the invention is in no way limited by this application example.
  • a server transmits to a destination device (terminal) an encrypted digital content, a license adapted to the destination device and a signature of this license by the server.
  • the license includes a digital content identifier, usage rights on the content and the key used to decrypt the content.
  • the key used to encrypt the content is transmitted after having been encrypted with a public key corresponding to this recipient device.
  • the recipient device is able to decrypt the encrypted key, and thus decrypt the encrypted content.
  • the key public and the private key can be known from a single recipient device, in which case the license is specifically adapted to the recipient device, or be known to a group of terminals, for example the terminals belonging to the same user.
  • a server may transmit encrypted content and a license to the terminals of this group.
  • the management of the group for example the registration and cancellation of terminals, is provided by the server.
  • the invention allows management of the terminals by the intermediate server, which may be local, and not by the signatory server (remote).
  • This local management makes it possible to simplify the operation of the signatory device, and also to keep certain information confidential. For example, the number of terminals in the domain, the rights attached to each recipient device, etc. constitute information that may remain unknown to the signatory device.
  • the license may include a key previously used to encrypt the content, this key being transmitted encrypted by another key.
  • the step of modifying the license may include a step of decrypting the key used to encrypt the content, and a key encryption step thus decrypted. This encryption is performed by means of another key, for example a public key associated with the recipient device to which the content is intended. This recipient device then uses its private key associated with its public key to decrypt the key used for content encryption.
  • the license may include a field of usage rights on the content, to specify the rights attached to this content. For example, a given content may be read a limited number of times, be transferable or non-transferable, etc.
  • the modification of the license may for example include a modification of rights of use on the content corresponding to the license.
  • a user may want multimedia files downloaded from their child's computer to not be viewed only once. In this case, when a request is made for a given multimedia file from the child's computer, the signatory device sends to the parental computer the desired file, in encrypted form, accompanied by a license and a signature.
  • the license contains a rights field filled with a value corresponding to the rights of use for the parents.
  • the parent computer acts as an intermediary server and modifies this rights field so that the file can only be seen once.
  • the parent computer transmits the encrypted file to the child's computer, along with the modified license and signature data.
  • This signature data is such that the child's computer recognizes the modified license received as signed by the remote server.
  • the key used to encrypt the multimedia file is encrypted by the signing device by means of a public domain key.
  • the child's computer decrypts the key used to encrypt the media file using a domain private key corresponding to the domain public key.
  • the intermediate server it is possible to provide a step for inserting information given by the intermediate server, this given information enabling the recipient device to verify that the file has actually passed through the intermediate server.
  • the information given may for example include a signature by the intermediate server of the file.
  • the file is sent with two signatures and the destination device performs two signature checks.
  • the subject of the invention is an intermediate server device comprising receiving means for receiving a file issuing from a signing device and a signature, means for modifying the received file, processing means for determining data. signature so that a destination device recognizes the modified file as generated by the signatory device, and transmission means of the modified file and signature data to the recipient device.
  • the subject of the invention is a method intended to be implemented by a signatory device and comprising a step signing a file by means of a private key of the signatory device.
  • At least one delegation data and at least one first adjustment data is generated, which delegation and adjustment data enables an intermediate server device to determine signature data such as a recipient device recognizes the file modified by the intermediate server device as having been signed by the signatory device.
  • the signing device sends to the intermediate server device the file, the signature of this file by the signatory device, the adjustment data (s) and the data (s) of delegation.
  • This method is an example of a method implemented by the signing device to allow recognition of the modified file as having been signed by the signatory device.
  • the modification of the file by the intermediate server can thus be made transparent to the recipient device.
  • This method may advantageously be in accordance with or approach a current standard, defined for example by the OMA DRM standard. Thus, it may be possible to implement the method simply by making slight modifications to the configuration of an existing server.
  • the signature step comprises the steps of hashing with the aid of a first hash function at least the file so as to obtain a first result, to chop using a second hash function to both the first result and a characteristic data of the file, so as to obtain a second result, and to apply to the second result a cryptographic function, for example by means of the private key of the signatory device.
  • Such a double hash makes it possible, by introducing the characteristic data of the file, to limit the delegation of signature offered to the intermediate server to the sent file, or more precisely to files presenting the same characteristic data. Indeed, if the intermediate server determines signature data for a file presenting a different characteristic data, for example a distinct identifier, the recipient device may be able to find, using the signature data, the first result, but fails to find the second result. The recipient device thus fails to recognize as being signed by the signer the file with an identifier distinct from that of the file actually signed by the signer.
  • the file itself comprises the characteristic data of the file.
  • This characteristic data therefore constitutes a part of the file whose modification by the intermediate server is prohibited, as soon as it fails to recognize the signatory device as signatory of the modified file.
  • the signatory device can limit the portions of the file that can be modified by the intermediate server.
  • the invention is of course not limited by the double hashing.
  • the subject of the invention is a signatory device comprising means for signing a file, these signature means being arranged to use a private key of the signatory device, means for generating at least one data item.
  • delegation and at least one adjustment data said delegation and adjustment data enabling an intermediate server device to determine signature data such as a recipient device recognizes the file modified by the intermediate server device as having been signed by the signatory device, and means for sending to the intermediate server device of the file, the signature of this file by the signatory device, the data or data of adjustment and the data or data delegation.
  • the subject of the invention is a method intended to be implemented by a recipient device, the method comprising a step of receiving a server device of a file and of signature data corresponding to this file, the signature data including a signature and at least one adjustment data, and a signature verification step.
  • This step uses both the file, the signature, and the adjustment data, so that for a value of the appropriate adjustment data, the file is recognized as being signed by a separate signing device of the server device.
  • This method is an example of a method implemented by the recipient device to allow the recipient device to recognize the source of a file received from an intermediate server.
  • This method may advantageously approach a current standard, or be in accordance with this standard, defined for example by the standard
  • the double-hash file and the adjustment data are performed during the verification step, the second hash being performed on the result of the first hash and a characteristic value of the file.
  • the server has modified the file so as to change this feature, or has replaced it with another file having a different characteristic value, the signature is not recognized as valid, that is, the recipient device does not recognize the file as having been signed by the signatory device.
  • the subject of the invention is a recipient device comprising reception means for receiving from a server device a file and signature data corresponding to this file, the signature data comprising a signature and at least one piece of data.
  • adjustment means, and means for verifying the signature are arranged to use the adjustment data (or data) so that, for a value of the appropriate adjustment data (s), the The file is recognized as being signed by a separate signing device of the server device.
  • Figure 1 shows an example of a system according to one embodiment of the invention.
  • FIG. 2 is a flowchart of a method executable by a signatory device according to one embodiment of the invention.
  • Figure 3 is a flowchart of a method executable by an intermediate server according to one embodiment of the invention.
  • FIG. 4 is a flowchart of a method executable by a destination device according to one embodiment of the invention.
  • FIG. 1 shows an intermediate server device SLI receiving from a signatory device, here a remote server SL, a file GL and a signature ⁇ of this file.
  • the server SLI modifies the file GL and sends the modified file L with signature data ⁇ to a recipient device, here a terminal T.
  • the GL file is a license that grants rights to a content content
  • the file L is a modified license that grants rights to the same content content.
  • the invention is in no way limited by the nature of Content content. It may for example be a multimedia content (video or musical sequence, etc.).
  • the SL server is a license server, which, upon request, provides the content content in encrypted form, and the license GL corresponds to that content.
  • the server SL comprises means for signing the file GL, for example a processor, not represented, means for generating delegation data B, and adjustment data R, for example the same processor, not represented, and sending means, for example a conventional communication port not shown.
  • the SLI server is thus able to acquire, for example by buying it, a GL license for a given content, and to transform and customize this license into a modified license L for each of the other members T, T of the group (association , family, business, etc.).
  • the server In order for the destination terminal T to accept the signature of the modified license, the server
  • the local server SLI manages the communications between the license server SL and all members of the group.
  • the SLI server thus constitutes the interface between the terminals of the group and the server SL.
  • the management of the group itself (registrations, modifications of the rights granted to a member etc.) is done dynamically and locally by the intermediary server SLI.
  • the treatment related to the group is indeed deported within the group.
  • the license server SL can thus avoid storing data relating to this group (name of the devices of the group, rights attached to each device of the group, etc.), which on the one hand simplifies the operation of the license server SL, and on the other, keep group information confidential.
  • the system represented in FIG. 1 makes it possible to easily and dynamically manage the rights for a set of users wishing to access a content.
  • a single license is acquired for the group, instructs the SLI server to broadcast this license to the T, T 1 SLI members of the group.
  • the system is adaptable to the specificities of the members T, T ', SLI of the group, since the intermediate server SLI can modify and transfer the license.
  • the SLI server is therefore a particular player in DRM systems.
  • the SLI server manages a group, and can broadcast the licenses received from the SL server to one or more of the terminals of this group.
  • the server SLI comprises unrepresented receiving means, for example a communication port, file modification means, for example a not shown processor, processing means, for example the same processor or another processor, and means transmission, for example another communication port not shown.
  • the SL server constructs a GL license on a content and sends it to the SLI server.
  • the server SL also sends the SLI the signature ⁇ of the license GL, the data B delegation of its signature to the server SLI, and the adjustment data R, some of these data being sent for example separately.
  • variable ⁇ G L comprises at the same time the signature ⁇ and the first adjustment data R, the values of ⁇ and R being for example able to be concatenated when sent to the server SLI.
  • the variable ⁇ _ representing the signature data comprises both the signature ⁇ and a second adjustment data r, the values of ⁇ and r being able for example to be concatenated when sending to the terminal T.
  • the embodiment illustrated by the figures uses an identity-based chameleon hashing function cryptographic brick and a standard signature scheme.
  • the license server executes an initialization algorithm to obtain a first public and private key pair (pk, sk), said delegation keys and a second pair public and private keys (PK, SK), so-called signature keys.
  • Keys PK, SK 1 pk, sk may be the same or may be different.
  • the keys sk and pk are then defined as (p, q, w) and (n, v) respectively.
  • the keys SK and PK are defined as (p, q, w) and (n, v) respectively.
  • the license server SL receives in a step 21 a request comprising an identifier of the intermediate server Idsu and an identifier of the desired content ID_content.
  • the request is advantageously (but not limited to) issued by the local server SLI, which allows to keep the information (or just some information) relative to the unknown group of the license server.
  • the server SL sends the content to the server SLI, in an encrypted form (in an optional step not shown).
  • the content is possible to send the content only after verification of the signature by the recipient device.
  • the server SL defines the rights attached to this content and for this intermediate server SLI. Furthermore, in a step 23, the server SL encrypts a key CEK used to encrypt the content, by means of a public key of the intermediate server KP SL I, which it has read before.
  • the license GL is obtained by concatenation of the content identifier ID_content Rights Rights and encrypted key CEK.
  • the GL license is associated with the signature ⁇ , then sent to the SLI intermediate server in a step 29.
  • the license GL is thus defined to grant rights given on a given content to a given intermediate server.
  • a first adjustment data R is then generated randomly. This number R is used during a first step 26 of hashing.
  • This first hash step involves a chameleon hash function based on the Hash identity.
  • RSA Cryptography Standard EMSAPSS, PKCS # 1 v2.1. 2002 ".
  • the first result h is then concatenated with the identifier of content ID_content and hashed using another hash function //, which can be a classic hash function.
  • This second hash leads to an imprint, to which a cryptographic function is applied, to obtain a signature ⁇ in a step 27.
  • the cryptographic function is an RSA function using the signature private key SK of the server SL.
  • a delegation data B is obtained in step 28 by applying an extraction function:
  • An extraction function makes it possible to extract secret information enabling the holder of this information to transform a message signed so that the signature of this message remains valid without being modified.
  • the license GL, the signature ⁇ concatenated with the number R 1 and the delegation data B are transmitted to the intermediate server SLI in step 29.
  • the transmission of the delegation data B can be separated from the transmission of the license GL, and from the signature ⁇ concatenated with the number R.
  • Such a separate sending of the data B is of course only an example of implementation of the invention.
  • the license GL may be sent by the signatory server in an XML format for example, and may include indications (not shown) on the algorithm used, the type of key and / or the standard used.
  • FIG. 3 is a flowchart of a method implemented by the intermediate server SLI.
  • the server SLI After reception in a step 31 of the license GL, the signature ⁇ concatenated with the number R, and the delegation data B transmitted by the server SL, the server SLI verifies in a step 32 that the signature ⁇ received is valid. This verification step is performed by means of the public key PK signature of the server SL according to the conventional method of verification of signature.
  • the SLI server opens and modifies the GL license in steps 33, 34, 35.
  • the modification of the GL license consists of both modifying in a step 35 the rights in Rights' according to the terminal T to which the license is intended, and to modify in a step 34 the encryption of the key CEK for this terminal T is able to find the key CEK.
  • the received CEK key encrypted with the public key of the SLI server is decrypted by means of the private key of the server SLI in a step 33, then encrypted again in a step 34, by means of the public key KP T of terminal T.
  • a modified license L is obtained in a step 36.
  • a function of modification makes it possible to modify a message connected to a signature so that this signature can be recognized as valid on the modified message.
  • the server SLI transmits to the terminal T the modified license L and signature data ⁇ L comprising the signature ⁇ received from the server SL and the second adjustment data r.
  • the terminal T receives these data (step 41 in FIG. 4) using unrepresented reception means, for example a communication port.
  • the terminal T comprises unrepresented signature verification means, arranged to carry out a particular signature verification in the sense that in addition to the license L received and the signature ⁇ received, the verification uses the adjustment data r.
  • the terminal performs a conventional step of verifying the signature received by means of the PK public key PK of the server SL during a step 42, and on the other hand, a hash step of the value h 'concatenated with the identifier ID_content, the hash function being the same as that used in step 27 according to FIG. 2, it can be expected that the comparison step 44 leads to recognizing the signature ⁇ as originating from the server SL and corresponding to the modified license L.
  • the verification step of the signature is validated, and the terminal can open the license L and access the key CEK by means of its private key (step 45). The terminal is thus able to decrypt the content.
  • Hash, Forge and Extract are described in more detail in the document G. Ateniese, B. de Medeiros supra.
  • the delegation of signature is therefore limited to a license corresponding to a given content, by identifier ID_content.
  • the encryption of the key CEK makes it possible to limit to a given intermediate server the possibility of modifying the encryption of the key CEK.
  • the principle of double hashing, the second hash being performed on a result of the first hash and on part of the file limits the possibility of modification to the rest of the file only.
  • the modules that implement the steps of the previously described method are preferably software modules comprising instructions for executing the steps of the method by respectively the server SL, the intermediate server SLI and the recipient device T.
  • the software modules can be stored in respectively, the SL server, the intermediate server SLI and the destination device T, or transmitted by a data medium.
  • This may be a hardware storage medium, for example a CD-ROM or a hard disk, or a transmission medium such as a telecommunications network.

Abstract

Un procédé destiné à être mis en uvre par un dispositif serveur intermédiaire (SLI), comprenant les étapes consistant à; recevoir un fichier (GL) issu d'un dispositif signataire (SL) et une signature (s) dudit fichier par ledit dispositif signataire, modifier le fichier reçu, déterminer des données de signature (s, r) de façon à ce qu'un dispositif destinataire (T) reconnaisse le fichier modifié comme signé par le dispositif signataire, et envoyer le fichier modifié (L) et les données de signature au dispositif destinataire.

Description

DELEGATION DE SIGNATURE NUMERIQUE
L'invention se rapporte au domaine des communications numériques. Plus précisément, l'invention concerne la réception d'un fichier signé, et la modification en vue d'une transmission de ce fichier.
Le fichier peut par exemple comprendre une licence accordant des droits à un contenu distinct de cette licence. L'invention peut ainsi, par exemple et de façon non limitative, se rapporter à la protection de contenus numériques, et en particulier aux systèmes de gestion numérique des droits ou DRM (de l'anglais « Digital Rights Management ») par exemple tel que définis dans la norme OMA DRM. II est connu d'utiliser une signature pour s'assurer qu'un fichier donné a bien été émis par un dispositif signataire donné. La signature est typiquement obtenue par application d'une fonction cryptographique au moyen d'une clé privée associée au signataire à une empreinte du fichier à signer. L'empreinte peut être obtenue en appliquant une fonction de hachage au fichier. A la réception du fichier et de la signature, d'une part on calcule l'empreinte du fichier reçu, et d'autre part, on vérifie la signature en utilisant une clé publique associée à la clé privée du signataire. Si l'empreinte calculée et la signature ainsi déchiffrée coïncident, alors on considère que le fichier a bien été émis par le signataire. Selon des procédés connus, le signataire peut envoyer à un dispositif serveur intermédiaire le fichier et la signature de ce fichier. Le serveur intermédiaire peut modifier le fichier, signer le fichier modifié, et transmettre le fichier modifié et sa signature à un dispositif destinataire. Le dispositif destinataire, par exemple un terminal mettant en œuvre un procédé classique de vérification de signature, est alors seulement en mesure de vérifier que le fichier reçu du serveur intermédiaire a bien été émis par le serveur intermédiaire. L'invention a pour objectif de permettre à un dispositif destinataire mettant en œuvre un procédé classique de vérification de signature de vérifier l'origine du fichier.
Selon un premier aspect, l'invention a pour objet un procédé destiné à être mis en œuvre par un dispositif serveur intermédiaire, comprenant les étapes consistant à :
- recevoir un fichier issu d'un dispositif signataire et une signature du fichier par le dispositif signataire,
- modifier le fichier reçu, - déterminer des données de signature de façon à ce qu'un dispositif destinataire reconnaisse le fichier modifié comme signé par le dispositif signataire, et
- envoyer le fichier modifié et les données de signature au dispositif destinataire. Le dispositif destinataire reçoit ainsi le fichier modifié par le serveur intermédiaire, et reconnaît le fichier modifié comme ayant été généré par le dispositif signataire. Le dispositif destinataire peut ainsi s'assurer de l'origine du fichier reçu.
Par exemple, le dispositif signataire transmet au serveur intermédiaire un fichier comprenant un texte dans une langue donnée. Le serveur intermédiaire effectue une traduction automatique de ce texte dans une autre langue, et envoie le texte traduit, avec des données de signature adéquates, à un terminal destinataire. Les données de signature sont telles que le terminal reconnaît le texte traduit comme signé par le dispositif signataire. Selon un autre exemple, le fichier peut comprendre des portions de textes relatives à des montants dans une devise donnée, et le serveur intermédiaire effectue une conversion de devise. Avec un procédé connu de l'art antérieur, le terminal recevant le fichier modifié est seulement en mesure de vérifier que ce fichier provient du convertisseur de devise. L'invention permet au terminal de reconnaître le fichier comme étant issu du dispositif signataire.
L'invention n'est pas limitée par la nature de la modification apportée au fichier. La modification apportée au fichier par le serveur intermédiaire peut par exemple consister en un changement de format pour que le fichier soit lisible par le dispositif destinataire, en une compression de ce fichier, en une décompression de ce fichier, en un marquage (« watermark » en anglais), en un filtrage du fichier, etc. Le fichier issu du dispositif signataire peut avoir été généré par le dispositif signataire, ou bien le dispositif signataire l'a lui-même reçu d'un autre dispositif.
L'invention peut permettre de rendre transparent au destinataire le fait que le fichier a été modifié par un serveur intermédiaire. Il est bien entendu préférable que le serveur intermédiaire soit sécurisé.
Avantageusement, le serveur intermédiaire reçoit au moins une donnée de délégation issue du dispositif signataire et au moins une première donnée d'ajustement issue du dispositif signataire. Ces données de délégation et d'ajustement sont utilisées lors de la détermination des données de signature. Ainsi, le dispositif signataire autorise le serveur intermédiaire à modifier le fichier, tout en permettant au dispositif destinataire de reconnaître ce fichier comme signé par le dispositif signataire, et ce sans modification substantielle du procédé de reconnaissance de signature mis en œuvre par le dispositif destinataire. Le signataire peut envoyer au serveur intermédiaire des données de délégation et/ou d'ajustement lors de chaque envoi d'un fichier, ou bien en une seule fois, lors d'une phase d'initialisation.
L'invention n'est bien entendu pas limitée par un envoi du signataire au serveur intermédiaire de données de délégation, ni de données d'ajustement. On peut par exemple prévoir que les données de signature comprennent la signature reçue du dispositif signataire et des identifiants des modifications apportées au fichier par le dispositif serveur. Le dispositif destinataire est ainsi en mesure de retrouver une empreinte du fichier avant modification et donc de vérifier la validité de la signature. Avantageusement, les données de signature comprennent la signature reçue du dispositif signataire, ainsi qu'au moins une seconde donnée d'ajustement. C'est cette seconde donnée d'ajustement qui permet au dispositif destinataire de reconnaître le fichier modifié comme à l'origine de la signature.
Avantageusement, la signature issue du dispositif signataire est obtenue par application d'une fonction cryptographique à une empreinte, et la seconde donnée d'ajustement est déterminée de façon à permettre de recalculer cette empreinte.
On peut par exemple utiliser une fonction de hachage caméléon, et de préférence une fonction de hachage caméléon basée sur l'identité telle que définie dans le document "Identity-based chameleon hash and application", de G. Ateniese, B. de Medeiros (Financial Crypto 2004, volume 3110 of LNCS1 pages 164-180, Springer-Verlag, 2004). Dans ce document, la fonction de hachage caméléon permet à un premier dispositif recevant d'un deuxième dispositif un document et une signature ainsi obtenue pour ce document, de signer n'importe quel document en laissant croire qu'il provient du deuxième dispositif. De ce fait, le premier dispositif est incapable de prouver à une tierce partie que le document reçu provient effectivement du deuxième dispositif. Seul le deuxième dispositif est en mesure de démontrer une usurpation ou une non-usurpation.
Avantageusement, le fichier issu du dispositif signataire comprend une licence accordant des droits sur un contenu distinct de cette licence. Le serveur intermédiaire modifie la licence en fonction du dispositif destinataire. Bien entendu, l'invention n'est en rien limitée par cet exemple d'application.
Dans le domaine de la protection de contenus numériques, il est connu qu'un serveur transmette à un dispositif destinataire (terminal) un contenu numérique chiffré, une licence adaptée à ce dispositif destinataire et une signature de cette licence par le serveur. La licence comprend un identifiant du contenu numérique, des droits d'usage sur le contenu et la clé utilisée pour déchiffrer le contenu. La clé utilisée pour chiffrer le contenu est transmise après avoir été elle-même chiffrée avec une clé publique correspondant à ce dispositif destinataire. En utilisant une clé privée qui correspond à cette clé publique, le dispositif destinataire est capable de déchiffrer la clé chiffrée, et donc de déchiffrer le contenu chiffré. La clé publique et la clé privée peuvent être connues d'un seul dispositif destinataire, auquel cas la licence est spécifiquement adaptée à ce dispositif destinataire, ou bien être connues d'un groupe de terminaux, par exemple les terminaux appartenant à un même utilisateur. Dans le cas où les clés publique et privée sont associées à un groupe de terminaux, on parle de clés de domaine. Un serveur peut transmettre un contenu chiffré et une licence aux terminaux de ce groupe. La gestion du groupe, par exemple les inscriptions et radiations de terminaux, est assurée par le serveur.
En permettant à un serveur intermédiaire de recevoir, modifier et transmettre la licence, l'invention permet une gestion des terminaux par le serveur intermédiaire, lequel peut être local, et non par le serveur signataire (distant). Cette gestion locale permet de simplifier le fonctionnement du dispositif signataire, et également de garder certaines informations confidentielles. Par exemple, le nombre de terminaux du domaine, les droits attachés à chaque dispositif destinataire etc. constituent des informations qui peuvent rester inconnues du dispositif signataire.
La licence peut comprendre une clé préalablement utilisée pour chiffrer le contenu, cette clé étant transmise chiffrée par une autre clé. L'étape de modification de la licence peut comprendre une étape de déchiffrement de la clé utilisée pour chiffrer le contenu, et une étape de chiffrement de la clé ainsi déchiffrée. Ce chiffrement est effectué au moyen d'une autre clé, par exemple une clé publique associée au dispositif destinataire auquel le contenu est destiné. Ce dispositif destinataire utilise ensuite sa clé privée associée à sa clé publique pour déchiffrer la clé utilisée pour le chiffrement du contenu.
La licence peut comprendre un champ de droits d'usage sur le contenu, pour préciser les droits attachés à ce contenu. Par exemple, un contenu donné peut être lu un nombre limité de fois, être transférable ou non transférable, etc. La modification de la licence peut comprendre par exemple une modification de droits d'usage sur le contenu correspondant à la licence. Par exemple, un utilisateur peut souhaiter que les fichiers multimédias téléchargés depuis l'ordinateur de son enfant ne puissent être visualisés qu'une seule fois. Dans ce cas, lorsqu'une requête est émise pour un fichier multimédia donné depuis l'ordinateur de l'enfant, le dispositif signataire envoie à l'ordinateur parental le fichier souhaité, sous une forme chiffrée, accompagné d'une licence et d'une signature. La licence contient un champ de droits rempli avec une valeur correspondant aux droits d'utilisation pour les parents. L'ordinateur parental fait office de serveur intermédiaire et modifie ce champ de droits afin que le fichier ne puisse être vu qu'une seule fois. L'ordinateur parental transmet le fichier chiffré à l'ordinateur de l'enfant, avec la licence modifiée et des données de signature. Ces données de signature sont telles que l'ordinateur de l'enfant reconnaît la licence modifiée reçue comme signée par le serveur distant.
Dans cet exemple, on peut prévoir que la clé utilisée pour chiffrer le fichier multimédia est chiffrée par le dispositif signataire au moyen d'une clé publique de domaine. L'ordinateur de l'enfant déchiffre la clé utilisée pour chiffrer le fichier multimédia au moyen d'une clé privée de domaine correspondant à la clé publique de domaine.
On peut en outre prévoir une étape d'insertion d'une information donnée par le serveur intermédiaire, cette information donnée permettant au dispositif destinataire de vérifier que le fichier a bien transité par le serveur intermédiaire. L'information donnée peut par exemple comprendre une signature par le serveur intermédiaire du fichier. Le fichier est ainsi envoyé avec deux signatures et le dispositif destinataire effectue deux vérifications de signatures.
Selon un autre aspect, l'invention a pour objet un dispositif serveur intermédiaire comprenant des moyens de réception pour recevoir un fichier issu d'un dispositif signataire et une signature, des moyens de modification du fichier reçu, des moyens de traitement pour déterminer des données de signature de façon à ce qu'un dispositif destinataire reconnaisse le fichier modifié comme généré par le dispositif signataire, et des moyens de transmission du fichier modifié et des données de signature au dispositif destinataire.
Selon un autre aspect, l'invention a pour objet un procédé destiné à être mis en œuvre par un dispositif signataire et comprenant une étape consistant à signer un fichier au moyen d'une clé privée du dispositif signataire. Au moins une donnée de délégation et au moins une première donnée d'ajustement sont générées, ces données de délégation et d'ajustement permettant à un dispositif serveur intermédiaire de déterminer des données de signature telles qu'un dispositif destinataire reconnaisse le fichier modifié par le dispositif serveur intermédiaire comme ayant été signé par le dispositif signataire. Le dispositif signataire envoie au dispositif serveur intermédiaire le fichier, la signature de ce fichier par le dispositif signataire, la ou les donnée(s) d'ajustement et la ou les donnée(s) de délégation. Ce procédé constitue un exemple de procédé mis en œuvre par le dispositif signataire pour permettre une reconnaissance du fichier modifié comme ayant été signé par le dispositif signataire. La modification du fichier par le serveur intermédiaire peut ainsi être rendu transparente aux yeux du dispositif destinataire. Ce procédé peut avantageusement être conforme à ou se rapprocher d'un standard courant, défini par exemple par la norme OMA DRM. Ainsi, il peut être possible d'implémenter le procédé simplement par des modifications légères de la configuration d'un serveur existant.
Avantageusement, l'étape de signature comprend les étapes consistant à hacher à l'aide d'une première fonction de hachage au moins le fichier de façon à obtenir un premier résultat, à hacher à l'aide d'une deuxième fonction de hachage à la fois le premier résultat et une donnée caractéristique du fichier, de façon à obtenir un deuxième résultat, et à appliquer au deuxième résultat une fonction cryptographique, par exemple au moyen de la clé privée du dispositif signataire.
Un tel double hachage permet, de part l'introduction de la donnée caractéristique du fichier, de limiter la délégation de signature offerte au serveur intermédiaire au fichier envoyé, ou plus précisément aux fichiers présentant la même donnée caractéristique. En effet, si le serveur intermédiaire détermine des données de signature pour un fichier présentant une donnée caractéristique différente, par exemple un identifiant distinct, le dispositif destinataire peut être capable de retrouver, à l'aide des données de signature, le premier résultat, mais échoue a retrouver le deuxième résultat. Le dispositif destinataire échoue ainsi à reconnaître comme étant signé par le signataire le fichier avec un identifiant distinct de celui du fichier réellement signé par le signataire.
Avantageusement, le fichier lui-même comprend la donnée caractéristique du fichier. Cette donnée caractéristique constitue donc une partie du fichier dont la modification par le serveur intermédiaire est interdite, à peine d'échec à reconnaître le dispositif signataire comme signataire du fichier modifié. Ainsi, le dispositif signataire peut limiter les parties du fichier modifiables par le serveur intermédiaire. L'invention n'est bien entendu pas limitée par le double hachage.
Selon un autre aspect, l'invention a pour objet un dispositif signataire comprenant des moyens de signature d'un fichier, ces moyens de signature étant agencés pour utiliser une clé privée du dispositif signataire, des moyens de génération d'au moins une donnée de délégation et d'au moins une donnée d'ajustement, ces données de délégation et d'ajustement permettant à un dispositif serveur intermédiaire de déterminer des données de signature telles qu'un dispositif destinataire reconnaît le fichier modifié par le dispositif serveur intermédiaire comme ayant été signé par le dispositif signataire, et des moyens d'envoi au dispositif serveur intermédiaire du fichier, de la signature de ce fichier par le dispositif signataire, de la ou des donnée(s) d'ajustement et de la ou des donnée(s) de délégation.
Selon un autre aspect, l'invention a pour objet un procédé destiné à être mis en œuvre par un dispositif destinataire, le procédé comprenant une étape de réception d'un dispositif serveur d'un fichier et de données de signature correspondant à ce fichier, les données de signature comprenant une signature et au moins une donnée d'ajustement, et une étape de vérification de la signature. Cette étape utilise à la fois fe fichier, la signature et la donnée d'ajustement, de telle sorte que, pour une valeur de la donnée d'ajustement appropriée, le fichier est reconnu comme étant signé par un dispositif signataire distinct du dispositif serveur.
Ce procédé constitue un exemple de procédé mis en oeuvre par le dispositif destinataire pour permettre au dispositif destinataire de reconnaître la source d'un fichier reçu d'un serveur intermédiaire. Ce procédé peut avantageusement se rapprocher d'un standard courant, ou être conforme à ce standard, défini par exemple par la norme
OMA DRM. Ainsi, il peut être possible d'implémenter le procédé simplement par des modifications légères de la configuration d'un terminal existant, par exemple des modifications de l'agent DRM du terminal.
Avantageusement, il est procédé lors de l'étape de vérification à un double hachage du fichier et de la donnée d'ajustement, le deuxième hachage étant effectué sur le résultat du premier hachage et une valeur caractéristique du fichier. Ainsi, si le serveur a modifié le fichier de façon à changer cette caractéristique, ou l'a remplacé par un autre fichier présentant une valeur caractéristique différente, la signature n'est pas reconnue comme valide, c'est-à-dire que le dispositif destinataire ne reconnaît pas le fichier comme ayant été signé par le dispositif signataire.
Selon un autre aspect, l'invention a pour objet un dispositif destinataire comprenant des moyens de réception pour recevoir d'un dispositif serveur un fichier et des données de signature correspondant à ce fichier, les données de signature comprenant une signature et au moins une donnée d'ajustement, et des moyens de vérification de la signature, ces moyens de vérification étant agencés pour utiliser la (ou les) donnée d'ajustement de sorte que, pour une valeur de la (ou les) donnée d'ajustement appropriée, le fichier est reconnu comme étant signé par un dispositif signataire distinct du dispositif serveur.
D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après. La figure 1 montre un exemple de système selon un mode de réalisation de l'invention.
La figure 2 est un organigramme d'un procédé exécutable par un dispositif signataire selon un mode de réalisation de l'invention.
La figure 3 est un organigramme d'un procédé exécutable par un serveur intermédiaire selon un mode de réalisation de l'invention.
La figure 4 est un organigramme d'un procédé exécutable par un dispositif destinataire selon un mode de réalisation de l'invention. Le figure 1 montre un dispositif serveur intermédiaire SLI recevant d'un dispositif signataire, ici un serveur distant SL, un fichier GL et une signature σ de ce fichier. Le serveur SLI modifie le fichier GL et envoie le fichier modifié L avec des données de signature σι à un dispositif destinataire, ici un terminal T.
Dans le mode de réalisation représenté par les figures 1 à 4, le fichier GL est une licence qui accorde des droits sur un contenu Content, et le fichier L est une licence modifiée qui accorde des droits sur le même contenu Content. L'invention n'est en rien limitée par la nature du contenu Content. Il peut par exemple s'agir d'un contenu multimédia (séquence vidéo ou musicale, etc.).
Le serveur SL est un serveur de licences, qui, sur requête, fournit le contenu Content sous une forme chiffrée, et la licence GL correspond à ce contenu. Le serveur SL comprend des moyens de signature du fichier GL, par exemple un processeur non représenté, des moyens de génération de données de délégation B, et d'ajustement R, par exemple le même processeur non représenté, et des moyens d'envoi, par exemple un port de communication classique non représenté.
Le serveur SLI est ainsi en mesure d'acquérir, par exemple en l'achetant, une licence GL pour un contenu donné, et de transformer et personnaliser cette licence en une licence modifiée L pour chacun des autres membres T, T du groupe (association, famille, entreprise, etc.). Pour que le terminal destinataire T accepte la signature de la licence modifiée, le serveur
SLI transmet des données de signature σι= (σ, r), telles que le terminal T reconnaît la licence modifiée L comme étant signée par le serveur de licences SL.
Ainsi, le serveur local SLI gère les communications entre le serveur de licence SL et tous les membres du groupe. Le serveur SLI constitue donc l'interface entre les terminaux du groupe et le serveur SL. Egalement, la gestion du groupe lui-même (inscriptions, modifications des droits accordés à un membre etc.) est effectuée dynamiquement et localement par le serveur intermédiaire SLI. On peut ainsi éviter la lourdeur d'une gestion du groupe par un serveur centralisé et commun à plusieurs groupes. Le traitement lié au groupe est en effet déporté à l'intérieur du groupe. Le serveur de licence SL peut ainsi éviter de mémoriser des données relatives à ce groupe (nom des dispositifs du groupe, droits attachés à chaque dispositif du groupe, etc.), ce qui d'une part simplifie le fonctionnement du serveur de licences SL, et de l'autre permet de garder des informations relatives au groupe confidentielles.
Le système représenté sur la figure 1 permet de gérer facilement et dynamiquement les droits pour un ensemble d'utilisateurs désirant accéder à un contenu. Une seule licence est acquise pour le groupe, charge au serveur SLI de diffuser cette licence aux membres T, T1 SLI du groupe. Le système est adaptable aux spécificités des membres T, T', SLI du groupe, dans la mesure où le serveur intermédiaire SLI peut modifier et transférer la licence.
Le serveur SLI constitue donc un acteur particulier dans les systèmes DRM. Le serveur SLI gère un groupe, et peut diffuser les licences reçues du serveur SL vers un ou plusieurs des terminaux de ce groupe. Le serveur SLI comprend des moyens de réception non représentés, par exemple un port de communication, des moyens de modification de fichier, par exemple un processeur non représenté, des moyens de traitement, par exemple le même processeur ou un autre processeur, et des moyens de transmission, par exemple un autre port de communication non représenté.
Le serveur SL construit une licence GL sur un contenu et l'envoie au serveur SLI. Le serveur SL envoie également au SLI la signature σ de la licence GL, la donnée B de délégation de sa signature au serveur SLI, et la donnée d'ajustement R, certaines de ces données étant envoyées par exemple de façon séparée.
Dans l'exemple illustré par la figure 1 , la variable σGL comprend à Ia fois la signature σ et la première donnée d'ajustement R, les valeurs de σ et R pouvant par exemple être concaténées lors de l'envoi au serveur SLI. La variable σι_ représentant les données de signature comprend à la fois la signature σ et une seconde donnée d'ajustement r, les valeurs de σ et r pouvant par exemple être concaténées lors de l'envoi au terminal T. Le mode de réalisation illustré par les figures utilise une brique cryptographique de fonction de hachage caméléon basée sur l'identité et un schéma de signature standard.
Préalablement à l'exécution des étapes de l'organigramme de la figure 2, le serveur de licences exécute un algorithme d'initialisation pour obtenir une première paire de clés publique et privée (pk, sk), dites clés de délégation et une deuxième paire de clés publique et privée (PK, SK), dites clés de signature.
Les clés PK, SK1 pk, sk peuvent être les mêmes ou peuvent être différentes.
Dans un exemple de réalisation de l'invention, deux nombres p et q sont générés au hasard. Il est calculé n=pq. Un autre nombre v est généré au hasard. Il est déterminé les nombres w et z tels que vw+z(p-1)(q-1)=1.
Les clés sk et pk sont alors définies comme (p, q, w) et (n, v) respectivement. Les clés SK et PK sont définies comme (p, q, w) et (n, v) respectivement.
En fonctionnement, comme illustré sur la figure 2, le serveur de licences SL reçoit dans une étape 21 une requête comprenant un identifiant du serveur intermédiaire Idsu et un identifiant du contenu désiré ID_content.
La requête est avantageusement (mais de façon non limitative) émise par le serveur local SLI, ce qui permet de garder les informations (ou simplement certaines informations) relatives au groupe inconnues du serveur de licence.
Si la requête est acceptée, le serveur SL envoie au serveur SLI le contenu, sous une forme chiffrée (dans une étape optionnelle non représentée). On peut bien entendu prévoir d'envoyer le contenu seulement après la vérification de la signature par le dispositif destinataire.
Dans une étape 22, le serveur SL définit les droits attachés à ce contenu et pour ce serveur intermédiaire SLI. En outre, dans une étape 23, le serveur SL chiffre une clé CEK utilisée pour chiffrer le contenu, au moyen d'une clé publique du serveur intermédiaire KPSLI, dont il a pris connaissance auparavant.
Dans une étape 24, la licence GL est obtenue par concaténation de l'identifiant du contenu ID_content, des droits Rights et de la clé CEK chiffrée. La licence GL est associée à la signature σ, puis envoyée au serveur intermédiaire SLI lors d'une étape 29. La licence GL est donc définie pour accorder des droits donnés sur un contenu donné à un serveur intermédiaire donné.
Dans une étape 25, une première donnée d'ajustement R est ensuite générée aléatoirement. Ce nombre R est utilisé lors d'une première étape 26 de hachage. Cette première étape de hachage fait intervenir une fonction de hachage caméléon basée sur l'identité Hash. Un premier résultat h est obtenu par ce hachage à la fois de la licence GL, (qui est une concaténation de l'identifiant du contenu ID_content, des droits Rights et de la clé CEK chiffrée), du nombre R, de l'identifiant du serveur intermédiaire ldSu et de la clé publique pk de délégation du serveur SL : h = Hash(pk, Id su , ID _ content, M, R) , soit : h = JH{M)Rv(moάn) , où M est obtenu par concaténation des droits Rights et de la clé CEK chiffrée, H est une fonction de hachage donnée, et J = EMSAPSS(Id311 JD _content) , la fonction EMSAPSS étant une fonction de formatage décrite par exemple dans le standard « RSA Labs. RSA Cryptography Standard: EMSAPSS, PKCS#1 v2.1. 2002 ». Le premier résultat h est ensuite concaténé avec l'identifiant du contenu ID_content et haché à l'aide d'une autre fonction de hachage //, laquelle peut être une fonction classique de hachage.
Ce deuxième hachage conduit à une empreinte, à laquelle on applique une fonction cryptographique, pour obtenir une signature σ dans une étape 27. Dans cet exemple, la fonction cryptographique est une fonction RSA utilisant la clé privée SK de signature du serveur SL.
Une donnée de délégation B est obtenue dans l'étape 28 en appliquant une fonction d'extraction :
B = extract(Id SL1 , ID _ content, sk) Soit : B = Jw mod(«) . (1 )
Une fonction d'extraction permet d'extraire une information secrète permettant au détenteur de cette information de transformer un message signé de telle sorte que la signature de ce message reste valide sans- être modifiée.
Enfin, la licence GL, la signature σ concaténée avec le nombre R1 et la donnée de délégation B sont transmises au serveur intermédiaire SLI dans l'étape 29.
Comme représenté sur la figure 1 , la transmission de la donnée de délégation B peut être séparée de la transmission de la licence GL, et de la signature σ concaténée avec le nombre R. Un tel envoi séparé de la donnée B ne constitue bien entendu qu'un exemple de mise en œuvre de l'invention. On peut par exemple prévoir d'envoyer ensemble la licence GL, la signature σ concaténée avec le nombre R et la donnée de délégation B.
On notera que l'invention n'est en rien limitée par les techniques de chiffrement de contenu ou de chiffrement de la clé de chiffrement de contenu, ou les techniques de signature utilisées. La licence GL peut être envoyée par le serveur signataire sous un format XML par exemple, et peut comporter des indications (non représentées) sur l'algorithme utilisé, sur le type de clé et/ou sur le standard utilisé.
La donnée de délégation B et la première donnée d'ajustement R sont telles que seul le serveur SLI est capable de modifier la licence. La figure 3 est un organigramme d'un procédé mis en œuvre par le serveur intermédiaire SLI. Après réception dans une étape 31 de la licence GL, de la signature σ concaténée avec le nombre R, et de la donnée de délégation B transmises par le serveur SL, le serveur SLI vérifie dans une étape 32 que la signature σ reçue est valide. Cette étape de vérification est effectuée au moyen de la clé publique PK de signature du serveur SL suivant le procédé classique de vérification de signature.
Si la signature n'est pas reconnue comme valide, on peut prévoir que le serveur SLI s'abstienne d'exécuter les étapes suivantes du procédé, ou bien émette un message d'alerte. Si la signature est bien reconnue comme valide, le serveur SLI ouvre et modifie la licence GL dans des étapes 33, 34, 35. Dans cet exemple, la modification de la licence GL consiste à la fois à modifier dans une étape 35 les droits Rights en droits Rights' en fonction du terminal T auquel la licence est destinée, et à modifier dans une étape 34 le chiffrement de la clé CEK pour que ce terminal T soit capable de retrouver la clé CEK. A cet effet, la clé CEK reçue chiffrée avec la clé publique du serveur SLI est déchiffrée au moyen de la clé privée du serveur SLI dans une étape 33, puis chiffrée à nouveau dans une étape 34, au moyen de la clé publique KPT du terminal T.
En concaténant l'identifiant du contenu ID_content, les nouveaux droits Rights' et la clé CEK nouvellement chiffrée, on obtient une licence modifiée L dans une étape 36.
On détermine ensuite une seconde donnée d'ajustement r (étape 37) : r = Forge(pk, B, m, R, M) , où m est obtenu par concaténation des droits Rights' et de la clé CEK nouvellement chiffrée, et où Forge est une fonction de modification, c'est-à-dire : r ≈ RBHιU)-Him) mod(n) (2) Une fonction de modification permet de modifier un message relié à une signature de telle sorte que cette signature puisse être reconnue comme valide sur le message modifié.
Lors d'une étape 38, le serveur SLI transmet au terminal T la licence modifiée L et des données de signature σL comprenant la signature σ reçue du serveur SL et la seconde donnée d'ajustement r.
Le terminal T reçoit ces données (étape 41 sur la figure 4) à l'aide de moyens de réception non représentés, par exemple un port de communication. Le terminal T comprend des moyens de vérification de signature non représentés, agencés pour procéder à une vérification de signature particulière en ce sens qu'outre la licence L reçue et la signature σ reçue, la vérification fait intervenir la donnée d'ajustement r.
La donnée r intervient lors d'une étape 43 de hachage par une fonction de hachage caméléon basée sur l'identité :
/z'= Hash(pk, Id su , ID _ content, m, r) Soit h'≈ ./"«V mod(n)
En utilisant la formule (2), puis la formule (1 ) on obtient : h<= j"^RvBvHiM)-vHOn) mod(n) , h,= jfHm)RVJ™mM)-™m*) mod(n) _
Or vw = l
Donc h'= RvJH[m) mod(«) La donnée de délégation B, et les données d'ajustement R et r sont donc telles que h et h' coïncident.
Aussi, si d'une part, le terminal effectue une étape classique de vérification de la signature reçue au moyen de la clé publique de signature PK du serveur SL lors d'une étape 42, et de l'autre, une étape de hachage de la valeur h' concaténée avec l'identifiant ID_content, la fonction de hachage étant la même que celle utilisée lors de l'étape 27 selon la figure 2, on peut s'attendre à ce que l'étape de comparaison 44 conduise à reconnaître la signature σ comme provenant du serveur SL et correspondant bien à la licence modifiée L. L'étape de vérification de la signature est donc validée, et le terminal peut ouvrir la licence L et accéder à la clé CEK au moyen de sa clé privée (étape 45). Le terminal est ainsi en mesure de déchiffrer le contenu.
Les fonctions Hash, Forge et Extract sont décrites de façon plus détaillées dans le document G. Ateniese, B. de Medeiros précité. Avec le procédé illustré par les figures 1 à 4, seul le serveur SLI est capable de modifier la licence GL. La délégation de signature est donc limitée à une licence correspondant à un contenu donné, de part l'identifiant ID_content. En outre, le chiffrement de la clé CEK permet de limiter à un serveur intermédiaire donné la possibilité de modifier le chiffrement de la clé CEK. On remarquera également que le principe du double hachage, le deuxième hachage étant effectué sur un résultat du premier hachage et sur une partie du fichier, permet de limiter la possibilité de modification au reste du fichier seulement. Les modules qui mettent en œuvre les étapes du procédé précédemment décrit sont de préférence des modules logiciels comprenant des instructions pour faire exécuter les étapes du procédé par respectivement, le serveur SL, le serveur intermédiaire SLI et le dispositif destinataire T. Les modules logiciels peuvent être stockés dans respectivement, le serveur SL, le serveur intermédiaire SLI et le dispositif destinataire T, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM ou un disque dur, ou bien un support de transmission tel qu'un réseau de télécommunications.

Claims

REVENDICATIONS
1. Procédé destiné à être mis en œuvre par un dispositif serveur intermédiaire (SLI)1 comprenant les étapes consistant à : recevoir un fichier (GL) issu d'un dispositif signataire (SL), et une signature
(σ) dudit fichier par ledit dispositif signataire, modifier le fichier reçu, déterminer des données de signature (σ, r) de façon à ce qu'un dispositif destinataire (T) reconnaisse le fichier modifié (L) comme signé par le dispositif signataire, les données de signature comprenant la signature reçue du dispositif signataire, ιet envoyer le fichier modifié et les données de signature au dispositif destinataire.
2. Procédé selon la revendication 1 , comprenant en outre les étapes consistant à : recevoir au moins une donnée de délégation (B), et au moins une première donnée d'ajustement (R) issues du dispositif signataire (SL), utiliser ladite au moins une donnée de délégation et ladite au moins une donnée d'ajustement lors de la détermination des données de signature (σ, r).
3. Procédé selon l'une des revendications précédentes, dans lequel : les données de signature comprennent en outre au moins une seconde donnée d'ajustement (r), la signature est obtenue par application d'une fonction cryptographique à une empreinte, et la seconde donnée d'ajustement est déterminée de façon à permettre de recalculer ladite empreinte.
4. Procédé selon l'une des revendications précédentes, dans lequel : le fichier issu du dispositif signataire (SL) comprend une licence (GL) accordant des droits sur un contenu distinct de ladite licence, la licence est modifiée en fonction du dispositif destinataire (T) auquel la licence modifiée (L) est transmise.
5. Procédé selon la revendication 4, dans lequel l'étape de modification de la licence (GL) comprend les étapes consistant à : déchiffrer une clé (CEK) reçue de façon chiffrée dans la licence issue du dispositif signataire, la clé permettant de déchiffrer le contenu, chiffrer la clé ainsi déchiffrée au moyen d'une clé (KPT) correspondant au dispositif destinataire (T) auquel le contenu est destiné.
6. Procédé selon l'une des revendications 4 ou 5, dans lequel l'étape de modification de la licence comprend l'étape consistant à : modifier la valeur d'un champ de droits d'usage, ledit champ étant compris dans la licence issue du dispositif signataire et permettant de définir les droits attachés à ladite licence.
7. Dispositif pour un serveur intermédiaire (SLI) comprenant : des moyens de réception pour recevoir un fichier (GL) issu d'un dispositif signataire (SL), et une signature (σ) dudit fichier par ledit dispositif signataire (SL), des moyens de modification du fichier reçu, des moyens de traitement pour déterminer des données de signature (σ, r) de façon à ce qu'un dispositif destinataire (T) reconnaisse le fichier modifié (L) comme signé par le dispositif signataire, les données de signature comprenant la signature reçue du dispositif signataire, et des moyens de transmission pour transmettre le fichier modifié et les données de signature au dispositif destinataire.
8. Procédé destiné à être mis en œuvre par un dispositif signataire (SL), comprenant les étapes consistant à : signer un fichier (GL) au moyen d'une clé privée du dispositif signataire (SK), générer au moins une donnée de délégation (B), et au moins une donnée d'ajustement (R), ladite au moins une donnée de délégation et ladite au moins une donnée d'ajustement permettant à un dispositif serveur intermédiaire (SLI) de déterminer des données de signature (σ, r) telles qu'un dispositif destinataire (T) reconnaisse un fichier modifié (L) par le dispositif serveur intermédiaire comme ayant été signé par le dispositif signataire, les données de signature comprenant la signature reçue du dispositif signataire, envoyer au dispositif serveur intermédiaire le fichier, la signature (σ) de ce fichier par le dispositif signataire, ladite au moins une donnée de délégation et ladite au moins une donnée d'ajustement.
9. Procédé selon la revendication précédente, dans lequel l'étape de signature comprend les étapes consistant à : hacher à l'aide d'une première fonction de hachage (Hash) au moins le fichier (GL) de façon à obtenir un premier résultat (h), hacher à l'aide d'une deuxième fonction de hachage ( /ή à la fois le premier résultat et une donnée caractéristique du fichier (ID_content), de façon à obtenir un deuxième résultat, et appliquer au deuxième résultat une fonction cryptographique au moyen de la clé privée (SK) du dispositif signataire.
10. Dispositif signataire (SL) comprenant : des moyens de signature d'un fichier (GL), lesdits moyens de signature étant agencés pour utiliser une clé privée (SK) du dispositif signataire, des moyens de génération d'au moins une donnée de délégation (B) et d'au moins une donnée d'ajustement (R), ladite au moins une donnée de délégation et ladite au moins une donnée d'ajustement permettant à un dispositif serveur intermédiaire (SLI) de déterminer des données de signature (σ, r) telles qu'un dispositif destinataire (T) reconnaisse le fichier modifié (L) par le dispositif serveur intermédiaire comme ayant été signé par le dispositif signataire, les données de signature comprenant la signature reçue du dispositif signataire, des moyens d'envoi au dispositif serveur intermédiaire du fichier, de la signature (σ) de ce fichier par le dispositif signataire, de ladite au moins une donnée de délégation et de ladite au moins une donnée d'ajustement.
11. Procédé destiné à être mis en œuvre par un dispositif destinataire (T), le procédé comprenant : une étape de réception d'un dispositif serveur (SLI) d'un fichier (L) et de données de signature (σ, r) correspondant audit fichier, les données de signature comprenant une signature (σ) et au moins une donnée d'ajustement (r), la signature ayant étant effectuée au moyen d'une clé privée d'un dispositif signataire (SL) distinct du dispositif serveur, une étape de vérification de la signature, ladite étape utilisant à la fois le fichier, la signature et ladite au moins une donnée d'ajustement, de telle sorte que, pour une valeur de ladite au moins une donnée d'ajustement appropriée, le fichier est reconnu comme étant signé par le dispositif signataire.
12. Procédé selon la revendication précédente, dans lequel l'étape de vérification comprend les étapes consistant à vérifier la signature (σ) en appliquant une fonction cryptographique au moyen d'une clé publique (PK) du dispositif signataire (SL) sur la signature (σ), estimer un premier résultat (h') en appliquant une première fonction de hachage (Hash) au moins au fichier (L) et à la donnée d'ajustement (r), estimer un deuxième résultat en appliquant une deuxième fonction de hachage ( A) au premier résultat et à une donnée caractéristique
(ID_content) du fichier, comparer le deuxième résultat et la vérification de signature.
13. Dispositif destinataire (T) comprenant des moyens de réception pour recevoir d'un dispositif serveur (SLI) un fichier (L) et des données de signature (σ, r) correspondant audit fichier, les données de signature comprenant une signature (σ) et au moins une donnée d'ajustement (r), la signature ayant étant effectuée au moyen d'une clé privée d'un dispositif signataire (SL) distinct du dispositif serveur, des moyens de vérification de la signature, lesdits moyens de vérification étant agencés pour utiliser ladite au moins une donnée d'ajustement de sorte que, pour une valeur de ladite au moins une donnée d'ajustement appropriée, le fichier est reconnu comme étant signé par le dispositif signataire.
PCT/FR2008/050873 2007-05-23 2008-05-20 Delegation de signature numerique WO2008149029A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0703650 2007-05-23
FR0703650 2007-05-23

Publications (2)

Publication Number Publication Date
WO2008149029A2 true WO2008149029A2 (fr) 2008-12-11
WO2008149029A3 WO2008149029A3 (fr) 2009-04-16

Family

ID=38747885

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/050873 WO2008149029A2 (fr) 2007-05-23 2008-05-20 Delegation de signature numerique

Country Status (1)

Country Link
WO (1) WO2008149029A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010142923A1 (fr) * 2009-06-12 2010-12-16 France Telecom Procede cryptographique d'authentification anonyme et d'identification separee d'un utilisateur

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005066874A2 (fr) * 2004-01-08 2005-07-21 Matsushita Electric Industrial Co., Ltd. Systeme de distribution de contenus, procede de distribution de licences et dispositif terminal
WO2006069994A2 (fr) * 2004-12-27 2006-07-06 Universita' Degli Studi Di Roma 'la Sapienza' Procede et dispositif d'authentification de communications

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005066874A2 (fr) * 2004-01-08 2005-07-21 Matsushita Electric Industrial Co., Ltd. Systeme de distribution de contenus, procede de distribution de licences et dispositif terminal
WO2006069994A2 (fr) * 2004-12-27 2006-07-06 Universita' Degli Studi Di Roma 'la Sapienza' Procede et dispositif d'authentification de communications

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ATENIESE G ET AL: "Identity-based chameleon hash and applications" LECTURE NOTES IN COMPUTER SCIENCE, SPRINGER VERLAG, BERLIN, DE, vol. 3110, no. 8TH, 2004, pages 164-180, XP002383659 ISSN: 0302-9743 cité dans la demande *
KAZUO OHTA ET AL: "MEET-IN-THE-MIDDLE ATTACK ON DIGITAL SIGNATURE SCHEMES" ADVANCES IN CRYPTOLOGY - AUSCRYPT. SYDNEY, JAN. 8 - 11, 1990, PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON CRYPTOLOGY - AUSCRYPT, BERLIN, SPRINGER, DE, vol. CONF. 1, 8 janvier 1990 (1990-01-08), pages 140-154, XP000145204 ISBN: 3-540-53000-2 *
NEUMAN B C ED - INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS: "Proxy-based authorization and accounting for distributed systems" PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS. PITTSBURGH, MAY 25 - 28, 1993, LOS ALAMITOS, IEEE COMP. SOC. PRESS, US, vol. CONF. 13, 25 mai 1993 (1993-05-25), pages 283-291, XP010095707 ISBN: 0-8186-3770-6 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010142923A1 (fr) * 2009-06-12 2010-12-16 France Telecom Procede cryptographique d'authentification anonyme et d'identification separee d'un utilisateur
US8650403B2 (en) 2009-06-12 2014-02-11 France Telecom Crytographic method for anonymous authentication and separate identification of a user

Also Published As

Publication number Publication date
WO2008149029A3 (fr) 2009-04-16

Similar Documents

Publication Publication Date Title
EP2884716B1 (fr) Mécanisme d&#39;authentificaiton par jeton
EP3547203A1 (fr) Méthode et système de gestion d&#39;accès à des données personnelles au moyen d&#39;un contrat intelligent
TWI362873B (en) Method and system for identity recognition
FR3041195A1 (fr) Procede d&#39;acces a un service en ligne au moyen d&#39;un microcircuit securise et de jetons de securite restreignant l&#39;utilisation de ces jetons a leur detenteur legitime
EP3665609B1 (fr) Procédé et serveur de certification d&#39;un document électronique
FR2930390A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise.
EP2562958B1 (fr) Procédé et dispositif de signature juridique de documents électroniques
FR2913154A1 (fr) Chiffrement broadcast base sur identite
EP2242229A1 (fr) Procédé pour authentifier un terminal mobile client auprès d&#39;un serveur distant
FR2964812A1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP2301187A1 (fr) Terminal d&#39;authentification forte d&#39;un utilisateur
WO2016207527A1 (fr) Procédé de conversion d&#39;un premier chiffré en un deuxième chiffré
EP1514377A1 (fr) Procede et dispositif d&#39;interface pour echanger de maniere protegee des donnees de contenu en ligne
EP1949590A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en uvre des procedes, et systeme comprenant les dits dispositifs
WO2008149029A2 (fr) Delegation de signature numerique
FR3022716A1 (fr) Procede de partage de fichiers numeriques entre plusieurs ordinateurs, et ordinateur, ensemble de stockage de donnees et systeme de partage de fichiers numeriques associes
FR2898423A1 (fr) Procede securise de configuration d&#39;un dispositif de generation de signature electronique.
WO2011030069A1 (fr) Procede de generation d&#39;un certificat numerique
EP1989819B1 (fr) Procéde de certification de clé publique par un prestataire non accrédité
EP0923829A2 (fr) Instrument de securisation d&#39;echanges de donnees
EP1992104B1 (fr) Authentification d&#39;un dispositif informatique au niveau utilisateur
WO2022135952A1 (fr) Procédé et dispositif de génération d&#39;informations d&#39;authentification pour une entité sécurisée et procédé et dispositif de contrôle d&#39;identité associés
WO2023057652A1 (fr) Application de sécurité pour un dispositif informatique, et architecture de sécurité correspondante
FR2990818A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede.
WO2021198606A1 (fr) Procede et dispositif d&#39;authentification d&#39;un utilisateur aupres d&#39;une application

Legal Events

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

Ref document number: 08805819

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08805819

Country of ref document: EP

Kind code of ref document: A2