DE102013007202A1 - Method for building a key infrastructure - Google Patents

Abstract

A method for establishing a key infrastructure comprises the following steps: At the beginning, a communication channel between a first portable terminal (10) and a second portable terminal (20) is established by spatial proximity (S3) of the terminals (10; 20) to one another such that a Contactless data communication between the terminals (10; 20) is possible via a predetermined short-range communication protocol. In a second step (S4), a first cryptographic key (PuKA; SZA) is transmitted from the first terminal (10) to the second terminal (20) via the established data communication channel using the specified short-range communication protocol. Finally, the second terminal (20) confirms (S7) receipt of the first cryptographic key (PuKA; SZA).

Description

The present invention relates to a method for establishing a key infrastructure, in particular a PK key infrastructure, in which each party is associated with a key pair consisting of a public key (PK) and a secret key associated with the public key.

An important security aspect of such a PK key infrastructure and the use of the assigned keys for encrypted data communication and / or for signing data to be transmitted is the trustworthiness of the public keys. Ie. it must be clear to all parties involved that a public key supposedly issued to a party actually belongs to that party.

Common practice is to secure public keys with digital certificates that include the public key and certify the authenticity and integrity of the key. Such certificates usually contain, in addition to the public key, information about the identity of the user of the key and, if appropriate, details, for example, about the validity period of the certificate. The certification is carried out by a digital signature of a legitimate, the certificate issuing central body, a so-called certification agency.

A disadvantage of the described method is that the certification of public keys is associated with an administrative and technical effort, which, in particular for the consumer, also generates high costs.

The object of the present invention is to propose a method for setting up a key infrastructure, which does not require a central institution issuing certificates.

This object is achieved by methods having the features of the independent claims. Advantageous embodiments and further developments are the subject of the dependent claims.

The invention is based, on the one hand, on the idea that cryptographic keys between individual users in a first phase of the construction of the key infrastructure directly, d. H. in personal contact, using portable terminals, such as a smartphone or the like, and using a short-range communication protocol, in particular NFC-based ("near field communication"), are exchanged. As a result, on the one hand, the necessary trustworthiness and, on the other hand, a necessary data communication channel secured against attacks can be provided. Various certificates issued by the participating terminals themselves may additionally secure and authenticate the transmitted keys, as described in detail below.

In a second phase then, following the second basic idea of the invention, keys and / or certificates exchanged in the first phase can be used to enable a key exchange also between those parties who are not in direct personal contact, even with an insecure one Data communication network, such as the Internet. For this purpose, as a trustworthy, mediating authority, a third party is directly or indirectly involved. This third party is distinguished by the fact that in an earlier step, preferably in the first phase, it has already exchanged cryptographic keys in a secure and trustworthy manner with both parties now involved. Details of a method according to the second phase will be described in more detail below.

Finally, in a third phase, when the exchange of the cryptographic keys is completed, trusted and secured data communication based on the exchanged keys and / or certificates may take place.

Basic advantages of the outlined procedure arise immediately. A central certification authority is dispensable. This also eliminates the effort and costs previously incurred in connection with an external, centralized key certification. Gestures of trust known from personal interaction, such as a handshake, can be translated directly into a technical process - the pooling of portable terminals for the secure exchange of data over a short-range communication protocol. This allows cryptographic keys to be exchanged in a simple, cost-effective, trusted and secure manner.

In the following, the individual methods are described in detail.

A first method according to the invention for establishing a key infrastructure comprises the following steps: Initially, a communication channel between a first portable terminal and a second portable terminal is established by spatial proximity of the terminals to one another such that contactless data communication between the terminals via a predetermined short-range communication protocol is possible.

Preferably, an NFC-based protocol is used. Other, comparable protocols are also applicable, for example RFID protocols, as they are known in the field of contactless smart cards. It is important in the present context only that a communication channel can not accidentally and unintentionally between spatially to some extent adjacent devices may arise, but that an active and targeted merging of the devices concerned is required. It may be necessary to fall below a predetermined maximum distance. It is also possible that the devices must also be in a given spatial arrangement to each other. This arrangement may depend, for example, on the location of corresponding antenna devices, for example coils, in the devices.

In a second step, a first cryptographic key is transmitted from the first terminal to the second terminal via the data communication channel constructed as described above and via the predetermined short-range communication protocol.

Finally, a user confirmation is received. In particular, the user of the second terminal confirms the conscious reception of the first cryptographic key and / or the user of the first terminal the conscious reception of a key of the second terminal. In this way it can be ensured that a key transmission can not take place unnoticed and / or unintentionally. Further steps, such as generating a trust information for a received key, therefore preferably take place only after receipt of the acknowledgment.

Finally, confidence information is stored so that it can be used in a third phase which is independent of the first phase. The third phase is a subsequent communication to be secured by the first cryptographic key between the first terminal and the second terminal.

In the manner described, a cryptographic key can thus be transmitted in a trustworthy and secure manner from a first terminal to a second terminal. It is understood that the steps of transmitting a key and confirming the receipt of the key may additionally be done in an analogous manner when roles of the first and second terminals are interchanged. In this case, corresponding steps, depending on the protocol specifically used, can be carried out simultaneously to steps of the method of key transmission in the opposite direction, before or after. In this way, an exchange of cryptographic keys between two in direct, personal contact parties can be done in a secure and trustworthy way. The third phase of the communication to be secured can advantageously take place at any later time and / or use any data communication. The phases are thus independent of each other in time. The phases are independent of communication technology. The method allows, in particular, a later communication of the terminals remote from each other again.

As trust information, a signature of the recipient for the received key is preferably stored. The second terminal signs the received first key and thus generates a trust information. The first terminal signs a second key received from the second terminal and thus also generates trust information. Preferably, the first terminal stores the trust information for the first key. Similarly, the second terminal stores the trust information for the second key. It is conceivable, but in some cases disadvantageous, that the respective terminal stores the trust information generated by it or stores the received key in such a way that it represents trust information, for example in a memory area for keys received in the near range.

The trust information is checked in the third phase before the first key is used to secure the communication. Thus, the first key is only used if the check is positive, ie if a corresponding trust information has been provided and / or has been cryptographically verified. The use of the key can take many forms. For example, the key may be used before or during actual data communication. It can be used once, repeating or running. It can be used for different purposes, such as encryption, signature, authentication and / or key derivation.

The user confirmation may be for a received key. The user of the first / second terminal thus confirms the reception of the second / first key from the second / first terminal. The user confirmation can also be made for in the vicinity of receiving key. For example, the user starts a short-range application for the first phase on his terminal and thus confirms the keys now to be received. As already mentioned, should further steps of the first phase, such as storing trust information, generating trust information, and / or storing received trust information, occur only when the user acknowledgment has been received in the terminal. A user confirmation may also be in the form of an input of a rating for the key by the user. The user indicates his trust in the key with the rating. The rating is preferably stored as part of the trust information for the key. The keys transmitted between the terminals arranged close to one another can be treated as trusted keys by the user confirmation for the later communication of the third phase.

As mentioned, the method is particularly suitable for setting up a PK key infrastructure. Therefore, as the cryptographic key, one public key is preferably transmitted in the manner described above. This is part of an asymmetric key pair which additionally comprises a secret key assigned to the respective public key. In this case, the public key is generally used for encrypting data and verifying data signed by means of the secret key, whereas the secret key serves only the tasks reserved for the respective owner of the key, namely the decryption of data encrypted by means of the public key and the signing of data.

The best-known PK key infrastructure is mathematically based on the RSA method. However, other mathematical methods, for example based on the Diffie-Hellman key exchange method, can also be used.

The integrity and authenticity of the public key can be underlined by the fact that the public key is signed by means of the associated secret key. In this way, a so-called self-signing certificate is formed. A recipient of this certificate can verify this by means of the public key, which is part of the certificate, and in this way determine whether the signature has actually been formed by means of the secret key assigned to the public key.

The step of signing may be for the first public key in the first terminal and for the second public key in the second terminal. If such a self-signature certificate is formed for one or both of the public keys, then in the step of transmitting not only the respective public key but the public key is transmitted as part of the self-signed certificate formed therefor. This certificate can then, as described, be verified at the respective recipient in a further process step. In the described method, such a step of verifying may occur, for example, before confirming the receipt of the key. In this case, a successful verification can be made a condition for a confirmation.

As an additional measure to establish a trusted key infrastructure, a recipient of a public key or a self-signed certificate including the public key may himself sign this public key or the self-signature certificate by means of his secret key. In the method described above, therefore, the second terminal would, for example, sign the first public key received by the first terminal by means of the second secret key associated with the second terminal together with the second public key.

This creates a so-called third-party signing certificate. The term "foreign" in "foreign signature certificate" as opposed to "self" in "self-signature certificate" is intended to indicate conceptually that the secret key used for signing is just not the secret key associated with the signed public key. While there may be only one self-signature certificate for a public key, a variety of different foreign signature certificates pertaining to a single public key may be formed, as shown below, by signing the one public key with different secret keys, respectively. Each terminal may generate foreign signature certificates and self-signature certificates. To eliminate any doubt: the present third party signature certificates and / or self-signed certificates are not certificates of a central authority ("central certificates"). A third party signing certificate is the preferred embodiment of the stored trust information.

Typically, a third party signing certificate formed via a public key is returned to the party from which the public key was received. Ie. the generated foreign signing certificate does not remain with the signer itself, but is returned to the owner of the public key. However, the signer himself may alternatively or additionally a copy of the received public key or the received, the public key comprehensive self-signature certificate and optionally also a copy of the generated foreign signature certificate on his terminal to save. Which keys and certificates are stored at the individual instances essentially depends on which procedure is provided for a subsequent data transfer, ie in the third phase, in which the exchange of the cryptographic keys has already taken place. Specific preferred embodiments for accommodating such later data communication are described in detail below.

Technical benefits and use of a third party signing certificate generated in the manner described are manifold. In principle, such a certificate serves, for example, to increase the trustworthiness of a public key or self-signature certificate which is received again at a later time. The trustworthiness of a received public key will certainly be considered very high if it has been signed by means of a secret key assigned to the recipient of the key, i. H. the recipient himself has previously confirmed the trustworthiness of the public key by his own signature. On the other hand, in the already mentioned second phase, such a third party signature certificate can support a transmission of a public key via an intermediate instance in a trustworthy and cryptographically secured manner, as described in detail below.

As mentioned, public key certificates include at least the public key itself. In addition, other data, such as the identity of the owner of the key, the period of validity of the certificate, and the like may be part of the certificate.

According to a preferred embodiment of the presently proposed method, in a further method step, a technical evaluation relating to the public key can enter into a third party signature certificate generated by means of a secret key and certifying the public key. Ie. the certificate may include, in addition to the above-mentioned shares, an additional valuation of the public key. This assessment may involve various technical aspects of the public key, such as its cryptographic security.

Preferably, the evaluation at least partially also relates to the trustworthiness of the public key. The trustworthiness of the public key is to be understood in the present context as a technical parameter of the key. This is because the trustworthiness of the public key itself depends on technical parameters, such as the addressed cryptographic security of the key, the transmission path on which the key was received by the receiving device, the transmission method by which the receiving device has received the public key, the Number of intermediate stations between the receiving device and the public key generator device and the like. Also, the trustworthiness of the party or parties from whom the receiving device has received the public key may be included in the evaluation. It is understood that different receiver devices can each assess the trustworthiness of the same public key differently, since each of the above-mentioned parameters for different receiver devices can each be different or deviatingly evaluated.

The evaluation of the certified public key, which is included in a third-party signing certificate, primarily serves as a system-strengthening and system-securing security estimate of the established key infrastructure. Owners of low-valued trusted public keys may, for example, be further audited prior to secure contact, for example, to perform a security-related data transaction to build up lack of trust. Further, in passing a public key between two parties through one or more third parties in the second phase of the method according to the invention, if available, such high-valued parties may be preferred over others of less high rating as mediators. In this way, the rating of the transmitted public key at the receiving device increases and the key is more widely accepted and used in the overall system.

As already mentioned several times, several phases can be distinguished with reference to the present methods. In a first phase, cryptographic keys, preferably public keys, are exchanged directly and in personal contact between individual parties via a short-range communication protocol. In a second phase, described in detail below, cryptographic keys are exchanged between not necessarily in personal contact parties via any data communication channel. In this case, third parties, with which keys have already been exchanged according to the invention in a secure and trustworthy manner at an earlier point in time, preferably in the first phase, act as intermediaries securing and mediating such key transmission. In a third phase, finally, in which the key exchange is completed is, can be made on any data communication channel data communication based on the exchanged in the first two phases between the parties key. This may preferably take place in the manner described below by way of example.

To record a secure and trusted data communication between a first terminal and a second terminal via any data communication channel, the following steps can be performed: The first terminal transmits the third public key certifying third party signing certificate, which previously by signature using the second secret key of the second terminal has been generated to the second terminal. The second terminal verifies the foreign signature certificate and thus checks the trustworthiness of the first public key of the first terminal. In the same way, the procedure is reversed, ie. H. the second terminal transmits the second public key certifying foreign signature certificate, which has been previously generated by signing by means of the first secret key of the first terminal, to the first terminal. The first terminal verifies the received certificate by means of its own public key, i. H. the second public key.

In this way, both parties can assure themselves of the trustworthiness of the public key of the chosen communication partner. The subsequent data communication can take place in a known manner, for example, in each case encrypted with the public key of the opposite side and / or signed with the respective own secret key.

In cases in which no foreign signature certificates have been formed on at least one page, the respective public keys of the selected communication partner, possibly as part of a self-signature certificate, still exist, so that in these cases, in the third phase, a cryptographically secured data communication can take place , However, a verification of the public key of the other party based on a previously generated third party signing certificate can not then take place. In these cases, each terminal has to store and manage all public keys and self-signed certificates comprising such keys themselves.

On the other hand, in cases where received public keys have been signed by means of their own secret key and the third party signing certificate generated thereby has been returned to the owner of the public key, he is responsible for the storage and management of the foreign signing certificate. The amount of data to be managed in the own terminal can thereby be reduced.

In the following, another method according to the invention for establishing a key infrastructure is described, which defines the procedure in the second phase, which has been mentioned several times before. This procedure includes the following steps:
A third party signing certificate certifying a first public key is transmitted from a first terminal to a third terminal. In this case, the foreign signature certificate has been formed by signing the first public key with a second secret key of a second terminal. This can be done, for example, when the first terminal and the second terminal have exchanged their respective public keys according to the above-described first inventive method NFC-based.

At this point it is already apparent that in this case a transfer of a public key between the first and the third terminal should take place, the second terminal acts as an intermediary. The mediator position can be taken directly by the second terminal active in the process, for example, as a bridge in a data communication connection between the first and the third terminal. As an alternative, it is also possible for the second terminal to participate only indirectly in the method, in particular in that third party signature certificates previously generated by the second terminal are now used to secure the current key handover method.

In a second step, a third-party signing certificate certifying a second public key is transmitted from the second terminal to the third terminal. In this case, the foreign signature certificate has been formed by signing the second public key with a third secret key of the third terminal. A direct involvement of the second terminal may alternatively be omitted if the third terminal has stored a copy of the same after the generation of the corresponding foreign signature certificate and this now directly, instead of the second terminal, transmits to the first terminal.

Subsequently, the third terminal verifies the received second signing certificate certifying the second public key by means of its own public key, ie by means of a third public key assigned to the third secret key. Upon successful verification, the third terminal can now the second public key, which as the mediator serving as the second terminal, viewing it as trustworthy and based on the subsequent procedure on it.

There follows a step of verifying the third public key certificate certifying the first public key by the third terminal verified by the second public key verified in the previous step. If this verification is also successful, the third terminal can regard the first public key assigned to the first terminal as trustworthy and store it for later data communication

At this point, the method could end because the public key of the first terminal has been secured and trusted transmitted to the third terminal. As already described in connection with the first method according to the invention, it can also be provided here that the third terminal does not store the public key of the first terminal or a self-signature certificate comprising the same. Alternatively, the third terminal can form a foreign signature certificate for this public key and send this certificate back to the first terminal, possibly via the second terminal. Such a foreign signature certificate could then be used in a third phase, as described above, in the manner described above. H. after the public keys are exchanged, used to receive data communication between the first and third terminals.

Consequently, in a preferred embodiment, the second method according to the invention, the second phase, may comprise the following further steps: the third terminal signs the first public key of the first terminal verified in the preceding step with its own secret, the third secret key for forming a further, the first public key certifying third party signing certificate and transmits this, the first public key certifying third party signing certificate to the first terminal. Here is an example of how to a public key, the public key of the first terminal, various third party signature certificates can be generated and used.

It is understood that a transmission of a third public key, i. H. a public key of the third terminal to the first terminal can be absolutely analogous mediated by the second terminal when the roles of the first and third terminal are exchanged.

It is further obvious that the second method according to the invention can firstly be regarded as an independent method. It can be left open in what way the keys and certificates underlying the procedure have found their respective recipients.

It is just as obvious that the steps of the second method according to the invention can be regarded as further method steps of the first method according to the invention, thus the second method according to the invention can be regarded as a method dependent on the method according to claim 1. This applies, for example, in the event that at least one of the two introductory steps of the transmission of the third party signature certificate is carried out in the first phase. In other words, first, in a first phase, public keys and third-party signing certificates formed above are exchanged according to the first method of the invention. In particular, the transmission of the public key, if appropriate also the transfer of the foreign signature certificates, takes place via the described short-range communication protocol. Such an exchange may, for example, take place between the first and the second terminal. In a second phase, then, as described, the first terminal transmits its public key to the third terminal using the third-party certificate generated by the second terminal as a continuation of a multi-party method of establishing a key infrastructure.

It is understood that also in connection with the second method according to the invention, evaluations described above with reference to the first method according to the invention, the respective public keys can be introduced into the respective third party signature certificates. This is usually done in the penultimate step, d. H. when generating the respective further, the public key certifying third party signing certificate. In other words, z. B. the third terminal to evaluate the public key of the first terminal and bring such a rating in the final transmitted to the first terminal, further, the public key of the first terminal certifying foreign signature certificate.

In this case, the third terminal, by way of example for a party involved in the method, can make the evaluation concerning the first public key of the first terminal depending on a plurality of input variables, in particular depending on a plurality of already existing evaluations.

On the one hand, a separate rating, ie an evaluation by the third terminal, of the second public key of the mediating second terminal and a rating made by the second terminal regarding the first public key of the first terminal to be taken into the assessment of the first public key to be taken. The aforementioned evaluation made by the second terminal can be taken, for example, from the third public signature certificate certifying the first public key, which has been generated in a preceding method step, the first phase. In other words, an evaluation of public keys in the method according to the invention, in particular with regard to the trustworthiness of a key, can influence the evaluation of another key.

A terminal may be configured to carry out the steps of the first phase method. The terminal is correspondingly at least one short-range interface (NFC, RFID, o. Ä.), An interface for receiving a user confirmation (keyboard, touch screen ...), a non-volatile memory for the trust information and an interface (mobile, Internet, WLAN , ...) for further communication of the third phase. Terminals in the present context are preferably portable terminals. In one embodiment, a portable terminal may be arranged in the vicinity of a stationarily arranged terminal. As terminals are exemplary in particular mobile devices, portable computers, such as tablet PCs or notebooks to call. The range of short-range communication is less than 30 cm, in particular less than 10 cm.

The terminal may also be configured to carry out the steps of the second phase. In any case, the terminals support the third phase, thus comprising means for securing the third phase communication with a key. A present system includes at least two such terminals for performing the steps of the first phase method.

The invention will now be described by way of example with reference to the accompanying drawings. Show in it

1 Steps of a preferred embodiment of a first method according to the invention;

2 Steps of a preferred embodiment of a second method according to the invention and

3 Steps of a preferred embodiment of a method for receiving a secure data communication.

To illustrate the following procedures, the parties involved are referred to as "Alice", "Bob" and "Carol" as commonly used in this technical field. For example, Alice corresponds to the user of the first terminal in the above sense and the owner of the key associated with the first terminal, namely the first public key and the first secret key. Bob and Carol analogously correspond, for example, the users of the second and third terminal. The number of parties involved in the established key architecture is variable. Throughout the process, there is a possibility that new parties may join the architecture by passing on their public key to already participating parties. In the manner described below, parties can also delete already established connections to other parties.

It is understood that the individual method steps described in detail below are not carried out by persons but by technical devices assigned to persons or institutions or by devices and / or software devices installed on these devices, even if this is not always explicitly stated. For the sake of clarity and readability, formulations of the type "Alice transmits [...] to Bob" are used in the following, which "transfers the device assigned to Alice by means of the transfer application installed thereon to the device assigned to the Bob Receiving application "etc.

Preferred devices are with respect to the in 1 described method portable devices, especially mobile devices, smart phones, tablets, notebooks, etc. These are set up to support a given short-range communication protocol, in particular a compatible with NFC standards protocol. For the methods, which with reference to the 2 and 3 Any data processing devices will suffice because the data communication is no longer necessarily handled over a short-range communication protocol but over any network, such as the Internet.

Each of the terminals used comprises a software application set up to carry out the respectively required steps. In particular, the known cryptographic steps of the generator of an asymmetric key pair (cf. 1 , Step S1), the signing (see. 1 , Steps S2 or S8) and verifying a signature (cf. 2 , Step T5) as well as the known steps of encrypting and decrypting.

The according to the method according to 1 and 2 The key infrastructure that has been set up is a so-called PK key infrastructure, in which each party is assigned a key pair comprising a public key PuK (public key) and a private key PrK. By means of the public keys, which are forwarded to other communication partners in the manner described below, data can be encrypted and signatures which have been generated by means of the respectively associated secret key can be verified. The secret keys, which are only known to the respective owners and secured there and stored inaccessible to others, are used to decrypt data encrypted by means of the respectively associated public key and to sign data.

Forming a certificate "Z" by signing a date "D" by means of a secret key "PrK" will be hereinafter abbreviated as Z: = S [PrK] (D). The verification of this certificate by means of the associated public key PuK is indicated by V [PuK] (Z).

An owner of a key appears as a subscript refers trailing abbreviation of the name of the owner, that is to say the secret key of Alice is with PrK _A, the Bob with PrK _B, etc. A certificate Z via a key which is generated by signing the key is, is referred to as SZ, if it is a self-signed certificate, that is, if a public key has been signed with the associated secret key, so z. Eg in the case of Alice SZ _A = S [PrK _A ] (PuK _A ).

A certificate which arises when a public key (or a self-signing certificate which includes this public key) is signed by means of a foreign secret key, ie, not associated with the public key, is called a foreign signature certificate FZ. In this case, the owner of the secret key, which is used for signing, superscripted and presented as an abbreviation of the name. Thus, for example, if the self-signing certificate is signed by Alice, SZ _A , using the secret key of Bob, PrK _B , then this will be abbreviated hereafter to ^B FZ _A : = S [PrK _B ] (SZ _A ). This notation is unique and intuitive.

Regarding 1 The steps of a first method for establishing a key infrastructure will now be described, in particular, the steps for the secure and trustworthy exchange of public keys.

In step S1, Alice and Bob each generate a public key PuK _A , PuK _B and an associated secret key PrK _A , PrK _B.

In the optional step S2, in each case self-signature certificates SZ _A , SZ _{B are formed} via the previously generated public keys PuK _A , PuK _B. Alice, for example, signs her public key with her secret key: SZ _A : = S [PrK _A ] (PuK _A ), Bob proceeds in the same way.

In the third step S3, Alice and Bob approach their respective portable terminals 10 . 20 spatially such to each other that a contactless data communication between the terminals via the predetermined short-range communication protocol, preferably NFC, is possible. Optionally, a temporal synchronization of the two devices can take place. In this way, the certificates generated as described below can be provided with a respective consistent time stamp.

In steps S4 and S5, Alice and Bob now respectively transmit the self-signed certificates SZ _A , SZ _B generated in step S2 (or only the public keys PuK _A , PuK _B , if step S2 has not been performed, for reasons of readability always described only the first variant, although the second may be present in the same way) to the other communication partner. In this case, this data transmission proceeds via the contactless data communication channel produced in step S3 and via the predetermined short-range communication protocol.

The structure of the data communication connection between the two terminals 10 and 20 after completion of the approach and then preferably automatically following transmission of the self-signature certificates is preferably controlled by an established Verbindungsherstellungs- and key transfer application that has been installed on the respective terminals and started at the beginning of the process. Without a previous activation of this application no key exchange can take place. In this way, even the attempt of unrecognized or unintentionally carried key exchange can be prevented.

In the optional step S6, the self-signature certificate SZ _A , SZ _{B received} by the far site is verified by means of the public key PuK _A , PuK _B present in the certificate. Successful verification may be required as a prerequisite to perform the subsequent step S7. Step S6 is omitted in each case with step S2, but is also optional when performing step S2.

In step S7, Alice and Bob confirm the receipt of the self-signing certificate SZ _A , SZ _B to the other party. In the case of missing confirmation, the procedure, at least for the party, which failed the confirmation of reception, canceled at this point.

After confirmation, the received self-signed certificates SZ _A , SZ _B are stored at least temporarily in the respective terminals. Already at this time, a cryptographically secured and trusted data communication could take place, since both parties are in possession of the public key of the respective opposite party.

A preferred method for establishing a secure data communication connection, typically at a later time and not via the data communication connection established in step S3, will be described below with reference to FIG 3 described. In order, inter alia, to be able to carry out such a method, the steps S8 to S10 described below are carried out.

In step S8, Alice and Bob each create a foreign signature certificate ^A FZ _B , ^B FZ _A by signing the respective received self-signature certificate SZ _A , SZ _B by means of the private secret key PrK _A , PrK _B. For example, in the case of Alice as ^A FZ _B : = S [PrK _A ] (SZ _B ).

The foreign signature certificates ^A FZ _B , ^B FZ _A generated in this way are respectively transmitted to the other communication partner in steps S9 and S10. In other words, Alice receives her own self-signing certificate, signed with Bob's secret key, and Bob receives his own self-signing certificate, signed with Alice's secret key.

The received foreign signature certificates ^A FZ _B , ^B FZ _A are non-volatile stored in step S11, so that they for later data communication (see 3 ) be available.

The transmission of these certificates can proceed via the data communication connection established in step S3. This is optional. For example, it is also possible for the steps S8 and S9 or S10 to be at a certain time interval from the step S7 and after the terminals have become 10 . 20 already removed from each other again. In this case, any other data communication channel may be used.

It is understood that a transfer of a public key can also be carried out only on one side, d. H. For example, Alice wants Bob to submit her public key so that she can send her encrypted messages. Then, steps S2, S4 and S11 only need to be performed by Alice and steps S6, S7, S8 and S10 only by Bob, steps S1 and S3 are still performed on both sides, step S9 is omitted.

In 2 For example, steps of a method for securely and trustably exchanging public keys between two parties, for example between Alice and Carol, via a trusted mediating party, in the example shown Bob. It is assumed that each of the two parties, Alice and Carol, has already exchanged public keys with the mediating party, Bob, at an earlier date. This can for example also according to a method according to 2 , then with a corresponding other intermediary, or directly according to a method described above 1 be done. In other words, at the beginning of the process according to 2 Alice has a third-party signed certificate ^B FZ _A signed by Bob, Carol also has a third-party signature certificate ^B FZ _C signed by Bob, and Bob has signed foreign signature certificates ^A FZ _B , ^C FZ _B on the other side of Alice or Carol.

In a first step T1 Alice, possibly via Bob, transmits the foreign signature certificate ^B FZ _A to Carol. Similarly, in step T2, Bob sends the foreign signature certificate ^C FZ _B to Carol.

Similarly, in step T3, again, if necessary with the involvement of Bob, Carol transmits the foreign signature certificate ^B FZ _C to Alice. Similarly, in step T4, Bob sends the foreign signature certificate ^A FZ _B to Alice.

In step S5, Alice and Carol respectively first verify the third party signing certificate comprising Bob's public key, ^A FZ _B and ^C FZ _B, respectively. Alice, for example, calculates Bob's self-signature certificate SZ _B using her own public key from ^A FZ _B by means of SZ _B = V [PuK _A ] ( ^A FZ _B ). Bob acts analogously. In this way, Alice and Carol can assure themselves of the trustworthiness of public key PuK _{B of} the mediating party, Bob. This key PuK _B is then used in the following step T6 for verification of the second foreign signature certificate ^B FZ _C , ^B FZ _A respectively received in the starting phase of the method.

Alice, for example, verified in step T6, the foreign signature certificate ^B FZ _C virtue SZ _C = V [PuK _B] ^(B FZ _C) and can be obtained from the self-signature certificate SZ _C to extract the public key PuK _C Carol. In an analogous manner, Carol proceeds to finally obtain the public key PuK _A from Alice.

Analogous to the above with respect to the method according to 1 Executed there, following step S7, also applies in the present case to that At this time, a secure and trusting data communication between Alice and Carol could already take place, since both are now in possession of each other's public key. The steps T7 to T10 correspond exactly to the steps S8 to S11, serve the same purpose (generating and transmitting foreign signature certificates) and therefore will not be described again.

It should be noted that the method described above with reference to 2 is particularly suitable to exchange cryptographic keys over an existing network, such as a social network. In principle, there is the possibility that the network operator supports a transfer of keys over the network. Rather, it would be conceivable for him to assume the role of mediator described above. The operator can also participate in the evaluation of individual public keys. The rating could then be dependent on, for example, a frequency of use of the respective key, a distribution of a key, the reviews of the key by other parties, the cryptographic security of the key, etc. Participation of a central entity both in the key transfer and in the However, optional evaluation is dispensable for the procedures described in any case.

It should be noted in general that the attainable level of trust, ie the evaluation of a mediated third party certificate, always corresponds only to the minimum of the evaluation of the foreign certificates involved, thus for example: Rating ( ^A FZ _C) ) = min (Evaluation ( ^A FZ _B ); ^B FZ _C )).

Now to one according to a method according to 1 or 2 maintained trusted connection between, for example, Alice and Bob, each of them can keep each other's self-signature certificate. Secure data transmission then takes place on the basis of the public key contained therein. In this case, however, each party must store and manage all public keys or self-signature certificates ever received in order, if appropriate, to be able to establish data communication with a corresponding counterparty at a later date. In this case, for example, Alice would permanently store the certificate SZ _B received in step S5.

Alternatively (or additionally), however, each party may also retain and permanently store the own self-signed certificate signed by the other party, ie the third party signature certificate respectively received at the end of the method. According to this variant, Alice would keep and save the foreign signature certificate ^B FZ _A received in step S10. The self-signed certificate SZ _B previously received (in step S5) could be deleted. In addition, this variant allows the recording of a data communication connection which takes place later in a particularly secure and trustworthy manner, as described below with reference to FIG 3 is described.

It is understood that certificates, in particular the exchanged foreign signature certificates, can be limited in time, so that a basis of trust based thereon may have to be renewed, if desired. In this case, a rating described in detail in the first part of the application, optionally included in the certificate, can be adapted regarding the public key contained in the certificate. To cancel a connection made to the certificate by another party before the certificate expires, the foreign signing certificate in question must be deleted.

Regarding 3 Finally, as mentioned, a preferred embodiment of a method for receiving a secure and trusted data communication connection on the basis of before according to a method according to 1 or 2 exchanged foreign signature certificates ^B FZ _A , ^A FZ _B. 3 So describes the third phase of contact, which is particularly independent of time (at any later time) from the first and second phase.

A data communication 40 becomes in step U0 between the terminals 10 . 20 constructed, which are arranged away from each other. The data communication 40 Usually takes place via a network, such as a mobile network, wireless network or the Internet.

In step U1, Alice transfers (for example in step S10, cf. 1 , received) Third party signing certificate ^B FZ _A to Bob. This proceeds in step U2 analogous to that (for example in step S9, cf. 1 , received) foreign signature certificate ^A FZ _B and sends this to Alice.

In step U3 in each case a verification of the previously transmitted and received from the other side certificates, ie Alice, for example, verifies the foreign signature certificate ^A FZ _B by SZ _B = V [PuK _A ] ( ^A FZ _B ) and obtains in this way certainty about the trustworthiness of the public key PuK _B from Bob. The latter proceeds in a similar way to check the trustworthiness of Alice's public key PuK _A. The public keys thus obtained and verified can now be used in the further course of the data communication in one of the various known ways of securing, step U4. For example, in step U4, the key PuK _{A could be used} for an authentication, wherein as part of the authentication U4 optionally a session key for encryption of the data to be transmitted could be negotiated. The derived key and / or the key PuK _A can optionally serve in further steps of the data transmission U5 for authentication, encryption and / or signing.

Claims (21)

Method with a first phase (S1-S11) for establishing a key infrastructure, wherein the first phase (S1-S11) comprises the following steps: - establishing (S3) a communication between a first terminal ( 10 ) and a second terminal ( 20 ), whereby the terminals ( 10 . 20 ) are spatially arranged in such a way that a contactless data communication ( 30 ) between the terminals ( 10 . 20 ) according to a predetermined short-range communication protocol; Transferring (S4) a first cryptographic key from the first terminal ( 10 ) to the second terminal ( 20 ); - receiving (S7) a user confirmation; - Saving (S11) a confidence information such that in a third phase (U0-U5), which is independent of the first phase (S1-S11), usable, wherein the third phase (U0-U5) one by means of the first cryptographic key ( 40 ) between the first terminal ( 10 ) and the second terminal ( 20 ). Method according to Claim 1, characterized in that the trust information is stored in a second terminal ( 20 ) generated signature for the first cryptographic key. Method according to claim 1 or 2, characterized in that between the terminals ( 10 . 20 ) keys are treated as trusted keys by the user acknowledgment for later communication of the third phase. Method according to one of Claims 1 to 3, characterized in that the third phase (U0-U5) comprises: - checking (U1-U3) the confidence information; and - using (U4, U5) the first cryptographic key (SZ _A ) as a trusted key to secure the communication ( 40 ) between the first terminal ( 10 ) and the second terminal ( 20 ). Method according to one of claims 1 to 4, characterized in that the third phase (U0-U5) comprises: - recording (U0) of the data communication ( 40 ) between the first terminal ( 10 ) and the second terminal ( 20 ). Method according to one of claims 1 to 5, characterized by the further step of the first phase: - receiving (S5) a second cryptographic key (SZ _B ) from the second terminal ( 20 ) in the first terminal ( 10 ), wherein the user confirmation relates to the second cryptographic key. Method according to one of Claims 1 to 6, characterized by the further step of receiving (S10) the trust information from the second terminal and / or transmitting (S9) one in the first terminal ( 10 ) generated confidence information for the second cryptographic key (SZ _B ) to the second terminal ( 20 ). Method according to one of claims 1 to 7, characterized in that the first cryptographic key (SZ _A ) is a public key (PuK _A ) of an asymmetric key pair, which in addition to the public key (PuK _A ) associated secret key (PrK _A ) includes. A method according to claim 8, characterized by the further step of signing (S2) the public key (PuK _A ) with the secret key (PrK _A ) to form a public key (PuK _A ) certifying self-signing certificate (SZ _A ) before the step of Transmitting (S4) the public key (SZ _A ; PuK _A ). Method according to one of Claims 8 to 9, characterized by the further step of signing (S8) the received second public key (SZ _B ) in the first terminal ( 10 ) with the first secret key (PrK _A ) for forming a second public key (PuK _B ) certifying foreign signature certificate ( ^A FZ _B ) and / or the receiving in the second terminal ( 20 ) and the first public key (PuK _A ) certifying third party signing certificate ( ^B FZ _A ). Method according to one of claims 1 to 10, characterized in that the trust information comprises a score concerning the first key. A method according to any one of claims 4 to 11, characterized in that the step of checking (U1-U3) comprises, in the third phase of: - transmitting (U1) of the first public key (PuK _A) certifying foreign signature certificate ^(B FZ _A) from first terminal ( 10 ) to the second terminal ( 20 ) and Receiving (U2) of the second public key (PuK _B ) certifying foreign signature certificate ( ^A FZ _B ) from the second terminal ( 20 ) in the first terminal ( 20 ) and - verifying (U3) of the second public key (PuK _B ) certifying foreign signature certificate ( ^A FZ _B ) in the first terminal ( 10 ) by means of the first public key (PuK _A ). A method for establishing a key infrastructure, comprising the steps of: - receiving (T1) of a first public key (PuK _A) certifying foreign signature certificate ^(B FZ _A) (from a first terminal 10 ) in a third terminal, wherein the foreign signature certificate ( ^B FZ _A ) by signing the first public key (PuK _A ) with a second secret key (PrK _B ) of a second terminal ( 10 ) has been formed; Receiving (T2) a second public key (PuK _B ) certifying foreign signature certificate ( ^C FZ _B ) from a second terminal ( 20 ) in the third terminal, wherein the foreign signature certificate ( ^C FZ _B ) has been formed by signing the second public key (PuK _B ) with a third secret key (PrK _C ) of the third terminal; - Verifying (T5) of the second public key (PuK _B ) certifying third party signing certificate ( ^C FZ _B ) by means of the third secret key (PrK _C ) associated third public key (PuK _C ) by the third terminal; - Verifying (T6) of the first public key (PuK _A ) certifying foreign signature certificate ( ^B FZ _A ) by means of the verified in the preceding step, the second public key (PuK _B ) by the third terminal. Method according to claim 13, characterized by the further steps of: - signing (T7) of the first public key (PuK _A ) verified in the preceding step with the third secret key (PrK _C ) for forming a further third party signing certificate certifying the first public key ( ^C FZ _A ) by the third terminal; and - transmitting (T9) of the other, the first public key (PuK _A) certifying foreign signature certificate ^(C FZ _A) by the third terminal to the first terminal ( 10 ). Method according to claim 13 or 14, characterized by the further steps: - transfer (T3) of a third public key (PuK _C ) certifying foreign signature certificate ( ^B FZ _C ) from a third terminal to a first terminal ( 10 ), wherein the foreign signature certificate ( ^B FZ _C ) by signing the third public key (PuK _C ) with a second secret key (PrK _B ) of a second terminal ( 20 ) has been formed; Transferring (T4) of a second public key (PuK _B ) certifying foreign signature certificate ( ^A FZ _B ) from a second terminal ( 20 ) to the first terminal ( 10 ), wherein the foreign signature certificate ( ^A FZ _B ) by signing the second public key (PuK _B ) with a first secret key (PrK _A ) of the first terminal ( 10 ) has been formed; Verifying (T5) of the second public key (PuK _B ) certifying foreign signature certificate ( ^A FZ _B ) by means of a first secret key (PrK _A ) associated with the first public key (PuK _A ) by the first terminal ( 10 ); - verifying (T6) of the third public key (PuK _C) certifying foreign signature certificate ^(B FZ _C) by means of the verified in the preceding step second public key (PuK _B) by the first terminal ( 10 ). Method according to claim 15, characterized by the further steps: - signing (T7) of the third public key (PuK _C ) verified in the preceding step with the first secret key (PrK _A ) for forming a further, the third public key (PuK _C ) certifying third party signing certificate ( ^A FZ _C ) by the first terminal ( 10 ); and - transmitting (T8) of the other, the third public key (PuK _C) certifying foreign signature certificate ^(A FZ _C) by the first terminal ( 10 ) to the third terminal. A method according to any one of claims 13 to 16, characterized by the step of introducing a score regarding the first public key (PuK _A ) into the trust information. Method according to Claim 17, characterized in that the third terminal evaluates the first public key (PuK _A ) depending on its own second public key rating (PuK _B ) and / or on the second terminal ( 20 ) concerning the first public key (PuK _A ). Method according to one of claims 1 to 12, characterized by a second phase with the steps according to one of claims 13 to 18. Terminal set up to carry out a method according to one of Claims 1 to 19. A system comprising a plurality of terminals, wherein two terminals perform a method according to any one of claims 1 to 19.

Images