WO2003014888A1 - Procede de securisation de bases de donnees - Google Patents

Procede de securisation de bases de donnees Download PDF

Info

Publication number
WO2003014888A1
WO2003014888A1 PCT/FR2002/002824 FR0202824W WO03014888A1 WO 2003014888 A1 WO2003014888 A1 WO 2003014888A1 FR 0202824 W FR0202824 W FR 0202824W WO 03014888 A1 WO03014888 A1 WO 03014888A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
database
data
request
secure
Prior art date
Application number
PCT/FR2002/002824
Other languages
English (en)
Inventor
Philippe Pucheral
Luc Bouganim
Original Assignee
Centre National De La Recherche Scientifique - Cnrs -
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 Centre National De La Recherche Scientifique - Cnrs - filed Critical Centre National De La Recherche Scientifique - Cnrs -
Priority to EP20020779619 priority Critical patent/EP1415215A1/fr
Priority to US10/485,785 priority patent/US20050044366A1/en
Publication of WO2003014888A1 publication Critical patent/WO2003014888A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption

Definitions

  • the present invention relates to the field of secure information systems, and more particularly to systems and methods for securing databases.
  • the problem is not limited to protecting oneself against external hackers entering the attacked computer system.
  • internal attacks that is, attacks by employees with legal access to all or part of a company's data, are the most frequent and the most expensive.
  • the external hacker is an intruder who infiltrates a computer system and retrieves the data files produced by the DBMS.
  • a natural solution is to encrypt data in order to make their disk imprint unreadable.
  • the external hacker will then try to break the encryption key. Attacks on keys are facilitated in a database context due to the large volume of data encrypted with the same key (statistical attacks).
  • data encryption is static (the keys do not change from one session to another), thereby increasing the vulnerability of the database.
  • the user pirate is a current user of the computer system recognized by the operating system and the DBMS. He has rights to part of a shared database and wants to access data beyond his rights. This pirate potentially has the same power as an external pirate and can also exploit his restricted rights. If the database is encrypted, it also has access to certain decryption keys.
  • the administrator or DBA hacker is an unscrupulous employee of the company whose function is to administer the computer resources of the company or the database (DBA: Data Base Administrator). As such, it has all the system rights, it has information inaccessible to any other (ex: logs memorizing the operations carried out on the base) and can spy on the behavior of the DBMS during its execution. Note that an external hacker or user who manages to grant himself administrative rights has the same powers as the administrator hacker.
  • DBMS database management system
  • Authentication is typically done using a password stored encrypted in a DBMS catalog, the latter checking the correspondence between the user's identity and password on each new connection.
  • the authentication procedure can be reinforced by the use of a dedicated service [Oracle Advanced Security Administrator Guide, Release 8.1.7, September 2000]. This dedicated service avoids the clear passage of the password on the network.
  • a variant is known which makes it possible to authenticate a user by various means such as a smart card or TokenCard.
  • PIN personal code
  • the card hardware element In addition to authentication by a personal code (PIN), the card hardware element must itself be recognized by the server, thereby increasing the degree of security.
  • DBMS DBMS
  • the rights relating to the data can be assigned to the users, either on the basic tables (one thus obtains a primitive management of rights close to that offered by a operating system), either on views (virtual tables calculated by an SQL query), or on stored procedures (the right then relates to the triggering of a processing).
  • These last two cases allow sophisticated and very selective rights management.
  • this management of rights is ineffective against an attack directed against the files containing the database (the DBMS is again short-circuited) or against an attack carried out by a DBA (because it has all the rights, including the right to change the rights).
  • Another solution is based on encryption of communications.
  • Communication encryption can be used in addition to other security mechanisms, in particular to ensure the confidentiality and integrity of messages sent and received over a network. Their use goes far beyond the framework of databases.
  • SSL Secure Soket Layer
  • C-SET Chip-Secured Transaction
  • C-SET Chip-Secured Transaction
  • encryption of communications does not protect against an attack on the files containing the database.
  • the company Oracle offers a PL / SQL package (set of stored procedures) allowing to perform secret key encryption DES (Data Encryption Standard) [Oracle Technical White Paper. Database Security in Oracle 8i, November 1999].
  • the key to encryption must be passed as a parameter to the PL / SQL encryption / decryption procedure.
  • Key management (including confidentiality) is left to the application using this package. This management is all the more delicate since the same keys must be shared by users sharing the same data.
  • this encryption technique does not allow to resist the attacks of a DBA because it has the means to intercept the keys or to replace the encryption package by another. This last problem seems to be unresolved because restricting the rights of the DBA amounts to preventing it from performing its administrative task.
  • Protegrity offers a data encryption solution, called Secure.Data [P. Nilsson, U. Mattsson. Secure. Data Functional Overview, Doc. TWP-0011, Protegrity Inc., January 2000], adaptable to different DBMS.
  • Secure.Data P. Nilsson, U. Mattsson. Secure. Data Functional Overview, Doc. TWP-0011, Protegrity Inc., January 2000
  • Secure. Server is a module integrated into the host DBMS which interfaces with Secure .Manager and executes the data encryption / decryption primitives on the fly, during the execution of requests.
  • the security core and the surrounding SOE must be simple enough to be self-administrating.
  • a DBMS is not self-administered.
  • the aim of the present invention is to remedy these drawbacks by proposing a system and a method guaranteeing a maximum degree of protection against any type of attack (internal or external) targeting data put online on any network and managed by a Traditional Database Management System (DBMS).
  • DBMS Traditional Database Management System
  • the aims of the invention are as follows: - to ensure perfect confidentiality of the data managed by a DBMS,
  • the invention relates, in its most general sense, to a secure management system for confidential databases
  • a server consisting of at least one computer equipped with means for recording databases and means of communication, by at least host computer equipment comprising means of communication with the server and means for constructing requests and processing the results of requests, as well as a means for securing exchanges between the client equipment and the server (also referred to below as C-SDA, for "Chip-Secured Data Access "), characterized in that said securing means is constituted by a secure hardware medium interfacing between the client equipment and the server and comprising a microprocessor for the encryption of the attributes of the requests sent by the client equipment and the decryption of the responses sent by the server, a random access memory for recording intermediate results, a non-writable memory for recording the operating system and a memory for recording user personalization information and that said server saves encrypted data.
  • the client (s) and the server are connected by means of communication connected to a telecommunications network (Internet, intranet, etc.).
  • a telecommunications network Internet, intranet, etc.
  • the client and the server are installed on the same physical machine and the communication means correspond to means of communication internal to a computer, or even to software communication means.
  • the invention takes into account the following constraints: - the database can be managed by any traditional commercial DBMS,
  • the secure hardware support used is current technology (for example, a conventional smart card),
  • the applications of the invention are diverse, and take into account the development of mobile computing which reflects a growing tendency of users to access their data anytime, from anywhere and especially from any terminal (PC, personal assistant, cell phone, unmarked terminal, etc.).
  • PC personal assistant
  • cell phone unmarked terminal, etc.
  • the data hosted in this context is generally personal, for example:
  • the medical file which contains highly confidential data and which a patient wants to be able to access at the doctor, at the pharmacy, at home, while traveling, etc.
  • the virtual or virtual home environment which lists private information of various kinds such as: bank data, calendar, address book, passwords, bookmarks, cookies ..., and which must be able to be accessed by n ' anywhere.
  • the invention also relates to a method implementing a security application which interfaces between a client and a data server and it complies with the following rules:
  • the securing means is constituted by a microprocessor card.
  • the latest generation smart cards include on a monolithic chip, a 32-bit RISC processor at about 30 MIPS, memory modules (about 96 KB of ROM, 4 KB of RAM and 128 KB of EE-PROM), a component of I / O managing communications with the terminal and finally security modules protecting the card against physical attacks.
  • the EEPROM stores persistent information with a very fast access time for reading, comparable to that of RAM (60 to 100 ns / word) but very slow for writing (1 to 10 ms / word).
  • the main interest of the smart card is its very high level of security. This security is obtained thanks to the hardware security modules present in the chip and also thanks to the very small size of the chips used ( ⁇ 25mm_) making physical attacks very complex and costly.
  • the smart card is undoubtedly the smallest and most secure of the "computers". However, the small size of the chips has an immediate impact on the storage capacity of memory components.
  • a microprocessor card has the following characteristics:
  • the security means is constituted by a microprocessor card.
  • the securing means consists of a key connectable to a port of client equipment.
  • the security means further comprises at least one counter for the execution of statistical queries.
  • the securing means further comprises a register for the temporary registration of the rights downloaded during the opening of a session with the server.
  • the securing means further comprises a memory for recording a part of the database.
  • This solution avoids the recording on the server of certain sensitive data.
  • the database is then divided into two parts, one saved on the server, the other saved on the security medium.
  • the invention also relates to a means of securing the exchanges between a client equipment and a server constituted by a secure hardware support connected to the client equipment and comprising a microprocessor for the encryption of the attributes of the requests sent by the client equipment and the decryption. responses from the server, RAM for recording intermediate results, non-writable memory for recording the operating system, and memory for saving user personalization information.
  • the invention also relates to a method for secure management of a database comprising a step of constructing a request comprising at least one attribute characterized in that it comprises a step of encrypting the attributes by a computer integral with a individual security device connected to client equipment, the method consisting in then interrogating a database containing encrypted data with the same encryption means as those used in the previous step, in returning a response containing the data corresponding to the attributes of the requests and to decrypt said data by said computer of an individual security device before transmitting it to the host equipment.
  • the encryption of the attributes of the request and the decryption of the response is carried out according to a DES algorithm.
  • the translation of requests is limited to equality predicates to allow the execution of said requests executable directly by the server on encrypted data.
  • the translation of queries comprising inequality predicates or calculation functions includes a step of decomposing the query Q into a plane Q t (Q c (Q s ))), of interrogating the base of encrypted data (3) by inequality requests from encrypted attributes, a step of recording the results of the requests in a temporary memory of the individual security means after decryption of the data, and of recomposition of the result;
  • Q s symbolizes the portion of the request that can be evaluated by the server directly on the encrypted data
  • Qc symbolizes the complement of this evaluable request by the means of security after decryption
  • Qt symbolizes the portion of request linked to the presentation and which can be deported to the terminal without reducing the degree of security.
  • part of the database is recorded in a memory of the individual security means.
  • FIG. 1 shows a schematic view of a system according to the invention
  • FIG. 2 represents a schematic view of the encryption of a table:
  • FIG. 3 shows a diagram of information flows between the client equipment and the server
  • FIG. 4 shows a diagram of information flows between the client equipment and the server, in an advanced version of the invention
  • FIG. 7 shows a schematic view of the treatments; - Figure 8 shows the architecture of the security card.
  • the description which follows relates to a nonlimiting example of implementation of the invention. It combines software (management of database requests and encryption algorithms) and hardware (code embedded on a smart card or hardware support ensuring the same level of security) technologies.
  • FIG. 1 represents a schematic view of a system according to the invention.
  • client equipment (1) which can be constituted by a microcomputer, or even portable equipment such as a PDA, a cell phone or any other equipment making it possible to consult a database. It is equipped with a calculator and applications for managing a database
  • This server (2) comprises a database (3) of known type.
  • the database contains exclusively data encrypted by the user, as will be explained in the following description.
  • the server (2) manages the data without having access to it.
  • the data server is relational technology (Oracle, DB2, SQL Server, Sybase, Informix ). Taking into account other types of data servers and other query languages can bring about some modifications in the algorithms presented, without calling into question the principles described in the description which follows.
  • the communication between the client equipment (1) and the server (2) passes through a microprocessor card (4) operated by a peripheral of the client equipment (1), for example a terminal connected to a USB port of the client equipment.
  • the encryption of the database is ensured by the card (4) in the following manner.
  • the card (4) intercepts all SQL requests for schema creation / modification as well as all SQL requests for inserting / modifying / destroying tuples in the tables.
  • the schema of the database as well as the data are encrypted by the card, for example with a secret key algorithm of the DES type.
  • the encryption algorithm used is called Encryption. These requests, the parameters of which are now encrypted, are then sent to the data server (2) like conventional requests. This technology therefore requires no modification of the DBMS used.
  • the data recorded in the server (2) is recorded in encrypted form.
  • the Product table (ref, name, type, price) is stored as table P (r, n, t, x) where P Number ("product"), r ⁇ Number (re), n ⁇ Encryption (name), etc.
  • P P Number
  • r Number
  • r Number
  • n Encryption
  • all of the data is encrypted, knowing that partial encryption of the data can also be considered.
  • the encryption is applied to the data as well as to global information such as the name of the table and the names of the items.
  • FIG. 3 represents the steps of a procedure for consulting the encrypted database.
  • the first step is to prepare a clear request on the client equipment (step 1).
  • This request is transmitted by the client equipment to the card (4) where the attributes of the request are encrypted before being transmitted to the server (2).
  • This request is then processed in the usual way, the search being carried out on criteria of equality between the encrypted content of the request and the content encrypted with the same digit, recorded in the database (3). (2nd step) .
  • the server therefore does not require any adaptation, the only difference with a traditional application coming from the fact that the search is carried out on encrypted attributes.
  • the response to this request again passes through the card (4), which converts the content to restore the data corresponding to the request in clear (step 3).
  • This clear data is then retransmitted to the client equipment, for viewing or recording in a local table (step 4).
  • This query evaluation technique is possible when all users sharing the same data have the same encryption key. This brings two important remarks: The encryption must in no case interfere with the access rights. With regard to rights, it is possible to encrypt the entire database with a single key. Each user has access only to the data to which he has a right, the key being known only by the card (4) and not by each user. For example, in the case where the security application is executed in a smart card, the key allowing to decrypt the whole database is present in the smart card of each user without this one n have access to it.
  • the definition of rights is stored on the server and is loaded dynamically (or simply refreshed) on the card when the user connects to the server.
  • the definition of rights must be stored encrypted on the server.
  • the power of the DBMS rights mechanism comes from the ability to assign a right to a user on views, that is to say virtual tables calculated by an SQL query. It then becomes possible to express rights of great finesse, for example: giving the right to a user to consult a view defined as the average salary of employees over 40 years working in the IT department without giving him any right to the data allowing this calculation to be made. Or a view V defined by the Qview request on which the user has the right D.
  • the description which follows relates to an improved version of the invention, making it possible to process any type of SQL request.
  • This extended solution means that the security application actively participates in the processing of the request in order to evaluate the predicates that cannot be evaluated by the server.
  • This interaction of the card security application (4) in the processing has two consequences. The first relates to the performance of the global execution and the second to the appearance of new perspectives to strengthen the protection of the data of the base.
  • the query Q In the case of complex queries (predicates inequality, calculation functions, aggregates 7), the query Q must be decomposed into a Q s evaluable part by the server on the encrypted data and its complement Q c to be assessed by the security application on the partial result, after decryption. It is essential that Q c is executed by the security application and not by the terminal because only C-SDA is executed in a secure environment.
  • user rights generally relate to views whose virtual content is calculated by a query. Therefore, only a treatment of Q c by the security application, without outsourcing confidential data, can guarantee the level of security expected by rights management. For example, a user may have the right to consult the result of an aggregate calculation without having the right to consult the elementary data from which this aggregate is calculated.
  • C-SDA In order to evaluate Q c , C-SDA must contain filtering functions (to deal with inequality predicates) and calculation functions. This is the subject of the second example.
  • Map Decryption of the result of Q s and evaluation of Q c (calculation of the mean).
  • Terminal Display of the result in clear.
  • the evaluation of Q c by the card (4) must be able to be made while respecting the constraints inherent in the card. These constraints make it necessary to evaluate Q c without ever materializing temporary results because the very low capacity of the RAM does not allow such a materialization in volatile memory and the cost of writing the EEPROM also makes this materialization impossible in stable memory.
  • the proposed solution consists in executing the whole of Q c in pipeline mode (ie, tuple to tuple).
  • Order by clause can be systematically transferred to the terminal and therefore constitutes a third request noted Q ⁇ . Indeed, the Order by clause does not influence the value of the result tuples but simply their ordering. This clause therefore has no effect on rights management and can therefore be executed outside of C-SDA.
  • step 1 The evaluation of Q s , as presented above, suggests that the Cartesian products are executed first (step 1). In fact, the assessment all or parts of 2s and 6s can be performed before step 1 by following traditional query optimization techniques (replacement of Cartesian products by joins, application of restrictions and projections as soon as possible). Q s is transmitted to the server as a standard SQL query, it will follow the traditional optimization process.
  • the card's security application decrypts the Date attribute of these tuples, selects only the tuples whose date is greater than 1996 and returns their key to the server in the form of a temporary table R;
  • the volume of data transferred is greatly reduced. Indeed, the additional cost compared to a traditional execution is limited to size (II key / ai (T)) + size ( ⁇ key ( ⁇ ai ⁇ value (T)). This principle applies similarly to inequalities -joints.
  • This technique can be combined with a horizontal fragmentation encryption technique which consists in using several encryption keys for different values of the same attribute.
  • the encryption key applied to each value is determined by applying a hash function to that value.
  • the result of the hash function h (v) gives the index of the encryption key to be used.
  • the pair (h (v), Number h (v) (v)) is stored in the base in place of each value. It is easy to show that the previous constraint is respected. In these two techniques, all of the encryption keys used are managed by the security card.
  • the security application To evaluate a request for data, part of which resides in a smart card, the security application must generate an execution plan distributed between two sites.
  • This task complex for a smart card, can be simplified by imposing a particular way of isolating sensitive data.
  • the idea is to delete sensitive data from the database stored on the server, replacing it with clues in a sensitive area (set of data without duplicates), stored on the smart card.
  • the credit card codes of a set of customers could be stored as indices in the 'credit card codes' area stored in the smart card.
  • This 'coding' of sensitive data can be seen as a very specific encryption of this data, encryption whose particularity is to be definitively unbreakable without the smart card.
  • static sensitive data i.e., without updates
  • This particular case is likely to represent a majority of practical cases (for example, personal or SME identification data).
  • the durability of static data can be ensured by redundant storage of this data in a backup smart card.
  • This backup card is only used in the event of loss, theft or destruction of the initial card.
  • Static sensitive data is shared by copying it to each user's smart cards. For this type of data, the level of security reached is maximum since no copy is accessible on any server and the content of the card is considered inviolable.
  • Figure 7 summarizes a joint use of all the techniques exposed in the previous sections, with C-SDA running in a smart card.
  • the security application contacts the rights and views server to update the list of rights and views of the user. He deciphers them with his key database.
  • the security application contacts the sharing / durability server in order to update the dynamic sensitive data hosted by the smart card.
  • the user issues a Q request.
  • the request if it involves views, is translated into a Q 1 request relating to basic relationships.
  • Q s is sent to the server which executes it on the encrypted data and returns the tuples results to the security application.
  • the result is decrypted by the security application using the key database.
  • the additional request Q c is executed by the security application.
  • the result may be supplemented with the values of sensitive data (DS) during projections.
  • DS sensitive data
  • FIG. 8 represents a view of the architecture of the security card (4).
  • the electronic circuit includes an input-output interface circuit (14) for exchanges with the client equipment (1) and the server (2).
  • the output of this circuit (14) is connected to a buffer memory (15).
  • the card also comprises a microprocessor (10) and an EEPROM memory (11) for recording the operating system and the security application and a memory (12) for recording the personal data of the user and in particular the encryption key or the encryption parameters of the user, as well as the data relating to the rights of the user.
  • a microprocessor (10) and an EEPROM memory (11) for recording the operating system and the security application
  • a memory (12) for recording the personal data of the user and in particular the encryption key or the encryption parameters of the user, as well as the data relating to the rights of the user.
  • the card also comprises a random access memory (15) comprising registers (16) for recording the intermediate data of the calculations, and a counter (17) for carrying out the calculations corresponding to queries containing statistical predicates such as averages.

Abstract

La présente invention concerne un système de gestion securisée de bases de données confidentielles comprenant un serveur constitué par au moins un ordinateur équipé de moyens d'enregistrement de bases de données et de moyens de communication, par au moins un équipement informatique hôte comprenant des moyens de communication avec le serveur et des moyens pour la construction de requêtes et le traitement des résultats des requêtes, ainsi qu'un moyen de sécurisation des échanges entre l'équipement client (1) et le serveur, caracterisé en ce que ledit moyen de sécurisation est constitué par un support matériel sécurisé relié à l'équipement client (1) et comportant un microprocesseur pour le chiffrement des attributs des requêtes émises par l'équipement client (1) et le déchiffrement des réponses émises par le serveur, une mémoire pour l'enregistrement de résultats intermédiaires, une mémoire pour l'enregistrement du système d'exploitation et que ledit serveur enregistre des données chiffrées. Elle concerne également le procédé mis en oeuvre par un tel système.

Description

PROCEDE DE SECURISATION DE BASES DE DONNEES
La présente invention concerne le domaine des systèmes d'information sécurisés, et plus particulièrement des systèmes et procédés de sécurisation de bases de données .
La sécurisation des données est devenue un des enjeux majeurs des systèmes informatiques, compte tenu de la prolifération des données mises en ligne sur l'Internet (sites marchands, hébergement de données personnelles ou professionnelles, accès distants à des serveurs d'entreprise par des employés mobiles) et de l'interconnexion croissante de bases de données enrichies et consultées par de multiples acteurs (banques de données scientifiques, techniques, médicales) . Le besoin de sécurité est lié au caractère confidentiel d'un sous- ensemble de ces données. La motivation de pirates s 'attaquant aux données peut être multiple : tentative de fraude (vol de n° de cartes bancaires sur des sites marchands ...) , atteinte à la vie privée des particuliers
(enquêtes policières, politiques, fiscales, financières, médicales ...) , guerres commerciales, diplomatiques ou militaires (système Echelon, violation de secrets industriels ou commerciaux, violation de la propriété intellectuelle ...) .
Le problème ne se réduit pas à se protéger contre des pirates externes s' introduisant sur le système informatique attaqué. En effet, les attaques internes, c'est-à-dire conduites par des employés ayant légalement accès à tout ou parties des données d'une entreprise, sont les plus fréquentes et les plus coûteuses.
Trois classes de pirates susceptibles d'attaquer des bases de données peuvent être distinguées :
Le pirate externe est un intrus qui s'infiltre sur un système informatique et récupère les fichiers de données produits par le SGBD. Pour se prémunir contre ce type d'attaque, une solution naturelle est de chiffrer les données afin de rendre leur empreinte disque illisible. Le pirate externe va alors tenter de casser la clé de chiffrement. Les attaques sur clés sont facilitées dans un contexte bases de données du fait du volume important de données chiffrées avec la même clé (attaques statistiques) . De plus, le chiffrement des données est statique (les clés ne changent pas d'une session à l'autre), augmentant par là-même la vulnérabilité de la base.
- Le pirate utilisateur est un usager courant du système informatique reconnu par le système d'exploitation et le SGBD. Il possède des droits sur une partie d'une base de données partagée et veut accéder à des données outrepassant ses droits. Ce pirate a potentiellement le même pouvoir qu'un pirate externe et peut en plus exploiter ses droits restreints. Si la base est chiffrée, il possède en outre un accès à certaines clés de déchiffrement.
Le pirate administrateur ou DBA est un employé peu scrupuleux de l'entreprise dont la fonction est d'administrer les ressources informatiques de l'entreprise ou la base de données (DBA : Data Base Administrator) . A ce titre, il possède tous les droits système, il dispose d'informations inaccessibles à tout autre (ex : journaux mémorisant les opérations effectuées sur la base) et peut espionner le comportement du SGBD pendant son exécution. Notons qu'un pirate externe ou utilisateur arrivant à s'octroyer les droits d'administration possède les mêmes pouvoirs que le pirate administrateur.
On connaît dans l'état de la technique plusieurs solutions pour sécuriser l'accès à des bases de données . Une première famille de solutions est basée sur l'identification et authentification des utilisateurs.
Pour pouvoir utiliser un système de gestion de bases de données (SGBD) , tout utilisateur doit être identifié et authentifié. L' authentification se fait classiquement par le biais d'un mot de passe stocké de façon chiffrée dans un catalogue du SGBD, ce dernier contrôlant la correspondance entre identité et mot de passe de l'utilisateur à chaque nouvelle connexion. La procédure d' authentification peut être renforcée par l'utilisation d'un service dédié [Oracle Advanced Security Administrator Guide, Release 8.1.7, September 2000] . Ce service dédié évite le cheminement en clair du mot de passe sur le réseau. On connaît une variante qui permet d'authentifier un utilisateur par différents biais tels que carte à puce ou TokenCard. En plus de 1 ' authentification par un code personnel (PIN), l'élément matériel carte doit lui-même être reconnu par le serveur, augmentant ainsi le degré de sécurité. Ces mécanismes sont inopérants contre une attaque dirigée sur les fichiers contenant la base de données par un pirate externe (car le SGBD est alors court-circuité) ou contre une attaque menée par un pirate utilisateur ou DBA (qui n'auront aucun mal à s'authentifier).
Une autre famille de solutions est basée sur la gestion des droits des utilisateurs. Dans un SGBD, les droits portant sur les données (consultation, insertion, mise à jour, destruction de données) peuvent être affectés aux utilisateurs, soit sur les tables de base (on obtient ainsi une gestion de droits primitive proche de celle offerte par un système d'exploitation), soit sur des vues (tables virtuelles calculées par une requête SQL) , soit encore sur des procédures stockées (le droit porte alors sur le déclenchement d'un traitement). Ces deux derniers cas permettent une gestion de droits sophistiquée et très sélective. Cependant, cette gestion de droit est inopérante contre une attaque dirigée sur les fichiers contenant la base de données (le SGBD est à nouveau court-circuité) ou contre une attaque menée par un DBA (car il possède tous les droits, y compris le droit de changer les droits) . Une autre solution est basée sur le chiffrement des communications. Le chiffrement des communications peut être utilisé en complément d'autres mécanismes de sécurité afin d'assurer notamment la confidentialité et l'intégrité des messages émis et reçus via un réseau. Leur utilisation dépasse largement le cadre des bases de données. Le protocole le plus connu dans ce domaine est SSL (Secure Soket Layer) . C-SET (Chip-Secured Transaction) , utilisé pour les paiements électroniques sur Internet, exploite des cartes à puce pour identifier et authentifier les utilisateurs et assurer le chiffrement des messages. L'identification est de ce fait bien associée au porteur de carte et non au terminal sur lequel il est connecté, la confidentialité des clés de chiffrement est assurée et les algorithmes de chiffrement sont exécutés dans un environnement sécurisé, même si le terminal est lui-même non sécurisé. Bien évidemment, le chiffrement des communications ne permet pas de se prémunir contre une attaque sur les fichiers contenant la base de données.
D'autres solutions, complémentaire aux précédentes, consistent à chiffrer le contenu même de la base de données. Cette solution est la seule permettant de se prémunir contre des attaques dirigées sur les fichiers contenant la base de données. Elle n'est exploitée que depuis peu car sa mise en œuvre pose des problèmes complexes, comme mentionné ci-dessous.
La société Oracle (nom commercial) propose un package PL/SQL (ensemble de procédures stockées) permettant d'effectuer du chiffrement à clé secrète DES (Data Encryption Standard) [Oracle Technical White Paper. Database Security in Oracle 8i, November 1999] . La clé de chiffrement doit être passée en paramètre à la procédure PL/SQL de chiffrement/déchiffrement. La gestion des clés (notamment leur confidentialité) est laissée à la charge de l'application utilisant ce package. Cette gestion est d'autant plus délicate que les mêmes clés doivent être partagées par les utilisateurs partageant les mêmes données. D'autre part, cette technique de chiffrement ne permet pas de résister aux attaques d'un DBA car celui-ci possède le moyen d'intercepter les clés ou de substituer le package de chiffrement par un autre. Ce dernier problème paraît sans solution car restreindre les droits du DBA revient à l'empêcher d'accomplir sa tâche d'administration.
Un article de recherche [J. He, M. Wang.
Cryptography and Relational Database Management Systems. Int. Database and Engineering Symposium (IDEAS), 2001] propose une solution de chiffrement plus fortement intégrée au SGBD censée (i) faciliter l'utilisation du chiffrement par les applications et (ii) résister aux attaques du DBA. Le premier objectif est atteint du fait que le SGBD assure lui-même la confidentialité des clés de chiffrement
(celles-ci sont stockées dans un catalogue sécurisé) . Pour permettre le partage entre utilisateurs, les données sont chiffrées avec une clé secrète, celle-ci étant à son tour chiffrée avec la clé de chaque utilisateur. Le SGBD effectuant lui-même ce chiffrement, l'utilisateur n'a jamais accès aux clés. Une solution élégante est également proposée pour chiffrer la base de données avec un grand nombre de clés générées dynamiquement par le SGBD, rendant plus difficile les attaques statistiques conduites pour casser la (les) clé (s) de chiffrement. L'atteinte du second objectif (résister aux attaques du DBA) passe par la réalisation du catalogue sécurisé dans lequel sont stockées les clés de chiffrement. Celui-ci est implanté de sorte à constituer un SOE (Secure Operating Environment) dans lequel le pouvoir du DBA est considérablement réduit. Transformer un catalogue en SOE ne rend pas l'intégralité du SGBD SOE. Dans cette méthode, comme dans celle d'Oracle, le chiffrement et le déchiffrement sont toujours assurés par le serveur. Il paraît alors illusoire d'assurer que le DBA ne pourra jamais accéder aux données en clair (par exemple pendant l'exécution d'une requête ou dans les journaux) , à moins de restreindre ses droits à un point tel que toute tâche d'administration s'avérera impossible. Pour cette raison, la solution semble peu convaincante, d'autant plus qu'elle impose la réécriture d'une partie (dont les contours restent à préciser) du noyau du SGBD.
La société Protegrity propose une solution de chiffrement de données, appelée Secure.Data [P. Nilsson, U. Mattsson. Secure. Data Functional Overview, Doc. TWP-0011, Protegrity Inc., January 2000], adaptable à différents SGBD. Cette solution, dont le principe est proche de celui proposé par IBM, repose sur deux modules distincts. Secure .Manager est un serveur de sécurité indépendant du SGBD hôte qui prend en charge la gestion des utilisateurs, des droits d'accès et des clés de chiffrement. Il joue donc le rôle du catalogue sécurisé introduit précédemment. Secure . Server est un module intégré au SGBD hôte qui s 'interface avec Secure .Manager et exécute les primitives de chiffrement/déchiffrement de données à la volée, pendant l'exécution des requêtes. Selon Protegrity, la sécurité de la solution repose sur une séparation stricte des rôles de DBA (Database Administrator) et de SA (Security Administrator gérant le Secure .Manager) , ces rôles étant joués par des personnes physiques différentes. Au-delà du fait que ce principe de séparation physique puisse être difficile à garantir dans la pratique, chiffrement et déchiffrement sont toujours assurés par le SGBD. Ce dernier n'étant toujours pas un SOE, la protection vis-à-vis du DBA reste toute relative. Les solutions de l'art antérieur ne sont pas totalement satisfaisantes, car :
Seul le chiffrement des données permet de résister aux attaques conduites sur les fichiers de la base - Pour résister aux attaques du DBA ou d'un pirate ayant usurpé les droits de ce dernier, le noyau de sécurité (incluant le chiffrement/déchiffrement) doit être géré dans un SOE .
Le noyau de sécurité et le SOE l'englobant doivent être suffisamment simples pour être auto- administrables .
Un SGBD n'est pas auto-administrable . Le but de la présente invention est de remédier à ces inconvénients en proposant un système et un procédé garantissant un degré de protection maximal contre tout type d'attaque (interne ou externe) visant des données mises en ligne sur un réseau quelconque et gérées par un Système de Gestion de Bases de Données (SGBD) traditionnel. Les buts de l'invention sont les suivants : - assurer une confidentialité parfaite des données gérées par un SGBD,
- offrir aux utilisateurs un accès sécurisé à toutes données auxquelles ils ont légalement accès depuis n'importe quel terminal connecté à Internet, - permettre à chaque utilisateur de partager ses données avec d'autres utilisateurs,
- être compatible avec les outils logiciels (SGBD) et matériels (cartes à puce) existants sur le marché.
A cet effet, l'invention concerne selon son acception la plus générale un système de gestion sécurisée de bases de données confidentielles comprenant un serveur constitué par au moins un ordinateur équipé de moyens d'enregistrement de bases de données et de moyens de communication, par au moins équipement informatique hôte comprenant des moyens de communication avec le serveur et des moyens pour la construction de requêtes et le traitement des résultats des requêtes, ainsi qu'un moyen de sécurisation des échanges entre l'équipement client et le serveur (désigné également dans la suite sous le terme C- SDA, pour "Chip-Secured Data Access"), caractérisé en ce que ledit moyen de sécurisation est constitué par un support matériel sécurisé s ' interfaçant entre l'équipement client et le serveur et comportant un microprocesseur pour le chiffrement des attributs des requêtes émises par l'équipement client et le déchiffrement des réponses émises par le serveur, une mémoire vive pour l'enregistrement de résultats intermédiaires, une mémoire non inscriptible pour l'enregistrement du système d'exploitation et une mémoire pour l'enregistrement des informations de personnalisation de l'utilisateur et que ledit serveur enregistre des données chiffrées.
Selon un mode de réalisation préféré de l'invention, le (s) client (s) et le serveur sont reliés par des moyens de communication connectés à un réseau de télécommunication (Internet, intranet, ...) . Selon une variante, le client et le serveur sont installés sur la même machine physique et les moyens de communication correspondent à des moyens de communication internes à un ordinateur, voire à des moyens de communication logiciels. Ce système répond aux objectifs visés en assurant une confidentialité parfaite des données gérées par un
SGBD, vis-à-vis des trois classes de pirates citées précédemment, en offrant aux utilisateurs un accès
(interrogation / modification) sécurisé à toutes données auxquelles ils ont légalement accès depuis n'importe quel terminal connecté à Internet, et en permettant à chaque utilisateur de partager ses données avec d'autres utilisateurs .
L'invention prend en compte les contraintes suivantes : - la base de données peut être gérée par tout SGBD commercial traditionnel,
- le support matériel sécurisé utilisé est de technologie courante (par exemple, une carte à puce conventionnelle) ,
- les algorithmes de chiffrement utilisés sont connus .
Les applications de l'invention sont diverses, et prennent en compte le développement de l'informatique mobile qui traduit une tendance croissante des utilisateurs à accéder à leurs données à tout moment, de n'importe où et surtout à partir de n' importe quel terminal (PC, assistant personnel, téléphone cellulaire, borne banalisée ...) . Ceci suppose que les données de l'utilisateur sont hébergées par un prestataire de service garantissant un stockage et un accès permanent, tolérant aux pannes et sécurisé à ces données. Les données hébergées dans ce contexte sont généralement personnelles, par exemple :
- le dossier médical, qui contient des données hautement confidentielles et qu'un patient veut pouvoir accéder chez le médecin, à la pharmacie, chez lui, en voyage, etc.
- le courrier électronique qui, de plus en plus, devient un outil de travail et contient bien sûr des informations confidentielles.
-l'environnement virtuel ou virtual home, qui répertorie des informations privées de diverses natures telles que : données bancaires, agenda, carnet d'adresses, mots de passes, bookmarks , cookies ..., et qui doivent pouvoir être accédées de n'importe où.
Ces applications personnelles se caractérisent par les besoins suivants :
- données devant être accessibles de n'importe où et à tout moment, - données hautement confidentielles car personnelles ,
- données partagées par plusieurs acteurs humains (ex : dossier médical) ou logiciels (virtual home) , - petit volume de données,
- interrogations complexes (inégalités sur dates ou valeurs, recherche textuelle sur libellé, calculs d'agrégats et de groupement ...) .
Elle concerne également les situations où un utilisateur fait appel aux services d'un hébergeur de données pour stocker des données comptables, des données liées à des procédés de fabrication ou des informations confidentielles sur ses clients et fournisseurs. En effet, une PME dispose rarement de l'ensemble des moyens techniques et humains nécessaires à la sécurisation de ces données contre des attaques directes (piratage, vol) ou indirectes (virus informatique). De plus, la motivation initiale d'une PME pour recourir aux services d'un hébergeur peut être en priorité d'assurer la durabilité de ses données (tolérance aux pannes) , le besoin de confidentialité étant alors induit par le fait que les données de l'utilisateur sont externalisées . La confidentialité des données est liée à la protection de l'entreprise vis-à-vis de la concurrence (ex : secret de fabrication, stratégie commerciale ...) et à sa crédibilité vis-à-vis de ses clients (ex : n° de cartes bancaires) . Cette classe d'application introduit le même type de besoin que la précédente, avec la contrainte supplémentaire que le volume de données est potentiellement beaucoup plus grand. L'invention concerne également un procédé mettant en œuvre une application de sécurité qui s 'interface entre un client et un serveur de données et il respecte les règles suivantes :
Chiffrement des données à protéger stockées sur le serveur, Gestion des requêtes portant sur les données chiffrées et le déchiffrement des résultats,
Gestion des privilèges (droits d'accès) de chaque utilisateur, Cette application de sécurité est auto- administrable, et s'exécute sur une plateforme matérielle et logicielle sécurisée (SOE). Tout manquement à l'une de ces règles introduit un trou de sécurité tels que ceux identifiés dans la section précédente. Ces cinq règles déterminent les éléments techniques de la solution proposée et en font probablement l'unique solution au problème posé.
Selon une variante préférée, le moyen de sécurisation est constitué par une carte à microprocesseur.
Les cartes à puce de dernière génération comprennent sur une puce monolithique, un processeur RISC 32 bits à environ 30 MIPS, des modules mémoire (d'environ 96 Ko de ROM, 4 Ko de RAM et 128 Ko d'EE-PROM) , un composant d' I/O gérant les communications avec le terminal et enfin des modules de sécurité protégeant la carte contre des attaques physiques. L'EEPROM permet de stocker des informations persistantes avec un temps d'accès très rapide en lecture, comparable à celui de la RAM (60 à 100 ns/mot) mais très lent en écriture (1 à 10 ms/mot) . L'intérêt principal de la carte à puce est son très haut niveau de sécurité. Cette sécurité est obtenue grâce aux modules de sécurité matériels présents dans la puce et grâce également à la très faible taille des puces utilisées (< 25mm_) rendant les attaques physiques très complexes et coûteuses . La carte à puce est sans aucun doute le plus petit et le plus sûr des "ordinateurs". Cependant, la faible taille des puces a une incidence immédiate sur la capacité de stockage des composants mémoire. Une carte à microprocesseur se traduit par les caractéristiques suivantes :
- sécurité maximale des données et du code hébergés dans la puce, - processeur puissant (notamment pour les fonctions de chiffrement/déchiffrement) ,
- très faible capacité de la RAM,
- capacité du stockage persistant en constante extension mais temps d'écriture très lent.
Selon une variante préférée de l'invention, le moyen de sécurisation est constitué par une carte à microprocesseur.
Selon une autre variante, le moyen de sécurisation est constitué par une clé raccordable sur un port d'un équipement client.
De préférence, le moyen de sécurisation comporte en outre au moins un compteur pour l'exécution de requêtes statistiques . De préférence, le moyen de sécurisation comporte en outre un registre pour l'enregistrement temporaire des droits téléchargés lors de l'ouverture d'une session avec le serveur.
Selon une mode de mise en œuvre avantageux, le moyen de sécurisation comporte en outre une mémoire pour l'enregistrement d'une partie de la base de données.
Cette solution permet d'éviter l'enregistrement sur le serveur de certaines données sensibles . La base de données est alors divisée en deux parties, l'une enregistrée sur le serveur, l'autre enregistrée sur le support de sécurisation.
L'invention concerne également un moyen de sécurisation des échanges entre un équipement client et un serveur constitué par un support matériel sécurisé relié à l'équipement client et comportant un microprocesseur pour le chiffrement des attributs des requêtes émises par l'équipement client et le déchiffrement des réponses émises par le serveur, une mémoire vive pour l'enregistrement de résultats intermédiaires, une mémoire non inscriptible pour l'enregistrement du système d'exploitation et une mémoire pour l'enregistrement des informations de personnalisation de l'utilisateur.
Selon une variante, il comporte en outre au moins un compteur pour l'exécution de requêtes statistiques. L'invention concerne également un procédé de gestion sécurisée d'une base de données comportant une étape de construction d'une requête comprenant au moins un attribut caractérisé en ce qu' il comporte une étape de chiffrement des attributs par un calculateur solidaire d'un dispositif individuel de sécurité relié à un équipement client, le procédé consistant à interroger ensuite une base de données contenant des données chiffrées avec les mêmes moyens de chiffrement que ceux utilisés lors de l'étape précédente, à retourner une réponse contenant les données correspondant aux attributs de la requêtes et à procéder au déchiffrement desdites données par ledit calculateur d'un dispositif individuel de sécurité avant de les transmettre à 1 ' équipement hôte .
Selon un mode de mise en œuvre particulier, le chiffrement des attributs de la requête et le déchiffrement de la réponse est réalisé selon un algorithme DES.
Selon une variante simplifiée, la traduction de requêtes est limitée aux prédicats d'égalité pour permettre l'exécution desdites requêtes exécutables directement par le serveur sur des données chiffrées.
Selon une variante préférée, la traduction de requêtes comportant des prédicats d'inégalité ou fonctions de calcul comporte une étape de décomposition de la requête Q en un plan Qt(Qc(Qs))), d'interrogation de la base de données chiffrées (3) par des requêtes d'inégalités à partir d'attributs chiffrés, une étape d'enregistrement des résultats des requêtes dans une mémoire temporaire du moyen de sécurisation individuel après déchiffrement des données, et de recomposition du résultat ; Qs symbolise la portion de requête évaluable par le serveur directement sur les données chiffrées, Qc symbolise le complément de cette requête évaluable par le moyen de sécurisation après déchiffrement et Qt symbolise la portion de requête liée à la présentation et pouvant être déportée sur le terminal sans réduire le degré de sécurité.
Selon une autre variante, la traduction de requêtes comportant des prédicats d' inégalité ou fonctions de calcul comporte une étape de décomposition d'une requête en un plan Q = Q t (Q C(Q S (* [Q C P (QS P) ] ) ) ) • où Qc? et Qs? sont des requêtes de préparation, d' interrogation de la base de données chiffrées (3) par des requêtes d'inégalités à partir d'attributs chiffrés, une étape d'enregistrement des résultats des requêtes dans une mémoire temporaire du moyen de sécurisation individuel après déchiffrement des données, et de recomposition du résultat.
Selon un mode de mise en œuvre particulier, une partie de la base des données est enregistrée dans une mémoire du moyen individuel de sécurisation.
L' invention sera mieux comprise à la lecture de la description d'un exemple non limitatif de réalisation, se référant aux dessins annexés où :
- la figure 1 représente une vue schématique d'un système selon l'invention ;
- la figure 2 représente une vue schématique du chiffrement d'une table :
- la figure 3 représente un diagramme des flux d'informations entre l'équipement client et le serveur ;
- la figure 4 représente un diagramme des flux d'informations entre l'équipement client et le serveur, dans une version évoluée de l'invention ;
- Les figures 5 et 6 représentent les schémas d'exécution de requête 'complexe'
- La figure 7 représente une vue schématique des traitements ; - la figure 8 représente l'architecture de la carte de sécurisation.
La description qui suit concerne un exemple non limitatif de mise en œuvre de l'invention. Elle associe des technologies logicielles (gestion de requêtes bases de données et algorithmes de chiffrement) et matérielles (code embarqué sur une carte à puce ou un support matériel assurant le même niveau de sécurité) .
La figure 1 représente une vue schématique d'un système selon l'invention.
Il comporte un équipement client (1) qui peut être constitué par un micro-ordinateur, ou encore un équipement portable tel qu'un PDA, un téléphone cellulaire ou tout autre équipement permettant de consulter une base de données . Il est équipé avec un calculateur et des applications pour la gestion d'une base de données
(insertion de données, consultations, modifications des données) et pour l'établissement d'une session avec un serveur (2) auquel il est relié par un réseau de télécommunication (Internet, extranet, intranet, réseau GSM,...) .
Ce serveur (2) comporte une base de données (3) de type connu. La base de données contient exclusivement des données chiffrées par l'utilisateur, comme cela sera exposé dans la suite de la description. Le serveur (2) gère les données sans pour autant y avoir accès . Le serveur de données est de technologie relationnelle (Oracle, DB2 , SQL Server, Sybase, Informix ...) . La prise en compte d'autres types de serveurs de données et d'autres langages de requêtes peut amener quelques modifications dans les algorithmes présentés, sans remettre en cause les principes décrits dans la description qui suit.
La communication entre l'équipement client (1) et le serveur (2) transite par une carte à microprocesseur (4) exploitée par un périphérique de l'équipement client (1), par exemple un terminal raccordé sur un port USB de l'équipement client.
Le chiffrement de la base de données est assuré par la carte (4) de la façon suivante. La carte (4) intercepte toutes les requêtes SQL de création/modification de schéma ainsi que toutes les requêtes SQL d' insertion/modification/destruction de tuples dans les tables. Le schéma de la base de données ainsi que les données sont chiffrées par la carte, par exemple avec un algorithme à clé secrète de type DES. Dans la suite, l'algorithme de chiffrement utilisé est appelé Chiffre. Ces requêtes, dont les paramètres sont désormais chiffrés, sont ensuite envoyées au serveur de données (2) comme des requêtes classiques. Cette technologie ne demande donc aucune modification du SGBD utilisé.
Les données enregistrées dans le serveur (2) sont enregistrées sous forme chiffrée. Comme illustré sur la figure 2, la table Produit (ref, nom, type, prix) est stockée comme table P(r, n, t, x) où P Chiffre ("produit") , r ≈ Chiffre (re ) , n ≈ Chiffre (nom) , etc.. Dans cet exemple, l'intégralité des données est chiffrée, sachant qu'un chiffrement partiel des données peut également être envisagé.
Le chiffrement est appliqué aux données ainsi qu'aux informations globales telles que le nom de la table et les noms des rubriques.
La figure 3 représente les étapes d'une procédure de consultation de la base de données chiffrées.
On procède à une première étape consistant à préparer une requête en clair sur l'équipement client (étape 1) .
Cette requête est transmise par l'équipement client à la carte (4) où les attributs de la requête sont chiffrés avant d'être transmis au serveur (2). Cette requête est alors traitée de façon habituelle, la recherche s 'effectuant sur critères d'égalité entre le contenu chiffré de la requête et le contenu chiffré avec le même chiffre, enregistré dans la base de données (3) . (étape 2) . Le serveur ne nécessite donc aucune adaptation, la seule différence avec une application traditionnelle venant du fait que la recherche s'effectue sur des attributs chiffrés .
La réponse à cette requête transite à nouveau par la carte (4) , qui procède à une conversion du contenu pour restituer les données correspondant à la requête en clair (étape 3) . Ces données en clair sont ensuite retransmises à l'équipement client, pour la visualisation ou l'enregistrement dans une table locale (étape 4).
Cette technique permet d'exécuter toute requête sur des données chiffrées ne faisant intervenir que des prédicats d'égalité (attribut = valeur ou attribut = attribut) sans fonction de calcul (agrégat, ...) . En effet, les propriétés des algorithmes de chiffrement ne permettent pas, de façon générale, d'évaluer des prédicats d'inégalité ni des fonctions de calcul sur des données chiffrées. Cette contrainte est forte car :
Elle limite les capacités d'interrogation des utilisateurs,
Elle limite de la même façon la puissance d'expression des droits d'accès.
La résolution d'une requête SQL simple du type "sélect* from produit where type = 'pentium3'", permettant de retrouver tous les produits de type pentium3, sera effectuée comme suit : 1. Terminal (1) : saisie de la requête en clair
2. Carte (4) : chiffrement et envoi de la requête chiffrée au serveur : sélect * from Chiffre (Produit) where Chiffre (type) = Chiffre ( "pentium3" ) 3. Serveur (2) : Résolution de la requête sur les données chiffrées (transparent pour le SGBD)
4. Carte (4) : Déchiffrement du résultat
5. Terminal : Affichage du résultat en clair.
Cette technique d' évaluation de requêtes est possible lorsque tous les utilisateurs partageant les mêmes données possèdent la même clé de chiffrement. Ceci amène deux remarques importantes : Le chiffrement ne doit en aucun cas interférer avec les droits d'accès. Vis-à-vis des droits, il est envisageable de chiffrer l'intégralité de la base de données avec une seule clé. Chaque utilisateur n'a accès qu'aux données sur lesquelles il possède un droit, la clé étant connue uniquement par la carte (4) et non par chaque utilisateur. Par exemple, dans le cas où l'application de sécurité s'exécute dans une carte à puce, la clé permettant de déchiffrer l'intégralité de la base de données est présente dans la carte à puce de chaque utilisateur sans que celui-ci n'y ait accès.
Plusieurs clés de chiffrement peuvent être utilisées pour augmenter la difficulté de cassage des clés et en réduire l'impact. La gestion des droits faisant partie intégrante du mécanisme de sécurité, celle-ci ne peut en aucun cas être déléguée au serveur de données . Autrement, le DBA n'aura aucune difficulté à s'octroyer tous les droits sur l'ensemble des données. La gestion des droits doit donc être assurée par l'application de sécurité de la carte (4) . Cette gestion pose un problème particulier lorsque cette application s'exécute dans une carte à puce propre à chaque utilisateur. En effet, les droits expriment un partage de données entre plusieurs utilisateurs et ces droits sont dynamiques (de nouveaux droits peuvent être définis et certains existants peuvent être supprimés) . Si la carte à puce est responsable de la vérification des droits, elle ne peut par contre pas stocker elle-même la définition de ces droits du fait du partage entre les utilisateurs. Par conséquent, la définition des droits est stockée sur le serveur et est chargée dynamiquement (ou simplement rafraîchie) sur la carte lors de la connexion de l'utilisateur au serveur. Afin de prévenir toute altération, pouvant introduire un trou de sécurité, la définition des droits doit être stockée chiffrée sur le serveur . La puissance du mécanisme de droits des SGBD provient de la capacité d'affecter un droit à un utilisateur sur des vues, c'est-à-dire des tables virtuelles calculées par une requête SQL. Il devient alors possible d'exprimer des droits d'une grande finesse, par exemple : donner le droit à un utilisateur de consulter une vue définie comme la moyenne des salaires des employés de plus de 40 ans travaillant dans le service informatique sans lui donner aucun droit sur les données permettant de réaliser ce calcul. Soit une vue V définie par la requête Qvue sur laquelle l'utilisateur possède le droit D. Lorsque l'utilisateur exprime une requête Q(V), le gestionnaire de droits vérifie tout d'abord que cette requête est compatible avec le droit D. Si oui, la requête Q(V) est transformée par le gestionnaire de vue en une requête Q(Qvue) = Q' ({Ti}), où {Ti} dénote la liste des tables de base sur laquelle la vue V est définie. Q' est ensuite évaluée comme une requête classique selon la méthode introduite précédemment. La conséquence en est que C-SDA doit intégrer la gestion des vues au même titre que la gestion des droits (la définition des vues est stockée chiffrée sur le serveur et chargée dynamiquement sur la carte) .
La description qui suit concerne une version améliorée de l'invention, permettant de traiter tout type de requête SQL. Cette solution étendue implique que l'application de sécurité participe de façon active au traitement de la requête afin d'évaluer les prédicats non évaluables par le serveur. Cette interaction de l'application de sécurité de la carte (4) dans le traitement a deux conséquences. La première porte sur la performance de l'exécution globale et la seconde sur l'apparition de nouvelles perspectives pour renforcer la protection des données de la base.
Dans le cas d'interrogations complexes (prédicats d'inégalité, fonctions de calcul, agrégats ...) , la requête Q doit être décomposée en une partie Qs évaluable par le serveur sur les données chiffrées et son complément Qc à évaluer par l'application de sécurité sur le résultat partiel, après déchiffrement. Il est fondamental que Qc soit exécutée par l'application de sécurité et non par le terminal car seul C-SDA s'exécute dans un environnement sécurisé. Comme il a été montré dans la section 5.4, les droits des utilisateurs portent généralement sur des vues dont le contenu virtuel est calculé par une requête. Donc, seul un traitement de Qc par l'application de sécurité, sans externalisation de données confidentielles, peut garantir le niveau de sécurité escompté par une gestion de droits. Par exemple, un utilisateur peut avoir le droit de consulter le résultat .d'un calcul d'agrégat sans pour autant posséder le droit de consulter les données élémentaires à partir desquelles cet agrégat est calculé.
Afin d'évaluer Qc , C-SDA doit contenir des fonctions de filtrage (pour traiter les prédicats d'inégalité) et des fonctions de calcul. C'est l'objet du deuxième exemple .
La requête "sélect Avg (prix) from produit where type = 'pentium3'" sera effectuée comme suit : 1. Terminal : Saisie de la requête en clair 2. Carte : Chiffrement et envoi d'une sous-requête chiffrée Qs : sélect Chiffre (prix) from Chiffre (Produit ) where Chiffre (type) = Chiffre ( "pentium3" )
3. Serveur : Résolution de la requête sur les données chiffrées : Résultat ( Chif f re (prixl ) ,
Chiffre (prix2) , Chiffre (prix3) , ...)
4. Carte : Déchiffrement du résultat de Qs et évaluation de Qc (calcul de la moyenne) .
5. Terminal : Affichage du résultat en clair. Pour que ce principe soit applicable sur une carte à puce, il faut que l'évaluation de Qc par la carte (4) puisse se faire en respectant les contraintes inhérentes à la carte. Ces contraintes imposent d'évaluer Qc sans jamais matérialiser de résultats temporaires car la très faible capacité de la RAM ne permet pas une telle matérialisation en mémoire volatile et le coût d'écriture de l'EEPROM rend également cette matérialisation impossible en mémoire stable. La solution proposée consiste à exécuter l'intégralité de Qc en mode pipeline (c.à.d, tuple à tuple) . Bien que ce mode d'évaluation ne soit pas traditionnel, surtout pour les requêtes faisant intervenir des groupements et calculs d'agrégats, nous pouvons montrer que toute requête Qc est évaluable en pipeline en suivant le principe d'exécution suivant. La forme générale d'une requête SQL est :
Select liste d'attributs, fonctions From liste de relations Where qualification Group by liste d'attributs - Having qualification sur fonction agrégat
Order by critère de tri La sémantique opérationnelle de SQL précise que le résultat d'une requête SQL doit être équivalent au traitement suivant : 1. Calcul du produit cartésien des relations impliquées dans la clause From
2. Restriction aux seuls tuples produits en (1) satisfaisant la qualification de la clause Where 3. Groupement des tuples issus de (2) ayant même valeur pour la liste d'attributs spécifiée
4. Calcul des fonctions agrégats apparaissant dans les clauses Select, Having et Order by
5. Restriction aux seuls groupes produits en (4) satisfaisant la qualification de la clause Having
6. Projection des tuples issus de (5) sur la liste d'attributs et fonctions de la clause Select
7. Tri des tuples issus de (6) en fonction du critère de tri spécifié par la clause Order by Le serveur est capable d'exécuter sur des données chiffrées les étapes suivantes, soit Qs :
1. Calcul du produit cartésien des relations impliquées dans la clause From
2s. Restriction aux seuls tuples produits en (1) satisfaisant les prédicats d'égalité présents dans la qualification de la clause Where
3. Groupement des tuples issus de (2s) ayant même valeur pour la liste d'attributs spécifiée
6s. Projection des tuples issus de (3) sur la liste d'attributs résultat de l'union des listes d'attributs des clauses Select, Group by, Order by ainsi que de la liste d'attributs nécessaires à l'évaluation des prédicats non traités en 2s de la clause Where et des prédicats de la clause Having. L'application de sécurisation est pour sa part contraint d'exécuter sur la carte à puce en pipeline les étapes suivantes, soit Qc :
Pour chaque tuple t résultat de Qs, faire : 2c. Vérifier les prédicats de la clause Where non traités en 2s 4. Agréger dans une variable tampon la valeur de (s) attribut (s) de t impliqué (s) dans l'évaluation d'une fonction agrégat (apparaissant dans les clauses Select, Having et Order by) et ce, tant que t appartient au même groupe que le tuple précédent (par exemple, le calcul de la moyenne d'un attribut se réalise en sommant la valeur de l'attribut de chaque tuple du groupe. Lorsque le dernier tuple du groupe est détecté, cette somme est divisée par le nombre de tuples du groupe) . 5. Lorsque la fin de groupe est détectée et que les fonctions agrégats sont calculées, évaluer la qualification de la clause Having.
6c. S'il est sélectionné, projeter le tuple issu de (5) sur la liste d'attributs et de fonctions spécifiée dans la clause Select
A noter que la clause Order by peut être systématiquement déportée sur le terminal et constitue donc une troisième requête notée Q^ . En effet, la clause Order by n' influe pas sur la valeur des tuples résultat mais simplement sur leur ordonnancement. Cette clause est donc sans effet vis-à-vis de la gestion des droits et peut de ce fait être exécutée à l'extérieur de C-SDA.
En résumé, et comme illustré par l'exemple de la figure 5, l'évaluation d'une requête SQL quelconque Q se fait de la façon suivante : Q = Q^- (Qc (Qs) . Ce principe d'évaluation respecte bien les contraintes de la carte puisque l'espace mémoire consommé se réduit à la mémorisation d'un tuple courant et de quelques variables tampons destinées au calcul des fonctions agrégats. La figure 5 représente le schéma d'exécution de requête 'complexe'. Ce mode d'évaluation présenté ci-dessus peut être amélioré pour deux raisons :
- L'évaluation de Qs , telle que présentée précédemment, laisse à penser que les produits cartésiens sont exécutés en premier (étape 1) . En fait, l'évaluation de tout ou parties de 2s et de 6s peut être réalisée avant l'étape 1 en suivant les techniques d'optimisation de requêtes traditionnelles (remplacement des produits cartésiens par des jointures, application des restrictions et des projections au plus tôt) . Qs étant transmise au serveur comme une requête SQL classique, elle suivra le processus d'optimisation traditionnel.
- Les prédicats d'inégalité (restrictions, inéqui- jointures) ne pouvant être évalués directement par le serveur, le volume de données transféré vers la carte peut être très supérieur au volume du résultat final . Dans l'exemple de la figure 5, toutes les commandes des clients sont transférées à C-SDA, sans distinction de date. La solution à ce problème est détaillée ci-dessous. II est nécessaire d'évaluer les prédicats d'inégalité au plus tôt afin de profiter de leur sélectivité pour simplifier l'ensemble de la chaîne de traitements réalisés sur l'équipement client, la carte et le serveur. Cela nécessite un pré-traitement coopératif entre la carte et le serveur. Soit une requête Q contenant un prédicat de la forme σal θ valeur (T) , où σ dénote l'opérateur de restriction, θ e {<, >, ≤, >} et a1 est un attribut quelconque de la table T. Le principe d'optimisation consiste pour l'application de sécurisation à envoyer au serveur une requête de pré-traitement QS P = πclé/ aι (T) , i dénotant l'opérateur de projection. C-SDA
exécute alors Qc p = riclé (σaι θ valeur (riciô, Déciffretau (QS P) ) ) et renvoie le résultat R au serveur. C-SDA transforme ensuite la requête Q en remplaçant le prédicat initial σaι θ valeur (T) par le prédicat °=(T, R) , où <≈ dénote l'opérateur de semi- jointure sur clé. Sur l'exemple de la figure 5, ce principe donne l'enchaînement suivant exécuté en pipe-line sur la carte : - l'application de sécurité de la carte rapatrie les tuples de la table Commandes après avoir fait une projection sur l'attribut clé et l'attribut Date;
- l'application de sécurité de la carte déchiffre l'attribut Date de ces tuples, sélectionne uniquement les tuples dont la date est supérieure à 1996 et renvoie leur clé au serveur sous la forme d'une table temporaire R;
- l'application de sécurité de la carte transforme enfin la requête initiale Q en remplaçant le prédicat (Q.Date > 1996) par (Q.clé = R.clé) et envoie cette requête au serveur pour exécution. Le volume de données transféré est très fortement réduit. En effet, le surcoût par rapport à une exécution traditionnelle se limite à taille (IIclé/ ai(T)) + taille (πclé (σai θ valeur(T) ) . Ce principe s'applique de façon similaire pour les inéqui-jointures .
Comme illustré par la figure 6, le principe général d'évaluation d'une requête contenant des prédicats d'inégalité devient : Q = Qt (Qc (Qs ( * [Qc p (QS P) ] ) ) ) , la composition Qc p (QS P) se répétant pour chaque prédicat d'inégalité.
L'utilisation de plusieurs clés de chiffrement pour une même base de données est une idée simple et efficace pour réduire le volume de données dévoilées en cas de cassage d'une clé. Dans notre contexte, l'utilisation de plusieurs clés doit respecter la contrainte suivante : Va,
Vb, a = b <=> Chiffre (a) = Chiffre (b) . Cette contrainte est nécessaire pour permettre au serveur d'exécuter tous les prédicats d'égalité présents dans les requêtes de type Qs .
Toutefois, cette contrainte n'a pas lieu d'être si a et b ne sont jamais comparés, soit qu'ils ne sont pas de types comparables (ex : un entier et une chaîne de caractère) , soit que leur comparaison est dépourvue de toute sémantique
(ex : l'âge d'un client et le numéro de client), soit encore que ces données appartiennent à des utilisateurs ou groupes d'utilisateurs différents ne désirant pas les partager. Dans tous ces cas, il est possible d'utiliser des clés de chiffrement différentes selon une technique que nous appellerons chiffrement à fragmentation verticale.
Cette technique peut se combiner avec une technique de chiffrement à fragmentation horizontale qui consiste à utiliser plusieurs clés de chiffrement pour différentes valeurs d'un même attribut. Dans cette technique, la clé de chiffrement appliquée à chaque valeur est déterminée par l'application d'une fonction de hachage à cette valeur. Ainsi, pour chaque valeur v, le résultat de la fonction de hachage h(v) donne l'indice de la clé de chiffrement à utiliser. Le couple (h(v), Chiffreh(v) (v) ) est stocké dans la base en lieu et place de chaque valeur. Il est facile de montrer que la contrainte précédente est respectée. Dans ces deux techniques, l'ensemble des clés de chiffrement utilisées est géré par la carte de sécurisation.
Les données renvoyées par le serveur à la carte de sécurisation étant déjà chiffrées, l'opportunité de chiffrer les communications n'est pas indispensable. Ce chiffrement s'avère cependant nécessaire, notamment pour résister à des attaques menées par un pirate utilisateur. En effet, celui-ci peut obtenir une paire (texte chiffré / texte clair) en écoutant les communications lors de l'exécution d'une requête autorisée (i.e., sur laquelle il possède les droits) . Cette paire de texte est une arme importante pour casser la clé de chiffrement. Les communications entre le serveur et la carte de sécurisation doivent donc être chiffrées avec une des techniques de l'état de l'art.
La carte de sécurisation (4) participant de façon active à l'exécution des requêtes, il devient envisageable de stocker une partie de la base de données, considérée comme très sensible, directement sous le contrôle de la carte. Par exemple, dans le cas où l'application de sécurité s'exécute dans une carte à puce, ces données très sensibles peuvent être stockées dans la mémoire stable
(EEPROM) de la carte à puce. Ceci permet de rendre ces données définitivement inaccessibles à tout type de pirate
(y compris un pirate utilisateur) . Par exemple, si les données stockées dans la carte correspondent aux données d'identification de l'utilisateur, même un pirate arrivant à déchiffrer l'ensemble de la base ne saura pas à qui appartiennent les données correspondantes. Cette approche offre un degré de protection inégalable mais pose trois problèmes importants : (i) augmentation de la complexité de l'évaluation de requêtes ; (ii) durabilité des données sensibles ; et (iii) partage éventuel de ces données entre plusieurs utilisateurs.
Pour évaluer une requête sur des données dont une partie réside dans une carte à puce, l'application de sécurisations devra générer un plan d'exécution réparti entre deux sites. Cette tâche, complexe pour une carte à puce, peut être simplifiée en imposant une façon particulière d'isoler les données sensibles. L'idée consiste à supprimer les données sensibles de la base stockée sur le serveur, en les remplaçant par des indices dans un domaine sensible (ensemble de données sans doublons), stocké lui, sur la carte à puce. Par exemple, les codes de cartes de crédit d'un ensemble de clients pourront être stockés comme des indices dans le domaine 'codes de cartes de crédit' stocké dans la carte à puce. Ce 'codage' des données sensibles peut être vu comme un chiffrement très particulier de ces données, chiffrement dont la particularité est d'être définitivement incassable sans la carte à puce. L'intérêt de cette modélisation est qu'elle permet de conserver exactement les mêmes techniques d'évaluation de requêtes, une partie de l'évaluation pouvant se faire sur le serveur puisque la propriété Va, Vb, a = b <=> Chiffre (a) = Chiffre (b) est préservée.
Pour ce qui concerne la durabilité et le partage, considérons tout d'abord le cas des données sensibles statiques (i.e., sans mises à jour). Ce cas particulier est susceptible de représenter une majorité de cas pratiques (par exemple, les données d'identification de particuliers ou de PME) . La durabilité des données statiques peut être assurée par le stockage redondant de ces données dans une carte à puce de backup . Cette carte de backup n'est utilisée qu'en cas de perte, vol ou destruction de la carte initiale. Le partage des données sensibles statiques est assuré par leur copie dans les cartes à puce de chaque utilisateur. Pour ce type de données, le niveau de sécurité atteint est maximum puisque aucune copie n'est accessible sur aucun serveur et que le contenu de la carte est considéré comme inviolable.
Considérons maintenant le cas des données dynamiques. Le partage et la durabilité de ces données doivent être assurés par un serveur connu de l'ensemble des utilisateurs partageant ces données. Ce serveur doit conserver l'historique des mises à jour effectuées sur les données dynamiques et diffuser, sur demande, ces mises à jour aux utilisateurs y ayant accès. Il est préférable que ce serveur soit distinct du serveur de données pour se prémunir contre des attaques internes (outre le cassage des clés de chiffrement, une coalition entre pirates internes des deux sites devient alors nécessaire pour mener une attaque) . Les données stockées sur le serveur de partage et de durabilité sont évidemment chiffrées. Notons qu'il est plus facile d'obtenir un chiffrement efficace sur ces données historiques car ici, aucune contrainte relative à l'exécution de requêtes n'est imposée sur les méthodes de chiffrement. A l'extrême, on peut envisager une clé différente pour chaque donnée historique.
La figure 7 résume une utilisation conjointe de l'ensemble des techniques exposées dans les sections précédentes, avec C-SDA s 'exécutant dans une carte à puce.
Les étapes de l'exécution d'une requête utilisateur sont les suivantes :
1. Lors de la connexion, l'application de sécurisation contacte le serveur de droits et de vues pour mettre à jour la liste des droits et des vues de l'utilisateur. Il les déchiffre avec sa base de clés.
2. l'application de sécurisation contacte le serveur de partage/durabilité afin de mettre à jour les données sensibles dynamiques hébergées par la carte à puce. 3. L'utilisateur émet une requête Q.
4. Les droits sont vérifiés par l'application de sécurisation avec la base de droits et de vues.
5. La requête, si elle met en jeu des vues, est traduite en une requête Q1 portant sur les relations de base.
6. La requête Q' est transformée en un plan d'exécution de la forme Q' = Qt(Qc(Qs)), éventuellement précédé de requêtes de préparation (* [QC P (Qs p) ] ) en cas de prédicats d' inégalité dont la sélectivité est intéressante à exploiter.
7. Qs est envoyée au serveur qui l'exécute sur les données chiffrées et renvoie les tuples résultats à l'application de sécurisation. Le résultat est déchiffré par l'application de sécurité en utilisant la base de clés. 8. La requête complément Qc est exécutée par l'application de sécurité.
9. Le résultat est éventuellement complété avec les valeurs des données sensibles (DS) lors des projections . 10. Le résultat final déchiffré est renvoyé au terminal qui exécute Qfc, c.à.d., le tri final s'il est demandé .
La figure 8 représente une vue de l'architecture de la carte de sécurité (4) . Le circuit électronique comporte un circuit d'interface entrée-sortie (14) pour les échanges avec l'équipement client (1) et le serveur (2) . La sortie de ce circuit (14) est relié à une mémoire tampon (15) .
La carte comporte également un microprocesseur (10) et une mémoire EEPROM (11) pour l'enregistrement du système d'exploitation et de l'application de sécurité et une mémoire (12) pour l'enregistrement des données personnelles de l'utilisateur et en particulier la clé de chiffrement ou les paramètres de chiffrement de l'utilisateur, ainsi que les données relatives aux droits de l'utilisateur.
La carte comporte encore une mémoire vive (15) comportant des registres (16) pour l'enregistrement des données intermédiaires des calculs, et un compteur (17) pour la réalisation des calculs correspondant à des requêtes contenant des prédicats statistiques tels que des moyennes .
L'invention est décrite dans ce qui précède de façon non limitative. L'architecture du moyen de sécurisation peut être réalisé sous différentes formes sans pour autant sortir du cadre de l'invention.

Claims

REVENDICATIONS
1 - Système de gestion sécurisée de bases de données confidentielles comprenant un serveur constitué par au moins un ordinateur équipé de moyens d'enregistrement de bases de données et de moyens de communication, par au moins un équipement informatique hôte comprenant des moyens de communication avec le serveur et des moyens pour la construction de requêtes et le traitement des résultats des requêtes, ainsi qu'un moyen de sécurisation des échanges entre l'équipement client (1) et le serveur, caractérisé en ce que ledit moyen de sécurisation est constitué par un support matériel sécurisé relié à l'équipement client (1) et comportant un microprocesseur pour le chiffrement des attributs des requêtes émises par l'équipement client (1) et le déchiffrement des réponses émises par le serveur, une mémoire pour l'enregistrement de résultats intermédiaires, une mémoire pour l'enregistrement du système d'exploitation et que ledit serveur enregistre des données chiffrées.
2 - Système de gestion sécurisée de bases de données selon la revendication 1, caractérisé en ce que le moyen de sécurisation est constitué par une carte à microprocesseur .
3 - Système de gestion sécurisée de bases de données selon la revendication 1, caractérisé en ce que le moyen de sécurisation est constitué par une clé raccordable sur un port d'un équipement client (1) .
4 - Système de gestion sécurisée de bases de données selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de sécurisation comprend en outre une mémoire pour l'enregistrement des informations de personnalisation de l'utilisateur. 5 - Système de gestion sécurisée de bases de données selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de sécurisation comporte en outre au moins un compteur pour l'exécution de requêtes statistiques.
6 - Système de gestion sécurisée de bases de données, selon l'une quelconque des revendications précédentes caractérisé en ce que le moyen de sécurisation comporte en outre un registre pour la gestion des droits téléchargés lors de l'ouverture d'une session avec le serveur.
7 - Système de gestion sécurisée de bases de données selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de sécurisation comporte en outre une mémoire pour l'enregistrement d'une partie de la base de données.
8 - Procédé de gestion sécurisée d'une base de données comportant une étape de construction d'une requête comprenant au moins un attribut, caractérisé en ce qu'il comporte une étape de chiffrement des attributs par un calculateur solidaire d'un dispositif individuel de sécurité relié à un équipement client, le procédé consistant à interroger ensuite une base de données contenant des données chiffrées avec les mêmes moyens de chiffrement que ceux utilisés lors de l'étape précédente, à retourner une réponse contenant les données correspondant aux attributs de la requête et à procéder au déchiffrement desdites données par ledit calculateur d'un dispositif individuel de sécurité avant de les transmettre à 1 ' équipement hôte . 9 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que le chiffrement des attributs de la requête et le déchiffrement de la réponse est réalisé par une application de sécurité exploitée par une carte à microprocesseur.
10 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que le chiffrement des attributs de la requête et le déchiffrement de la réponse est réalisé par une application de sécurité exploitée par une clé raccordable sur un port d'un équipement client.
11 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que le chiffrement des attributs de la requête et le déchiffrement de la réponse est réalisé selon un algorithme à clé secrète tel que DES.
12 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que la traduction de requêtes est limitée aux prédicats d'égalité pour permettre l'exécution desdites requêtes exécutables directement par le serveur sur des données chiffrées.
13 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que la traduction de requêtes comportant des prédicats d' inégalité ou fonctions de calcul comporte une étape de décomposition de la requête Q en un plan Qt(Qc(Qs))), d'interrogation de la base de données chiffrées (3) par des requêtes d'inégalités à partir d'attributs chiffrés, une étape d'enregistrement des résultats des requêtes dans une mémoire temporaire du moyen de sécurisation individuel après déchiffrement des données, et de recomposition du résultat .
14 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que la traduction de requêtes comportant des prédicats d' inégalité ou fonctions de calcul comporte une étape de décomposition d'une requête en un plan Q = Qt (Qc (Qa (* [QC P (QS P) ] ) ) ) , où Qc p et Qs p sont des requêtes de préparation, d'interrogation de la base de données chiffrées (3) par des requêtes d'inégalités à partir d'attributs chiffrés, une étape d'enregistrement des résultats des requêtes dans une mémoire temporaire du moyen de sécurisation individuel après déchiffrement des données, et de recomposition du résultat .
15 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce qu'une partie de la base des données est enregistrée dans une mémoire du moyen individuel de sécurisation.
16 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que la résolution d'une requête SQL est réalisée en effectuant les étapes de saisie de la requête en clair sur l'équipement client (1), de chiffrement par l'application de sécurité (4) de l'attribut de la requête et l'envoi de la requête chiffrée au serveur, de résolution de la requête sur les données chiffrées par le serveur (2), déchiffrement du résultat sur la carte (4) et de restitution du résultat en clair sur l'équipement client (1).
17 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce que la résolution d'une requête SQL comportant des prédicats d'inégalité ou des fonctions de calcul est réalisée en effectuant les étapes de saisie de la requête en clair sur l'équipement client (1), de chiffrement par l'application de sécurité (4) et d'envoi au serveur (2) d'une sous- requête chiffrée Qs , contenant uniquement des prédicats d'égalité, de résolution de la requête sur les données chiffrées par le serveur, de déchiffrement du résultat de Qs et évaluation de Qc et de reconstruction de la réponse à la requête initiale par l'application de sécurisation (4).
18 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce qu'il comporte un pré-traitement coopératif entre la carte et le serveur, consistant, pour une requête Q contenant un prédicat de la forme σai θ valeur(T) , où σ dénote l'opérateur de restriction, θ G {<, >, ≤, >} et a. est un attribut quelconque de la table T, à envoyer au serveur une requête de pré-traitement QS P = IIclé/ al(T), Il dénotant l'opérateur de projection, à exécuter sur le moyen de sécurisation (4) la fonction Qc p = πclé (σai θ valeur (πclé; Dëchiffe(ai) (QsP) ) ) de renvoyer le résultat R au serveur (2), l'application de sécurisation (4) transformant ensuite la requête Q en remplaçant le prédicat initial σai θ valeur (T) par le prédicat
°<:(T, R) , où ∞ dénote l'opérateur de semi-jointure sur clé.
19 - Procédé de gestion sécurisée d'une base de données selon la revendication 8, caractérisé en ce qu'il comporte les étapes suivantes :
- Lors de la connexion, l'application de sécurisation contacte le serveur de droits et de vues pour mettre à jour la liste des droits et des vues de l'utilisateur. Il les déchiffre avec sa base de clés. - L'application de sécurisation contacte le serveur de partage/durabilité afin de mettre à jour les données sensibles dynamiques hébergées par la carte (4), - L'utilisateur émet une requête Q,
- Les droits sont vérifiés par l'application de sécurisation avec la base de droits et de vues,
- La requête, si elle met en jeu des vues, est traduite en une requête Q1 portant sur les relations de base,
La requête Q ' est transformée en un plan d' exécution de la forme Q' = Qt (Qc ( Qs ) ) , éventuellement précédé de requêtes de préparation (*[QC P (QsP) 1) en cas ^e prédicats d'inégalité dont la sélectivité est intéressante à exploiter,
- Qs est envoyée au serveur qui l'exécute sur les données chiffrées et renvoie les tuples résultats à l'application de sécurisation, le résultat est déchiffré par l'application de sécurité en utilisant la base de clés,
La requête complément Qc est exécutée par l'application de sécurité,
- Le résultat est éventuellement complété avec les valeurs des données sensibles (DS) lors des projections,
- Le résultat final déchiffré est renvoyé au terminal qui exécute Qfc, c.à.d., le tri final s'il est demandé.
PCT/FR2002/002824 2001-08-07 2002-08-07 Procede de securisation de bases de donnees WO2003014888A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20020779619 EP1415215A1 (fr) 2001-08-07 2002-08-07 Procede de securisation de bases de donnees
US10/485,785 US20050044366A1 (en) 2001-08-07 2002-08-07 Method for making databases secure

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR01/10552 2001-08-07
FR0110552A FR2828607B1 (fr) 2001-08-07 2001-08-07 Procede de securisation de bases de donnees

Publications (1)

Publication Number Publication Date
WO2003014888A1 true WO2003014888A1 (fr) 2003-02-20

Family

ID=8866350

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/002824 WO2003014888A1 (fr) 2001-08-07 2002-08-07 Procede de securisation de bases de donnees

Country Status (4)

Country Link
US (1) US20050044366A1 (fr)
EP (1) EP1415215A1 (fr)
FR (1) FR2828607B1 (fr)
WO (1) WO2003014888A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006087604A2 (fr) * 2004-11-09 2006-08-24 Fortiva Inc. Systeme et procede de stockage securise et consultable
US7418600B2 (en) 2003-03-13 2008-08-26 International Business Machines Corporation Secure database access through partial encryption

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7500111B2 (en) * 2003-05-30 2009-03-03 International Business Machines Corporation Querying encrypted data in a relational database system
US7685437B2 (en) * 2003-05-30 2010-03-23 International Business Machines Corporation Query optimization in encrypted database systems
US10339336B2 (en) * 2003-06-11 2019-07-02 Oracle International Corporation Method and apparatus for encrypting database columns
US20070011158A1 (en) * 2005-07-06 2007-01-11 Parikh Prashant S Personal information database with context-driven information retrieval
US8135948B2 (en) * 2006-01-27 2012-03-13 Imperva, Inc. Method and system for transparently encrypting sensitive information
US8510846B1 (en) * 2006-06-29 2013-08-13 Google Inc. Data encryption and isolation
US7599936B2 (en) * 2006-12-22 2009-10-06 Verizon Services Organization Inc. Publication service using web pages and web search engines
US9275249B1 (en) * 2013-03-07 2016-03-01 Amazon Technologies, Inc. Accelerated encrypted database operations
US9311504B2 (en) * 2014-06-23 2016-04-12 Ivo Welch Anti-identity-theft method and hardware database device
CN104348609B (zh) * 2014-09-18 2017-06-06 成都西山居互动娱乐科技有限公司 一种非存储的密码管理算法
US9767219B2 (en) * 2014-10-27 2017-09-19 Successfactors, Inc. Automatic detection of queries missing order-by via unit test
DE202015009141U1 (de) 2015-10-15 2016-11-03 Tesa Se Klebemasse, insbesondere für stripbare Klebestreifen, und Verwendung zur Verklebung auf getrichener Raufasertapete
US10284535B2 (en) * 2016-12-13 2019-05-07 Chronicle Llc Secure database
CN111225051A (zh) * 2020-01-03 2020-06-02 湖北民族大学 一种新型云环境下静态数据安全共享系统及方法
US11582208B1 (en) 2021-10-11 2023-02-14 Cisco Technology, Inc. Detecting domain fronting through correlated connections
CN116861474B (zh) * 2023-05-26 2024-02-20 东莞市铁石文档科技有限公司 一种在线档案安全评估系统和方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5559888A (en) * 1994-02-15 1996-09-24 Lucent Technologies Inc. Secure information retrieval service (SIRS)
EP0766184A2 (fr) * 1995-09-27 1997-04-02 Sun Microsystems, Inc. Dispositif et procédé pour garantir un accès niveau SQL en toute sécurité à une base de données
US5721777A (en) * 1994-12-29 1998-02-24 Lucent Technologies Inc. Escrow key management system for accessing encrypted data with portable cryptographic modules
US5963642A (en) * 1996-12-30 1999-10-05 Goldstein; Benjamin D. Method and apparatus for secure storage of data
US20010007975A1 (en) * 1998-10-26 2001-07-12 Gte Service Corporation Data access system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5913214A (en) * 1996-05-30 1999-06-15 Massachusetts Inst Technology Data extraction from world wide web pages
US7272723B1 (en) * 1999-01-15 2007-09-18 Safenet, Inc. USB-compliant personal key with integral input and output devices
US6615349B1 (en) * 1999-02-23 2003-09-02 Parsec Sight/Sound, Inc. System and method for manipulating a computer file and/or program
US7093137B1 (en) * 1999-09-30 2006-08-15 Casio Computer Co., Ltd. Database management apparatus and encrypting/decrypting system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5559888A (en) * 1994-02-15 1996-09-24 Lucent Technologies Inc. Secure information retrieval service (SIRS)
US5721777A (en) * 1994-12-29 1998-02-24 Lucent Technologies Inc. Escrow key management system for accessing encrypted data with portable cryptographic modules
EP0766184A2 (fr) * 1995-09-27 1997-04-02 Sun Microsystems, Inc. Dispositif et procédé pour garantir un accès niveau SQL en toute sécurité à une base de données
US5963642A (en) * 1996-12-30 1999-10-05 Goldstein; Benjamin D. Method and apparatus for secure storage of data
US20010007975A1 (en) * 1998-10-26 2001-07-12 Gte Service Corporation Data access system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DOMINGO-FERRER J: "Multi-application smart cards and encrypted data, processing", FUTURE GENERATIONS COMPUTER SYSTEMS, ELSEVIER SCIENCE PUBLISHERS. AMSTERDAM, NL, vol. 13, no. 1, 1 July 1997 (1997-07-01), pages 65 - 74, XP004081710, ISSN: 0167-739X *
FERREIRA R: "THE PRACTICAL APPLICATION OF STATE OF THE ART SECURITY IN REAL ENVIRONMENTS", ADVANCES IN CRYPTOLOGY - AUSCRYPT. SYDNEY, JAN. 8 - 11, 1990, PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON CRYPTOLOGY - AUSCRYPT, BERLIN, SPRINGER, DE, vol. CONF. 1, 8 January 1990 (1990-01-08), pages 334 - 355, XP000145211, ISBN: 3-540-53000-2 *
See also references of EP1415215A1 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7418600B2 (en) 2003-03-13 2008-08-26 International Business Machines Corporation Secure database access through partial encryption
US7992010B2 (en) 2003-03-13 2011-08-02 International Business Machines Corporation Secure database access through partial encryption
US8001389B2 (en) 2003-03-13 2011-08-16 International Business Machines Corporation Secure database access through partial encryption
US8032765B2 (en) 2003-03-13 2011-10-04 International Business Machines Corporation Secure database access through partial encryption
WO2006087604A2 (fr) * 2004-11-09 2006-08-24 Fortiva Inc. Systeme et procede de stockage securise et consultable
WO2006087604A3 (fr) * 2004-11-09 2007-01-11 Fortiva Inc Systeme et procede de stockage securise et consultable
US7512814B2 (en) 2004-11-09 2009-03-31 Fortiva Inc. Secure and searchable storage system and method

Also Published As

Publication number Publication date
US20050044366A1 (en) 2005-02-24
FR2828607A1 (fr) 2003-02-14
EP1415215A1 (fr) 2004-05-06
FR2828607B1 (fr) 2004-01-30

Similar Documents

Publication Publication Date Title
US11373192B2 (en) Apparatus for customer authentication of an item
US8613107B2 (en) System, method and apparatus for electronically protecting data associated with RFID tags
US8826448B2 (en) System, method and apparatus for electronically protecting data and digital content
WO2003014888A1 (fr) Procede de securisation de bases de donnees
US20170228371A1 (en) Blockchain-enhanced database
TWI388183B (zh) 用以使敏感資料及關聯記錄無法識別之系統和方法
US8359271B2 (en) Apparatus for customer authentication of an item
US7937579B2 (en) System, method and apparatus for electronically protecting data and digital content
EP3547203A1 (fr) Méthode et système de gestion d&#39;accès à des données personnelles au moyen d&#39;un contrat intelligent
CN103039057B (zh) 对移动中数据进行保护的系统和方法
US20100005509A1 (en) System, method and apparatus for electronically protecting data and digital content
US20080222734A1 (en) Security System with Extraction, Reconstruction and Secure Recovery and Storage of Data
US20120089835A1 (en) System and Method for Automatic Authentication of an Item
Mukherjee Popular SQL server database encryption choices
EP1095491A1 (fr) Procede, systeme, serveur et dispositif pour securiser un reseau de communication
Madyatmadja et al. Performance testing on Transparent Data Encryption for SQL Server's reliability and efficiency
WO2020136206A1 (fr) Plateforme de sécurisation de données
Nanda et al. Oracle Privacy Security Auditing: Includes Federal Law Compliance with HIPAA, Sarbanes-Oxley & the Gramm-Leach-Bliley Act GLB
EP3889809A1 (fr) Protection d&#39;un logiciel secret et de données confidentielles dans une enclave sécurisée
EP3863219A1 (fr) Procédé et dispositif d&#39;évaluation de correspondance d&#39;ensembles de données structurées protégées par le chiffrement
KR20230085314A (ko) 블록체인 기반 게놈 데이터 저장 및 보호 시스템
WO2002065411A2 (fr) Methode et systeme de securisation d&#39;une transaction commerciale au moyen d&#39;une carte a memoire
WO2010040150A1 (fr) Système et procédé destinés à l&#39;authentification client d&#39;un article
Doyle Lock up your data
CA3050353A1 (fr) Procede de recherche d&#39;informations dans un corpus chiffre stocke sur un serveur

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP

Kind code of ref document: A1

Designated state(s): CA JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FR GB GR IE IT LU MC NL PT SE SK TR

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR

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: 2002779619

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002779619

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10485785

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP