WO2003043000A1 - Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques - Google Patents

Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques Download PDF

Info

Publication number
WO2003043000A1
WO2003043000A1 PCT/FR2001/003130 FR0103130W WO03043000A1 WO 2003043000 A1 WO2003043000 A1 WO 2003043000A1 FR 0103130 W FR0103130 W FR 0103130W WO 03043000 A1 WO03043000 A1 WO 03043000A1
Authority
WO
WIPO (PCT)
Prior art keywords
character
byte
alphabet
bytes
information
Prior art date
Application number
PCT/FR2001/003130
Other languages
English (en)
Inventor
Jacques Rivaillier
Original Assignee
Jacques Rivaillier
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 Jacques Rivaillier filed Critical Jacques Rivaillier
Priority to PCT/FR2001/003130 priority Critical patent/WO2003043000A1/fr
Priority to EP01976389A priority patent/EP1436810A1/fr
Publication of WO2003043000A1 publication Critical patent/WO2003043000A1/fr

Links

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor

Definitions

  • the invention relates to a method which makes it possible to mark, identify and secure the content of a computer file during its various transfers, transformations and representations.
  • To secure means here, to guarantee the integrity, the authenticity and possibly the confidentiality of the information.
  • File B often called "computer signature" of A, contains from a few dozen to a few hundred bytes. It often consists of a part intended for identification which explains external data such as the date, the place, the name of the author, an operation number ... Another part developed from the content of the file A allows its integrity to be checked, i.e. to guarantee that A's information is complete and error-free. Finally, a last one notably includes a random number and often a public key.
  • file B The content of file B is therefore unique and depends on that of file A. However, these two files must remain united. If B is lost or if an error affects B to a file other than A, the process has failed. This sometimes happens in IT since files like A and B are often physically separate.
  • the present invention remedies these defects by making it possible to keep the files A and B inseparable whatever their representations. It is based, in particular, on a process of transcription, coding and control of information which remains consistent from the bytes of the computer signature to the outputs on paper, video, sound or the development of chemical compounds, and allows then the exploitation of the "signature" at all stages of the application.
  • MT2S implements the principle of the alphabet generalized to the main types of representation of information.
  • each symbol is independent and carries contextual information specific to its implementation in the field or fields considered.
  • the basic set of these symbols or "compound characters" is called the canonical alphabet. This principle guarantees clarity and portability.
  • the MI2S process implements the principle of generalized use of alphabets by specializing and enriching them as and when they are processed.
  • Each character becomes an autonomous and versatile vehicle of intrinsic information (for example to the computer byte), on the one hand, and contextual to its use, on the other.
  • this process also supports the character of information concerning the group to which it belongs. This time it is the "collective" context. This role is filled (for example) by the last 2 bytes of the canonical character (see paragraph: composition of the canonical alphabet below).
  • the information necessary for the implementation of the byte in a given application is no longer added to the original file according to a protocol specific to each application software (closed mode), but integrated into each character allowing an open mode accessible to processing software and any interface.
  • the process first of all develops and uses a “canonical alphabet” which optimizes, simplifies and standardizes the descriptions of the different representations of the information with a view to implementing, ultimately, the basic elements of the domain considered; for example the pixels for the visual, the acoustic frequencies for the sound, the molecules for the chemical compounds.
  • the information is then "universally” usable despite the heterogeneous representations from its storage in memory to their final “representations”.
  • This alphabet allows, in particular, security software to complete the description of each character, mainly with directives, then to produce a C file (for example security) more complete than the previous B file (figure 1, right part).
  • MI2S Magnetic Ink-Semiconductor
  • This representation will take up more space in memory, but it will have the advantage of allowing a canonical representation: notion of universal formalism supporting an intrinsic value and the information necessary for its implementation whatever the field of application.
  • the byte can be described in turn by pixels within an image or acoustic frequencies in a recording or during a sound reproduction or by electromagnetic frequencies in a hertzian transmission or by molecules. organized within a chemical compound.
  • MI2S MI2S
  • Adaptation to the fields visual (paper documents, video ...), sound, touch, chemical ...
  • Adaptation to a field is carried out in 2 ways: o by a general configurable interface which directly uses the alphabet canonical (figure 3, plate 3), or o by a specialized but simplified interface at the peripheral level which uses the alphabet of the domain to which it belongs (figure 3, plate 3).
  • the C file can in practice be created without writing the B file.
  • this transformation performs a conversion of each grouping of information elements, for example the byte, into a canonical representation which takes into account the physical characteristics necessary for implementation in each field of application, and whose the whole in turn forms "the canonical alphabet".
  • This alphabet contains the same number of symbols or characters as the source set.
  • the canonical alphabet is a “universal” alphabet where each character is independent and contains all the information which will be necessary for the implementation of the corresponding characters, in particular, in the application alphabets dedicated to the various fields. It is also the “dedicated IT” alphabet.
  • the bytes of a "signature" used to guarantee the integrity, authenticity and confidentiality of an original file can be used at any time, whatever the means of representation (computer memory, network, medium paper, sound, touch, chemical compound ...) and can be automatically reintroduced in the machine from most of these representations, such as paper or sound ...
  • the element or character (compound) of the canonical alphabet of inlay comprises, for example, 12 bytes which are broken down as follows:
  • overlay characters can be placed anywhere in the file to be guaranteed (A) (as in Figure 1 part II) without necessarily respecting their place in the file they make up (for example the computer signature file) and which should be returned to the operator.
  • • 1 bit indicates whether the (compound) symbol or character codes pure information ranging from 0 to 255 or an index. This information is essential when using formatted data. • 1 bit gives the parity of the number of “black” Elementary Graphic Points (dots) of the byte which supports the proper value of the overlay character to increase security (in visual).
  • • 1 bit gives the parity of the number of “black” segments of the byte which supports, in visual) the proper value (0 to 255).
  • • 2 bits indicate the name of the application domain, data necessary for interfaces with the different domains.
  • 1 byte supports the actual information of the original byte (eigenvalue varying from lee 00 to 225555) V.
  • -1 byte supports additional or modifying data from the previous one, as a key for security, value extension, incrementation, tabulation, link, indexing or indirect addressing.
  • the first contains pure information, generally an address distributed over several bytes belonging to a group. For example an address distributed over several adjacent canonical characters.
  • the second mainly specifies the type of information of the previous byte, in the following way:
  • the 4 least significant bits code the reading order number of the previous byte, character by character, so as to reconstitute the address or addresses (for example) over several characters.
  • the security software composes the “signature” file B in terms of conventional (or conventional) bytes.
  • Each of these bytes is then converted into a compound character using a visual graphic representation which uses character fonts such as those of barcodes when possible, or better still those of byte codes, specially studied for this purpose. , like ECO or DOTE.
  • Software generally complex and which requires a particular font format (often specific to the application software, for example .ttf), will embed the file B within A, using one of the fonts mentioned above, in calculating their representations in pixels to make them compatible with the format of A.
  • MI2S Second case
  • the MI2S solution allows each canonical character to contain, in part or in whole, the data and directives which transmit and extend all the possibilities of security calculation software, on the one hand, and serve as a common and complete source, at the interfaces on the other hand.
  • a simplified interface could advantageously use existing symbologies, specially adapted to the visual field, such as certain graphic alphabets encoding 'byte (ECO, DOTE ...), to integrate them automatically in terms of pixels in mid printer file using the data and directives (context) contained in the characters made up of the canonical alphabet, without that it is necessary to use a "printing-type” font format.
  • the rules for building symbologies (ECO, DOTE, etc.) are sufficient. They can be used by any software and in particular the interfaces of specialized peripherals.
  • the interface adapts, as before, the pixels corresponding to the design and context of each character to include them in the final image to an output device: screen, video recorder, etc.
  • the interface prepares the final images in the same way as above and applies the protocol specific to the type of transmission chosen or it uses specialized software to which the final embedded images are passed as data.
  • Operating equipment for document security include “writing” devices (printing, engraving, etc. on different supports) implementing the preceding alphabets and “reading” devices made up of image sensors such as scanner, camera, pen scanner, fax, hand shower .. which transform the images of the documents into video signals. These electronic signals are sent to a processing unit which recognizes the symbols (composite characters represented using a defined symbology: ECO, DOTE ..., embedded in the general image) by recognition software suitable for the symbology. The security data thus extracted from the general image are available for the security processing proper.
  • Video signals are processed in the same way after extracting the pure video component from complex signals, such as those used in transmission for example.
  • Hz frequency frequency
  • * 1 byte completes the previous one with interpretation and assignment directives such as individual keys, value extensions, fabulations and addressing modifications, * 1 byte defines the frequency fl which corresponds to the zero bit, not 1 khz;
  • * 1 byte ensures the control of the character: - parities of the Graphic Points of the eigenvalue byte and the full character, parities of the number of segments of the eigenvalue byte and the full character; indication of the type of alphabet: normal or indexing; sound level of fl, £ 2, f3 relative to the average level of the encrusted area; bit always at "1" (weight 128) to indicate the end of the character.
  • the acoustic interface draws its information from the “canonical” file. If the final device is known, it will directly control the acoustic signals. Otherwise it will establish a new file expressed in a dedicated acoustic domain alphabet, that is to say in terms of frequencies. If the base is binary we have for example: First case (audible frequencies). 1. The 0 values of the character correspond to a frequency “fl” of 5 kHz over 10 periods
  • the values 1 of the character correspond to the same frequency “£ 2” of 8 kHz over 10 periods.
  • a third frequency “f3”, for example 10 kHz over 10 periods, makes it possible to create by composition (simultaneous transmission) with the previous two a series of 4 control signals as follows:
  • F3 fl + f2, inter-byte pulse for normal alphabet
  • the transmission times are referenced over a number of periods.
  • the composite duration corresponds to the shortest sound pulse. In the previous example, it is the pulse of 5 periods of 8 kHz.
  • the separation between bits corresponds to a silence long enough not to interfere with hearing, for example 20 ms.
  • the sequence is inaudible because it is generally cut by a low pass filter set to 50 Hz.
  • the coding expression speed is approximately 6 bytes per second, or approximately 15 seconds to use the security information.
  • the frequency f1 is 20 kHz (for example) and 10 periods.
  • the frequency f2 is 25 kHz (for example) and 10 periods.
  • the frequency f3 is increased for example to 30 kHz.
  • the speed at which the encrypted information is restored is around 100 bytes per second.
  • the security processing takes approximately 2 seconds from the start of an MES sequence.
  • the bytes thus coded by pulses of acoustic frequencies are grouped according to a particular format previously defined to allow a complete understanding of the message transmitted. This will result in a series of format definitions, at least one per domain. These formats also increase the efficiency of securing by allowing encryption of codes such as coded modification (whatever the formula) of the acoustic frequencies fl, £ 2 and f3, for example.
  • coded modification whatever the formula
  • code components and / or “markers” developed from elements of constitutive Bases, such as for example, elements of Thymine, Cytosine, Guanine, ... for DNA, preferably organized according to an architecture or a stack defined which can be supported by the characters of the MI2S alphabets.
  • a block is a set of elements belonging to the same Base.
  • the block is generally structured. It is defined, composition and structure, by a "chemical character”.
  • a segment consists of one or more blocks.
  • composition architecture can be defined block by block. These blocks, which correspond to characters in the “chemical” alphabet, make it possible to describe chemical compounds. It is useful to provide a “chemical” alphabet by specialty.
  • ⁇ 2 bytes to indicate the length of the block or segment and the sequence number corresponding to the segment it contains. * 3 bytes to specify where the elements of the block appear in the segment (fabulation) or the type of architecture corresponding to the segment; ⁇ 2 bytes to specify the order of the character in the definition message, ⁇ 1 byte for the control and end of character. Such a "chemical" character takes 11 bytes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Document Processing Apparatus (AREA)

Abstract

Le procédé MI2S permet de traiter et notamment de sécuriser les fichiers informatiques, les documents physiques, les sons et les composés chimiques, principalement par incrustation d'informations de type signatures informatiques, au moyen d'un alphabet "universel" dit "canonique" utilisé directement par une interface "universelle" ou par des interfaces propres à chaque périphérique utilisant un alphabet spécialisé à chaque domaine d'application et codant, par exemple, les 256 valeurs d'un octet. Les différents domaines ont chacun leur alphabet propre. L'alphabet canonique est également dédié à l'informatique. Il permet l'écriture du fichier informatique de sécurisation (comme la signature "informatique" et les données d'authentification) correspondant au fichier à sécuriser et dans lequel il sera incrusté pour rester indissociables ; il permet à une interface générale paramétrée de piloter l'ensemble des périphériques ; il sert de base à tous les autres alphabets dédiés utilisés par des interfaces simplifiées spécifiques pour sécuriser les informations correspondantes dans les différents domaines d'application. Un alphabet dédié acoustique est défini ainsi qu'un appareillage d'exploitation en temps réel. Un alphabet dédié chimie est également défini pour sécuriser les composés chimiques. Il existe, par ailleurs, plusieurs alphabets (ou police de caractères) pouvant coder l'octet pour les documents visuels, ECO, DOTE..

Description

Procédé pour marquer, identifier et sécuriser les fichiers informatiques, les documents, les sons et les composés chimiques
Présentation.
L'invention concerne un procédé qui permet de marquer, d'identifier et de sécuriser le contenu d'un fichier informatique lors de ses différents transferts, transformations et représentations. Sécuriser signifie ici, garantir l'intégrité, l'authenticité et éventuellement la confidentialité des infonnations.
On sait que l'on peut identifier et sécuriser un fichier donné A à l'aide d'un fichier B spécifique qui lui est associé. Le fichier B souvent appelé « signature informatique » de A, contient de quelques dizaines à quelques centaines d'octets. II se compose souvent d'une partie destinée à l'identification qui explicite les données extérieures comme la date, le lieu, le nom de l'auteur, un numéro d'opération... Une autre partie élaborée à partir du contenu du fichier A permet de contrôler son intégrité, c'est-à-dire garantir que les informations de A sont complètes et sans erreur. Enfin une dernière comprend notamment un nombre aléatoire et souvent une clé publique.
Le contenu du fichier B est donc unique et dépend de celui du fichier A. Toutefois ces deux fichiers doivent rester solidaires. Si B est perdu ou si une erreur affecte B à un autre fichier que A, le processus est en échec. Ceci se produit parfois en informatique puisque les fichiers comme A et B sont souvent physiquement disjoints.
Une méthode pour les rendre indissociables consiste à accoler ou mieux à « incruster », tel quel,, le fichier B au sein de A. Mais cette solution directe peut poser problème lors des transferts ou transformations telles les compressions qui comportent le risque de perte d'information, mais surtout lors de changement de domaine, comme le cas d'un fichier en ordinateur et son impression sur papier où les informations du fichier B ne pourront toutes être transposées, entraînant une perte notoire d'informations. Les applications sonores sont encore plus mal protégées.
La présente invention remédie à ces défauts en permettant de garder indissociables les fichiers A et B quelles que soient leurs représentations. Elle repose, notamment, sur un procédé de transcription, de codage et de contrôle de l'information qui demeure cohérente depuis les octets de la signature informatique jusqu'aux sorties sur papier, vidéo, sonore ou l'élaboration de composés chimiques, et permet ensuite l'exploitation de la « signature » à tous les stades de l'application.
Ce procédé appelé MT2S met en oeuvre le principe de l'alphabet généralisé aux principaux types de représentation de l'infonnation. Dans ce cas chaque symbole est indépendant et porteur des informations contextuelles propres à sa mise en oeuvre dans le ou les domaines considérés. L'ensemble de base regroupant ces symboles ou « caractères composés » est dit alphabet canonique. Ce principe est gage de clarté et de portabilité.
Remarque importante :
Le procédé MI2S met en oeuvre le principe d'usage généralisé des alphabets en les spécialisant et en les enrichissant au fur et à mesure des traitements. Chaque caractère devient un véhicule autonome et polyvalent des informations intrinsèque (par exemple à l'octet informatique), d'une part, et contextuelle à son utilisation, d'autre part.
Le cas échéant, ce procédé fait supporter également au caractère des informations concernant le groupe auquel il appartient. Il s'agit cette fois du contexte « collectif». Ce rôle est rempli (par exemple) par les 2 derniers octets du caractère canonique (voir paragraphe : composition de l'alphabet canonique ci-après). Les infonnations nécessaires à la mise en œuvre de l'octet dans une application donnée n'est plus ajoutée au fichier d'origine selon un protocole propre à chaque logiciel applicatif (mode fermé), mais intégré à chaque caractère pennettant un mode ouvert accessible aux logiciels de traitement et à toute interface.
Le procédé élabore et utilise en premier lieu un « alphabet canonique» qui optimise, simplifie et uniformise les descriptions des différentes représentations des informations en vue de la mise en oeuvre, in fine, des éléments de base du domaine considéré ; par exemple les pixels pour le visuel, les fréquences acoustiques pour le sonore, les molécules pour les composés chimiques. Les informations sont alors « universellement » exploitables malgré les représentations hétérogènes depuis leur stockage en mémoire jusqu'à leurs « représentations » finales.
Cet alphabet permet, notamment, aux logiciels de sécurisation de compléter la description de chaque caractère, principalement par des directives, puis de produire un fichier C (par exemple de sécurisation) plus complet que le fichier B précédent (figure 1, partie droite).
En effet, dans un ordinateur un octet est défini normalement en mémoire par 8 bits « électroniques ». Le procédé « MI2S » lui fait correspondre une autre représentation qui, en plus du contenu intrinsèque de cet octet, tient compte des caractéristiques physiques (ou contexte) du domaine d'application correspondant. Cette représentation est définie en mémoire, par un groupe d'octets, de façon à lui adjoindre les infonnations nécessaires aux diverses applications.
Cette représentation prendra plus de place en mémoire, mais elle aura l'avantage de permettre une représentation canonique : notion de formalisme universel supportant une valeur intiinsèque et les informations nécessaires à sa mise en oeuvre quel que soit le domaine d'application. Ainsi, l 'octet peut être décrit à son tour par des pixels au sein d'une image ou des fi'équences acoustiques dans un enregistrement ou lors d'une restitution sonore ou par des fréquences électromagnétiques dans une transmission hertzienne ou encore par des molécules organisées au sein d'un composé chimique.
Schématiquement le procédé « MI2S » élabore:
1. Une transformation des octets du fichier d'origine, en caractères d'un alphabet dit canonique qui s'enrichissent au fur et à mesure des traitements pour disposer des informations nécessaires aux opérations de juxtaposition ou d'incrustation dans leurs représentations au sein des différents domaines d'application.
2. Une adaptation aux domaines: visuel (documents papier, vidéo...), sonore, tactile, chimique... L'adaptation à un domaine est réalisée de 2 façons : o par une interface générale paramétrable qui utilise directement l'alphabet canonique (figure 3, planche 3), ou o par une interface spécialisée mais simplifiée au niveau du périphérique qui utilise l'alphabet du domaine auquel il appartient (figure 3, planche 3).
3. Des données et directives permettant l'exploitation, dans les différents domaines, des ensembles incrustés. Elles définissent, grâce aux alphabets dédiés, les correspondances entre les éléments d'mformation (exemple les bits) et les éléments physiques de représentation comme les Impulsions de Fréquences ou les Points Graphiques Elémentaires (dots) ou les Bases chimiques, et les appareillages d'exploitation correspondants.
Précision sur la mise en oeuvre des données de sécurisation exprimées à l'aide de l'alphabet canonique.
Au sein des fichiers informatiques, quel que soit le support physique (mémoire, réseau), les données de sécurisation gagnent à être indissociables du fichier qu'elles doivent sécuriser. En conséquence, dans un domaine précisé, les données qui lui sont spécifiques, sont extraites du fichier canonique par l'interface, et juxtaposées ( figure 1 partie III) ou mieux, incrustées au sein du fichier à sécuriser de deux façons : soit incrustées en 1 bloc homogène (figure 1, partie I en haut à droite),
* soit en incrustations multiples réparties dans le fichier sécurisé, caractère par caractère ou en petits groupes éparses (figure 1, partie II, représentés par des traits fins).
Remarque : Le fichier C peut être, en pratique, élaboré sans écrire le fichier B.
Transformation à l'aide de « l'alphabet canonique».
Comme vu précédemment, cette transformation réalise une conversion de chaque groupement d'éléments d'information, par exemple l'octet, en une représentation canonique qui tient compte des caractéristiques physiques nécessaires à la mise en œuvre dans chaque domaine d'application, et dont l'ensemble forme à son tour « l'alphabet canonique». Cet alphabet contient le même nombre de symboles ou caractères que l'ensemble source.
En effet, on peut considérer l'ensemble des octets qui peuvent prendre 256 valeurs différentes comme un alphabet de 256 symboles auxquels correspondent les 256 caractères composés de l'alphabet canonique. La structure générale de ces derniers est conçue pour permettre la traduction des informations de départ par une interface;, à l'aide des éléments de Base du domaine final (comme les Points Graphiques Elémentaires (dots), en visuel).
En résumé, l'alphabet canonique est un alphabet « universel » où chaque caractère est indépendant et renferme toutes les informations qui seront nécessaires aux mises en oeuvre des caractères correspondants, notamment, dans les alphabets applicatifs dédiés aux différents domaines. Il est également l'alphabet « dédié informatique ».
Une telle description des octets reste compatible avec tous les domaines de représentation. Par exemple : les octets d'une « signature » servant à garantir l'intégrité, l'authenticité et la confidentialité d'un fichier origine, restent exploitables à tout moment, quel que soit le moyen de représentation ( mémoire informatique, réseau, support papier, sonore, tactile, composé chimique...) et peuvent être automatiquement réintroduit en machine à partir de la plupart de ces représentations, comme le papier ou le son...
Il est également possible, le cas échéant, et à partir de l'alphabet canonique de construire un fichier intermédiaire dédié à un domaine particulier à l'aide de l'alphabet spécifique à ce domaine. L'interface du périphérique qui utilisera ce dernier fichier sera plus simple et plus rapide que celle exploitant directement l'alphabet canonique.
Composition recommandée de l'alphabet canonique.
Pour des raisons de commodité nous nous limiterons au cas de l'octet, mais le principe reste applicable à tout ensemble d'éléments binaires ou non.
Dans ce cas l'élément ou caractère (composé) de l'alphabet canonique d'incrustation comprend, par exemple, 12 octets qui se décomposent de la manière suivante :
-1 octet signale le début du caractère d'incrustation. Il peut être codé « échappement » (valeur 27 dans la table ASCII).
-2 octets indiquent le numéro d'ordre du caractère, c'est-à-dire sa position réelle dans l'ensemble qu'il sert à composer (exemple la position réelle dans le fichier C ). En effet les caractères d'incrustation peuvent être placés n'importe où dans le fichier à garantir (A) (comme en figure 1 partie II) sans respecter nécessairement leur place dans le fichier qu'ils composent (par exemple le fichier de signature informatique) et qu'il convient de restituer à l'exploitation.
-4 octets précisent le positionnement de l'incrustation au sein du fichier A. Il est recommandé 2 octets pour les X et 2 octets pour les Y, pour le visuel. Pour le domaine sonore ces octets codent le moment, la cadence et la durée d'exécution suivant les formats de composition des données. Les positions d'incrustation peuvent être gérées par le logiciel de sécurisation ou par l'interface. En chimie ces octets peuvent, par exemple, coder la concentration de marqueurs.
-1 octet de contrôle du caractère, détaillé comme suit :.
• 1 bit indique si le symbole ou caractère (composé) code une information pure allant de 0 à 255 ou un index. Ces informations sont indispensables lors de l'exploitation des données formatées . • 1 bit donne la parité du nombre de Points Graphiques Elémentaires (dots) « noirs » de l'octet qui supporte la valeur propre du caractère d'incrustation pour accroître la sécurité (en visuel).
• 1 bit donne la parité du nombre de segments « noirs » de l'octet qui supporte, en visuel) la valeur propre (0 à 255). • 2 bits indiquent le nom du domaine applicatif, donnée nécessaire aux interfaces avec les différents domaines.
• 3 bits précisent le mode d'incrustation : noir/blanc, multiniveaux, couleur pour le domaine visuel, niveau ou profondeur de modulation pour le domaine sonore, la concentration des marqueurs en chimie; et une bonne ou mauvaise exécution...
1 octet supporte rinformation proprement dite de l'octet d'origine (valeur propre variant d lee 00 à à 225555)V.
-1 octet supporte les données complémentaires ou modificatrices du précédent, comme une clé pour la sécurité, extension de valeur, incrémentation, tabulation, lien, indexation ou adressage indirect.
-2 octets de contrôle de l'enviromiement du caractère :
* Le premier contient rinformation pure, généralement une adresse répartie sur plusieurs octets appartenant à un groupe. Par exemple une adresse répartie sur plusieurs caractères canoniques adjacents. Le second précise principalement le type d'information de l'octet précédent, de la façon suivante :
- Les 4 bits de poids faibles codent le numéro d'ordre de lecture de l'octet précédent, caractère par caractère, de façon à reconstituer la ou les adresses (par exemple) sur plusieurs caractères.
-Le bit de poids le plus élevé (128) est toujours à « 1 » pour permettre de renforcer le contrôle de la fin de caractère puisqu' ainsi le dernier octet sera toujours supérieur à 128. Les 3 autres bits du demi-octet caractérisent le type d'information portée par l'octet précédent. Ces 3 bits peuvent coder 7 valeurs. Exemple :
1 : adresse de lien (application à la la traçabilité, notamment),
2 : adresse de tables de chiffrement et de description de contexte spécifique au domaine,
3 : adresses des éléments effacés par les traitements pour permettre de revenir en arrière,
4 : adresse d'une clé publique, 5 : adresse interdite : retour interdit.
6 .. 7 ...
JLes détails de réalisation sont définis dans les spécifications des formats des informations « signature » pour chaque domaine. En complément de l'exemple du début, où A était le fichier de départ à sécuriser et B le fichier signature, nous avons maintenant le ficliier C exprimé en caractères composés pour effectuer l'incrustation. Il reprend les informations de B et les complète au fur et à mesure du traitement des infonnations d'origine Sa capacité est 12 fois (pour le modèle décrit) celle de B, mais en assurant le contrôle de chaque caractère « canonique » indépendamment, il apporte une description canonique adaptable à tous les domaines et les connaissances telles que : la position d'incrustation, qui permet de le placer n'importe où dans l'Ensemble à sécuriser pour assurer discrétion et esthétique ;
* l'ordre dans le fichier signature; le contrôle de la valeur de l'octet d'information (valeur propre : 0 à 255) à l'aide de parités et du nombre o segments spécifique,
* les modifications dynamiques de la valeur propre ou de modification d'affectation : comme les entités de codage ou de chiffrement, liens, adresse de fabulation ;
* la conservation de l'information avant incrustation, pour permettre un retour vers l'origine ;
* le type d'incrustation ;
* l'état de l'incrustation et la possibilité de bloquer le processus de retour.
+ le codage de mots très longs en utilisant 1 octet par caractère d'incrustation et permettant de coder une référence, des adresses de tables par exemple, ou un lien fort utile dans le chaînage d'opérations comme en traçabilité.
DESCRIPTION DES UTILISATIONS DU FICHIER CANONIQUE
ET DES PRINCIPALES INTERFACES « MI2S » ADAPTÉES À CHAQUE DOMAINE.
1 - Application au domaine visuel.
Considérons à nouveau le cas d'un fichier informatique A sécurisé à l'aide d'un fichier signature B, lui-même élaboré par un logiciel spécifique en vue de l'incrustation dans A et de sa représentation dans le domaine visuel. Deux cas peuvent s'envisager.
Premier cas (classique) :
- Le logiciel de sécurisation compose le fichier « signature » B en termes d'octets conventionnels (ou classiques).
- Chacun de ces octets est ensuite converti en caractère composé utilisant une représentation graphique visuelle qui fait appel à des polices de caractères comme celles des codes-barres quand c'est possible, ou mieux celles des codes d'octets, spécialement étudiés à cet effet, comme ECO ou DOTE. Un logiciel, généralement complexe et qui exige un format particulier de police (souvent propre au logiciel d'application, par exemple .ttf), incrustera le fichier B au sein de A, à l'aide d'une des polices précédemment citées, en calculant leurs représentations en pixels pour les rendre compatibles avec le format de A.
Des imperfections apparaissent avec cette méthode. Notamment, les « directives » issues des traitements des signatures ne peuvent être transmises directement. Leur absence réduit l'efficacité, rend précaire l'automatisation du processus et réduit la portabilité de l'ensemble. Second cas (MI2S):
La solution MI2S pennet à chaque caractère canonique de contenir, en partie ou en totalité, les données et directives qui transmettent et prolongent toutes les possibilités des logiciels de calcul de sécurisation, d'une part, et servent de source commune et complète, aux interfaces spécialisées des différents domaines, d'autre part. Ainsi dans le domaine visuel, pour élaborer in fine un document sécurisé papier (par exemple) à partir d'im « fichier canonique », une interface simplifiée pourra avantageusement utiliser les symbologies existantes, spécialement adaptées au domaine visuel, comme certains alphabet graphiques codant l'octet (ECO, DOTE ...), pour les intégrer automatiquement en termes de pixels à mi fichier d'imprimante à l'aide des données et directives (contexte) contenues dans les caractères composés de l'alphabet canonique, sans qu'il soit nécessaire d'utiliser un format de police de caractères « de type imprimerie ». Les règles de construction des symbologies (ECO, DOTE ..) suffisent. Elles sont exploitables par tout logiciel et notamment les interfaces de périphériques spécialisés.
Exemple : les positions des Points Graphiques Elémentaires (dots) des caractères à incruster peuvent être calculées directement dans l'interface à destination de l'imprimante. Il en serait de même pour un autre type de périphérique. Pour la restitution d'images sous forme vidéo, l'interface adapte, comme précédemment, les pixels correspondants au dessin et au contexte de chaque caractère pour les inclure dans l'image finale vers un périphérique de sortie : écran, enregistreur vidéo...
Dans le cas de transmission d'images, l'interface élabore les images finales de la même façon que précédemment et applique le protocole propre au type de transmission choisi ou elle fait appel à un logiciel spécialisé auquel les images incrustées finales sont passées comme données.
Appareillages d'exploitation de la sécurisation des documents. Us comprennent les appareils « d'écriture » (d'impression, de gravure... sur différents supports) mettant en œuvre les alphabets précédents et les appareils de « lecture » constitués de capteurs d'images tels que scanner, caméra, styloscanner, fax, douchette.. qui transforment les images des documents en signal vidéo. Ces signaux électroniques sont dirigés vers une unité de traitement qui reconnaît les symboles (caractères composés représentés à l'aide d'une symbologie définie : ECO, DOTE ..., incrustés dans l'image générale) par un logiciel de reconnaissance approprié à la symbologie. Les données de sécurisation ainsi extraites de l'image générale sont disponibles pour les traitements de sécurisation proprement dits.
L'exploitation des signaux vidéo se pratique de la même façon après avoir extrait la composante vidéo pure des signaux complex, comme ceux utilisés en transmission par exemple.
Remarque :
Il est possible d'identifier et de sécuriser en temps réel les images fixes ou vidéo, par lecture directe du signal vidéo comme en entrée d'écran ou en sortie de caméra. Il convient qu'au préalable les images aient été « incrustées » selon le procédé MI2S avec les informations nécessaires à la sécurisation.
2- Application au domaine Acoustique.
Remarque :
On forme des « Impulsions sonores » dans le domaine acoustique qui correspondent aux « Points Graphiques Elémentaires » du domaine visuel.
Au niveau exécution, les uns sont exprimés en tenne de fréquence (Hz), les autres en terme de pixels.
Toutefois, dans ce domaine il n'existe pas à proprement parler d'alphabet Acoustique ou sonore applicable à un tel procédé. Il convient d'en définir un qui établit la correspondance entre les caractères canoniques d'incrustation et le signal acoustique. Il est nécessairement de nature temporelle. Nous présentons un exemple de composition comme suit : 1 octet début de caractère initialisé de préférence à 27 (caractère escape) ; * 1 octet précise le domaine, le type d'alphabet et ses caractéristiques spécifiques ;
* 1 octet porte la valeur propre, dans le cas d'un octet de 0 à 255 ;
* 1 octet complète le précédent par des directives d'interprétation et d'affectation comme les clés individuelles, les extensions de valeur, les fabulations et modificatifs d'adressage, * 1 octet définit la fréquence fl qui correspond au bit zéro, pas de 1 khz ;
* 1 octet définit la fréquence f2 qui correspond au bit un, pas de 1 khz
* 1 octet définit la fréquence f3 qui correspond à la séparation entre bits et octets, pas de 1 khz ;
* 1 octet contrôle la séquence de l'octet :
4 bits pour le nombre de périodes des impulsions construites avec fl, f2, f3 ; - 4 bits pour quantifier les intervalles entre fréquences ou séparateurs interbits, notamment la durée des zones de silence ; 1 octet précise le contexte de l'incrustation dans le message sonore à sécuriser : nombre de séquences complètes, position dans le message (en début, milieu, fin ou continu) ;
* 1 octet assure le contrôle du caractère : - parités des Points Graphiques de l'octet valeur propre et du caractère complet, parités du nombre de segments de l'octet valeur propre et du caractère complet ; indication du type d'alphabet : normal ou d'indexation ; niveau sonore de fl, £2, f3 par rapport au niveau moyen de la zone incrustée ; bit toujours à « 1 » ( poids 128) pour indiquer la fin du caractère.
Soit im caractère décrit sur 10 octets.
En pratique, il est utile de prévoir 2 gammes de correspondance, l'une dans le spectre audible et l'autre dans les ultrasons. L'interface acoustique puise ses informations dans le fichier « canonique ». Si le périphérique final est connu, elle pilotera directement les signaux acoustique. Dans le cas contraire elle établira un nouveau ficliier exprimé en alphabet dédié domaine acoustique, c'est-à-dire en terme de fréquences. Si la base est binaire nous avons par exemple : Premier cas ( fréquences audibles). 1. Les valeurs 0 du caractère correspondent à une fréquence « fl » de 5 khz sur 10 périodes
(par exemple),
2. Les valeurs 1 du caractère correspondent à mie fréquence « £2 » de 8 khz sur 10 périodes.
3. Une troisième fréquence « f3 », par exemple 10 khz sur 10 périodes, permet de créer par composition (émission simultanée) avec les deux précédentes une série de 4 signaux de commande comme suit :
Fl = f2 + B, impulsion inter-bit 0 après un « 0 » logique ;
F2 = fl + f3, impulsion inter-bit 1 après un « 1 » logique ;
F3 = fl + f2, impulsion inter-octet pour alphabet normal ;
- F4 = fl + f2 + f3, impulsion inter-octet pour alphabet d'index. Les amplitudes respectives gagnent à être adaptées aux périphériques finaux pour être restitués d'égale amplitude.
Les durées d'émission sont référencées sur un nombre de périodes. La durée composite correspond à l'impulsion sonore la plus courte. Dans l'exemple précédent, il s'agit de l'impulsion de 5 périodes de 8 khz.
La séparation entre bits correspond à un silence assez long pour ne pas gêner l'audition, exemple 20 ms. La séquence est inaudible car elle est généralement coupée par un filtre passe bas réglé sur 50 hz.
Exemple : Si la valeur propre du caractère est en binaire : 1 1 0 0 1 0 1 0 S
Avec le symbole "_" correspondant à un silence de 20 ms, un bit de parité ci-après en gras et l'impulsion F3 indiquant qu'il s'agit d'un caractère normal. (L'impulsion F4 à la place de F3 qualifierait un caractère d'index.) Sa correspondance sonore sera :
F3J2 F2_f2 F2_fl Fl_fl F1JE2 F2_fl Fl_£2 F2_fl Fl_f2 F2_E?
La vitesse d'expression du codage est d'environ 6 octets par seconde, soit environ 15 secondes pour exploiter les informations de sécurisation..
Second cas (ultrasons).
Ces fréquences sont surtout destinées aux enregistrements ou la bande passante apparente est suffisante. La fréquence fl est de 20 khz (par exemple) et 10 périodes. La fréquence f2 est de 25 khz (par exemple) et 10 périodes.
+ La fréquence f3 est portée par exemple à 30 khz.
La vitesse de restitution de l'information incrustée est de l'ordre de 100 octets par seconde. Les traitements de sécurisation durent environ 2 secondes à partir du début d'une séquence MES.
Remarque générale : FORMATS.
Les octets ainsi codés par des impulsions de fréquences acoustiques, sont groupés selon un format particulier préalablement défini pour permettre une compréhension complète du message transmis. Ceci donnera lieu à une série de définitions de formats, au moins un par domaine. Ces formats augmentent également l'efficacité de la sécurisation en permettant un chiffrement des codes comme la modification codée ( quelle qu'en soit la formule) des fréquences acoustiques fl, £2 et f3, par exemple En conclusion, ce procédé permet de sécuriser dynamiquement les enregistrements audio ou les émissions sonores par codage MI2S et l'exploitation du son en temps réel par un appareillage adapté. Il est alors possible de détecter en transmission, à la lecture comme à l'audition, les informations qualifiant l'origine et les données commerciales d'un signal sonore.
3 Application au domaine chimique.
Le principe consiste à. coder des composants et/ou des « marqueurs » élaborés à partir d'éléments de Bases constitutives, comme par exemple, les éléments de Thymine, Cytosine, Guanine,... pour l'ADN, organisés de préférence suivant une architecture ou un empilement définis qui peuvent être supportés par les caractères des alphabets MI2S.
Un bloc est un ensemble d'éléments appartenant à une même Base. Le bloc est généralement structuré. Il est définit, composition et structure, par un « caractère chimique ». Un segment est constitué d'un ou de plusieurs blocs.
Les éléments gagnent à être regroupés Base par Base et leur architecture de composition correspondante peuvent être définies bloc par bloc. Ces blocs qui correspondent à des caractères de l'alphabet « chimique » permettent de décrire des composés chimiques. II est utile de prévoir un alphabet « chimique » par spécialité.
Pour certains composés chimiques, en absence de constitution géométrique définie, il est utile de compléter chaque caractère par un numéro d'ordre qui spécifie son rang dans le message de constitution. Ces infonnations sont présentes dans les caractères canoniques pour définir l'endroit d'incrustation par exemple ; elles sont obligatoires dans le cas présent pour reconstituer l'ordre du a « m mKeusssnagope \ »s H d''norriigo-iinnpe» En conséquence l'alphabet « chimique » peut être associatif, c'est-à-dire que les caractères qui composent une description de marqueur, par exemple, pourront être mémorisés dans le désordre. Un caractère « cliimique » désigne les éléments d'une Base et leur organisation ou architecture dans un « bloc » précisé. C'est l'assemblage des éléments des Bases constitutives au sein des blocs, caractère par caractère, qui pennet, par exemple, de définir un composé cliimique ou un marqueur. Les caractères de l'alphabet «cliimique » peuvent se composer comme suit : * 1 octet début de caractère initialisé à 27 (escape).
Φ 1 octet pour préciser le domaine applicatif et les contraintes spécifiques ; Φ 1 octet pour coder la « Base » supportée par ce caractère,
Φ 2 octets pour indiquer la longueur du bloc ou du segment et le numéro d'ordre correspondant au segment qu'il le contient. * 3 octets pour spécifier où les éléments du bloc apparaissent dans le segment (fabulation) ou le type d'architecture correspondant au segment; Φ 2 octets pour préciser l'ordre du caractère dans le message de définition, Φ 1 octet pour le contrôle et fin de caractère. Un tel caractère « chimique » prend 11 octets. Exemple :
Dans le cas d'une structure à 5 bases, 5 caractères associés à une table de description peuvent suffire pour décrire un marqueur simple d'un segment de 65000 éléments.

Claims

REVENDICATIONS
1- Principe et Procédé pour marquer, identifier et sécuriser les ensembles d'informations tels que les fichiers infonnatiques, les documents physiques, les sons et les composés chimiques, caractérisé en ce que : les données nécessaires au contrôle de leur marquage, de leur intégrité et de leur authenticité dans les différents modes de représentation, sont juxtaposées ou incrustées au sein de ces ensembles d'informations au moyen d'alphabets de symboles indépendants ou caractères composés qui codent une valeur intrinsèque et des informations contextuelles aux applications et à des traitements ultérieurs. Ces infonnations ainsi que leurs représentations physiques finales sont actualisées au cours des traitements qu'ils subissent.
Ces alphabets sont spécifiques à chaque domaine tel que l'informatique, le visuel, l'acoustique et le chimique. Us ont le même nombre de caractères composés défini par leur capacité de codage. Chaque caractère composé possède im correspondant dans les alphabets dédiés aux autres domaines. Ce procédé est optimisé par des appareillages d'application.
2- Procédé selon la revendication précédente, caractérisé en ce que l'ensemble des informations à sécuriser est exprimé à l'aide d'octets. La correspondance entre composants d'alphabets différents s'établit en fonction de leur valeur propre. Dans le cas de l'octet cette valeur peut varier de 0 à 255 ; il y a dans ce cas 256 caractères composés par alphabet.
3- Procédé selon les revendications précédentes, caractérisé en ce qu'un des alphabets précités, dit canonique, est spécialement élaboré pour servir de source de données actualisées de référence. Chacun de ses caractères mémorise les informations nécessaires à la mise en oeuvre des caractères correspondants des autres alphabets. H s'agit, pour chaque caractère canonique, de sa valeur propre et des valeurs caractérisant ses environnements et les directives de mise en oeuvre dans les différents domaines. Quand la valeur propre est codée par un octet, l'alphabet canonique est utilisé comme alphabet dédié à l'informatique où il sert à composer le fichier de sécurisation pour le rendre solidaire du fichier à sécuriser, par juxtaposition ou incrustation au sein de ce dernier. 4- Procédé selon les revendications précédentes, caractérisé en ce que l'alphabet canonique est supporté par des moyens informatiques et comme tel, il est décrit de la façon suivante :
• 1 octet caractérise le début du caractère. Il porte avantageusement la valeur 27 (escape)
• 2 octets précisent l'emplacement du caractère dans le « fichier signature » en vue de son incrustation ou de sa juxtaposition dans l'ensemble d'informations à sécuriser. « 4 octets précisent l'emplacement du caractère au sein de l'ensemble d'informations à sécuriser.
• 1 octet est affecté aux infonnations de contrôle du caractère et du type d'alphabet : parités, alphabet normal ou d'index.
• 1 octet supporte l'information intrinsèque du caractère ou valeur propre.
• 2 octets mémorisent les éléments de contrôle de l'environnement du caractère dont le premier est l'information elle-même, et le second précise son type, comme : l'adresse où est mémorisée l'information effacée lors de l'incrustation, l'adresse de lien vers les opérations précédentes, l'adresses de tabulation pour les données de cliiffrement et le contexte lié au domaine. Il code également la fin du caractère.
5- Procédé selon les revendications précédentes, caractérisé en ce que les informations incrustées sont réparties au sein du document à sécuriser dans un ordre quelconque.
6- Procédé selon les revendications précédentes, caractérisé en ce que l'alphabet dédié au domaine acoustique est construit pour permettre la mise en oeuvre de 3 fréquences différentes et des 4 combinaisons qu'elles permettent et qui servent à valider les bits et les octets. La description d'un caractère est la suivante :
• 1 octet signale le début du caractère, il est initialisé à 27 (escape) ;
• 1 octet précise le domaine d'application et les contraintes particulières ; • 1 octet code la valeur propre du caractère ; 1 octet donne la valeur de la fréquence f 1 qui correspond au « zéro » logique, en khz ;
1 octet donne la valeur de la fréquence f2 qui correspond au « un » logique, en khz ;
1 octet fournit la valeur de la fréquence f3 qui correspond à la séparation entre octets, en khz ;
1 octet contrôle la séquence de l'octet dont le nombre de périodes et durée des zones de silence ;
1 octet définit le contexte : nombre de séquences et position dans le signal acoustique ;
1 octet contrôle le caractère : parités de la valeur propre et du caractère complet, alphabet normal ou d'index, amplitude, fin de caractère.
7- Procédé selon la revendication précédente, caractérisé en ce que la première famille de fréquences correspond au spectre audible avec les durées de silence portées à 20 millisecondes et la seconde famille correspond à des fréquences ultrasonores.
8- Procédé selon les revendications précédentes, caractérisé en ce que l'appareillage (figure 2) qui permet d'exploiter des séquences sonores et ultrasonores, extrait et recompose les octets incrustés dans le signal acoustique à l'aide d'un microphone (1), si nécessaire, et d'un amplificateur (2) suivi d'un jeu de filtres (3) analogiques ou numériques, centrés chacun sur une des fréquences fl (voie I), f2, (voie II) et β (voie III)., Ces trois filtres, constituant 3 voies semblables, sont suivis chacun de détecteurs (ou redresseurs) (4), d'intégrateurs (5) à faible constante de temps (0,5 période) et d'un seuillage par comparateur (6) qui transforme les signaux acoustiques en « 0 » ou « 1 ». Ces signaux sont injectés dans un registre à décalage de 9 positions (15) par l'intermédiaire de circuits logiques dont 4 portes « ET » (7, 8, 9, 10) qui extraient respectivement les combinaisons d'impulsions de fréquences : F4=fl+f2+β, F3=fl+f2, F2=fl+β, Fl=f2+β. La bascule (11) et les portes « ET » (12) valident fl par Fl pour le « 0 » logique ou £2 par F2 pour le « 1 » qui sont injectés à l'entrée de (15). L'horloge de décalage des bits est la sortie de (9) OU de (10) et l'horloge de sortie de l'octet et de sa parité est F3 en sortie de (8). Les sorties des octets et de la parité (16) et de F4 (porte 7) sont reliées à un processeur pour exploiter les octets de code et les formats associés au domaine
9- Procédé selon l'une des revendications précédentes, caractérisé en ce qu'un composé chimique est décrit au moyen d'un alphabet dont chaque caractère est lui-même décrit par un jeu d'octets précisant sa nature et sa mise en oeuvre. Chaque caractère possède, au moins, un numéro d'ordre définissant sa place dans le message.
10- Procédé selon l'une des revendications précédentes, caractérisé en ce que le composé chimique à sécuriser contient des composants et/ou marqueurs spécifiques décrits par im ou plusieurs blocs constitués par des ensembles d'éléments de différentes Bases d'éléments constitutifs. Chaque caractère est associée à une Base. Il définit la composition, la structure et la loi d'incrustation des éléments de la Base au sein du bloc. Un bloc est défini par , au moins, autant de caractères « chimiques » qu'il contient de Bases constitutives différentes. Un segment est composé d'au moins un bloc. Le caractère de l'alphabet « cliimique » est de description suivante :
• 1 octet pour désigner le début de caractère initialisé à une valeur convenue comme 27 ;
• 1 octet pour coder le domaine et les particularités de l'application ;
• 2 octets pour coder le nom de la Base cliimique que représente le caractère ;
• 2 octets pour indiquer le numéro d'ordre du bloc dans le segment et le type de segment ; • 2 octets pour préciser le type d'architecture du bloc pour la Base précisée ;
• 2 octets pour mentionner le numéro d'ordre du caractère dans le message de constitution.
• 1 octet pour assurer le contrôle du caractère et indiquer la fin du caractère.
Figure imgf000013_0001
PCT/FR2001/003130 2001-10-10 2001-10-10 Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques WO2003043000A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/FR2001/003130 WO2003043000A1 (fr) 2001-10-10 2001-10-10 Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques
EP01976389A EP1436810A1 (fr) 2001-10-10 2001-10-10 Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FR2001/003130 WO2003043000A1 (fr) 2001-10-10 2001-10-10 Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques

Publications (1)

Publication Number Publication Date
WO2003043000A1 true WO2003043000A1 (fr) 2003-05-22

Family

ID=8860865

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/003130 WO2003043000A1 (fr) 2001-10-10 2001-10-10 Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques

Country Status (2)

Country Link
EP (1) EP1436810A1 (fr)
WO (1) WO2003043000A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7878413B2 (en) 2005-02-16 2011-02-01 Alphacode Method for the dual coding of information on physical media and in a computerized format (DOTEM)
US8256687B2 (en) 2005-02-16 2012-09-04 Alphacode Method of coding information in a dual fashion on physical media and in DOTEM computerised form

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0464352A2 (fr) * 1990-06-25 1992-01-08 International Business Machines Corporation Architecture d'interface de sous-point d'entrée pour la gestion de modifications dans un réseau d'ordinateurs
GB2291522A (en) * 1994-07-15 1996-01-24 Thorn Secure Science Ltd Authentication technique
EP0829810A1 (fr) * 1995-03-17 1998-03-18 Kureha Kagaku Kogyo Kabushiki Kaisha Processeur, methode de traitement et support d'enregistrement d'informations biochimiques
US6273340B1 (en) * 1997-09-30 2001-08-14 Centre National De La Recherche Scientifique Coding method, coding equipment and resulting coded product
FR2806200A1 (fr) * 2000-03-10 2001-09-14 Jacques Rivaillier Dispositif permettant et garantissant le processus de tracabilite d'un objet ou d'un produit
US20010042206A1 (en) * 2000-05-12 2001-11-15 International Business Machines Corporation Of Armonk System and method of uniquely authenticating each replication of a group of soft-copy documents

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0464352A2 (fr) * 1990-06-25 1992-01-08 International Business Machines Corporation Architecture d'interface de sous-point d'entrée pour la gestion de modifications dans un réseau d'ordinateurs
GB2291522A (en) * 1994-07-15 1996-01-24 Thorn Secure Science Ltd Authentication technique
EP0829810A1 (fr) * 1995-03-17 1998-03-18 Kureha Kagaku Kogyo Kabushiki Kaisha Processeur, methode de traitement et support d'enregistrement d'informations biochimiques
US6273340B1 (en) * 1997-09-30 2001-08-14 Centre National De La Recherche Scientifique Coding method, coding equipment and resulting coded product
FR2806200A1 (fr) * 2000-03-10 2001-09-14 Jacques Rivaillier Dispositif permettant et garantissant le processus de tracabilite d'un objet ou d'un produit
US20010042206A1 (en) * 2000-05-12 2001-11-15 International Business Machines Corporation Of Armonk System and method of uniquely authenticating each replication of a group of soft-copy documents

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZENG W ET AL: "STATISTICAL WATERMARK DETECTION TECHNIQUE WITHOUT USING ORIGINAL IMAGES FOR RESOLVING RIGHTFUL OWNERSHIPS OF DIGITAL IMAGES", IEEE TRANSACTIONS ON IMAGE PROCESSING, IEEE INC. NEW YORK, US, vol. 8, no. 11, November 1999 (1999-11-01), pages 1534 - 1548, XP000862788, ISSN: 1057-7149 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7878413B2 (en) 2005-02-16 2011-02-01 Alphacode Method for the dual coding of information on physical media and in a computerized format (DOTEM)
US8256687B2 (en) 2005-02-16 2012-09-04 Alphacode Method of coding information in a dual fashion on physical media and in DOTEM computerised form

Also Published As

Publication number Publication date
EP1436810A1 (fr) 2004-07-14

Similar Documents

Publication Publication Date Title
Sellars An introduction to steganography
EP0178232B1 (fr) Document d'identité difficilement falsifiable et procédé de fabrication d'un tel document
Dutta et al. An overview of digital audio steganography
Bender et al. Techniques for data hiding
Kekre et al. Information hiding in audio signals
Hakak et al. Preserving content integrity of digital holy Quran: Survey and open challenges
Al-Othmani et al. A survey on steganography techniques in real time audio signals and evaluation
JP2003264685A (ja) 文書画像出力方法及び装置、改ざん判定方法及びシステム、並びに改ざん判定システムの制御用プログラム
Moon et al. Data security using data hiding
US6564322B1 (en) Method and apparatus for watermarking with no perceptible trace
WO2014005966A1 (fr) Procede de tatouage de livres numeriques
EP4181106A1 (fr) Système de gestion de données
EP1880348A1 (fr) Procede de codage de l'information de facon duale sur supports physiques et sous forme informatique dotem
Gutub Integrity verification of Holy Quran verses recitation via incomplete watermarking authentication
RU2001113515A (ru) Способ копирования, устраняющий возможность побитного копирования цифровых данных и считывающее устройство для его осуществления
JP2012523579A (ja) 混合信号を形成する方法及び装置、信号を分離する方法及び装置、並びに対応する信号
WO2003043000A1 (fr) Procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sons et les composes chimiques
Singh et al. Enhancement of LSB based steganography for hiding image in audio
FR2815155A1 (fr) Principe et procede pour marquer, identifier et securiser les fichiers informatiques, les documents, les sous, les composes chimiques et appareillages de mise en oeuvre
Bhattacharyya et al. A method of data hiding in audio signal
Backes et al. Information flow in the peer-reviewing process
Pareek et al. An Overview of Steganography: Data Hiding Technique
Aboelezz Watermarking audio files with copyrights
Lai et al. Android Audio Recorder Mobile Application with Digital Watermarking
CN117476019A (zh) 音频数据处理方法、装置、设备及存储介质

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2001976389

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001976389

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP