WO1998026537A1 - Method for electronically protected storage of data in a data bank - Google Patents

Abstract

The invention relates to a method for protected data management in a data bank, whereby the data records upon creation or modification are provided with a user identifier (Ui) and an electronic signature (C) which encrypts the data and the user identifier. In order to create said electronic signature (C), the data (M) is initially reduced along with the user identifier (Ui) to a bit sequence (H) of a predetermined length by means of a hash function (HF) and subsequently encrypted by means of an electronic (preferably asymmetrical) ciphering method.

Description

 Process for electronically secure storage of data in a database

Technical field

The invention relates to a method for electronically secured storage of data in a database and a device for performing the method. State of the art

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.

The effects can be divided into three categories:

• Unauthorized gain of information (loss of confidentiality) 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. To increase security, 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. In addition, 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. When the signature is created, the data (object) is subjected to a hash function. In addition to the actual data, Date and identification of the signer are also included in the signature.

Presentation of the invention

The object of the invention is to protect the data stored in a database against accidental or deliberate unauthorized access (modifications).

The solution to the problem is defined by the features of claim 1. According to the invention, 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. In a medical database, for example, 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 In contrast, does not take into account the database structure, but only assumes how many bits can be processed with a signature with reasonable computing effort

According to a preferred embodiment, 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.There are two secret keys (private key) and one public key.The secret key is used to generate and the public key to verify the electronic signature.These are examples of asymmetrical encryption methods RSA and the DSA method (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) In systems with a large number of users, it is advisable to use a central for the authentication of the public keys. 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.

If 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).

Unless the entire data record is additionally protected against unauthorized reading by encryption, the data and user ID are saved in plain text. It is therefore always possible to get the key belonging to the user ID from the control center, which then allows the signature to be verified.

As a rule, 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.)

If 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. In the same way, 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. 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. In principle, 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.

For security reasons, it is always advantageous if the signature is physically calculated as close as possible to the input device and added to the data record.

In principle, it is not necessary to develop new database systems. External cryptographic functions can be used without further ado. The data exchange takes place, for example, via so-called "data pipes". The encryption procedures are separate program modules that are hacked by the database program. It is of course more convenient for the system programmer if the database program itself provides the finished functions for carrying out the electronic signature and for checking.

From the following detailed description and the entirety of the claims, further advantageous embodiments and combinations of features of the invention result.

Brief description of the drawings

The drawings used to explain the exemplary embodiment show:

Figure 1 is a schematic representation of the principle for backing up the data.

2 shows a schematic representation of a computer system for carrying out the method.

In principle, the same parts are provided with the same reference symbols in the figures.

Ways of Carrying Out the Invention The integrity of the following objects can be protected against unnoticed modification with digital signatures:

Entries of the application and / or users in the database Entries in the dictionary of the database ^• User profiles

Log files

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.

It is not only possible to secure application or user-related data against manipulation in the above manner, but also any type of entries. This means that every existing data record in the database can in principle be provided with a checksum, a digital signature. When entering a procedure with a specified integrity condition (check constraint) ensures that the above condition is correct everywhere in the database. If the condition is not met, the entry is rejected. This means that entries for the dictionary (authorization data, security axioms, integrity rules, etc.) also receive a digital signature.

The data records for the user profiles (e.g. access rights and privileges at operating system level) can be saved in the same way.

In addition to the digital signature, 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

For the sake of simplicity, the exemplary embodiments described below deal only with the backup of data records which the user enters or changes. With the other possible applications, the invention can be implemented analogously

The integrity of a single data record in the database system is reliably protected with an asymmetric cryptographic procedure (eg RSA or DSA). 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

• Time stamp (date and time of modification or creation of the data record)

• User ID (unique user identification in the database system)

• digital signature (depending on the information in the data record, the time stamp, the user ID and the user's secret key)

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

1 illustrates the structure of a data record according to the invention. 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. This is converted with 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.

Every entry or change is recorded in the database in this way and protected against manipulation.

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.

The data M are entered on the input device 5. When the enter key is pressed, 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 functions and elements indicated in the figures are explained in detail below.

So that the digital signature does not become too extensive and the calculation effort also remains within the scope, 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 | TS | Ui). The fingerprint is then encrypted using an asymmetric cryptographic algorithm and a secret key Ki. The result obtained is a digital signature

C = E _rι (H (M | TS | U.))

filed.

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.

The above data record is entered into the database after the following steps:

1. The user enters the data in the individual attributes of the data record and closes the transaction (commit).

2. When the transaction is completed by the user, a fingerprint of the entered data and the user ID is initially generated (hash function). 3. The database system enters the user ID of the user authenticated at the beginning of the session in the data record.

4. The fingerprint of the data and the user ID are encrypted in a signature unit.

5. The generated signature is entered in the data record and the transaction is completed.

There must be a secure path for the user's data entry. The user must have the guarantee that the data entered on the keyboard will actually be stored in the database without modification.

An attacker could otherwise masquerade by installing a program that only pretends to interact with the user, but stores other data in the background and has it signed by the user. All without the user noticing.

It is advantageous if the electronic signature (physically speaking) is calculated as close as possible to the input.

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.

As a variant of the method described above, 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:

1. The user enters the data in the individual attributes of the data record and closes the transaction (commit).

2. When the transaction is completed by the user, a fingerprint of the entered data and the user ID is initially generated (hash function).

3. The fingerprint is encrypted in a signature unit.

4. The generated signature is entered in the data record together with the user ID contained in the signature unit and the transaction is completed.

As with the first variant, there must also be a secure path for user data entry. The signature unit in turn contains the secret key Ki and the identifier Ui of the user.

The lack of verifiability at which point in time a certain transaction took place can be remedied by introducing a time stamp TS (date and time). Such a time stamp is created by a secure and accurate time service. The server can e.g. provide signed time codes. Alternatively, 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:

1. The user enters the data in the individual attributes of the data record and closes the transaction (commit). 2. When the transaction is completed by the user, a fingerprint of the data entered, the time stamp and the user ID is initially generated.

3. The current time and date are added to the data record.

4. The fingerprint is encrypted in a signature unit (e.g. smart card).

5. The generated signature is entered in the data record and the transaction is completed.

In the embodiment mentioned, 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.

Assuming the log file consists of sequential entries (records), it must be prevented that entries can be added or removed without being noticed. This can be achieved, for example, by giving each entry a consecutive number. Two identical numbers in the file are not permitted. Whether the last entry is actually the last can only be reliably determined when the next entry is created: If the number is a successor to the previous entry, it was actually the last entry at the moment.

A log record is created as follows:

1. The DBMS or the operating system reports an event to be logged to the log monitor.

2. 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.

4. A fingerprint is created from the number, the information, the time stamp and the user identification.

5. The fingerprint is encrypted in the signature unit.

6. The generated signature and the protocol monitor entry are entered in the data record, which is then saved on the disk.

Because no secure integrity check logic prevents incorrect entries, the entire log monitor must be secure so that tampering can be excluded. The events must be able to be sent to the log monitor via a secure path. 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.

The digital signature E _KI (H (M) | τs | u is decrypted with the public key K, 'of the user u _L

H (M | TS | U,) <- D-, (E _U (H (M | TS | U,)))

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.and the fingerprint H (M | TS | U of the original components TS,

and received. This is compared with the calculated fingerprint H (M | TS | U of the entry. If there is a complete match, one can be sure that the entry is authentic, ie that the user has saved the existing information content M at the specified time TS. If the two fingerprints do not match, the data record is not valid and can no longer be used because it is based on unauthorized manipulation.

In the methods described above, 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:

1. The integrity condition is triggered by an INSERT or UPDATE command.

2. When the transaction is completed, the user ID is determined from the data record.

3. Then a fingerprint of the entered data and the user ID is generated.

4. The user certificate with the public key is requested.

5. The digital signature is decrypted using the public key.

6. 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 must be able to check the authenticity of a data record. Despite the integrity condition already described, subsequent manipulations cannot be excluded. It should therefore be possible to check a data record when it is being used.

An existing data record is checked for a correct signature as follows:

1. First, the user ID is determined from the data record.

2. Then a fingerprint of the entered data and the user ID is generated.

3. The user certificate with the public key is requested.

4. The digital signature is decrypted using the public key.

5. 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.

6. If the components match, the data record is authentic, i.e. no unauthorized modification has taken place.

At least one component of the data record (information or signature) 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 previously mentioned methods are based on the following requirements:

• 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.

• Use of a suitable one-way function (hash function) for compressing the information M of the data record. The likelihood that with others

Information M ¹ the same fingerprint

H (M ') = H (M)

is calculated, should be negligibly small.

• The digital signature obtained with the asymmetric cryptographic algorithm (RSA or DSA) cannot be calculated without knowledge of the secret key K,.

• The secret key κ ₁ 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 proposed methods do not protect against unintentional or deliberate deletion of a data record. In order to prevent important information from disappearing in this way, delete operations should no longer be permitted in the database system. The delete command will only mark the data entry as deleted, but not destroy it. This would require another attribute ("delete field"). Duplication of an existing or existing data record (replay attack) must also be prevented If, as suggested above, no data records can be deleted, identical data records are no longer plausible and can be easily recognized or even prevented by the database system when they are entered (e.g. Signature as primary key)

It should be emphasized that ensuring the integrity of the data should in principle be treated separately from ensuring confidentiality. In practice, the demands for integrity and confidentiality often occur together, but are not necessarily linked to one another

The following should be noted regarding the question of confidentiality

The following database objects can be protected against loss of confidentiality using cryptographic procedures

• Entry of the application and / or user in the database

• User password

• Entries in the logbook of the DBMS

• Backup copies of the database and logbook

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.

In this way, 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.

In contrast to authentication, the cryptographic method used is a symmetrical method (e.g. DES = Data Encryption Standard, IDEA = International Data Encryption Algorithm, see WO 91/18459). All authorized users receive the same secret key K with which they encrypt the information M.

C = E _K (M)

and decipher the ciphertext c again with the inverse function E _κ -1

M = E _K -1 (C) = EK-KEK ()) = M

can. 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.

If all N attributes of a data record T., are encrypted together,

Additional information must be added so that the decryption can be broken down into the individual attributes A, again correctly. It is therefore advantageous if each attribute A _{1 is} encrypted individually and if the received cipher text c (A = E _K (A,) is stored separately in the respective data record attribute.

C (T.) = (C (A ₁ ), C (A ₂ ), ..., C (A _N )) _: = (E _K (A, E _K (A ₂ ), E ^ A «)) . As a result, the data record structure is retained and administration (eg adding an additional attribute) is much easier. 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.

C (T ₃ ) = (C (A ₁ ), C (A ₂ ), A ₃ , A _N ) _:

The remaining attributes A ₃ . , , A _N are saved in plain text.

The methods for ensuring confidentiality can therefore be combined with integrity assurance in an advantageous manner

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.

By using different keys K-, it can be differentiated which subjects (users) for which objects (tables, attributes or individual data records) are given a right of access to the plain text space. The principle is very similar to the user-definable access control DAC (discretionary access control). The creator of an object encrypts it with a temporarily generated key K ^. and then assigns the inspection rights in the form of certificates to each individual or group of users. In the simplest case, a certificate z contains the identifier of the authorized user and the encrypted temporary key.

Z ^ IU ^ E ^. (Kj)) 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.

However, a higher-level entity is still required for the authentication of the association of user ID u and public key K, '(asymmetrical crypto-algorithm). However, such an instance is already assumed in connection with integrity assurance, so that the same infrastructure can be used in the above procedure.

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:

• RSA (public key algorithm) 512, 768, 1024 or 20481 bit key

• IDEA (block cipher algorithm) 128 bit key • MD5 (message digest) 128 bit fingerprint

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. In contrast, 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. Although several keys can have the same user ID, there are practically no two keys with the same key identifier

Each user generates a key pair with the PGP program

(K, κ ^, ) ₁ has pgp -kg

whereby the secret key κ _{L is} protected with a password or an entire sentence by default in the secrxng file. pgp is stored During the generation process, a unique user ID must be specified. It is stored together with the secret and the public key. The public key K ^ is in the pubring file. pgp saved Both files must be protected against unauthorized manipulation

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

With asymmetric methods, it is important to protect the public key from changes so that it can be ensured that the public key really belongs to the specified user. This is the greatest danger for asymmetrical algorithms. A hostile user can otherwise use the public key from a specific user exchange it with your own to get encrypted messages The problem can only be solved if the public keys and the user identification are protected against changes. No problem arises if the public key is personally accepted by the other user and kept in a place where no one else can access it (e.g. in a chip card). However, the integrity can also be protected in such a way that another user, whom both trust, issues a certificate. The certificate certifies that the public key and user ID belong together.

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 above data record is entered into the database after the following steps:

1. The user enters the data in the individual attributes of the data record and closes the transaction.

2. 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).

4. The PGP program generates the signature using the RSA algorithm, the user's secret key and the fingerprint.

5. 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.

There must be a secure path for the user's data entry. The user should have the guarantee that the data entered on the keyboard is actually stored in the database without modification. It must also be prevented that a user can enter or change a data record without a valid identifier and / or signature. This can be achieved through a correspondingly secure integrity condition or through secure program logic.

The secret key κ _A is stored encrypted in a file. The key can be activated by entering the correct password or phrase. However, 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. In the PGP environment, such 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.

An existing data record is checked for a correct signature as follows:

1. The information in the data record is prepared together with the user ID and the fingerprint is calculated using the MD5 algorithm. 2. The key identifier k, is extracted from the PGP signature.

3. The associated public key is determined from the corresponding certificate z _λ .

4. The digital signature is decrypted with the public key and compared with the fingerprint calculated in step 1.

5. If the components match, the data record is authentic, i.e. there has been no unauthorized modification of data and user ID.

In order not to allow fake correct answers, 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.

However, with the above requirement regarding secure channels, it is still possible that false answers can be faked. To prevent this, all paths should be safe.

The data exchange with the PGP program takes place either via files or pipes. In the following solution concept, 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:

pgp -sb <filename> -u <user_id>

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.

The interactions between the database application and the PGP program for the signing process run as follows:

First, a file with the data to be signed is created. To ensure that the signing process runs in batches, the password is exported to the shell for the duration of the execution of the pgp command with PGPPASS = <passphrase>. 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 authenticity of data contained in the file <file name> can be checked with the associated signature file <file name>. sig with the command

pgp <file name>. sig <filename>

be checked.

The interaction of the database application with the PGP program when checking a signature is as follows:

First, 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 configuration that is particularly suitable for networks is characterized by the following properties:

1. A local installation of the PGP program is used on the local PC (or workstation) for the signing of data records.

2. 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.

3. An installation of the PGP program for checking the signature of data records is also available on the database server.

4. The public keys of all users are available on the server as read-only.

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

Z _a = (U _a , K _a -, E _Ka (U _a | K _a '))

The issuing office is now ready to sign the users' public keys, i.e. Certificates Z to issue for their public keys.

The process for generating user keys and issuing certificates is as follows:

1. A new user generates a key pair locally (κ, K ') .. The user ID u chooses according to the specifications of the issuing office.

2. The pair of keys is stored on a diskette (the key diskette) and the public key K, ^{■ is signed} by the user himself.

3. 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).

5. The issuing office provides the user with a personal copy of their signed public key z _a .

6. 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.

In summary, the following should be noted:

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, on the other hand, 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

(e.g. separate database, X.500 directory service or authentication server) and thus to make them available to several applications. A so-called In addition to certificate management, authentication servers would also identify and authenticate users (using a password, token or biometric method).

In principle, the invention can be used in any database. In particular, the 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 exemplary embodiments described cover two points of the security architecture with cryptographic protection mechanisms:

• 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 login procedure with password and asymmetrical encryption.

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 is a safe hash function and generates a hash value of 128 bit length from any character string.

• Key generation: "Real" random numbers are required for key generation so that no two identical key pairs are generated. The random numbers are derived from the writing speed and the entered text. These features are very individual and therefore unique.

• Key management: 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).

In most cases, a simple hierarchy of trust (issuing office, user) will suffice to manage the keys. Each user generates the key pairs themselves and has the public key certified by the issuing authority.

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. There is also an installation of the PGP program on the database server for checking the signatures of data records. The server application communicates with the PGP program installed on the server.

All public user keys are available on the server as read-only.

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.

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.

Claims

claims 1. A method for electronically secured storage of data in a database, characterized in that data records when they are created or modified with a user ID (Ui) and an electronic signature (C.) That encrypts both the data (M) and the user ID (Ui) ) must be provided in order to be saved in this way to form an extended data set. 2. The method according to claim 1, characterized in that to form the electronic signature (C) first the data (M) together with the user identification (Ui) with the aid of a hash function (HF) on a bit sequence (H) of a predetermined length can be reduced in order to then be encrypted using an electronic encryption method. 3. The method according to claim 1 or 2, characterized in that an asymmetrical encryption method, in particular an RSA method, is used to generate the electronic signature. 4. The method according to any one of claims 1 to 3, characterized in that the user IDs (Ui) with the associated keys required for checking the electronic signature are authenticated and stored at a central office. 5. The method according to claim 4, characterized in that the center signs or authenticates the user IDs and the corresponding keys using an asymmetrical encryption method. 6. The method according to any one of claims 1 to 5, characterized in that storage of data is only permitted when the user ID has been entered. 7. The method according to any one of claims 1 to 6, characterized in that in addition to the user ID, a time stamp (TS) is recorded and signed in the data record. 8. The method according to any one of claims 1 to 7, characterized in that in the event of a change or deletion of old data, these are provided with a signed deletion marker and stored in order to always have a history of the data available. 9. The method according to any one of claims 1 to 8, characterized in that protocol data are created and stored electronically signed via database accesses. 10. The method according to any one of claims 1 to 9, characterized in that the electronic signature is created in a chip card, which is temporarily connected to the database system for this purpose. 11. An apparatus for performing the method according to one of claims 1 to 10, comprising a) a computer which is programmed to process and store data in a database, b) a work station for the input of the data, c) an access-protected memory with an encryption key, d) a computing unit for generating an electronic signature, wherein e) Means are provided which, prior to their storage in the database, are passed on to the computing unit together with a user ID for generating an electronic signature, only to then save the data record containing the data, the user ID and the electronic signature. 12. The device according to claim 11, characterized in that the access-protected memory and the computing unit are part of a personal chip card.