FR 2945175 A1 20101105 FR 0952827 A 20090429 Procédé permettant aux usagers de vérifier les factures téléphoniques les concernant émises par un opérateur. La présente invention concerne un procédé permettant à un usager de vérifier les factures téléphoniques émises par un opérateur. Elle concerne également les factures téléphoniques découlant dudit procédé ainsi que les terminaux IP permettant la mise en oeuvre dudit procédé. L'architecture de téléphonie ciblée par la présente invention est préférentiellement celle qui est basée sur le protocole SIP mais le procédé de la présente invention peut être transposé sur d'autres architectures de téléphonie telles que GSM, H323. Les réclamations des consommateurs concernant leurs factures téléphoniques émises par différents opérateurs sont un sujet récurrent. La multiplication des opérateurs qui, jusque dans un passé récent, représentaient l'autorité publique, associée au développement de la téléphonie sur IP (VoIP), contribuent à amplifier ces problèmes. En effet, les consommateurs ne disposent pas de réel instrument pour la vérification de leur facture. Ainsi, les architectures et protocoles de téléphonie sont basés sur des approches où l'opérateur détient l'ensemble des éléments qui caractérisent l'utilisation des ressources téléphoniques, ne permettant pas aux usagers consommateurs de vérifier la facture produite par leurs opérateurs. Le protocole de téléphonie � Session Initiation Protocol � (SIP) est un protocole standard ouvert de gestion de sessions qui est souvent utilisé dans les télécommunications multimédia et, depuis 2007, le protocole le plus courant pour la téléphonie par internet (VoIP). Ce protocole, décrit dans le standard RFC3261 de l'IETF (Internet Engineering Task Force), semble devenir le standard de la téléphonie et connaît de nombreuses applications telles que la visiophonie ou la messagerie instantanée. SIP est un protocole normalisé et standardisé qui a été conçu pour établir, modifier et terminer des sessions multimédia. SIP se charge de l'authentification et de la localisation des multiples participants. Il partage de nombreuses similitudes avec le protocole http comme le codage en ASCII et les codes de réponses. Le protocole SIP est de type requête/réponse. Un usager qu'on appelle User Agent (UA) peut établir un appel vers un serveur qu'on appelle le Proxy ou User Agent Server (UAS). Une requête peut être ainsi transmise par un UA ou un UAS et une ou plusieurs réponses peuvent être retournées à l'émetteur de la requête. Une requête est composée d'une méthode ; parmi les méthodes de base figurent les méthodes suivantes reconnues par leurs appellations communément utilisées : INVITE qui permet à un UA ou UAS de demander une nouvelle session, ACK qui confirme l'établissement d'une session, CANCEL qui annule une demande INVITE en suspens, BYE qui termine une session en cours. D'autres méthodes sont définies dans SIP dont les appellations sont les suivantes : ACK, BYE, CANCEL, OPTIONS, REGISTER, SUSCRIBE, INFO, NOTIFY, PRACK, 10 PREFER, UPDATE, MESSAGES, PUBLISH. Une réponse contient un code numérique sur trois digits suivis de plusieurs en-têtes d'un type similaire à ceux des codes http. Parmi ceux-ci figurent par exemple : 100 Trying, 200 OK, 404 Not Found ; des codes supérieurs à x80 sont spécifiques de SIP tels que : 180 Ringing, 486 Busy, etc... 15 Dans les tableaux ci-dessous, à titre d'illustration, sont représentées la requête (Tableau 1) et la réponse associée (Tableau 2) à une demande d'appel selon le protocole SIP: Tableau 1 : Requête : INVITE sip:dest@domain.org SIP/2.0 Via: SIP/2.0/UDP oeni.domain.org:5060 From: SRC ;tag=123456795 To: Contact: Call-ID: 1231B49C6F5E634Z954C1234560BCBD99ABCE5EE4231 CSeq: 43557 INVITE Content-Type: application/sdp User-Agent: X-yyy build 1112 Content-Length: 198 v=0 o=src 6543217 6543217 IN IP4 133.194.192.133 s=X-yyy c=IN IP4 133.194.192.133 t=0 0 m=audio 8000 RTP/AVP 8 101 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 20 25 30 35 40 Tableau 2 : Réponse: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP oeni.domain.org:5060; received= oeni.domain.org From: Src ;tag=123456795 To: ;tag=jd555ab2fc CallùID: 1231B49C6F5E634Z954C1234560BCBD99ABCE5EE4231 CSeq: 43557 INVITE UserùAgent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY MaxùForwards: 70 Contact: ProxyùAuthenticate: Digest realm="asterisk", nonce="3bddb6da" ContentùLength: 0 Les en-têtes Via, From, To, Call-ID, CSEQ et Max-Forwards sont présents dans toutes les requêtes et réponses formant l'en-tête général. L'en-tête Call-ID contient un 25 identificateur unique pour un appel. L'ensemble des requêtes et réponses pour un appel donné sont reliées entre elles par une valeur identique associée à cet en-tête Call-ID. A chaque appel une valeur globale unique est associée à cet en-tête. Plusieurs attaques existent sur la base de la prédiction de la valeur de ce champ. En effet, l'émission par un attaquant d'une terminaison d'une session nécessite l'envoi d'une 30 requête de type Cancel ou Bye avec une valeur du Call-ID semblable à celle de l'appel en cours qui met fin à la session. D'autres en-têtes sont définies pour SIP mais leur présence dans les messages SIP n'est pas obligatoire, on peut citer les en-têtes suivantes : Date, Accept,, Accept-Contact, Accept-Encoding, Accept-Language , Accept-Resource-Priority, Alert-Info, Allow, Allow-Events, 35 Authentication-Info, Authorization, Call-Info, Contact, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Encryption, Error-Info, Event, Expires, Hide, etc. Certains en-têtes garantissent une valeur unique pour un appel tel que l'en-tête � Date � pris comme exemple non limitatif. 40 Dans le paragraphe 8.1.1.4 du RFC3261 qui décrit le protocole SIP, il est préconisé d'utiliser une fonction cryptographique pour générer la valeur du Call-ID sans décrire de 3 10 15 20 méthode particulière pour le faire, notamment quant à la gestion des clés associées à cet algorithme cryptographique. Un premier objet de la présente invention est de proposer un procédé permettant aux usagers d'un opérateur téléphonique de vérifier les factures téléphoniques le concernant. Le procédé de la présente invention est remarquable en ce qu'il comprend sur lesdites factures dudit usager l'apposition d'un numéro propre émis et transmis à chaque appel dudit usager par le terminal de cet usager, ledit numéro étant obtenu par l'application d'une clé cryptographique prenant en compte tout ou partie des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique étant uniquement connue et gérée par le terminal dudit usager. Cette clé cryptographique est de type f (K, n) = N°Id dans laquelle : - K représente ladite clé cryptographique, - n représente tout ou partie des données des champs de l'en-tête pris en compte par ladite clé cryptographique pour calculer le numéro propre à chaque appel, N°Id représente le numéro calculé propre à chaque appel associé à l'en-tête du Call-ID. Cette clé est archivée, stockée et protégée du côté de l'usager, principalement dans le terminal de celui-ci. Elle est ainsi secrète et connue par lui seul. Le procédé de la présente invention permet donc le calcul d'une valeur unique à chaque appel émis dont le déchiffrement sera seulement permis à l'usager qui est seul en possession de la clé qui a permis de chiffrer cette valeur, lui permettant ainsi de reconstituer l'en-tête de l'appel qu'il a initié et vérifier que cet appel lui est facturé à juste titre. Par N°Id est entendu le numéro calculé propre à chaque appel c'est à dire la valeur qui sera associée à l'en-tête Call-ID dans le procédé de la présente invention. Dans le mode de réalisation principal, les champs de l'en-tête définissant un appel dans un protocole standard de téléphonie pris en compte sont au moins un des champs parmi Via, From, To, Call-ID et Cseq. Dans le mode de réalisation principal, N°Id qui représente le numéro calculé propre à chaque appel est transcrit en un codage permettant sa lecture et son impression. Dans un mode de réalisation particulier, dans le cas où les valeurs associées aux données des champs de l'en-tête sont identiques pour deux appels ou sessions distincts, un nombre aléatoire est rajouté à n afin d'assurer un résultat unique pour le calcul cryptographique du N°Id représentant la valeur qui sera associée à l'en-tête Call-ID. Dans un mode particulier de ce mode de réalisation, ce nombre aléatoire n est concaténé à N°Id. Dans un autre mode de réalisation particulier, dans le cas où l'en-tête � Date � est présent ou tout autre en-tête garantissant une valeur unique pour un appel, la valeur associée à cette en-tête peut faire partie de n. Un des avantages du procédé de la présente invention est que le calcul cryptographique par 10 une clé uniquement connue de l'usager empêche toute prédiction du Call-ID et attaques inhérentes à cette prédiction. Un second objet de l'invention concerne les factures d'un opérateur de téléphonie obtenues à l'aide du procédé précédent, remarquables en ce qu'elles contiennent un numéro propre à 15 chaque appel émis et transmis par le terminal dudit usager, ledit numéro étant obtenu par l'application d'une clé cryptographique prenant en compte des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique étant uniquement connue et gérée par ledit usager, les données des champs de l'en-tête ayant été considérés pour ledit numéro étant obtenues par l'application 20 d'une clé cryptographique. Le déchiffrement de cette valeur contenue dans lesdites factures téléphoniques sera seulement possible par l'usager seul en possession de la clé qui a permis de chiffrer cette valeur et lui permettra de reconstituer l'en-tête de l'appel qu'il a initié et vérifier que cet appel lui est facturé à juste titre. 25 Un troisième objet de la présente invention concerne les terminaux IP qui permettent la mise en oeuvre du procédé de la présente invention. Par terminaux IP, on entend l'ensemble des types de terminaux IP qui initient ou reçoivent les requêtes tels que téléphones, hardphone, softphone, boîtier ATA, etc... Les exemples suivants accompagnés des dessins ci-annexés, le tout donné à titre d'exemple non limitatif, permettront de bien comprendre comment l'invention peut être réalisée. Dans les dessins : 30 - La figure 1 schématise une session d'appel classique entre deux UA (UA1, UA2) dans l'environnement SIP et une facture émise par l'opérateur qui en découle. - La figure 2 schématise une session d'appel entre deux UA (UA1, UA2) dans l'environnement SIP mettant en oeuvre le procédé de la présente invention permettant l'obtention et la transmission par le terminal de l'UA1 émettant l'appel, d'un numéro propre à l'appel obtenu par l'application d'une clé cryptographique ainsi que la facture découlant dudit procédé de l'invention sur laquelle figure le numéro N°Id propre à cet appel. - La figure 3 compare un type de facture classique (partie supérieure de la figure) avec une facture présentant des N°Id propres à chaque appel, émise lors de la mise en oeuvre du procédé de l'invention (partie inférieure de la figure). Dans les figures 1 et 2 commentées ci-après, les requêtes et réponses dans les étapes ST1 à ST3 constituent la transaction INVITE ; L'étape ST3 est l'étape à partir de laquelle il y a création du dialogue entre les deux usagers UA1 et UA2. L'étape ST5 est l'étape qui marque l'arrêt du dialogue ; les requêtes et réponses des étapes ST5 et ST6 constituent la transaction BYE. L'étape ST7 représente l'étape de facturation émise par l'opérateur 3. La figure 1 schématise une session d'appel avec différentes requêtes et réponses 4 entre deux UA 1 et 2 (UA1, UA2) dans l'environnement SIP, UA1 1 étant l'usager qui émet l'appel et une facture 5 émise par l'opérateur 3 en rapport avec cet appel. La figure 2 schématise la même hypothétique session d'appel dans l'environnement SIP avec différentes requêtes et réponses 4 mettant en oeuvre le procédé de l'invention. Dans cette session d'appel entre deux UA 1 et 2 (UA1, UA2), l'UA1 1 est l'usager qui émet l'appel. Par le procédé de la présente invention, une clé cryptographique 6 de type f (K, n) = N°Id prenant en compte dans cet exemple les différents champs de l'en-tête, Via = n1, From = n2, To = n3, Call-ID = n4 et CSeq = n5, permet au terminal de l'UA1 1 d'émettre et de transmettre un numéro N°Id 7 propre à cet appel. La clé cryptographique 6 est stockée et protégée dans le terminal de UA1 1. Le N°Id 7 est apposé par l'opérateur 3 sur la facture 5 concernant l'appel émis. Le N°Id 7 présent sur la facture reçue par l'UA1 1 permet à celui-ci, via son terminal 1, de retrouver l'en-tête général de son appel en décryptant N°Id 7 par la clé cryptographique 6 et vérifier ainsi que cet appel lui a été facturé à juste titre. Le champ supplémentaire correspondant à l'apposition des N°Id 7 dans les factures 5 5 émises lors de la mise en oeuvre du procédé de l'invention sont mis en évidence dans la figure 3. Le procédé de la présente invention préserve totalement les architectures et protocoles associés à l'environnement du protocole SIP. Cette solution a pour avantage de préserver 10 l'interopérabilité avec l'ensemble des implantations courantes de SIP et ne nécessite aucune modification des protocoles associés à l'architecture SIP. Le procédé de la présente invention s'applique à SIP mais peut être transposé sur d'autres architectures de téléphonie (GSM, H323,...). 15 20 Revendications: 1. Procédé permettant de vérifier les factures téléphoniques (5) émises par un opérateur concernant les appels facturés à un usager dans un protocole standard de téléphonie, caractérisé en ce qu'il comprend sur lesdites factures (5) dudit usager l'apposition d'un numéro propre (7) émis et transmis à chaque appel dudit usager par le terminal (1) dudit usager, ledit numéro (7) étant obtenu par l'application d'une clé cryptographique (6) prenant en compte tout ou partie des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique (6) étant uniquement connue et gérée par le terminal (1) dudit usager. 2. Procédé selon la revendication 1, caractérisé en ce que la clé cryptographique (6) est de type f (K, n) = N°Id dans laquelle : - K représente ladite clé cryptographique (6), - n représente tout ou partie des données des champs de l'en-tête prises en compte par ladite clé cryptographique (6) pour calculer le numéro propre à chaque appel, - N°Id représente le numéro calculé propre à chaque appel (7) associé à l'en-tête du Call-ID. 5. Procédé selon la revendication 2, caractérisé en ce que la clé cryptographique (6) est connue seulement par l'usager, archivée et protégée dans le terminal de l'usager (1). 6. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que les champs de l'en-tête définissant un appel dans un protocole standard de téléphonie pris en compte sont au moins un des champs parmi Via, From, To, Call-ID et Cseq. 7. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le numéro calculé propre N°Id (7) est transcrit en un codage permettant sa lecture et son impression. 830 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'un nombre aléatoire est rajouté à n afin d'assurer un résultat unique pour le calcul cryptographique de N°Id. 7. Procédé selon la revendication 6, caractérisé en ce que le nombre aléatoire n est concaténé à N°Id. 8. Procédé selon la revendication 1, caractérisé en ce que le protocole standard de téléphonie est le protocole SIP. 9. Facture téléphonique (5) concernant les appels facturés à un usager dans un protocole standard de téléphonie, caractérisée en ce qu'elle contient un numéro propre à chaque appel (7) émis et transmis par le terminal (1) dudit usager, ledit numéro (7) étant obtenu par l'application d'une clé cryptographique (6) prenant en compte tout ou partie des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique (6) étant uniquement connue et gérée par ledit usager, les données des champs de l'en-tête ayant été considérés pour ledit numéro (7) étant obtenues par l'application d'une clé cryptographique (6). 10. Terminal client IP (1) caractérisé en ce qu'il permet la mise en oeuvre du procédé selon les revendications 1 à 8.