EP0947072A1 - Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank - Google Patents

Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank

Info

Publication number
EP0947072A1
EP0947072A1 EP97945716A EP97945716A EP0947072A1 EP 0947072 A1 EP0947072 A1 EP 0947072A1 EP 97945716 A EP97945716 A EP 97945716A EP 97945716 A EP97945716 A EP 97945716A EP 0947072 A1 EP0947072 A1 EP 0947072A1
Authority
EP
European Patent Office
Prior art keywords
data
user
database
signature
key
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP97945716A
Other languages
English (en)
French (fr)
Inventor
Alfred Schmid
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ascom Systec AG
Original Assignee
Ascom Systec AG
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 Ascom Systec AG filed Critical Ascom Systec AG
Publication of EP0947072A1 publication Critical patent/EP0947072A1/de
Withdrawn legal-status Critical Current

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/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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 invention relates to a method for electronically secured storage of data in a database and a device for performing the method.
  • a database is understood to be a structured, content-related data pool.
  • the database consists of one or more tables (or objects), each with a series of identical data records.
  • Each data record is composed of a number of data fields. Normally, the number and nature of the data fields for a certain type of data record in the database are identical.
  • the various application programs and users can access shared data in database environments. On the one hand, this prevents problems such as redundancy and inconsistency of data and data structures, on the other hand, the threat potential regarding database security increases.
  • Database security violations include unlawful reading, modification, or deletion of data or the prevention of the same.
  • Unauthorized gain of information by reading data through deliberate or accidental access by an unauthorized user.
  • the information gain of inadmissible information obtained by inference from permitted accesses also belongs to this category.
  • Unauthorized modification (loss of integrity) of data includes all violations of data integrity. It is not absolutely necessary that an illegal gain of information must have taken place beforehand.
  • Disruption and sabotage Loss of availability. This includes all actions that prevent the legitimate users of a system from using them. Protecting a database from possible attacks means that the infrastructure, especially the stored data, must be protected against accidental or deliberate unauthorized access (reading and / or modification).
  • a method for securing the integrity of (electronically stored) data is known from US Pat. No. 5,097,504.
  • the data stored in plain text are provided with a signature that is unique to the text and the author.
  • the parameters (e.g. key, program) for calculating the signature are e.g. stored in a protected memory card with an integrated processor.
  • a series of information elements (there Fig. 4: D, B, A) is multiplied by a corresponding number of random numbers (Ci) and added. The resulting sum is subjected to a modulo operation. The result is the signature.
  • the information elements can be calculated with any numerical values such as e.g. can be combined or supplemented with the date or the identification of the signatory.
  • the procedure is primarily intended for the transmission of messages. A powerful computer is required to use it to protect a database.
  • a special method is proposed for this large amount of data, in which the data to be processed are divided into data blocks for calculating the signature (column 6, lines 41-44).
  • the individual bits can be grouped so that they only partially represent the "characters" (column 7, lines 1-5).
  • a partial signature is created for each data block, so that the entire signature is formed by a series of individual partial signatures (column 6, lines 54-56).
  • the partial signatures can be attached to the corresponding data blocks (column 7, lines 24-28). In this way, backup copies of databases can be signed (column 12, lines 37-38).
  • the European patent application EP 0 709 760 A2 deals with a method for the administration of copyrights.
  • the data to be managed are not central, but stored in a network of computers.
  • the dates are not in Form of data records with a fixed structure included, but in any files.
  • In order to control the recycling of copyrighted data they are encrypted before being transmitted to the user, so that they can only be read and reused using a key to be obtained from a central office.
  • a method for the certification of keys in public key systems is known from EP 0 386 867 A2.
  • the aim is to enable the transmission of data (such as e-mail and electronic transfers or payments) via insecure channels.
  • data such as e-mail and electronic transfers or payments
  • the signature is created, the data (object) is subjected to a hash function.
  • Date and identification of the signer are also included in the signature.
  • the object of the invention is to protect the data stored in a database against accidental or deliberate unauthorized access (modifications).
  • each data record (which contains the useful data) is first provided with a user ID and then with an electronic signature when it is created or changed.
  • the content of the signature is based on both the user data and the user ID. In principle, it is created with a one-way function that has a secret, user-specific key as a parameter. Only the data record thus supplemented is stored on the available storage medium in the form of an expanded data record. The signature therefore represents an additional field in the data record.
  • the method described has the advantage that the data backed up in this way can in principle be read by any user (who is admitted to the database) and, if necessary, changed, but that it can always be subsequently determined who made the changes.
  • the electronic Signature ensures that it can be checked whether the user ID and the data are authentic. It is therefore not possible for someone to change data under another user ID
  • the invention differs from the prior art according to US Pat. No. 5,097,504 in that individual data records are processed.
  • a database is not secured as a whole with signatures. Rather, the data records of certain selected tables are selectively encoded in the invention.
  • the table is in which records the illnesses of each patient, is secured by a signature according to the invention, while the assigned tables with the addresses of the patients, for example, are deliberately not saved (and as a result can be created and changed without a complex procedure).
  • the formation of blocks proposed in US Pat. No. 5,097,504 does not take into account the database structure, but only assumes how many bits can be processed with a signature with reasonable computing effort
  • the user data are reduced together with the user ID to a bit sequence of a predetermined length with the aid of a hash function.
  • the hash function is a one-way function which carries out compression of the data in such a way that the probability that the result despite different output data same function value, negligibly small D h it creates a kind of fingerprint
  • An asymmetric encryption method is used to generate the electronic signature.
  • the secret key is used to generate and the public key to verify the electronic signature.
  • RSA public key cryptosystem by Ron Rivest Adi Shamir and Leonard Adleman, see US 4 405 829 DSA Digital Signature Algo ⁇ thm according to the American Digital Signature Standard
  • Every user has to register with this center in order to provide his user ID and public key.
  • the control center maintains a list which contains the user IDs of the existing users and the corresponding keys. Each entry in the list is preferably signed by the center.
  • a user now wants to check a signature of a data record, he takes the public key listed in the central list and belongs to the user ID of the data record in question and checks the electronic record signature.
  • the electronic signature of the head office can be used to determine that the public key and the user ID actually belong to the corresponding user (i.e. his person).
  • check functions are provided that check the data entered for its logical consistency. That The data to be stored in a certain field of a data record must be of the correct data type. These test functions can be more or less expanded. In connection with the invention it is important that an input or change of sensitive data is only accepted if the electronic signature is present. (The system does not necessarily have to check the user signature when entering the data.)
  • the database has to offer special security, it is an advantage if no deletion is carried out in general or if the data is changed, but only a deletion mark. This is also according to the invention with a marked electronic signature. This makes it possible to trace the history of a data record and determine responsibility.
  • a secure time base is preferably provided, which can be used to date an entry or change. Secure means that it must not be possible to enter an incorrect time (date / time). This is particularly important when sensitive data has to be processed from workstations that are far apart. It goes without saying that the time stamp should also be included in the electronic signature. Of course, the timestamp should not be manipulable. If such a time stamp is not available at all workstations, the server can possibly (additionally) attach a time stamp itself, so that e.g. at least users cannot backdate changes.
  • the invention can of course not only be used to back up individual data records.
  • entries in the dictionary (authorization files, security axioms, integrity conditions or the like), entire user profiles and log files can also be protected.
  • the key to generating the electronic signature is preferably stored neither in the computer system that manages the database, nor in a decentralized workstation, but in a personal chip card. This should meet a high security standard (the security of the known CP8 card should be mentioned as an example).
  • the secret key should not have to be given from the card when generating the electronic signature.
  • a chip card reader To operate the database system, a chip card reader must be provided at the workplace. Whenever an electronic signature has to be generated, the corresponding clear data is transferred from the chip card reader to the chip card, which in turn creates and issues the signature.
  • the method according to the invention can be implemented with hardware known per se. In order to be able to implement the preferred embodiment with the chip cards, chip card readers must be provided at the work stations.
  • the signature is physically calculated as close as possible to the input device and added to the data record.
  • Figure 1 is a schematic representation of the principle for backing up the data.
  • FIG. 2 shows a schematic representation of a computer system for carrying out the method.
  • the data records in the database are additionally secured with an integrity condition (check constraint) against undetectable manipulation by generating a digital signature (a kind of checksum) of the entered data. This will of course insert redundant information. But on the other hand, the authenticity and origin of the data are protected against undetectable manipulation.
  • an integrity condition check constraint
  • a digital signature a kind of checksum
  • the data records for the user profiles (e.g. access rights and privileges at operating system level) can be saved in the same way.
  • the entries for the log file and the logbook are also provided with a sequential number in order to delete an entry Being able to determine Deletion and duplication cannot generally be prevented by cryptographic methods alone
  • Each data record has the actual information (this can be made up of several attributes - such as name, address, age, blood type, etc.) Patients - exist), which depends on the intended use, three additional attributes
  • the information defines the WHAT, the time stamp the WHEN and the user ID the WHO.
  • the digital signature protects the authenticity of the previously mentioned data parts
  • the useful information is designated by M and depends on the specific application. It is formed, for example, by the name, address or further details of a person. According to an advantageous embodiment, a time stamp TS (date, time) is also available This is always recorded when the user information M is entered or changed.
  • An indispensable attribute is the user identifier Ui. It is a code or a number which allows the specified user to be clearly identified
  • the three named elements of the data set are converted into a bit sequence H with a fixed length (for example 128 bits) using a hash function HF.
  • a one-way function E kl into a code C (with a length of, for example, 512 or 1024 bits), which serves as an electronic signature and is added to the data record.
  • the one-way function has the user's secret key Ki (private key) as a parameter.
  • Fig. 2 shows a rough block diagram of a database system.
  • the data are managed by a server, which has a computer 2 and a memory 3 in a conventional manner.
  • the data is entered or changed at a terminal 4 (workstation). This includes Via a known input device 5 (keyboard, barcode reader, screen, etc.), a clock 6 and a card reader 7. A line 9 connects the terminal 4 to the server 1.
  • a known input device 5 keyboard, barcode reader, screen, etc.
  • a clock 6 and a card reader 7.
  • a line 9 connects the terminal 4 to the server 1.
  • the data M are entered on the input device 5.
  • the data M are transferred to the chip card 8 together with a time stamp generated by the clock 6 via card reader 7. This creates the signature described above.
  • the data record consisting of the data M, the time stamp TS, the user identification (which is preferably stored in the chip card 8 and is issued by the latter) and the electronic signature can then be transmitted to the server 1 via line 9.
  • the effective information M of the data record is collected.
  • men with the time stamp TS and the user identifier Ui first compressed using a suitable hash function (one-way function, message digest), that is to say generates a type of fingerprint H (M
  • M TS
  • H a type of fingerprint
  • the database system only accepts a data record if the above constraint is correct, i.e. the signature can be derived from the other elements.
  • the simplest case of cryptographically securing entries with a digital signature only includes the actual information without a secure date. Even in the event that the information part has a time indication, it cannot be trusted unless it is ensured in any way that the wrong time cannot be used.
  • the user ID is necessary so that the signature can be checked with the public key.
  • the disadvantage of missing a time is, of course, that the time of the transaction cannot be easily deduced.
  • a fingerprint of the entered data and the user ID is initially generated (hash function).
  • the database system enters the user ID of the user authenticated at the beginning of the session in the data record.
  • the fingerprint of the data and the user ID are encrypted in a signature unit.
  • the generated signature is entered in the data record and the transaction is completed.
  • the signature unit contains the secret key Ki. This must be kept secret, otherwise another user can sign - without being able to determine it.
  • a secure integrity check system and a corresponding integrity condition are also required so that an illegal entry by the DBMS (Data Base Management System) is reliably rejected. An invalid entry can arise, for example, if an attacker changes the fingerprint or the user ID. It is therefore not necessary to request secure paths and functions for the same.
  • the user ID and the digital signature can be generated in a (physically separate) functional unit.
  • To each user ID Ui has exactly one secret key Ki. Therefore, it makes sense to combine the two sizes in one unit (e.g. smart card) - protected against manipulation.
  • the data record is entered in the database after the following steps:
  • the fingerprint is encrypted in a signature unit.
  • the generated signature is entered in the data record together with the user ID contained in the signature unit and the transaction is completed.
  • the signature unit in turn contains the secret key Ki and the identifier Ui of the user.
  • a time stamp TS date and time
  • the server can e.g. provide signed time codes.
  • a radio clock can be provided, which records the time (also with a forgery-proof code).
  • a data record is therefore entered in the manner listed below:
  • the user enters the data in the individual attributes of the data record and closes the transaction (commit). 2.
  • a fingerprint of the data entered, the time stamp and the user ID is initially generated.
  • the fingerprint is encrypted in a signature unit (e.g. smart card).
  • a signature unit e.g. smart card
  • the generated signature is entered in the data record and the transaction is completed.
  • the DBMS must provide a secure path for the user entries.
  • the time service must provide a sufficiently precise and reliable time specification and be resistant to manipulation.
  • the signing unit in turn contains the secret key Ki and the user identification Ui.
  • a log record is created as follows:
  • the DBMS or the operating system reports an event to be logged to the log monitor.
  • Event handling generates the next data record number and the associated information (message). 3. The current time and date are added to the data record.
  • a fingerprint is created from the number, the information, the time stamp and the user identification.
  • the fingerprint is encrypted in the signature unit.
  • the signature unit contains the secret key ⁇ p and the identifier U p of the protocol monitor.
  • the monitor identifier u P in the log entries is not absolutely necessary if only a global monitor is available.
  • the integrity of a data record is checked in reverse by the system (when saving) or by a user.
  • a secure integrity checking system and a corresponding integrity condition are required so that an "invalid" entry is reliably rejected by the DBMS.
  • the corresponding public key of the user recorded in the data record is necessary for checking a digital signature.
  • the public key must be available in the form of a certificate.
  • Such certificates are issued by an independent, trustworthy entity (authentication center). They prove that the user ID and the public key belong together. The authenticity of a certificate can also be checked using the issuing authority's public key.
  • a newly entered or modified data record is checked for a correct signature as follows:
  • the integrity condition is triggered by an INSERT or UPDATE command.
  • the user ID is determined from the data record.
  • the digital signature is decrypted using the public key.
  • the fingerprint obtained from the digital signature and the user ID are compared with the fingerprint calculated in step 2 and the user ID entered in the data record. 7. If the components match, the transaction is accepted, in all other cases rejected.
  • the DBMS must offer a secure mechanism for integrity checking. Otherwise entries can be made without a correct signature.
  • the user ID is determined from the data record.
  • the digital signature is decrypted using the public key.
  • the fingerprint obtained from the digital signature and the user ID are compared with the fingerprint calculated in step 2 and the user ID entered in the data record.
  • the data record is authentic, i.e. no unauthorized modification has taken place.
  • At least one component of the data record must be able to be routed to the test function via a secure channel.
  • the result of the check must also be communicated to the user via a secure channel can.
  • the test unit contains the public key ⁇ a 'and the identifier u a of the certification body.
  • the attribute for the time stamp TS (if available) must be based on a trusted time base and program logic (trusted code).
  • a trustworthy entity is necessary for the certification of user ID u and public key K, 'so that a masquerade by another user u' can be prevented or avoided. can be recognized.
  • the secret key ⁇ 1 is only known to one user (or a user group) so that the authorized user cannot be denied (repudiation). Otherwise he can claim someone else had signed.
  • the encryption of the data can be carried out at different levels. Encryption on the disk, I / O or file system level only provides protection against theft of the disk or the backup copies, especially when using ent / server applications in network environments encryption at the lowest (physical) level does not provide effective protection
  • the best protection of confidentiality can be achieved with cryptographic procedures if the data has already been encrypted by the user or only then deciphered again there
  • the confidentiality of data records can be guaranteed by encrypting the information they contain. Only users who have the secret key K are able to interpret the information again in plain text.
  • the authorized users form a closed user group, so that other users with other privileges (e.g. system manager, DBA, network operator) can still not interpret the information.
  • other privileges e.g. system manager, DBA, network operator
  • Information M can be understood to mean all attributes of a data record (also including a time stamp, user ID and digital signature) or only individual attributes that need special protection.
  • administration eg adding an additional attribute
  • Another advantage of this approach is the optional encryption of attributes.
  • the data record does not have to be a whole, but the individual attributes can be encrypted as required (e.g. only the particularly sensitive data). In the following example, only the two attributes A and A 2 are stored encrypted in the data record.
  • the remaining attributes A 3 . , , A N are saved in plain text.
  • the table contents of a database can be encrypted with a single key K. Every user who has this key has access to the plain text space. All other users can at most gain insight into the ciphertext space.
  • the key K- is encrypted with the public key K, ⁇ of the user u, and an asymmetrical algorithm. Only the user u has the associated secret key ⁇ L and is therefore able to determine the key ⁇ ⁇ .
  • the user who distributes the inspection rights will, of course, also grant himself such rights so that he can later also access the corresponding data.
  • the method described has the advantage that there is no need to have a higher-level entity that manages the secret keys it for confidentiality protection.
  • Each user issues the keys themselves, i.e. anyone can be the issuing authority for inspection certificates.
  • the above-mentioned certificates can include the encrypted access key K-. and the user ID u A contain further details about the period of validity, the identifier of the issuing office and a signature of the issuing office.
  • the signature in the certificates has the advantage that counterfeits can be recognized immediately.
  • Encryption or electronic signing can e.g. with the so-called PGP program by Philip Zimmermann. This program was developed in the USA, is available on various platforms and is based on the following algorithms:
  • the program therefore offers ready-made procedures for confidentiality protection and authentication.
  • Both functions can be used in combination, so that confidentiality and authentication are guaranteed at the same time, by first signing the data with your own secret key and then encrypting it with the recipient's public key.
  • the steps are used in reverse for the recipient, by first decrypting the encrypted message with the secret key and then checking the authenticity with the public key. The steps are carried out automatically by PGP.
  • the symmetrical IDEA algorithm is used for the encryption of data, because symmetrical methods are many times faster than the asymmetrical ones.
  • the PGP generates a temporary key for encryption (invisible to the user) and uses it to encrypt the plain text.
  • the temporary key is encrypted asymmetrically with the recipient's public key and transmitted to the recipient together with the ciphertext.
  • the recipient uses his or her secret key to find the temporary key. With the temporary key and the fast symmetrical procedure, he finally restores the plain text.
  • the public keys are stored together with the user ID and a time stamp of the generation in public key certificates.
  • the secret keys are stored in secret key certificates.
  • Each secret key is also encrypted with a password so that the key cannot be used in the event of theft.
  • a key file, or key ring can include several certificates.
  • Public keyrings contain public key certificates and secret keyrings contain secret key certificates.
  • the keys are referenced in the PGP by a so-called key ID. This is an abbreviation of the public key, in which the last 64 bits are used for the key ID.
  • the key pair is derived from large real random numbers, so that the case can be excluded that two independent users generate the exact same key pair.
  • the random numbers are mainly derived from the time intervals between keystrokes when entering any text.
  • the typed text also influences the result, so that the same key should not always be printed
  • the integrity of a certificate can then be checked using the trustworthy public key. To do this, of course, you have to have the trustworthy public key and be assured that the key is not tampered with. The integrity could therefore be secured again with a different signature.
  • a public key may only be used if it bears the signature of a trusted person or comes directly from the user whom you trust.
  • a PGP signature also contains a time stamp, but you cannot rely on it because it is derived from the system time and the system time can of course be manipulated. Also included in the PGP signature is a key identification (key ID) k ⁇ With which the PGP program can independently select the correct public key ⁇ 'when checking a PGP signature.
  • the user enters the data in the individual attributes of the data record and closes the transaction.
  • the PGP program When the transaction is completed by the user, the PGP program first creates a fingerprint (message digest) from the entered data and the user ID using the MD5 algorithm. 3. The user releases the secret key Ki by means of a password (or an entire sentence).
  • the PGP program generates the signature using the RSA algorithm, the user's secret key and the fingerprint.
  • the database system enters the user ID of the user authenticated at the start of the session and the signature created in the data record and closes the transaction.
  • the secret key ⁇ A is stored encrypted in a file.
  • the key can be activated by entering the correct password or phrase.
  • the file should not be accessible to other users.
  • the corresponding public key of the user recorded in the data record is necessary for checking a digital signature.
  • the public key must be available in the form of a certificate.
  • certificates can either be issued by the individual users themselves (network structure) or issued by an independent, trustworthy entity (tree structure). The certificates prove that the user ID and the public key belong together.
  • the information in the data record is prepared together with the user ID and the fingerprint is calculated using the MD5 algorithm.
  • the key identifier k is extracted from the PGP signature.
  • the associated public key is determined from the corresponding certificate z ⁇ .
  • the digital signature is decrypted with the public key and compared with the fingerprint calculated in step 1.
  • the data record is authentic, i.e. there has been no unauthorized modification of data and user ID.
  • At least one component of the data record (information or signature) must be routed to the PGP program via a secure channel.
  • the result of the check must also be able to be communicated to the user via a secure channel.
  • the data exchange with the PGP program takes place either via files or pipes.
  • the way is selected via files.
  • PGP offers the possibility to create a separate file for the signature during the signing process (with the option -b). If the user wants to sign the file ⁇ file name> with the identifier ⁇ user_id>, the command is:
  • the password When executing the command, the password is requested by the user in order to be able to activate the encrypted secret key.
  • the password is allowed by the user not to be given out of hand, otherwise another user along with access to secrxng. pgp can sign on his behalf.
  • the signature file is named ⁇ filename>. saved.
  • a file with the data to be signed is created.
  • the specifications + batchmode and + force do not cause any interactive queries from the PGP program and the return of the result in the exit status. Such an o signifies a successfully created signature file.
  • the content of the signature file can then be inserted into the corresponding data record by the database application.
  • the database application provides the two files (data and signature) with the corresponding content.
  • the user data is stored in the file ⁇ file name> together with the user ID of the data record and in the file ⁇ file name>.
  • the signature is provided.
  • the command options + batch ode and + force in turn suppress interactive queries during execution and return the result in the exit status of the PGP program.
  • a return value of o is a positive check, ie the two files are unchanged and signed by the specified user.
  • a local installation of the PGP program is used on the local PC (or workstation) for the signing of data records.
  • a user's secret key is stored on a personal write-protected floppy disk (floppy disk key) together with the public key of the issuing office.
  • a user logs on to the database server by the local workstation (PC) receiving a random message from the server.
  • the random message is sent back encrypted to the server using the local PGP program and the secret key. This can use the public key to check the authenticity of the user.
  • the user signs data records with the locally installed PGP program by pushing the write-protected floppy disk key (floppy disk with the secret key) into the drive and typing in the password. After signing, the diskette key is removed from the drive. Data records in the database are checked for authenticity using the PGP program installed on the server. All public keys on the server have been certified (signed) by the issuing authority. The certificate can be checked by any user with the issuing authority's public key. This is also included on the personal floppy key and thus protected against manipulation. An attacker would therefore have to manipulate as many diskette keys as possible to undermine the effectiveness of the system.
  • the issuing office determines the user ID, among other things , based on guidelines and generates a key pair (K, K ') a for itself.
  • the public key is signed according to
  • the issuing office is now ready to sign the users' public keys, i.e. Certificates Z to issue for their public keys.
  • a new user generates a key pair locally ( ⁇ , K ') ..
  • the user ID u chooses according to the specifications of the issuing office.
  • the pair of keys is stored on a diskette (the key diskette) and the public key K, ⁇ is signed by the user himself.
  • the issuing authority verifies the signature of the user and then issues a certificate for x for the public key K, 'and u the associated user ID. out. 4. The issuing authority makes the certificate z available to other users on the server system-wide (read-only access).
  • the issuing office provides the user with a personal copy of their signed public key z a .
  • the user copies a to the key diskette and activates the write protection.
  • the floppy disk key and the drive are comparable to a smart card and the associated reader. Just as the smart card is activated with a password, the floppy key is also activated. The difference is that with this solution the secret key is exposed in the main memory of the local workstation. With the smart card, the secret key never leaves the card.
  • a separate crypto process is provided to sign data records and to check the authenticity of existing signatures.
  • the signing process is preferably carried out in a smart card. This protects the secret key very effectively (the key never leaves the card) and the owner always has the card under his supervision.
  • the verification of signatures can easily remain on a more powerful platform (workstation) because this process is not critical in terms of security.
  • the only critical point is the issuer's public key for verifying user certificates. This key should also be stored in the smart card by every user in order to prevent masquerades.
  • the user certificates can be managed in the same database. However, this does not have to be the case, because it would also be possible to have the certificates in an external unit
  • authentication servers e.g. separate database, X.500 directory service or authentication server
  • authentication servers would also identify and authenticate users (using a password, token or biometric method).
  • the invention can be used in any database.
  • object-oriented and relational databases which are known per se, should be mentioned.
  • Object-oriented database systems not only offer the advantages of object-oriented programming, but are also more flexible with regard to the implementation of the method according to the invention.
  • Relational database systems are significantly more standardized and therefore restrict the possible solutions.
  • the entries of user data in the database are provided with a digital signature. In the event of later access, the authenticity of the entry and the user ID can be reliably checked.
  • the cryptographic part can be covered by the PGP program, whereby the encryption function also contained in the PGP program does not have to be used. Only the functions for key generation and management as well as for the authentication of data are used.
  • RSA is generally considered secure if sufficiently large keys (512 bits are considered unsafe) are used. Security is based on the difficulty of breaking down large integers. However, enormous progress has been made in this area recently. RSA is very susceptible to "chosen plaintext attacks". When used for signing purposes this danger does not arise because a cryptographic hash function (MD5) is interposed.
  • MD5 cryptographic hash function
  • MD5 is a safe hash function and generates a hash value of 128 bit length from any character string.
  • a hierarchical trust structure makes sense for a database and can be easily mapped.
  • the public key of the issuing office must be communicated via a secure channel (e.g. personal handover) and protected against manipulation (e.g. personal floppy disk with write protection).
  • the configuration for a client / server environment has the following features:
  • a local installation of the PGP program is used on the PC (or workstation) for the signing of data records.
  • the local application part (client) communicates with the locally installed PGP program.
  • a user's secret key is stored on a personal read-only diskette (diskette key) together with the public key of the issuing office.
  • diskette key diskette key
  • the server application communicates with the PGP program installed on the server.
  • a user logs on to the database server by the local workstation (PC) receiving a random message from the server.
  • the random message is sent back encrypted to the server using the local PGP program and the secret key. This can use the public key to check the authenticity of the user.
  • the user signs data records with the locally installed PGP program by pushing the read-only floppy disk key (floppy disk with the secret key) into the drive and typing in the password. After signing, the diskette key is removed from the drive.
  • the read-only floppy disk key floppy disk with the secret key
  • Data records in the database are checked for authenticity using the PGP program installed on the server. All public keys on the server have been certified (signed) by the issuing authority. The certificate can be checked by any user with the issuing authority's public key.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Bei einem Verfahren zur sicheren Verwaltung von Daten in einer Datenbank werden Datensätze bei ihrer Erstellung bzw. Änderung mit einer Benutzerkennung (Ui) und einer sowohl die Daten als auch die Benutzerkennung verschlüsselnden elektronischen Signatur (C) versehen. Zur Bildung der elektronischen Signatur (C) werden zuerst die Daten (M) zusammen mit der Benutzerkennung (Ui) unter Zuhilfenahme einer Hashfunktion (HF) auf eine Bitsequenz (H) vorgegebener Länge reduziert, um dann mit einem elektronischen Chiffrierverfahren (vorzugsweise einem asymmetrischen) verschlüsselt zu werden.

Description

Verfahren zur elektronisch gesicherten Speicherung von Daten in einer Datenbank
Technisches Gebiet
Die Erfindung betrifft ein Verfahren zur elektronisch gesicherten Speicherung von Daten in einer Datenbank sowie eine Vorrichtung zur Durchführung des Verfahrens. Stand der Technik
Unter einer Datenbank wird ein strukturierter, inhaltlich zusammengehöriger Datenbestaπd verstanden. Der Datenbestand besteht aus einer oder mehreren Tabellen (bzw. Objekten) mit jeweils einer Reihe von gleichartigen Datensätzen. Jeder Datensatz setzt sich wiederum aus einer Reihe von Datenfeldern zusammen. Im Normalfall sind Anzahl und Beschaffenheit der Datenfelder für einen bestimmten Typ von Datensatz der Datenbank identisch.
In Datenbankumgebungen können die verschiedenen Applikationsprogramme und Benutzer auf gemeinsame Daten zugreifen. Dies verhindert auf einer Seite Probleme wie Redundanz und Inkonsistenz von Daten und Datenstrukturen, auf der anderen Seite nimmt das Bedrohungspotential betreffend Datenbanksicherheit zu.
Verletzungen der Datenbanksicherheit sind unrechtmässiges Lesen, Modifizieren oder Löschen von Daten oder das Verhindern derselben.
Die Auswirkungen können in drei Kategorien eingeteilt werden:
• unbefugter Informationsgewinπ (Verlust der Vertraulichkeit) durch Lesen von Daten durch absichtlichen oder zufälligen Zugriff von einem unbefugten Benutzer. Der durch Inferenz aus erlaubten Zugriffen erhaltene Informationsgewinn von nicht erlaubter Information zählt ebenfalls in diese Kategorie.
• unbefugte Modifikation (Verlust der Integrität) von Daten beinhaltet alle Verletzungen der Datenintegrität. Dabei ist es nicht unbedingt notwendig, dass zuvor ein unerlaubter Informationsgewiπn stattgefunden haben muss.
• Störung und Sabotage (Verlust der Verfügbarkeit). Darunter fallen alle Aktionen, welche die rechtmässigen Benutzer eines Systems von deren Benützung abhalten. Eine Datenbank vor möglichen Angriffen zu schützen hat zur Folge, dass die Infrastruktur, insbesondere die gespeicherten Daten, vor zufälligen oder willentlichen nichtautorisierten Zugriffen (Lesen und/oder Modifikation) geschützt werden muss.
Aus der US 5,097,504 ist ein Verfahren zur Sicherung der Integrität von (elektronisch abgespeicherten) Daten bekannt. Die im Klartext abgespeicherten Daten werden mit einer für den Text und den Autor eindeutigen Signatur versehen. Die Parameter (z.B. Schlüssel, Programm) zur Berechnung der Signatur sind z.B. in einer geschützten Speicherkarte mit integriertem Prozessor abgespeichert.
Eine Reihe von Informationselementen (dortige Fig. 4: D,B,A) wird mit einer entsprechenden Anzahl von Zufallszahlen (Ci) multipliziert und aufaddiert. Die resultierende Summe wird einer Modulo-Operation unterworfen. Das Ergebnis stellt die Signatur dar. Zur Verstärkung der Sicherheit können die Informationselemente bei der Berechnung der Signatur mit beliebigen numerischen Werten wie z.B. mit dem Datum oder der Identifikation des Signierenden kombiniert bzw. ergänzt werden. Das Verfahren ist primär für die Übertragung von Mitteilungen bestimmt. Damit es auch für den Schutz einer Datenbank eingesetzt werden kann, ist ein leistungsfähiger Computer erforderlich. Zusätzlich wird für diese grosse Datenmenge ein spezielles Verfahren vorgeschlagen, bei welchem für die Berechnung der Signatur die zu verarbeitenden Daten in Datenblöcke unterteilt werden (Spalte 6, Zeilen 41-44). Dabei können die einzelnen Bits so gruppiert werden, dass sie die "Characters" auch nur teilweise darstellen (Spalte 7, Zeilen 1-5). Für jeden Datenblock wird eine partielle Signatur erstellt, so dass die gesamte Signatur durch eine Reihe von einzelnen partiellen Signaturen gebildet wird (Spalte 6, Zeilen 54-56). Die partiellen Signaturen können an die entsprechenden Datenblöcke angehängt werden (Spalte 7, Zeilen 24- 28). Auf diese Weise können Backup-Kopien von Datenbanken signiert werden (Spalte 12, Zeilen 37-38).
Die europäische Patentanmeldung EP 0 709 760 A2 hat ein Verfahren zur Verwaltung von Urheberrechten zum Gegenstand. Die zu verwaltenden Daten sind nicht zentral, sondern in einem Netzwerk von Computern abgespeichert. Die Daten sind nicht in Form von Datensätzen mit fest vorgegebener Struktur enthalten, sondern in beliebigen Dateien. Um die Wiederverwertung urheberrechtlich geschützter Daten zu kontrollieren, werden sie vor der Übertragung an den Benutzer verschlüsselt, so dass sie nur unter Einsatz eines von einer Zentrale zu beschaffenden Schlüssels gelesen und weiterverwendet werden können.
Aus der EP 0 386 867 A2 ist ein Verfahren zur Zertifizierung von Schlüsseln in Public Key Systemen bekannt. Ziel ist es, die Übertragung von Daten (wie E-mail und elektronische Überweisungen bzw. Zahlungen) über unsichere Kanäle zu ermöglichen. Bei der Erstellung der Signatur werden die Daten (Objekt) einer Hashfunktion unterworfen. Neben den eigentlichen Daten werden u.a. auch Datum und Identifikation des Signierenden in die Signatur eingeschlossen.
Darstellung der Erfindung
Aufgabe der Erfindung ist es, die in einer Datenbank gespeicherten Daten vor zufälligen oder willentlichen nichtautorisierten Zugriffen (Modifikationen) zu schützen.
Die Lösung der Aufgabe ist durch die Merkmale des Anspruchs 1 definiert. Gemäss der Erfindung wird jeder Datensatz (welcher die Nutzdaten enthält) bei seiner Erstellung bzw. Änderung zuerst mit einer Benutzerkennung und dann mit einer elektronischen Signatur versehen. Die Signatur stützt sich inhaltlich sowohl auf die Nutzdaten als auch auf die Benutzerkennung. Sie wird im Prinzip mit einer Einwegfunktion erstellt, die als Parameter einen geheimen, benutzerspezifischen Schlüssel hat. Erst der so ergänzte Datensatz wird auf dem zur Verfügung stehenden Speichermedium in Form eines erweiterten Datensatzes abgespeichert. Die Signatur stellt somit ein zusätzliches Feld des Datensatzes dar.
Das beschriebene Verfahren hat den Vorteil, dass die auf diese Weise gesicherten Daten im Prinzip von jedem beliebigen Benutzer (welcher zur Datenbank zugelassen ist) gelesen und erforderlichenfalls geändert werden können, dass aber nachträglich stets festgestellt werden kann, wer die Änderungen durchgeführt hat. Die elektronische Signatur gewährleistet, dass überprüft werden kann, ob die Benutzerkennung und die Daten authentisch sind Es ist also nicht möglich, dass jemand unter einer fremden Benutzerkennung verdeckt Daten ändert
Vom Stand der Technik gemäss US 5,097 504 unterscheidet sich die Erfindung dadurch, dass einzelne Datensatze verarbeitet werden Eine Datenbank wird nicht als ganzes mit Signaturen gesichert Vielmehr werden bei der Erfindung selektiv die Datensatze gewisser ausgewählter Tabellen codiert In einer medizinischen Datenbank beispielsweise ist die Tabelle, in welcher die Krankheiten eines jeden Patienten festgehalten wird, durch eine erfindungsgemasse Signatur gesichert wahrend die zugeordneten Tabellen mit den Adressen der Patienten z B bewusst nicht gesichert werden (und infolgedessen ohne aufwendiges Prozedere erstellt und geändert werden können) Die in der US 5,097,504 vorgeschlagene Bildung von Blocken nimmt im Gegensatz dazu nicht auf die Datenbankstruktur Rucksicht, sondern geht allein davon aus, wieviele Bits mit einer Signatur mit vernunftigem Rechenaufwand noch verarbeitet werden können
Gemäss einer bevorzugten Ausfuhrungsform werden die Nutzdaten zusammen mit der Benutzerkennung mit Hilfe einer Hashfunktion auf eine Bitsequenz vorgegebener Lange reduziert Die Hashfunktion ist eine Einwegfunktion, die eine Kompression der Daten ausfuhrt und zwar so, dass die Wahrscheinlichkeit, dass das Resultat trotz un- terschiedlicher Ausgangsdaten zum selben Funktionswert fuhrt, vernachlassigbar klein ist D h es wird eine Art Fingerabdruck erzeugt
Zur Erzeugung der elektronischen Signatur wird ein asymmetrisches Chiffrierverfahren eingesetzt Bei diesen gibt es jeweils einen geheimen Schlüssel (private key) und einen öffentlichen (public key) Der geheime Schlüssel wird zur Erzeugung und der öffentliche zur Überprüfung der elektronischen Signatur verwendet Beispiele für asymmetrische Chiffrierverfahren sind das RSA- und das DSA-Verfahren (RSA public key Kryptosystem von Ron Rivest Adi Shamir und Leonard Adleman, vgl US 4 405 829 DSA Digital Signature Algoπthm gemäss dem amerikanischen Digital Signature Standard) Bei Systemen mit einer grösseren Anzahl von Benutzern empfiehlt es sich, eine Zentrale für die Authentifikation der öffentlichen Schlüssel zu verwenden. Jeder Benutzer muss sich bei dieser Zentrale melden, um seine Benutzerkennung und seinen öffentlichen Schlüssel abzugeben. Die Zentrale führt eine Liste, welche die Benutzerkennun- gen der vorhandenen Benutzer und die entsprechenden Schlüssel enthält. Vorzugsweise wird jeder Eintrag in der Liste durch die Zentrale signiert.
Wenn nun ein Benutzer eine Signatur eines Datensatzes überprüfen will, dann nimmt er den in der zentralen Liste aufgeführten, zur Benutzerkennung des fraglichen Datensatzes gehörenden öffentlichen Schlüssel und überprüft die elektronische Datensatzsi- gnatur. Dass der öffentliche Schlüssel und die Benutzerkennung tatsächlich zum entsprechenden Benutzer (d.h. zu seiner Person) gehören, kann anhand der elektronischen Signatur der Zentrale festgestellt werden.
Sofern der ganze Datensatz nicht zusätzlich durch eine Chiffrierung gegen unbefugtes Lesen geschützt wird, sind die Daten und die Benutzerkennung im Klartext abgespei- chert. Es ist daher stets möglich, bei der Zentrale den zur Benutzerkennung gehörenden Schlüssel zu holen, welcher dann die Verifikation der Signatur erlaubt.
In der Regel sind Prüffunktionen vorgesehen, die die eingegebenen Daten hinsichtlich ihrer logischen Konsistenz überprüfen. D.h. die in einem bestimmten Feld eines Datensatzes abzuspeichernden Daten müssen vom richtigen Datentyp sein. Diese Prüf- funktionen können mehr oder weniger ausgebaut sein. Im Zusammenhang mit der Erfindung ist es wichtig, dass eine Eingabe bzw. Änderung von sensiblen Daten nur dann akzeptiert wird, wenn die elektronische Signatur vorliegt. (Eine Überprüfung der Benutzersignatur seitens des Systems muss nicht zwingend bei der Eingabe stattfinden.)
Wenn die Datenbank eine besondere Sicherheit bieten muss, ist es von Vorteil, wenn generell bzw. bei einer Änderung der Daten keine Löschung, sondern nur eine Löschmarkierung vorgenommen wird. Diese wird gemäss der Erfindung ebenfalls mit einer elektronischen Signatur gekennzeichnet. Damit wird es möglich, die Historie eines Datensatzes zurückzuverfolgen und die Verantwortlichkeit festzustellen.
Vorzugsweise wird eine gesicherte Zeitbasis zur Verfügung gestellt, welche zur Datierung einer Eingabe bzw. Änderung herangezogen werden kann. Gesichert heisst, dass es nicht möglich sein darf, eine falsche Zeit (Datum/Uhrzeit) einzugeben. Dies ist insbesondere dann wichtig, wenn sensible Daten von örtlich weit auseinander liegenden Arbeitsstationen bearbeitet werden müssen. Es versteht sich, dass der Zeitstempel ebenfalls in die elektronische Signatur einfliessen sollte. Der Zeitstempel sollte natürlich nicht manipulierbar sein. Sofern nicht an allen Arbeitsstationen ein solcher Zeitstempel zur Verfügung steht, kann der Server unter Umständen selbst (zusätzlich) einen Zeitstempel anbringen, so dass z.B. zumindest Rückdatierungen von Änderungen durch die Anwender nicht möglich sind.
Die Erfindung kann natürlich nicht nur zur Sicherung einzelner Datensätze verwendet werden. In derselben Weise können namentlich auch Einträge im Dictionary (Authorisierungsdateien, Sicherheitsaxiome, Integritätsbedingungen o. dgl.), ganze Benutzerprofile und auch Protokolldateien (log files) geschützt werden.
Der Schlüssel zur Generierung der elektronischen Signatur wird vorzugsweise weder im Rechnersystem, welches die Datenbank verwaltet, noch in einer dezentralen Arbeitsstation, sondern in einer persönlichen Chipkarte gespeichert. Diese sollte einen hohen Sicherheitsstandard erfüllen (als Beispiel sei die Sicherheit der an sich bekannten CP8-Karte erwähnt). Der geheime Schlüssel soll beim Erzeugen der elektronischen Signatur nicht aus der Karte gegeben werden müssen. Für die Bedienung des Datenbanksystems muss also am Arbeitsplatz ein Chipkartenleser vorgesehen sein. Immer wenn eine elektronische Signatur erzeugt werden muss, werden die entspre- chenden Klardaten vom Chipkartenleser an die Chipkarte übergeben, welche dann ihrerseits die Signatur erstellt und ausgibt. Das erfindungsgemässe Verfahren lässt sich im Prinzip mit an sich bekannter Hardware umsetzen. Um die bevorzugte Ausführungsform mit den Chipkarten implementieren zu können, sind bei den Arbeitsstationen Chipkartenleser vorzusehen.
Aus Sicherheitsgründen ist es in jedem Fall vorteilhaft, wenn die Signatur physisch möglichst nahe beim Eingabegerät berechnet und zum Datensatz hinzugefügt wird.
Grundsätzlich ist es nicht erforderlich, neue Datenbanksysteme zu entwickeln. Es können ohne weiteres datenbankexterne kryptografische Funktionen eingesetzt werden. Der Datenaustausch erfolgt beispielsweise über sogenannte "Data pipes". Die Verschlüsselungsprozeduren sind eigene Programm-Module, die vom Datenbankpro- gramm gethggert werden. Für den Systemprogrammierer ist es natürlich angenehmer, wenn das Datenbankprogramm selbst die fertigen Funktionen zur Durchführung der elektronischen Signatur und zur Überprüfung bereitstellt.
Aus der nachfolgenden Detailbeschreibung und der Gesamtheit der Patentansprüche ergeben sich weitere vorteilhafte Ausführungsformen und Merkmalskombinationen der Erfindung.
Kurze Beschreibung der Zeichnungen
Die zur Erläuterung des Ausführungsbeispiels verwendeten Zeichnungen zeigen:
Fig. 1 eine schematische Darstellung des Prinzips zur Sicherung der Daten;
Fig. 2 eine schematische Darstellung eines Computersystems zur Durchfüh- rung des Verfahrens.
Grundsätzlich sind in den Figuren gleiche Teile mit gleichen Bezugszeichen versehen.
Wege zur Ausführung der Erfindung Es lassen sich die folgenden Objekte in ihrer Integrität mit digitalen Signaturen gegen unbemerkte Modifikation schützen:
Einträge der Applikation und/oder Benutzer in der Datenbank Einträge im Dictionary der Datenbank • Benützerprofile
Protokolldateien
Die Datensätze in der Datenbank werden zusätzlich mit einer Integritätsbedingung (check constraint) gegen nicht nachweisbare Manipulation gesichert indem eine digitale Signatur (eine Art Prüfsumme) der eingetragenen Daten erzeugt wird. Dadurch wird natürlich redundante Information eingefügt. Aber auf der anderen Seite werden die Echtheit und der Ursprung der Daten gegen nicht feststellbare Manipulationen geschützt.
Es lassen sich nicht nur applikations- oder benützerbezogene Daten auf die obige Art gegen Manipulation sichern, sondern jede Art von Einträgen. Das heisst jeder existie- rende Datensatz in der Datenbank kann grundsätzlich mit einer Prüfsumme, einer digitalen Signatur, versehen werden. Beim Eintragen sorgt eine Prozedur mit einer vorgegebenen Integritätsbedingung (check constraint) dafür, dass überall in der Datenbank die obige Bedingung stimmt. Ist die Bedingung nicht erfüllt, wird der Eintrag zurückgewiesen. Dies bedeutet, dass auch Einträge für das Dictionary (Authorisierungsdaten, Sicherheitsaxiome, Integritätsregeln, usw.) eine digitale Signatur erhalten.
In der gleichen Art können die Datensätze für die Benützerprofile (z.B. Zugriffsrechte und Privilegien auf Betriebssystemebene) gesichert werden.
Die Einträge für Protokolldatei und das Logbuch werden neben der digitalen Signatur zusätzlich mit einer sequentiellen Nummer versehen, um ein Löschen eines Eintrages feststellen zu können Das Loschen und das Duplizieren können generell mit krypto- grafischen Verfahren alleine nicht verhindert werden
Die weiter unten beschriebenen Ausfuhrungsbeispiele befassen sich der Einfachheit halber nur mit der Sicherung von Datensätzen, die der Benutzer eingibt bzw ändert Bei den übrigen Anwendungsmoglichkeiten kann die Erfindung sinngemass umgesetzt werden
Die Integrität eines einzelnen Datensatzes im Datenbanksystem wird mit einem asymmetrischen kryptografischen Verfahren (z B RSA oder DSA) zuverlässig geschützt Jeder Datensatz hat nebst der eigentlichen Information (diese kann aus meh- reren Attributen - wie z B Name, Anschrift, Alter, Blutgruppe etc eines Patienten - bestehen), welche vom Einsatzzweck abhangig ist, drei zusätzliche Attribute
• Zeitstempel (Datum und Zeit der Modifikation oder der Erstellung des Datensatzes)
• Benutzerkennung (eindeutige Benutzeridentifikation im Datenbanksystem)
• digitale Signatur (abhangig von der Information des Datensatzes, dem Zeitstempel, der Benutzerkennung und dem geheimen Schlüssel des Benutzers)
Die Information legt das WAS, der Zeitstempel das WANN und die Benutzerkennung das WER fest Die digitale Signatur schützt die Echtheit der vorher erwähnten Daten- teile
Fig 1 veranschaulicht den Aufbau eines erfindungsgemassen Datensatzes Die Nutzinformation ist mit M bezeichnet und hangt von der konkreten Anwendung ab Sie wird z B durch Name, Anschrift oder weitere Angaben einer Person gebildet Weiter ist gemäss einer vorteilhaften Ausfuhrungsform ein Zeitstempel TS (Datum, Uhrzeit) vorhanden Dieser wird immer dann aufgenommen, wenn die Nutzinformation M eingegeben bzw geändert wird Ein unerlassliches Attribut ist die Benutzerkennung Ui Es handelt sich dabei um einen Code oder eine Nummer, die die eindeutige Identifizierung des angegebenen Benutzers erlaubt Die drei genannten Elemente des Datensatzes werden mit Hilfe einer Hashfunktion HF in eine Bitsequenz H mit fixer Länge überführt (z.B.128 Bits). Diese wird mit einer Einwegfunktion Ekl in einen Code C (mit einer Länge von z.B. 512 oder 1024 Bits) umgerechnet, welcher als elektronische Signatur dient und zum Datensatz hinzugefügt wird. Die Einwegfunktion hat als Parameter den geheimen Schlüssel Ki (private key) des Benutzers.
In der Datenbank wird jede Eingabe oder Änderung in dieser Weise erfasst und gegen Manipulation geschützt.
Fig. 2 zeigt ein grobes Blockschaltbild eines Dateπbanksystems. Die Daten werden von einen Server verwaltet, welcher in konventioneller Weise einen Rechner 2 und einen Speicher 3 aufweist.
Die Eingabe bzw. Änderung der Daten findet an einen Terminal 4 (Arbeitsstation) statt. Dieses verfügt u.a. über ein an sich bekanntes Eingabegerät 5 (Tastatur, Barcodeleser, Bildschirm etc.), eine Uhr 6 und einen Kartenleser 7. Eine Leitung 9 verbindet das Terminal 4 mit dem Server 1.
Am Eingabegerät 5 werden die Daten M eingegeben. Beim Betätigen der Eingabetaste werden die Daten M zusammen mit einem von der Uhr 6 erzeugten Zeitstempel via Kartenleser 7 an die Chipkarte 8 übergeben. Diese erstellt die weiter oben beschriebene Signatur. Danach kann der aus den Daten M, dem Zeitstempel TS, der Benut- zerkennung (welche vorzugsweise in der Chipkarte 8 abgespeichert ist und von dieser ausgegeben wird) und der elektronischen Signatur bestehende Datensatz via Leitung 9 an den Server 1 übertragen werden.
Im folgenden werden die in den Figuren angedeuteten Funktionen und Elemente im Detail erläutert.
Damit die digitale Signatur nicht zu umfangreich wird und der Berechnungsaufwand ebenfalls im Rahmen bleibt, wird die effektive Information M des Datensatzes zusam- men mit dem Zeitstempel TS und der Benutzerkennung Ui zuerst mittels einer geeigneten Hashfunktion (Einwegfunktion, message digest) komprimiert, also eine Art Fingerabdruck H(M|TS|Ui) erzeugt. Der Fingerabdruck wird danach mittels eines asymmetrischen kryptografischen Algorithmus und einem geheimen Schlüssel Ki verschlüs- seit. Das erhaltene Ergebnis wird als digitale Signatur
C = Erι ( H (M | TS | U. ) )
abgelegt.
Das Datenbanksystem akzeptiert einen Datensatz nur im Fall, dass die obige Integritätsbedingung stimmt, d.h. die Signatur aus den anderen Elementen hergeleitet werden kann.
Der einfachste Fall der kryptografischen Integritätssicherung von Einträgen durch eine digitale Signatur umfasst nur die eigentliche Information ohne ein sicheres Datum. Auch im Fall, dass der Informationsteil eine Zeitangabe aufweist, kann diesem nicht vertraut werden, sofern nicht in irgendeiner Weise sichergestellt ist, dass nicht eine falsche Zeit eingesetzt werden kann.
Die Benutzerkennung ist notwendig, damit mit dem öffentlichen Schlüssel die Signatur überprüft werden kann. Die Nachteile einer fehlenden Zeitangabe liegt natürlich darin, dass nicht ohne weiteres auf den Zeitpunkt der Transaktion geschlossen werden kann.
Der obige Datensatz wird nach den folgenden Schritten in die Datenbank eingetragen:
1. Der Benutzer trägt die Daten in die einzelnen Attribute des Datensatzes ein und schliesst die Transaktion ab (commit).
2. Beim Transaktionsabschluss durch den Benutzer wird vorerst ein Fingerabdruck der eingetragenen Daten und der Benutzerkennung erzeugt (Hashfunktion). 3. Das Datenbanksystem trägt die Benutzerkennung des zu Beginn der Sitzung authentifizierten Benutzers in den Datensatz ein.
4. Der Fingerabdruck der Daten und der Benutzerkennung werden in einer Signiereinheit verschlüsselt.
5. Die erzeugte Signatur wird im Datensatz eingetragen und die Transaktion abgeschlossen.
Es muss ein sicherer Pfad für die Dateneingabe des Benutzers vorhanden sein. Der Benutzer muss die Gewähr haben, dass die an der Tastatur eingegebenen Daten auch tatsächlich - ohne Modifikation - in der Datenbank abgelegt werden.
Ein Angreifer könnte sonst eine Maskerade durchführen, indem er ein Programm installiert das den Dialog mit dem Benutzer nur vortäuscht, im Hintergrund aber andere Daten ablegt und diese durch den Benutzer signieren lässt. Alles ohne, dass der Benutzer davon etwas bemerken würde.
Es ist von Vorteil, wenn die elektronische Signatur (physisch gesehen) so nahe wie möglich an der Eingabe berechnet wird.
Die Signiereinheit beinhaltet den geheimen Schlüssel Ki. Dieser muss geheim gehalten werden, ansonsten ein anderer Benutzer - ohne Möglichkeit der Feststellung - signieren kann. Ebenfalls vorausgesetzt wird ein sicheres Integritätsprüfsystem und eine entsprechende Integritätsbedingung, damit ein unzulässiger Eintrag durch das DBMS (Data Base Management System) zuverlässig zurückgewiesen wird. Ein ungültiger Eintrag kann zum Beispiel entstehen, wenn ein Angreifer den Fingerabdruck oder die Benutzerkennung verändert. Es ist deshalb auch nicht notwendig sichere Pfade und Funktionen für dieselben zu fordern.
Als Variante zum oben beschriebenen Verfahren kann die Benutzerkennung und die digitale Signatur in einer (physisch getrennten) Funktionseinheit erzeugt werden. Zu jeder Benutzerkennung Ui gehört genau ein geheimer Schlüssel Ki. Deshalb ist es auch sinnvoll die beiden Grossen in einer Einheit (z.B. Smart-Card) - geschützt vor Manipulation - zusammenzufassen.
Der Datensatz wird nach den folgenden Schritten in die Datenbank eingetragen:
1. Der Benutzer trägt die Daten in die einzelnen Attribute des Datensatzes ein und schliesst die Transaktion ab (commit).
2. Beim Transaktionsabschiuss durch den Benutzer wird vorerst ein Fingerabdruck der eingetragenen Daten und der Benutzerkennung erzeugt (Hashfunktion).
3. Der Fingerabdruck wird in einer Signiereinheit verschlüsselt.
4. Die erzeugte Signatur wird im Datensatz zusammen mit der in der Signiereinheit enthaltenen Benutzerkennung eingetragen und die Transaktion abgeschlossen.
Es muss ebenfalls (wie bei der ersten Variante) ein sicherer Pfad für die Dateneingabe des Benutzers vorhanden sein. Die Signiereinheit beinhaltet wiederum den geheimen Schlüssel Ki und die Kennung Ui des Benutzers.
Der Mangel an Beweisbarkeit, zu welchem Zeitpunkt eine bestimmte Transaktion stattgefunden hat, kann mit Einführung eines Zeitstempels TS (Datum und Zeit) behoben werden. Ein solcher Zeitstempel wird durch einen sicheren und genauen Zeitservice erstellt. Der Server kann z.B. signierte Zeitcodes zur Verfügung stellen. Alternativ kann eine Funkuhr vorgesehen sein, welche die Zeit (ebenfalls mit einem Fälschungs- sicheren Code) aufnimmt.
Ein Datensatz wird demzufolge in der nachfolgend aufgelisteten Art eingetragen:
1. Der Benutzer trägt die Daten in die einzelnen Attribute des Datensatzes ein und schliesst die Transaktion ab (commit). 2. Beim Transaktionsabschluss durch den Benutzer wird vorerst ein Fingerabdruck der eingetragenen Daten, vom Zeitstempel und der Benutzerkennung erzeugt.
3. Die aktuelle Zeit und das Datum werden im Datensatz ergänzt.
4. Der Fingerabdruck wird in einer Signiereinheit (z.B. Smart-Card) verschlüsselt.
5. Die erzeugte Signatur wird im Datensatz eingetragen und die Transaktion abgeschlossen.
Das DBMS muss bei der erwähnten Ausführungsform einen sicheren Pfad für die Be- nützereinträge zur Verfügung stellen. Der Zeitservice muss eine genügend genaue und verlässliche Zeitangabe liefern und resistent gegenüber Manipulationen sein. Die Si- gniereinheit enthält wiederum den geheimen Schlüssel Ki und die Keπnung Ui des Benutzers.
Angenommen die Protokolldatei besteht aus sequentiellen Einträgen (records) so muss verhindert werden, dass unbemerkt Einträge hinzugefügt oder entfernt werden können. Dies kann zum Beispiel erreicht werden, indem jeder Eintrag eine fortlaufende Nummer erhält. Zwei gleiche Nummern in der Datei sind unzulässig. Ob der letzte Eintrag tatsächlich der letzte ist, kann erst zuverlässig festgestellt werden, wenn der nächste Eintrag entsteht: Ist die Nummer ein Nachfolger des vorherigen Eintrages, so war es tatsächlich der momentan letzte Eintrag.
Ein Protokolldatensatz wird wie folgt erzeugt:
1. Das DBMS oder das Betriebssystem meldet ein zu protokollierendes Ereignis an den Protokollmonitor.
2. Die Ereignisbehandlung erzeugt die nächste Datensatznummer und die zugehörige Information (Meldung). 3. Die aktuelle Zeit und das Datum werden im Datensatz ergänzt.
4. Aus der Nummer, der Information, dem Zeitstempel und derBenutzerkennung wird ein Fingerabdruck erstellt.
5. Der Fingerabdruck wird in der Signiereinheit verschlüsselt.
6. Die erzeugte Signatur und die Protokollmonitorkenπung werden im Datensatz eingetragen, welcher dann auf die Disk gespeichert wird.
Weil keine sichere Integritätsprüflogik falsche Einträge verhindert, muss der gesamte Protokollmonitor sicher sein, damit Manipulationen ausgeschlossen werden können. Die Ereignisse müssen durch einen sicheren Pfad dem Protokollmonitor zugeleitet werden können. Die Signiereinheit enthält den geheimen Schlüssel κp und die Kennung Updes Protokollmonitors.
Die Monitorkennung uP in den Protokolleinträgen ist nicht unbedingt notwendig, wenn nur ein globaler Monitor vorhanden ist.
Die Prüfung der Integrität eines Datensatzes durch das System (beim Abspeichern) oder durch einen Benutzer erfolgt in umgekehrter Weise.
Die digitale Signatur EKI(H(M) |τs|u wird mit dem öffentlichen Schlüssel K,' des Benutzers uL dechiffriert
H(M|TS|U,) <- D-, (EU(H(M|TS|U,) ) )
und es wird der Fingerabdruck H(M|TS|U der ursprünglichen Komponenten TS, und erhalten. Diesen vergleicht man mit dem errechneten Fingerabdruck H(M|TS|U des Eintrages. Bei völliger Übereinstimmung kann man sicher sein, dass der Eintrag authentisch ist, d.h. vom Benutzer u\ zur angegebenen Zeit TS mit dem vorhandenen Informationsinhalt M abgespeichert wurde. Wenn die beiden Fingerabdrücke nicht übereinstimmen ist der Datensatz nicht gültig und nicht weiter verwendbar, da eine unerlaubte Manipulation zugrunde liegt.
In den oben beschriebenen Verfahren werden ein sicheres Integritätsprüfsystem und eine entsprechende Integritätsbedingung vorausgesetzt, damit ein "ungültiger" Eintrag durch das DBMS zuverlässig zurückgewiesen wird. Für die Überprüfung einer digitalen Signatur ist der entsprechende öffentliche Schlüssel des im Datensatz festgehaltenen Benutzers notwendig. Der öffentliche Schlüssel muss in Form eines Zertifikates verfügbar sein. Solche Zertifikate werden von einer unabhängigen vertraubaren Instanz (Authentifikationszentrale) ausgegeben. Sie beweisen, dass die Benutzerkennung und der öffentliche Schlüssel zusammengehören. Die Echtheit eines Zertifikates kann ebenfalls mit Hilfe des öffentlichen Schlüssels der ausgebenden Instanz überprüft werden.
Ein neu eingetragener oder abgeänderter Datensatz wird wie folgt auf eine korrekte Signatur überprüft:
1. Durch einen INSERT- oder UPDATE-Befehl wird die Integritätsbedingung an- gestossen.
2. Beim Transaktionsabschluss wird die Benutzerkennung aus dem Datensatz ermittelt.
3. Danach wird ein Fingerabdruck der eingetragenen Daten und der Benutzerkennung erzeugt.
4. Das Benützerzertifikat mit dem öffentlichen Schlüssel wird angefordert.
5. Die digitale Signatur wird mittels des öffentlichen Schlüssels dechiffriert.
6. Der aus der digitalen Signatur erhaltene Fingerabdruck und die Benutzerkennung werden mit dem in Schritt 2 errechneten Fingerabdruck und der im Datensatz eingetragenen Benutzerkennung verglichen. 7. Bei Übereinstimmung der Komponenten wird die Transaktion akzeptiert, in allen anderen Fällen zurückgewiesen.
Das DBMS muss einen sicheren Mechanismus für die Integritätsüberprüfung anbieten. Andernfalls können Einträge ohne korrekte Signatur erfolgen.
Der Benutzer muss die Möglichkeit haben, einen Datensatz auf seine Echtheit zu überprüfen. Trotz der bereits beschriebenen Integritätsbedingung können nachträgliche Manipulationen nicht ausgeschlossen werden. Es soll deshalb möglich sein, einen Datensatz gerade bei seiner Verwendung zu überprüfen.
Ein vorhandener Datensatz wird wie folgt auf eine korrekte Signatur überprüft:
1. Zuerst wird die Benutzerkennung aus dem Datensatz ermittelt.
2. Danach wird ein Fingerabdruck der eingetragenen Daten und der Benutzerkennung erzeugt.
3. Das Benützerzertifikat mit dem öffentlichen Schlüssel wird angefordert.
4. Die digitale Signatur wird mittels des öffentlichen Schlüssels dechiffriert.
5. Der aus der digitalen Signatur erhaltene Fingerabdruck und die Benutzerkennung werden mit dem in Schritt 2 errechneten Fingerabdruck und der im Datensatz eingetragenen Benutzerkennung verglichen.
6. Bei Übereinstimmung der Komponenten ist der Datensatz authentisch, d.h. es hat keine unerlaubte Modifikation stattgefunden.
Mindestens eine Komponente des Datensatzes (Information oder Signatur) muss über einen sicheren Kanal zur Prüffunktion geleitet werden können. Ebenfalls das Ergebnis der Überprüfung muss über einen sicheren Kanal dem Benutzer mitgeteilt werden können. Die Prüfeinheit enthält den öffentlichen Schlüssel κa ' und die Kennung ua der Zertifizierungsinstanz.
Den vorher erwähnten Verfahren liegen folgende Anforderungen zugrunde:
• Das Attribut für den Zeitstempel TS (sofern vorhanden) muss auf einer vertraubaren Zeitbasis und Programmlogik (trusted code) basieren.
• Eine vertrauensvolle Instanz ist notwendig für die Zertifizierung von Benutzerkennung u, und öffentlichem Schlüssel K, ' , damit einer Maskerade durch einen anderen Benutzer u ' vorgebeugt resp. erkannt werden kann.
• Verwendung einer geeigneten Einwegfunktion (Hashfunktion) zur Kompression der Informationen M des Datensatzes. Die Wahrscheinlichkeit, dass mit anderen
Informationen M 1 der gleiche Fingerabdruck
H ( M ' ) = H ( M )
errechnet wird, soll vernachlässigbar klein sein.
• Die mit dem asymmetrischen kryptografischen Algorithmus (RSA oder DSA) er- haltene digitale Signatur ist nicht ohne Wissen des geheimen Schlüssels K, berechenbar.
• Der geheime Schlüssel κ1 ist nur einem Benutzer (oder einer Benützergruppe) bekannt, damit kein Abstreiten (repudiation) des berechtigten Benutzers erfolgen kann. Er kann sonst behaupten ein anderer hätte unterzeichnet.
Die vorgeschlagenen Verfahren schützen nicht vor unabsichtlichem oder willentlichem Löschen eines Datensatzes. Um zu verhindern, dass auf diese Weise wichtige Informationen zum Verschwinden gebracht werden können, sollten überhaupt keine Löschaktionen mehr im Datenbanksystem gestattet werden. Der Löschbefehl wird also den Dateneintrag nur als gelöscht markieren, nicht aber vernichten. Dies würde ein weiteres Attribut ("Lösch-Feld") voraussetzen. Auch das Duplizieren eines vorhandenen oder einmal vorhandenen Datensatzes (replay attack) muss verhindert werden Wenn, wie oben vorgeschlagen, keine Datensatze geloscht werden können, sind identische Datensatze nicht mehr plausibel und können leicht erkannt oder gar durch das Datenbanksystem beim Eintragen verhindert werden (z B Signatur als Primärschlüssel)
Es ist zu betonen, dass die Sicherung der Integrität der Daten im Prinzip getrennt von der Sicherung der Vertraulichkeit zu behandeln ist Die Forderungen nach Integrität und Vertraulichkeit treten zwar in der Praxis häufig gemeinsam auf, sind aber nicht zwingend miteinander verbunden
Zur Frage der Vertraulichkeit ist folgendes zu bemerken
Mit kryptografischen Verfahren lassen sich die folgenden Datenbankobjekte gegen den Verlust der Vertraulichkeit schützen
• Eintrage der Applikation und/oder Benutzer in der Datenbank
• Benutzerpassworter
• Eintrage in das Logbuch des DBMS
• Backup-Kopien der Datenbank und des Logbuches
Die Chiffrierung der Daten lasst sich auf verschiedenen Stufen durchfuhren Eine Chiffrierung auf Disk-, I/O- oder Dateisystem-Ebene bewirkt nur einen Schutz gegen Diebstahl der Disk oder der Backup-Kopien Gerade beim Einsatz von C ent/Server- Applikationen in Netzwerkumgebungen bringt die Chiffrierung auf der untersten (physikalischen) Ebene keinen wirksamen Schutz
Der beste Schutz der Vertraulichkeit kann mit kryptografischen Verfahren erreicht werden, wenn die Daten bereits beim Benutzer chiffriert resp erst dort wieder dechiffriert werden Die Vertraulichkeit von Datensätzen lässt sich durch Chiffrierung der darin enthaltenen Information gewährleisten. Nur Benutzer im Besitze des geheimen Schlüssels K sind in der Lage die Informationen wieder im Klartext interpretierbar zu machen.
Die autorisierten Benutzer bilden auf diese Weise eine geschlossene Benützergruppe, so dass andere Benutzer mit anderweitigen Privilegien (z.B. Systemmanager, DBA, Netzwerkbetreiber) die Informationen trotzdem nicht interpretieren können.
Das zur Anwendung gelangende kryptografische Verfahren ist, im Gegensatz zur Authentifizierung, ein symmetrisches Verfahren (z.B. DES =Data Encryption Standard, IDEA = International Data Encryption Algorithm, vgl. WO 91/18459). Alle autorisierten Benutzer erhalten den gleichen geheimen Schlüssel K mit dem sie die Informationen M chiffrieren
C = EK(M)
und den Chiffretext c auch wieder mit der Umkehrfunktion Eκ-1 dechiffrieren
M = EK-1(C) = EK-KEK( ) ) = M
können. Unter der Information M kann man alle Attribute eines Datensatzes (also auch mit Zeitstempel, Benutzerkennung und digitaler Signatur) oder nur einzelne Attribute, die besonders geschützt werden müssen, verstehen.
Wenn alle N Attribute eines Datensatzes T., zusammen chiffriert werden,
muss Zusatzinformation hinzugefügt werden, damit beim Dechiffrieren die Aufteilung zu den einzelnen Attributen A, wieder korrekt erfolgen kann. Es ist deshalb vorteilhaft, wenn jedes Attribut A1 einzeln chiffriert wird und wenn der erhaltene Chiffretext c (A =EK (A, ) separat in das jeweilige Datensatzattribut abgelegt wird.
C(T.) = (C(A1) ,C(A2) , ... ,C(AN) ):=(EK(A ,EK(A2) , E^A«) ). Dadurch bleibt die Datensatzstruktur erhalten und die Verwaltung (z.B. das Zufügen eines weiteren Attributes) wird wesentlich einfacher. Ein weiterer Vorteil bei diesem Lösungsansatz ist die optionale Chiffrierung von Attributen. Der Datensatz muss nicht als Ganzes, sondern die einzelnen Attribute können nach Bedarf chiffriert werden (z.B. nur die besonders sensiblen Daten). Im nachfolgenden Beispiel werden nur die beiden Attribute A und A2 chiffriert im Datensatz abgelegt.
C ( T3 ) = ( C ( A1 ) , C (A2 ) , A3 , AN) :
Die restlichen Attribute A3 . . . AN werden im Klartext abgespeichert.
Die Verfahren zur Sicherung der Vertraulichkeit können also in vorteilhafter Weise mit der Integritätssicherung kombiniert werden
Die Tabelleπinhalte einer Datenbank können mit einem einzigen Schlüssel K chiffriert werden. Jeder Benutzer, welcher im Besitze dieses Schlüssels ist, hat Einsicht in den Klartextraum. Alle anderen Benutzer können höchstens Einsicht in den Chiffretextraum erzielen.
Durch den Einsatz von verschiedenen Schlüsseln K-, kann differenziert werden, welche Subjekte (Benutzer) für welche Objekte (Tabellen, Attribute oder einzelne Datensätze) ein Einsichtsrecht in den Klartextraum erhalten. Das Prinzip hat grosse Ähnlichkeit mit der benutzerdefinierbaren Zugriffskontrolle DAC (discretionary access control). Der Ersteller eines Objektes chiffriert dieses mit einem temporär erzeugten Schlüssel K^. und vergibt danach die Eiπsichtsrechte in Form von Zertifikaten an jeden einzelnen oder Gruppen von Benutzern. Ein Zertifikat z beinhaltet im einfachsten Fall die Kennung des einsichtsberechtigten Benutzers sowie den chiffrierten temporären Schlüssel.
Z^ IU^ E^. ( Kj) ) Der Schlüssel K-, wird mit dem öffentlichen Schlüssel K, ■ des Benutzers u, und einem asymmetrischen Algorithmus chiffriert. Nur der Benutzer u, hat den zugehörigen geheimen Schlüssel κL und ist somit in der Lage den Schlüssel κτ zu eruieren.
Der Benutzer, welcher die Eiπsichtsrechte verteilt, wird sich selbst natürlich auch ein solches erteilen, damit er auch später Zugriff auf die entsprechenden Daten hat.
Das beschriebene Verfahren hat den Vorteil, dass keine übergeordnete Instanz vorhanden sein muss, welche die geheimen Schlüssel it- für den Vertraulichkeitsschutz verwaltet. Jeder Benutzer stellt die Schlüssel nach eigenem Bedarf selbst aus, d.h. jeder kann Ausgabestelle für Einsichtszertifikate sein.
Eine übergeordnete Instanz ist aber trotzdem für die Beglaubigung der Zusammengehörigkeit von Benutzerkennung u, und öffentlichem Schlüssel K, ' notwendig (asymmetrischer Krypto-Algorithmus). Eine solche Instanz wird aber schon im Zusammenhang mit der Integritätssicherung vorausgesetzt, so dass beim obigen Verfahren auf die gleiche Infrastruktur abgestützt werden kann.
Die oben erwähnten Zertifikate können nebst dem chiffrierten Zugriffsschlüssel K-. und der Benutzerkennung uA noch weitere Angaben über Gültigkeitsdauer, Kennung der Ausgabestelle und eine Signatur der Ausgabestelle enthalten.
Die Signatur in den Zertifikaten hat den Vorteil, dass Fälschungen sofort erkannt werden können.
Die Verschlüsselung bzw. elektronische Signierung kann z.B. mit dem sogenannten PGP-Programm von Philip Zimmermann durchgeführt werden. Dieses Programm wurde in den USA entwickelt, ist auf verschiedenen Plattformen erhältlich und hat die folgenden Algorithmen zugrunde gelegt:
• RSA (public key algorithm) 512, 768, 1024 oder 20481 Bit Schlüssel
• IDEA (block cipher algorithm) 128 Bit Schlüssel • MD5 (message digest) 128 Bit Fingerabdruck
Das Programm bietet also fertige Prozeduren für den Vertraulichkeitsschutz und die Authentifikation.
Beide Funktionen lassen sich kombiniert anwenden, damit Vertraulichkeit undAuthen- tifikation gleichzeitig gewährleistet sind, indem die Daten zuerst mit dem eigenen geheimen Schlüssel signiert und danach mit dem öffentlichen Schlüssel des Empfängers chiffriert werden. Beim Empfänger werden die Schritte umgekehrt angewendet, indem zuerst die chiffrierte Meldung mit dem geheimen Schlüssel dechiffriert und anschiies- send die Authentizität mit dem öffentlichen Schlüssel überprüft wird. Die Schritte wer- den durch PGP automatisch ausgeführt.
Für die Verschlüsselung von Daten wird der symmetrische IDEA-Algoritrimus verwendet, weil symmetrische Verfahren gegenüber den asymmetrischen um ein Vielfaches schneller sind. Das PGP erzeugt für die Verschlüsselung (für den Benutzer unsichtbar) einen temporären Schlüssel und chiffriert den Klartext damit. Der temporäre Schlüssel wird asymmetrisch mit dem öffentlichen Schlüssel des Empfängers chiffriert und zusammen mit dem Chiffretext zum Empfänger übertragen. Der Empfänger benützt seinen, geheimen Schlüssel, um den temporären Schlüssel ausfindig machen zu können. Mit dem temporären Schlüssel und dem schnellen symmetrischen Verfahren stellt er schliesslich den Klartext wieder her.
Die öffentlichen Schlüssel werden zusammen mit der Benutzerkennung und einem Zeitstempel der Generierung in öffentlichen Schlüsselzertifikaten aufbewahrt. Hingegen werden die geheimen Schlüssel in geheimen Schlüsselzertifikaten hinterlegt. Jeder geheime Schlüssel ist zudem mit einem Passwort chiffriert, damit im Falle eines Diebstahls der Schlüssel nicht angewendet werden kann. Eine Schlüsseldatei, oder auch Schlüsselbund (key ring) genannt, kann mehrere Zertifikate umfassen. Öffentliche Schlüsselbunde beinhalten öffentliche Schlüsselzertifikate und geheime Schlüsselbunde beinhalten geheime Schlüsselzertifikate. Die Schlüssel werden im PGP durch eine sogenannte Schlusselkennung (key ID) refe- renziert Dies ist eine Abkürzung des öffentlichen Schlüssels, indem die letzten 64 bit davon für die Schlusselkennung verwendet werden Obwohl mehrere Schlüssel die gleiche Benutzerkennung aufweisen können, gibt es praktisch keine zwei Schlüssel mit der gleichen Schlusselkennung
Jeder Benutzer generiert sich selbst mit dem PGP-Programm ein Schlusselpaar
( K , κ , ) 1 mιt pgp -kg
wobei der geheime Schlüssel κL mit einem Passwort oder einem ganzen Satz ge- schützt standardmassig in der Datei secrxng . pgp abgelegt ist Beim Generie- rungsprozess muss eine eindeutige Benutzerkennuπg u, angegeben werden Sie wird zusammen mit dem geheimen und dem öffentlichen Schlüssel abgelegt Der öffentliche Schlüssel K^ ist in der Datei pubring . pgp abgespeichert Beide Dateien müssen vor unerlaubten Manipulationen geschützt werden
Das Schlusselpaar ist von grossen echten Zufallszahien abgeleitet, damit der Fall ausgeschlossen werden kann, dass zwei unabhängige Benutzer das exakt gleiche Schlusselpaar erzeugen Die Zufallszahlen werden hauptsächlich von den Zeitin- tervallen zwischen den Tastaturanschlagen beim Eingeben irgendeines Textes abgeleitet Der eingetippte Text beeinflusst das Ergebnis ebenfalls, so dass nicht immer die gleiche Taste gedruckt werden soll
Bei asymmetrischen Verfahren ist es wichtig die öffentlichen Schlüssel vor Veränderungen zu schützen, damit sichergestellt werden kann, dass der öffentliche Schlüssel wirklich zu dem angegebenen Benutzer gehört Dies ist der grosste Gefahrenpunkt für asymmetrische Algorithmen Ein feindlich gesinnter Benutzer kann sonst den öffentlichen Schlüssel von einem bestimmten Benutzer gegen den eigenen austauschen, um so in den Besitz von chiffrierten Meldungen zu kommen Das Problem kann nur gelöst werden, wenn die öffentlichen Schlüssel und die Be- πutzerkennung gegen Veränderungen geschützt werden. Kein Problem entsteht, wenn der öffentliche Schlüssel vom anderen Benutzer persönlich entgegengenommen und an einem Ort aufbewahrt wird, wo niemand anderes darauf zugreifen kann (z.B. in einer Chipkarte). Die Integrität kann aber auch so geschützt werden, dass ein anderer Benutzer, dem beide vertrauen, ein Zertifikat ausstellt. Das Zertifikat bescheinigt die Zusammengehörigkeit vom öffentlichen Schlüssel und der Benutzerkennung.
Die Integrität eines Zertifikates kann danach mit dem öffentlichen Schlüssel der Vertrauensperson überprüft werden. Dazu muss man natürlich den öffentlichen Schlüssel der Vertrauensperson besitzen und die Gewähr haben, dass der Schlüssel nicht manipuliert ist. Die Integrität könnte also wieder mit einer anderen Signatur gesichert werden.
Ein öffentlicher Schlüssel darf nur zur Anwendung kommen, wenn er die Signatur einer Vertrauensperson trägt oder direkt vom Benutzer stammt, dem man vertraut.
Eine PGP-Signatur beinhaltet zwar auch einen Zeitstempel, auf diesen ist jedoch kein Verlass, da er von der Systemzeit abgeleitet wird und die Systemzeit natürlich manipulierbar ist. Ebenfalls in der PGP-Signatur enthalten ist eine Schlusselkennung (key ID) k^ Mit ihr kann das PGP-Programm beim Überprüfen einer PGP-Signatur selbständig den richtigen öffentlichen Schlüssel κ ' auswählen.
Der obige Datensatz wird nach den folgenden Schritten in die Datenbank eingetragen:
1. Der Benutzer trägt die Daten in die einzelnen Attribute des Datensatzes ein und schliesst die Transaktion ab.
2. Beim Transaktionsabschluss durch den Benutzer erstellt das PGP-Programm in einem ersten Schritt aus den eingetragenen Daten und der Benutzerkennung einen Fingerabdruck (message digest) mit Hilfe des MD5-Algorithmus. 3. Der Benutzer gibt mittels eines Passworts (oder eines ganzen Satzes) den geheimen Schlüssel Ki frei.
4. Das PGP-Programm erzeugt mit dem RSA-Algorithmus, dem geheimen Schlüssel des Benutzers und dem Fingerabdruck die Signatur.
5. Das Datenbanksystem trägt die Benutzerkennung des zu Beginn der Sitzung authentifizierten Benutzers und die erstellte Signatur in den Datensatz ein und schliesst die Transaktion ab.
Es muss ein sicherer Pfad für die Dateneingabe des Benutzers vorhanden sein. Der Benutzer soll die Gewähr haben, dass die an der Tastatur eingegebenen Daten auch tatsächlich - ohne Modifikation - in der Datenbank abgelegt werden. Ebenfalls muss verhindert werden, dass ein Benutzer einen Datensatz ohne gültige Kennung und/oder gültige Signatur eintragen oder abändern kann. Dies kann durch eine entsprechend sichere Integritätsbedingung oder durch eine sichere Programmlogik erreicht werden.
Der geheime Schlüssel κA ist chiffriert in einer Datei abgelegt. Der Schlüssel kann durch Eingabe des richtigen Passworts oder -satzes aktiviert werden. Trotzdem sollte die Datei nicht von anderen Benutzern zugänglich sein.
Für die Überprüfung einer digitalen Signatur ist der entsprechende öffentliche Schlüssel des im Datensatz festgehaltenen Benutzers notwendig. Der öffentliche Schlüssel muss in Form eines Zertifikates verfügbar sein. Im PGP-Umfeld können solche Zertifikate entweder unter den einzelnen Benutzern selbst erteilt werden (Netzstruktur) oder von einer unabhängigen vertraubaren Instanz ausgegeben werden (Baumstruktur). Die Zertifikate beweisen, dass die Benutzerkennung und der öffentliche Schlüssel zusammengehören.
Ein vorhandener Datensatz wird wie folgt auf eine korrekte Signatur überprüft:
1. Die Information im Datensatz wird zusammen mit der Benutzerkennung aufbereitet und der Fingerabdruck mit dem MD5-Algorithmus berechnet. 2. Aus der PGP-Signatur wird die Schlusselkennung k, extrahiert.
3. Der zugehörige öffentliche Schlüssel wird aus dem entsprechenden Zertifikat zλ ermittelt.
4. Die digitale Signatur wird mit dem öffentlichen Schlüssel dechiffriert und mit dem in Schritt 1 errechneten Fingerabdruck verglichen.
5. Bei Übereinstimmung der Komponenten ist der Datensatz authentisch, d.h. es hat keine unerlaubte Modifikation von Daten und Benutzerkennung stattgefunden.
Um keine vorgetäuschten richtigen Antworten zu ermöglichen muss mindestens eine Komponente des Datensatzes (Information oder Signatur) über einen sicheren Kanal zum PGP-Programm geleitet werden. Das Ergebnis der Überprüfung muss ebenfalls über einen sicheren Kanal dem Benutzer mitgeteilt werden können.
Mit der obigen Forderung betreffend sicheren Kanälen ist es aber noch möglich, dass falsche Antworten vorgetäuscht werden können. Um dies zu verhindern, müssten alle Pfade sicher sein.
Der Datenaustausch mit dem PGP-Programm geschieht entweder über Dateien oder sogenannte Pipes. Im nachfolgenden Lösungskonzept wird der Weg über Dateien gewählt.
PGP bietet die Möglichkeit beim Signiervorgang eine separate Datei für die Signatur zu erzeugen (mit der Option -b). Wenn der Benutzer mit der Kennung <benutzer_id> die Datei <dateiname> signieren will, lautet somit der Befehl:
pgp -sb <dateiname> -u <benutzer_id>
Beim Ausführen des Befehles wird das Passwort vom Benutzer verlangt, um den chiffrierten geheimen Schlüssel aktivieren zu können. Das Passwort darf vom Benutzer nicht aus der Hand gegeben werden, da sonst ein anderer Benutzer zusammen mit dem Zugriff auf secrxng . pgp in seinem Namen unterzeichnen kann. Die Signaturdatei wird unter dem Namen <dateiname> . sig abgespeichert.
Die Interaktionen zwischen der Datenbank-Applikation und dem PGP-Programm für den Signiervorgang laufen wie folgt ab:
Zuerst wird eine Datei mit den zu signierenden Daten erstellt. Damit derSigniervorgang batchmässig abläuft, wird das Passwort für die Dauer der Ausführung des pgp- Befehles mit PGPPASS=<passphrase> in die Shell exportiert. Die Angaben +batchmode und +force bewirken keine interaktiven Abfragen vom PGP-Programm und die Rückgabe des Ergebnisses im exit-Status. Ein solcher von o bedeutet eine erfolgreich erzeugte Signaturdatei.
Der Inhalt der Signaturdatei kann danach von der Datenbank-Applikation in den entsprechenden Datensatz eingefügt werden.
Die Echtheit von Daten, welche in der Datei <dateiname> enthalten sind, kann mit der zugehörigen Signaturdatei <dateiname> . sig mit dem Befehl
pgp <dateiname> . sig <dateiname>
überprüft werden.
Das Zusammenwirken der Datenbank-Applikation mit dem PGP-Programm beim Überprüfen einer Signatur ist wie folgt:
Zuerst werden durch die Datenbank-Applikation die beiden Dateien (Daten und Signatur) mit den entsprechenden Inhalten bereitgestellt. In der Datei <dateiname> werden die Benützerdaten zusammen mit der Benutzerkennung des Datensatzes und in der Datei <dateiname> . sig wird die Signatur bereitgestellt. Die Befehlsoptionen +batch ode und +force bewirken wiederum ein Unterdrücken von interaktiven Abfragen während der Ausführung und die Rückgabe vom Ergebnis im exit-Status des PGP-Programmes. Ein Rückgabewert von o ist eine positive Überprüfung, d.h. die beiden Dateien sind unverändert und vom angegebenen Benutzer signiert worden.
Eine Konfiguration, die sich für Netzwerke besonders eignet, zeichnet sich durch die folgenden Eigenschaften aus:
1. Auf dem lokalen PC (oder Workstation) wird eine lokale Installation des PGP-Programmes für die Signierung von Datensätzen eingesetzt.
2. Der geheime Schlüssel eines Benutzers ist auf einer persönlichen schreibge- schützten Diskette (Diskettenschlüssel) zusammen mit dem öffentlichen Schlüssel der Ausgabestelle abgelegt.
3. Auf dem Datenbankserver ist ebenfalls eine Installation des PGP-Programmes für die Überprüfung der Signaturen von Datensätzen vorhanden.
4. Die öffentlichen Schlüssel aller Benutzer sind schreibgeschützt auf dem Server verfügbar.
Ein Benutzer meldet sich beim Datenbankserver an, indem die lokale Arbeitsstation (PC) eine Zufallsmeldung vom Server erhält. Die Zufallsmeldung wird mit Hilfe des lokalen PGP-Programmes und des geheimen Schlüssels chiffriert wieder zum Server zurückgeschickt. Dieser kann mit dem öffentlichen Schlüssel die Authentizität des Benutzer überprüfen.
Der Benutzer signiert Datensätze mit dem lokal installierten PGP-Programm, indem der schreibgeschützte Diskettenschlüssel (Diskette mit dem geheimen Schlüssel) in das Laufwerk geschoben und das Passwort eingetippt werden. Nach der Signierung wird der Diskettenschlüssel wieder aus dem Laufwerk entfernt. Datensätze in der Datenbank werden mit dem auf dem Server installierten PGP- Programm auf ihre Echtheit überprüft. Alle öffentlichen Schlüssel auf dem Server sind durch die Ausgabestelle einmal zertifiziert (unterschrieben) worden. Die Zertifikate können von jedem Benutzer mit dem öffentlichen Schlüssel der Ausgabestelle überprüft werden. Dieser ist auch auf dem persönlichen Diskettenschlüssel enthalten und so vor Manipulationen geschützt. Ein Angreifer müsste demzufolge möglichst viele Disketteπschlüssel manipulieren, um die Wirksamkeit des Systems zu unterlaufen.
Die Ausgabestelle legt die Benutzerkennung ua anhand von Richtlinien fest und generiert für sich ein Schlüsselpaar ( K , K ' ) a. Der öffentliche Schlüssel wird selbst unterzeichnet gemäss
Za= (Ua , Ka - , EKa ( Ua | Ka ' ) )
Die Ausgabestelle ist jetzt bereit, den Benutzern ihre öffentlichen Schlüssel zu unterschreiben, d.h. Zertifikate Z, für deren öffentliche Schlüssel auszustellen.
Der Ablauf für die Generierung von Benützerschlüsseln und die Ausstellung von Zertifikaten läuft wie folgt ab:
1. Ein neuer Benutzer generiert lokal ein Schlüsselpaar (κ, K ' ) .. Die Benutzerkennung u wählt er nach den Vorgaben der Ausgabestelle.
2. Das Schlüsselpaar wird auf einer Diskette (der Schlüsseldiskette) abgelegt und der öffentliche Schlüssel K, ■ vom Benutzer gleich selbst unterzeichnet.
3. Die Ausgabestelle überprüft die Signatur des Benutzers und stellt danach ein Zertifikat zx für den öffentlichen Schlüssel K, ' und die dazugehörende Benutzerkennung u,. aus. 4. Die Ausgabestelle stellt das Zertifikat z auf dem Server systemweit den anderen Benutzern zur Verfügung (nur Lesezugriff).
5. Die Ausgabestelle stellt dem Benutzer eine persönliche Kopie ihres unterschriebenen öffentlichen Schlüssels za zur Verfügung.
6. Der Benutzer kopiert za auf die Schlüsseldiskette und aktiviert den Schreibschutz.
Der Diskettenschlüssel und das Laufwerk sind vergleichbar mit einer Smart-Card und dem dazugehörenden Lesegerät. So wie die Smart-Card mit einem Passwort aktiviert wird, so wird auch der Diskettenschlüssel aktiviert. Der Unterschied liegt darin, dass der geheime Schlüssel bei dieser Lösung im Hauptspeicher der lokalen Arbeitsstation offengelegt wird. Bei der Smart-Card verlässt der geheime Schlüssel die Karte nie.
Zusammenfassend ist folgendes festzuhalten:
Um Datensätze zu signieren und bestehende Signaturen auf ihre Echtheit hin zu überprüfen ist ein separater Krypto-Prozess vorgesehen. Der Signiervorgang wird vorzugsweise in einer Smart-Card durchgeführt. Dadurch ist der geheime Schlüssel sehr wirksam geschützt (der Schlüssel verlässt die Karte nie) und der Besitzer hat die Karte immer unter seiner Aufsicht. Die Überprüfung von Signaturen hingegen kann ohne weiteres auf einer leistungsfähigeren Plattform (Arbeitsstation) bleiben, weil dieser Vorgang sicherheitstechnisch unkritisch ist. Der einzige kritische Punkt dabei ist der öffentliche Schlüssel der Ausgabestelle zum Überprüfen der Benützerzertifikate. Dieser Schlüssel sollte ebenfalls in der Smart-Card von jedem Benutzer abgelegt werden, um Maskeraden vorbeugen zu können.
Die Benützerzertifikate können in der gleichen Datenbank verwaltet werden. Dies muss aber nicht so sein, denn es wäre auch möglich, die Zertifikate in einer externen Einheit
(z.B. separate Datenbank, X.500 Verzeichnisdienst oder Authentifikations-Server) zu verwalten und somit mehreren Applikationen zur Verfügung zu stellen. Ein sogenannter Authentifikations-Server würde nebst der Zertifikatsverwaltung auch die Identifizierung und Authentifizierung der Benutzer (mit Passwort, Token oder biometrischen Verfahren) durchführen.
Die Erfindung kann im Prinzip in jeder Datenbank eingesetzt werden. Zu erwähnen sind insbesondere die an sich bekannten objektorientierten und die relationalen Datenbanken. Objektorientierte Datenbanksysteme bieten nicht nur die Vorteile der objektorientierten Programmierung, sondern sind flexibler in Bezug auf die Implementation des erfindungsgemässen Verfahrens. Relationale Datenbanksysteme sind wesentlich mehr standardisiert und schränken demzufolge auch die Lösungsmöglichkei- ten ein.
Die beschriebenen Ausführungsbeispiele decken zwei Punkte der Sicherheitsarchitektur mit kryptografischen Schutzmechanismen ab:
• Die Einträge von Benutzerdaten in der Datenbank werden mit digitaler Signatur versehen. Beim späteren Zugriff kann die Authentizität des Eintrages sowie die Benutzerkennung zuverlässig überprüft werden.
• Die Anmeldeprozedur mit Passwort und asymmetrischer Verschlüsselung.
Der kryptografische Teil kann durch das PGP-Programm abgedeckt werden, wobei die ebenfalls im PGP Programm enthaltene Chiffrierfunktion nicht zur Anwendung gelangen muss. Es werden nur die Funktionen für Schlüsselgenerierung und -verwal- tung sowie für die Authentifizierung von Daten angewendet.
• RSA gilt im allgemeinen als sicher, wenn genügend grosse Schlüssel (512 bit gelten als unsicher) verwendet werden. Die Sicherheit basiert auf der Schwierigkeit vom Zerlegen von grossen Integerzahlen. In letzter Zeit wurden jedoch enorme Fortschritte in diesem Gebiet gemacht. RSA ist sehr anfällig auf »gewählte Klartext-At- tacken« (chosen plaintext attack). Bei der Anwendung für Signierzwecke besteht diese Gefahr nicht, weil noch eine kryptografische Hashfunktion (MD5) dazwi- schengeschaltet ist.
• MD5 ist eine sichere Hashfunktion und erzeugt von einer beliebigen Zeichenkette einen Hashwert von 128 bit Länge.
• Schlüsselgenerierung: Für die Schlüsselgenerierung werden "echte" Zufallszahlen benötigt, damit keine zwei gleichen Schlüsselpaare erzeugt werden. Die Zufallszahlen werden u.a. von der Schreibgeschwindigkeit und dem eingegebenen Text abgeleitet. Diese Merkmale sind sehr individuell und somit einmalig.
• Schlüsselverwaltung: Eine hierarchische Vertrauensstruktur ist für eine Datenbank sinnvoll und kann problemlos abgebildet werden. Der öffentliche Schlüssel der Ausgabestelle muss über einen sicheren Kanal mitgeteilt (z.B. persönliche Übergabe) und gegen Manipulationen geschützt aufbewahrt (z.B. persönliche Diskette mit Schreibschutz) werden können.
Für die Verwaltung der Schlüssel wird In den meisten Fällen eine einfache Vertrau- enshierarchie (Ausgabestelle, Benutzer) genügen. Jeder Benutzer generiert sich die Schlüsselpaare selbst und lässt den öffentlichen Schlüssel durch die Ausgabestelle (Vertrauensinstanz) zertifizieren.
Die Konfiguration für eine Client/Server Umgebung weist die folgenden Merkmale auf:
Auf dem PC (oder Workstation) wird eine lokale Installation des PGP-Programmes für die Signierung von Datensätzen eingesetzt. Der lokale Applikationsteil (Client) kommuniziert mit dem lokal installierten PGP-Programm.
Der geheime Schlüssel eines Benutzers ist auf einer persönlichen schreibgeschützten Diskette (Diskettenschlüssel) zusammen mit dem öffentlichen Schlüssel der Ausgabestelle abgelegt. Auf dem Datenbankserver ist ebenfalls eine Installation des PGP-Programmes für die Überprüfung der Signaturen von Datensätzen vorhanden. Die Server-Applikation kommuniziert mit dem auf dem Server installierten PGP-Programm.
Alle öffentlichen Benützerschlüssel sind schreibgeschützt auf dem Server verfügbar.
Ein Benutzer meldet sich beim Datenbankserver an, indem die lokale Arbeitsstation (PC) eine Zufallsmeldung vom Server erhält. Die Zufallsmeldung wird mit Hilfe des lokalen PGP-Programmes und des geheimen Schlüssels chiffriert wieder zum Server zurückgeschickt. Dieser kann mit dem öffentlichen Schlüssel die Authentizität des Benutzers überprüfen.
Der Benutzer signiert Datensätze mit dem lokal installierten PGP-Programm, indem der schreibgeschützte Diskettenschlüssel (Diskette mit dem geheimen Schlüssel) in das Laufwerk geschoben und das Passwort eingetippt werden. Nach der Signierung wird der Diskettenschlüssel wieder aus dem Laufwerk entfernt.
Datensätze in der Datenbank werden mit dem auf dem Server installierten PGP-Pro- gramm auf ihre Echtheit überprüft. Alle öffentlichen Schlüssel auf dem Server sind durch die Ausgabestelle einmal zertifiziert (unterschrieben) worden. Die Zertifikate können von jedem Benutzer mit dem öffentlichen Schlüssel der Ausgabestelle überprüft werden.

Claims

Patentansprüche
1. Verfahren zur elektronisch gesicherten Speicherung von Daten in einer Datenbank, dadurch gekennzeichnet, dass Datensätze bei ihrer Erstellung bzw. Änderung mit einer Benutzerkennung (Ui) und einer sowohl die Daten (M) als auch die Benutzerkennung (Ui) verschlüsselnden elektronischen Signatur (C) versehen werden, um dann auf diese Weise zu einem erweiterten Datensatz ergänzt abgespeichert zu werden.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass zur Bildung der elektronischen Signatur (C) zuerst die Daten (M) zusammen mit der Benutzer- keπnung (Ui) unter Zuhilfenahme einer Hashfunktion (HF) auf eine Bitsequenz
(H) vorgegebener Länge reduziert werden, um dann mit einem elektronischen Chiffrierverfahren verschlüsselt zu werden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass zur Erzeugung der elektronischen Signatur ein asymmetrisches Chiffrierverfahren, insbe- sondere ein RSA-Verfahren verwendet wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Benutzerkennungen (Ui) mit den dazugehörenden, für die Prüfung der elektronischen Signatur erforderlichen Schlüsseln bei einer Zentrale authentifiziert und abgespeichert werden.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Zentrale die Benutzerkennungen und die entsprechenden Schlüssel mit einem asymmetrischen Chiffrierverfahren signiert bzw. authentifiziert.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass eine Abspeicherung von Daten nur dann zugelassen wird, wenn die Benutzerkennung eingegeben worden ist.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass zusätzlich zur Benutzerkennung ein Zeitstempel (TS) in den Datensatz aufgenommen und signiert wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass bei einer Änderung bzw. Löschung von alten Daten diese mit einer signierten Löschmarkierung versehen und abgespeichert werden, um stets eine Historie der Daten zur Verfügung zu haben.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass über Datenbankzugriffe Protokolldaten erstellt und elektronisch signiert abgespeichert werden.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die elektronische Signatur in einer Chipkarte erstellt wird, welche zu diesem Zweck temporär mit dem Datenbanksystem verbunden wird.
11. Vorrichtung zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 10, umfassend
a) einen Computer, welcher zur Bearbeitung und Speicherung von Daten in einer Datenbank programmiert ist,
b) eine Arbeitsstatioπ für die Eingabe der Daten,
c) einen zugriffsgeschützten Speicher mit einem Chiffrierschlüssel,
d) einer Recheneinheit zur Erzeugung einer elektronischen Signatur, wobei e) Mittel vorgesehen sind, welche Daten vor deren Abspeicherung in der Datenbank zusammen mit einer Benutzerkennung der Recheneinheit zur Erzeugung einer elektronischen Signatur übergeben, um erst dann den die Daten, die Benutzerkennung und die elektronische Signatur enthaltenden Datensatz abzuspeichern.
12. Vorrichtung nach Anspruch 11 , dadurch gekennzeichnet, dass der zugriffsgeschützte Speicher und die Recheneinheit Teil einer persönlichen Chipkarte sind.
EP97945716A 1996-12-12 1997-12-11 Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank Withdrawn EP0947072A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CH304796 1996-12-12
CH304796 1996-12-12
PCT/CH1997/000462 WO1998026537A1 (de) 1996-12-12 1997-12-11 Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank

Publications (1)

Publication Number Publication Date
EP0947072A1 true EP0947072A1 (de) 1999-10-06

Family

ID=4247425

Family Applications (1)

Application Number Title Priority Date Filing Date
EP97945716A Withdrawn EP0947072A1 (de) 1996-12-12 1997-12-11 Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank

Country Status (2)

Country Link
EP (1) EP0947072A1 (de)
WO (1) WO1998026537A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101603A (en) * 1997-05-21 2000-08-08 At&T Corporation System and method for using a second resource to store a data element from a first resource in a first-in last-out stack
DE19925910B4 (de) * 1999-06-07 2005-04-28 Siemens Ag Verfahren zum Be- oder Verarbeiten von Daten
US6675152B1 (en) 2000-09-13 2004-01-06 Igt Transaction signature
DE10136608B4 (de) 2001-07-16 2005-12-08 Francotyp-Postalia Ag & Co. Kg Verfahren und System zur Echtzeitaufzeichnung mit Sicherheitsmodul
FR2839594B1 (fr) * 2002-05-10 2004-07-30 Radio Systemes Ingenierie Procede de transmission radiofrequence securisee et systeme mettant en oeuvre ce procede
DE10343369A1 (de) * 2003-09-17 2005-05-04 Francotyp Postalia Ag Verfahren zum Zuordnen von Identifikationen zu Informationen

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2596177B1 (fr) * 1986-03-19 1992-01-17 Infoscript Procede et dispositif de sauvegarde qualitative de donnees numerisees
US5005200A (en) * 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
EP1691315A1 (de) * 1994-10-27 2006-08-16 Intarsia Software LLC Verwaltungssystem für Datenurheberrecht

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9826537A1 *

Also Published As

Publication number Publication date
WO1998026537A1 (de) 1998-06-18

Similar Documents

Publication Publication Date Title
DE69724946T2 (de) Programmvermietungssystem und Verfahren zur Vermietung von Programmen
DE69725833T2 (de) Gesicherte zweiteilige Benutzer-Authentifizierung in einem Rechnernetz
DE60023705T2 (de) Sichere verteilung und schutz einer schlüsselinformation
DE69534757T2 (de) System und Verfahren zur sicheren Speicherung und Verteilung von Daten unter Verwendung digitaler Unterschriften
DE69724235T2 (de) Computersystem und Verfahren zum Schutz von Software
DE60211841T2 (de) Vorrichtung zur Aktualisierung und zum Entzug der Gültigkeit einer Marke in einer Infrastruktur mit öffentlichen Schlüsseln
DE69704684T2 (de) Vorrichtung und Verfahren zur Authentifizierung von Zugangsrechten eines Benutzers zu Betriebsmitteln nach dem Challenge-Response-Prinzip
DE69635143T2 (de) Verfahren und Vorrichtung zur Erzeugung und Verwaltung eines privaten Schlüssels in einem kryptografischen System mit öffentlichem Schlüssel
EP1946481B1 (de) Verfahren zur erzeugung einer fortgeschrittenen elektronischen signatur eines elektronischen dokuments
DE69727198T2 (de) Durchführen digitaler Unterschriften für Datenströme und Archive
DE60117598T2 (de) Sichere transaktionen mit passiven speichermedien
DE69629857T2 (de) Datenkommunikationssystem unter Verwendung öffentlicher Schlüssel
DE69028894T2 (de) Einrichtung zur notariellen Beglaubigung des Datums und der Zeit mittels öffentlichem Schlüssel
EP1214812B1 (de) Verfahren zum schutz von daten
EP1410128A1 (de) Datenverarbeitungsvorrichtung
DE19827659A1 (de) Systeme und Verfahren zum Speichern von Daten und zum Schützen der Daten gegen einen nichtauthorisierten Zugriff
DE10233297A1 (de) Vorrichtung zur digitalen Signatur eines elektronischen Dokuments
DE19959764A1 (de) Verbesserte digitale Signatur
EP0947072A1 (de) Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank
DE102020118716A1 (de) Verfahren zur sicheren Durchführung einer Fernsignatur sowie Sicherheitssystem
WO2008012020A1 (de) Verfahren zum erzeugen von zugangsdaten für ein medizinisches gerät
DE19703970B4 (de) Verfahren zur Erfassung von Daten und deren Übermittlung in authentischer Form
WO2022120400A1 (de) Verfahren zum migrieren einer it-anwendung
EP1362272B1 (de) Verfahren und anordnung für ein rechte-ticket-system zur erhöhung der sicherheit bei der zugangskontrolle zu rechnerrecourcen
DE10020562C1 (de) Verfahren zum Beheben eines in einer Datenverarbeitungseinheit auftretenden Fehlers

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19990525

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE ES FI FR GB IE IT LI NL SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030701