WO2012031821A1 - Verfahren zur zertifikats-basierten authentisierung - Google Patents

Verfahren zur zertifikats-basierten authentisierung Download PDF

Info

Publication number
WO2012031821A1
WO2012031821A1 PCT/EP2011/062644 EP2011062644W WO2012031821A1 WO 2012031821 A1 WO2012031821 A1 WO 2012031821A1 EP 2011062644 W EP2011062644 W EP 2011062644W WO 2012031821 A1 WO2012031821 A1 WO 2012031821A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
subscriber
participant
authentication
requirements
Prior art date
Application number
PCT/EP2011/062644
Other languages
English (en)
French (fr)
Inventor
Rainer Falk
Steffen Fries
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to CN201180043126.1A priority Critical patent/CN103109508B/zh
Priority to EP11741165.2A priority patent/EP2594047A1/de
Priority to US13/820,811 priority patent/US9432198B2/en
Publication of WO2012031821A1 publication Critical patent/WO2012031821A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • the invention relates to a method for certificate-based authentication, in which a first subscriber authenticates to a second subscriber with the aid of a digital certificate assigned to the first subscriber.
  • Digital certificates are known per se from the prior art. They contain the identity of an entity in the form of a person or institution or machine for which the certificate is issued. Here and below the term of the participant is used, to which a certificate can be assigned.
  • a subscriber can be a computer or a machine for which the certificate is issued.
  • a participant can refer to a computer or a machine that manages the certificate of a person or institution. The responsibility for certificate management assigns the certificate to the computer or machine.
  • a certificate contains a public key for the corresponding entity, and a digital signature in the certificate of the owner of the certificate can be confirmed ⁇ to.
  • the digital signature is calculated by a certifi ⁇ katsausgabestelle.
  • the signature can be verified as valid via a root certificate of this issuing authority or a certificate chain to the root certificate. Additional information in a digital certificate attributes so-called in the mold. Are encoded by which Be ⁇ authorizations for the user of the certificate or the certificate usage restrictions are set. Certificates generally have a limited validity ⁇ duration, which is specified as information in the certificate. After the end of the validity period, the certificate automatically becomes invalid.
  • Certificates ensure that a certificate that is to be available beyond its period of validity is replaced in good time by a corresponding certificate with a new validity period. This is associated with a high administrative effort in practice. Especially when issuing certificates for automation devices, which are used over a long period of time and are not subject to stringent computer administration, this is difficult to implement. Although it is possible to issue certificates with a very long or unlimited validity period, this increases the risk of misuse.
  • SAML Security Assertion Mark ⁇ up Language
  • a possible claim is for example an authentication by means of a certificate, by password and the like.
  • access is granted or denied.
  • the object of the invention is to provide a certificate-based authentication in which the validity of the certificate used for this purpose can be controlled simply and flexibly.
  • an authentication is carried out, in which a first subscriber authenticates himself to a second subscriber with the aid of a digital certificate assigned to the first subscriber.
  • the certificate specifies one or more requirements, wherein the fulfillment of a request by a third party is assured by the third
  • Participant issues the request.
  • the term of specification of requirements in the certificate is to be understood broadly. The specified requirements can be stored directly in the certificate or specified using an identifier or name. Likewise, the specification of one or more requests may be via a reference that references the requests, such as a URI or a URL.
  • the term of issuing a request is also to be understood in the sense of the invention. For example, a request may be considered as issued if it is deposited on the corresponding third party or can be retrieved by that party.
  • a validity condition is checked by the second participant and the certificate of the first participant is then classified as valid by the second participant if the validity condition is met.
  • the validity condition depends on the issuance and / or the missing publication of one or more of the requirements specified in the certificate by the third participant. If the respective specified validity condition not met, the certificate is canceled as invalid erach ⁇ tet and a corresponding authentication. It can in particular be assessed as the validity condition by the second user, whether the specified requirements are due to ⁇ a publication of the requirements satisfied by the third party at the time of verification of the certificate of the first subscriber.
  • the requirements may represent the SAML assertions mentioned at the outset or corresponding claims from the Claims-based Authorization Model.
  • the first subscriber asks the third user for the information as to whether one or more of the requirements specified in the certificate were issued by the third user.
  • the first subscriber is doing the beautufactor ⁇ th information the second party prepared, for example by transmitting the issued requests to the second party. Then the second part ⁇ participants reviewed based on this information, the Gültmaschinesbedin- supply.
  • the second participant it is also possible for the second participant to request the information directly from the third participant as to whether one or more of the requirements specified in the certificate are issued by the third participant. then check the validity condition based on the requested information.
  • the first one In order to avoid misuse by unauthorized querying requests from the third party, in a particularly preferred embodiment, the first one must be
  • a requirement in terms can be specified on the validity of the certificate, ie the temporal Valid ⁇ ness of the certificate is linked to the publication of a entspre ⁇ sponding requirement without taking into account other criteria.
  • a request may relate to the communication environment in which the first subscriber is operated. This communication environment can be determined for example by special properties or a corresponding address of the communication network. Also, a request may relate to one or more characteristics of the first and / or second and / or third party. For example, it may be specified that only certain first, second or third participants may be used within the framework of certificate-based authentication. In particular, it can also be determined from which participant the issued certificates must originate.
  • a request may specify the reliability of Au ⁇ thentmaschine of the first subscriber with the second subscriber. Only if the credibility specified in the request is given, for example in the form of a trusted value, is the certificate considered valid. By this means it can be considered that the trust worthiness ⁇ an authentication with the times may change, as for example is known an attack on a particular subscriber.
  • the validity condition is a logical Verknüp ⁇ added chain comprising one or more AND and / or NAND and / or OR and / or XOR and / or NOR-links, wherein the link chain is preferably in the certificate is encoded. In this way, very well, for example, blocking requests can be processed, in the presence of a blocking request ⁇ tion, the certificate is considered invalid. The validity of the certificate can therefore be linked to the absence of a blocking request by means of a NAND link.
  • verification of the certificate also takes place in addition to the above validation of the certificate. This verification can be done in a conventional manner by checking the signature of the certificate.
  • the method according to the invention is built up a cryptographically secure communication between the first and second subscriber associated with a public key contained in the certificate of the first subscriber and the public areas this ⁇ chen key private key.
  • the corresponding requirements for checking the validity condition can also be transmitted. If it should appear that the validity condition is not fulfilled, the encrypted connection and thus the authentication is ab ⁇ broken off.
  • a renewed verification of the validity condition takes place repeatedly with an encrypted connection established, for example periodically every 5 minutes or every hour. If this is not the case, in a variant of the invention, the connection is terminated.
  • the processing performed by the inventive process au- can mation based on known protocols, such as SSL / TLS protocol and / or the IKE / IPsec protocol and / or the IKEv2 / IPsec protocol, in addition to which he ⁇ -making proper verification the validity condition is based on appropriate requirements.
  • the certificate used in the present invention may be based on a ⁇ be known per se certificate.
  • the certificate may represent an extended X .509 certificate which specifies zusharm ⁇ Lich to the known entries one or more requests.
  • the method according to the invention can also be used for mutual authentication between the first and second subscribers. That is, with the method, the first participant at the second participant and exchanging the roles of the first and second participants is analogous to the second participant in the first participant.
  • the inventive method can be used for any first or second or third participants in the form of computers or machines.
  • the part ⁇ participants is on components of an automation system is, for example, as like a corresponding control devices, sensors, actuators, and.
  • the invention further relates to a communication network with a first, second and third party, wherein in the operation of the communication network, a certificate-based authentication according to the above-described ⁇ method or one or more variants of the method described above is feasible.
  • FIG. 1 shows a schematic representation of a communications network in which an embodiment of the certificate-based authentication is carried out
  • Fig. 2 is a schematic representation of a medicinalenaus ⁇ exchanges between two nodes in a network cation communi-, guide shape which authenticate each other based on mer E of the procedure according to the invention Rens
  • Fig. 1 shows a schematic representation of a communication network N with a plurality of computers, wherein the participating in the certificate-based authentication described below computer with Rl, R2, and R3 are designated.
  • the computer Rl corresponds to a first participant in the sense of claim 1, the computer R2 a second participant and the computer R3 a third participant.
  • the participants need not necessarily be computers, but participants can also represent any other kommunizie ⁇ generating units, such as automation units or machines.
  • the automation units can be corresponding components of an automation system which performs an automatic production or production process.
  • the individual Au ⁇ tomatleitersakuen may represent, for example, a programmable controller, a sensor, an electric car, a power charging station for an electric car, a power meter, an energy automation ⁇ s réelles réelle, a computer tomograph, an X-ray device and the like. All automation units are characterized by the fact that they are equipped with a communication interface for communication with other units.
  • the communication port ⁇ place it can be, for example, an Ethernet interface, an IP interface, a WLAN interface, a Bluetooth interface or a Zig-Bee interface.
  • the computer R 1 is authenticated to the computer R 2 using an extended X.509 certificate.
  • This certificate contains in a known manner, among other information, a public key of the subscriber Rl, which can be used in the context of authentication for the encrypted exchange of a secret and for generating a session key for a cryptographically secured communication between computer Rl and R2.
  • the certificate is signed by a trusted certification authority. For verification of the certificate this is transmitted to the computer R2, which then verifies the signature in a conventional manner based on a root certificate issued by the certificate authority or a certificate ⁇ chain to the root certificate.
  • Table 1 below shows the essential information of a conventional X.509 certificate. This certificate is e.g. used in the known SSL / TLS authentication or IKE / IPsec authentication.
  • the term “certificatelD” denotes an identity of the certificate specified by the serial number "SerialNumber".
  • the English expression “issuedTo” indicates for which participant the Certificate is issued, with the term “issuedTo” followed by the name of the subscriber.
  • the term “issuer” refers to the publisher of the certificate, which is specified by a suitable name of the publisher.
  • the terms “validFrom” and “validTo” specify the validity period of the certificate, with the term “validFrom” specifying a time “Time” at which the validity of the certificate begins or commencing, and the term “validTo” again Time specified “Time”, which specifies the expiration date of the certificate.
  • the certificate then contains the public key "Public Key” of the subscriber.
  • attributes may be present in the certificate, which are defined in the "Attributes" section of the certificate.
  • an attribute AttributeA and an attribute AttributeB are specified.
  • attributes can specify through which determines what actions the participant who owns the certifi cate ⁇ , can perform at ⁇ play as permissions.
  • attributes may specify usage restrictions of the certificate, for example, it may be specified that the certificate is only suitable for the digital signature and for authentication, but that it can not be used for encryption.
  • the certificate also includes the signature already described above, which is labeled "Signatu- re" and the verification of the certificate allows ba ⁇ sierend on a root certificate or a certificate chain to the root certificate.
  • the structure of the certificate of Table 2 corresponds to the greatest possible extent the certificate ⁇ Table 1, so that the same are standard terms are not explained again.
  • the extended X.509 certificate now includes another attribute, called "requi redClaims".
  • a so-called claim classifier is specified here, which specifies one or more so-called claims, which must be fulfilled for the certificate to be considered valid.
  • the syntax of the claims is based on the so-called "Claims-based Authorization Model” developed by Microsoft as part of the Geneva Framework 2008 was determined (see also htt: // msdn .microsoft. com / en - us / iaagazlne / d.d278426. aspx).
  • the claim classifier may be encoded directly in the certificate, but may also include a reference to a claim classifier (eg, a URL or URI) in the certificate through which the claim classifier can be accessed.
  • SAML assertions are based on the well-known XML-based SAML language, specify a statement.
  • An example of a syntax as SAML assertions may be co ⁇ diert instead of a claim classifier in an inventive certificate reads as follows:
  • ⁇ roleClaimType value "urn: remoteServcetApp / 2010/04 / Claims / permission" /> ⁇ / samlSecurityTokenRequirement>
  • the computer R3 is used, which is a publisher for corresponding claims or Represents assertions. Only if this computer has issued one or more of the assertions or claims specified in the corresponding certificate, the certificate is considered valid.
  • the corresponding certificate of the computer R 1 is indicated by the reference symbol C and the claims contained therein by the reference symbol CL.
  • it can additionally be specified in the certificate by which issuing computer the corresponding claims or SAML assertions must be issued so that the certificate is valid. If appropriate, this information can again be coded in the form of a corresponding claim or a corresponding SAML assertion in the certificate.
  • step S 1 the computer R 1, which wishes to authenticate itself to the computer R 2, first requests the corresponding claims based on the claim classifier in its certificate at the computer R 3. If the computer R3 issues a corresponding claim, so he also assures that the corresponding requirement is fulfilled according to the claim. Based on the requested in step Sl
  • Claims determines the computer R3, which of the claims he has actually published ⁇ Lich. This information is then transferred by the computer R3 in step S2 to the computer Rl. In the embodiment described here, the claims themselves are transmitted to the computer Rl.
  • step S3 the actual certificate ⁇ based authentication, which is indicated by step S3.
  • the certificate C of the computer Rl and all or a subset of the claims transmitted in step S2 are transmitted to the computer R2.
  • the computer R2 then verifies the certificate in a manner known per se and verifies fer ⁇ ner whether he classifies the certificate as valid. This is special when the SPECIFIED ⁇ th in the certificate claims to match the case with the other submitted claims. If the certificate C is not classified as valid, the authentication is aborted.
  • the authentication can be based on known protocols, such as, for example, SSL / TLS or IKE / IPsec or IKEv2 / IPsec, whereby the presence of the claims is additionally checked in the context of these protocols.
  • Is the above-described Authen ⁇ mation of step S3 finished, can subsequently be negotiated via a corresponding public key in the certificate, a session key and a cryptographically secure communication between the computers Rl and R2 take place. This is indicated in FIG. 1 by the step S4.
  • step S101 the computer R2 requests from the computer Rl its certificate C with the claims CL contained therein.
  • step S102 this certificate is transmitted, wherein the verification of the certificate takes place in step S103. As part of this step is also checked whether the claims contained in the certificate C were actually issued by the computer R3.
  • Step S104 also transmits the computer R2 his certificate C with contained claims CL 'to the computer Rl.
  • a check of the certificate C is made in step S105 in analogy to step S103 to see whether the claims CL 'have actually been issued by the computer R3. If the inspections carried in step S103 and S105 are both positive, both certificates are considered by the respective computers as valid and it can be a corresponding authentication SUC ⁇ gen, under which a session key SK between the two computers is set up Rl and R2. This key can subsequently take place trust protected commu ⁇ nication.
  • the corresponding requirements of the certificate are checked during the protocol run.
  • this check can also be performed outside the protocol separately between the authenticating communication partners, e.g. using the HTTP protocol after a completed SSL / TLS connection via the established SSL / TLS connection.
  • the requirements can be linked to any criteria. For example, a certificate for a part ⁇ participants can be edited, which is only valid as long as this device is operated in the current communication environment, wherein the communication environment is, for example specified by a corresponding network address.
  • the require ⁇ approximations can also depending issued by the participant who wants to authenticate itself, or if necessary against the au- tion also takes place by the subscriber.
  • the request can be determined in such a way that a subscriber can authenticate himself to a subscriber, for example, whereas an authentication to another subscriber is not possible.
  • a confidence value can be specified on a request that specifies the ceremonies Jewish ⁇ speed in the processing performed authentication.
  • ⁇ when it is considered that the quality of a Authenti ⁇ tion may change over the life of a user, such as when attacks are known or a particular subscriber has been hacked or if the participant could possibly be manipulated, eg in a non-confidential ⁇ ens Calculen Previous owners.
  • the requirements specified in the certificate can also be suitably concatenated. This makes it possible supraschrän- the circle of participants ken, must rely on a specific, present in network Resource ⁇ ce, for example.
  • a request associated with a subscriber certificate may require a further request from the subscriber describing how it has authenticated itself.
  • the corresponding requirements can, for example, be issued by the device manufacturer of the corresponding subscriber. This device manufacturer usually also issues the certificate for the subscriber.
  • the concatenation of requests described above can be done with known logical operators AND, NAND, OR, XOR and NOR.
  • the corresponding logical concatenation is preferably encoded in the certificate.
  • Ver ⁇ chaining example it is possible to issue lock requests for corresponding certificates. These revocation requests can be used to invalidate certificates from a large number of subscribers. If a lock request is linked to other requests with a NAND link, a necessary criterion that the certificate is valid is the absence of the lock request.
  • certificates for corresponding part ⁇ participants issued with virtually infinite validity advertising to. This can be done, for example, there ⁇ by with a .509 X certificate, that the relevant specifications "va- lidFrom" and "validTo" are set to an infinite valid period. In order nevertheless to revoke the certificate, it is sufficient that a requirement which must be present for the validity of a corresponding certificate is no longer provided by the publisher of the requirements. It is also possible that the corresponding An ⁇ requirements for controlling the validity of the certificate in a local communication network, for example in the communication network of an automation system, are issued by a local part ⁇ participants in the system. In particular, the manufacturer of an automation system for the individual components can issue corresponding certificates with specified therein requirements, but the release of the requirements is regulated locally by the operator of the automation system.

Abstract

Die Erfindung betrifft ein Verfahren zur Zertifikats-basierten Authentisierung, bei der sich ein erster Teilnehmer (R1) gegenüber einem zweiten Teilnehmer (R2) mit Hilfe eines, dem ersten Teilnehmer (R1) zugeordneten digitalen Zertifikats (C) authentisiert. Das Zertifikat (C, C') spezifiziert dabei eine oder mehrere Anforderungen (CL, CL'), wobei die Erfüllung einer Anforderung (CL, CL') durch einen dritten Teilnehmer (R3) zugesichert wird, indem der dritte Teilnehmer (R3) die Anforderung (CL, CL') herausgibt. Im Rahmen der Authentisierung wird durch den zweiten Teilnehmer (R2) eine Gültigkeitsbedingung überprüft und das Zertifikat von dem zweiten Teilnehmer (R2) als gültig eingestuft, falls die Gültigkeitsbedingung erfüllt ist, wobei die Gültigkeitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat spezifizierten Anforderungen (CL, CL') durch den dritten Teilnehmer (R3) abhängt. Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass zur Gültigkeitsbeschränkung des Zertifikats Anforderungen eingesetzt werden, wobei die Anforderungen z.B. auf den an sich bekannten SAML-Assertions beruhen können. Hierdurch kann einfach und flexibel die Gültigkeit eines Zertifikats gesteuert werden, ohne dass die Gültigkeit im Zertifikat explizit festgelegt ist. Das Verfahren kann zur Authentisierung in beliebigen technischen Gebieten eingesetzt werden, z.B. kann es zur Authentisierung von Teilnehmern in der Form von Komponenten einer Automatisierungsanlage verwendet werden.

Description

Beschreibung
Verfahren zur Zertifikats-basierten Authentisierung Die Erfindung betrifft ein Verfahren zur Zertifikats-basierten Authentisierung, bei der sich ein erster Teilnehmer gegenüber einem zweiten Teilnehmer mit Hilfe eines, dem ersten Teilnehmer zugeordneten digitalen Zertifikats authentisiert . Digitale Zertifikate sind an sich aus dem Stand der Technik bekannt. Sie enthalten die Identität einer Entität in der Form einer Person bzw. Institution bzw. Maschine, für die das Zertifikat ausgestellt ist. Hier und im Folgenden wird der Betriff des Teilnehmers verwendet, dem ein Zertifikat zuge- ordnet sein kann. Ein Teilnehmer kann dabei ein Computer bzw. eine Maschine sein, für die das Zertifikat ausgestellt ist. Ebenso kann sich ein Teilnehmer auf einen Computer bzw. eine Maschine beziehen, welche das Zertifikat einer Person bzw. Institution verwaltet. Durch die Zuständigkeit für die Zerti- fikatsverwaltung wird dem Computer bzw. der Maschine das Zertifikat zugeordnet.
Ein Zertifikat enthält einen öffentlichen Schlüssel für die entsprechende Entität, und über eine digitale Signatur im Zertifikat kann der Eigentümer des Zertifikats bestätigt wer¬ den. Die digitale Signatur wird dabei von einer Zertifi¬ katsausgabestelle berechnet. Über ein Root-Zertifikat dieser Ausgabestelle bzw. eine Zertifikatskette hin zu dem Root- Zertifikat kann die Signatur als gültig verifiziert werden. In einem digitalen Zertifikat können Zusatzinformationen in der Form sog. Attribute eincodiert werden, durch welche Be¬ rechtigungen für den Nutzer des Zertifikats oder Nutzungseinschränkungen des Zertifikats festgelegt werden. Zertifikate weisen in der Regel eine begrenzte Gültigkeits¬ dauer auf, welche als Information in dem Zertifikat spezifiziert ist. Nach Ende der Gültigkeitsdauer wird das Zertifikat automatisch ungültig. Es muss somit im Rahmen der Verwaltung von Zertifikaten sichergestellt werden, dass ein Zertifikat, welches über seine Gültigkeitsdauer hinaus verfügbar sein soll, rechtzeitig durch ein entsprechendes Zertifikat mit neuer Gültigkeitsdauer ersetzt wird. Dies ist in der Praxis mit einem hohen administrativen Aufwand verbunden. Insbesondere bei der Ausstellung von Zertifikaten für Automatisierungsgeräte, die über einen langen Zeitraum genutzt werden und keiner stringenten Rechner-Administration unterliegen, ist dies nur schwer umsetzbar. Es besteht zwar die Möglich- keit, Zertifikate mit sehr langer bzw. unbegrenzter Gültigkeitsdauer auszustellen, jedoch wird hierdurch die Missbrauchsgefahr erhöht.
Aus dem Stand der Technik ist es ferner bekannt, Zertifikate zu widerrufen. Der Rückruf von Zertifikaten ist jedoch aufwändig, da dazu Zertifikatswiderrufslisten ausgestellt und verteilt werden müssen. Ferner ist ein einmalig widerrufenes Zertifikat dauerhaft ungültig und kann nicht wieder reakti¬ viert werden.
Zur Authentisierung eines Teilnehmers gegenüber einem anderen Teilnehmer bzw. einem Dienst (z.B. Webservice) ist die Verwendung sog. SAML-Assertions (SAML = Security Assertion Mark¬ up Language) bekannt. Diese Assertions stellen Aussagen dar, welche durch einen Herausgeber der Assertions zugesichert werden. Die Authentisierung des Teilnehmers gegenüber einem anderen Teilnehmer bzw. einem Dienst kann somit an die Herausgabe entsprechender SAML-Assertions gekoppelt sein. Nur wenn vorbestimmte Assertions für einen Teilnehmer zugesichert sind, erfolgt dessen Authentisierung.
Aus dem Stand der Technik ist ferner das sog. "Claims-based Authorization Model" bekannt, das von der Firma Microsoft® entwickelt wurde. Ein Nutzer wird dabei nicht durch eine fes- te Identität repräsentiert, sondern über eine Menge sog.
Claims, die Eigenschaften des Nutzers bestätigen. Ein möglicher Claim ist z.B. eine Authentisierung mittels Zertifikat, mittels Passwort und dergleichen. Abhängig von den vorhande¬ nen Claims wird ein Zugriff gewährt oder abgewiesen.
Aufgabe der Erfindung ist es, eine Zertifikats-basierte Au- thentisierung zu schaffen, bei der einfach und flexibel die Gültigkeit des hierfür genutzten Zertifikats gesteuert werden kann .
Diese Aufgabe wird durch das Verfahren gemäß Patentanspruch 1 bzw. das Kommunikationsnetz gemäß Patentanspruch 14 gelöst. Weiterbildungen der Erfindung sind in den abhängigen Patentansprüchen definiert.
Im Rahmen des erfindungsgemäßen Verfahrens wird eine Authen- tisierung durchgeführt, bei der sich ein erster Teilnehmer gegenüber einem zweiten Teilnehmer mit Hilfe eines, dem ersten Teilnehmer zugeordneten digitalen Zertifikats authenti- siert. Das Zertifikat spezifiziert dabei eine oder mehrere Anforderungen, wobei die Erfüllung einer Anforderung durch einen dritten Teilnehmer zugesichert wird, indem der dritte
Teilnehmer die Anforderung herausgibt. Der Begriff der Spezifikation von Anforderungen im Zertifikat ist dabei weit zu verstehen. Die spezifizierten Anforderungen können direkt im Zertifikat hinterlegt sein bzw. über einen Identifikator oder Namen spezifiziert werden. Ebenso kann die Spezifikation von einer oder mehrerer Anforderungen über eine Referenz erfolgen, die auf die Anforderungen verweist, wie z.B. eine URI oder eine URL. Auch der Begriff der Herausgabe einer Anforderung ist im Sinne der Erfindung weit zu verstehen. Eine An- forderung kann beispielsweise dann als herausgegeben angesehen werden, wenn sie auf dem entsprechenden dritten Teilnehmer hinterlegt ist bzw. von diesem Teilnehmer abgerufen werden kann. Im Rahmen der erfindungsgemäßen Authentisierung wird durch den zweiten Teilnehmer eine Gültigkeitsbedingung überprüft und das Zertifikat des ersten Teilnehmers von dem zweiten Teilnehmer dann als gültig eingestuft, falls die Gültigkeits- bedingung erfüllt ist. Erfindungswesentlich ist dabei, dass die Gültigkeitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat spezifizierten Anforderungen durch den dritten Teilnehmer ab- hängt. Ist die entsprechend festgelegte Gültigkeitsbedingung dabei nicht erfüllt, wird das Zertifikat als ungültig erach¬ tet und eine entsprechende Authentisierung abgebrochen. Dabei kann insbesondere als Gültigkeitsbedingung durch den zweiten Teilnehmer geprüft werden, ob zum Zeitpunkt der Überprüfung des Zertifikats des ersten Teilnehmers die spezifizierten An¬ forderungen aufgrund einer Herausgabe der Anforderungen durch den dritten Teilnehmer erfüllt sind.
Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass die Gültigkeit eines Zertifikats nicht mehr direkt im
Zertifikat selbst festgelegt wird, sondern mittelbar über die Verwendung entsprechender Anforderungen, die einfach und flexibel durch einen dritten Teilnehmer verwaltet werden, der die entsprechenden Anforderungen herausgibt. In einer beson- ders bevorzugten Aus führungs form kann auf eine an sich bekannte Syntax zur Definition entsprechender Anforderungen zurückgegriffen werden, insbesondere können die Anforderungen die eingangs erwähnten SAML-Assertions bzw. entsprechende Claims aus dem "Claims-based Authorization Model" darstellen.
In einer bevorzugten Aus führungs form des erfindungsgemäßen Verfahrens fragt der erste Teilnehmer beim dritten Teilnehmer die Information ab, ob eine oder mehrere der im Zertifikat spezifizierten Anforderungen vom dritten Teilnehmer herausge- geben wurden. Der erste Teilnehmer stellt dabei die abgefrag¬ te Information dem zweiten Teilnehmer bereit, beispielsweise indem er die herausgegebenen Anforderungen an den zweiten Teilnehmer übermittelt. Daraufhin überprüft der zweite Teil¬ nehmer basierend auf dieser Information die Gültigkeitsbedin- gung. Alternativ oder zusätzlich ist es auch möglich, dass der zweite Teilnehmer direkt beim dritten Teilnehmer die Information abfragt, ob eine oder mehrere der im Zertifikat spezifizierten Anforderungen vom dritten Teilnehmer herausge- geben wurden, um anschließend basierend auf der abgefragten Information die Gültigkeitsbedingung zu überprüfen.
Um einen Missbrauch durch ein unbefugtes Abfragen von Anfor- derungen beim dritten Teilnehmer zu vermeiden, muss sich in einer besonders bevorzugten Aus führungs form der erste
und/oder zweite Teilnehmer beim dritten Teilnehmer zur Abfrage des oder der Anforderungen authentisieren . Nur bei erfolgreicher Authentisierung erhält der entsprechende Teilnehmer dann die Informationen über die Anforderungen.
Je nach Anwendungsfall können beliebige Arten von Anforderungen in dem Zertifikat spezifiziert werden. Insbesondere kann eine Anforderung in Bezug auf die zeitliche Gültigkeit des Zertifikats spezifiziert werden, d.h. die zeitliche Gültig¬ keit des Zertifikats wird an die Herausgabe einer entspre¬ chenden Anforderung gekoppelt, ohne weitere Kriterien zu berücksichtigen. Ferner kann sich eine Anforderung auf die Kommunikationsumgebung beziehen, in welcher der erste Teilnehmer betrieben wird. Diese Kommunikationsumgebung kann z.B. durch spezielle Eigenschaften bzw. eine entsprechende Adresse des Kommunikationsnetzes festgelegt werden. Ebenfalls kann sich eine Anforderung auf eine oder mehrere Eigenschaften des ersten und/oder zweiten und/oder dritten Teilnehmers beziehen. Zum Beispiel kann festgelegt werden, dass nur bestimmte erste bzw. zweite bzw. dritte Teilnehmer im Rahmen der Zertifikatsbasierten Authentisierung verwendet werden dürfen. Insbesondere kann dabei auch festgelegt werden, von welchem Teilnehmer die herausgegebenen Zertifikate stammen müssen. Darüber hinaus kann eine Anforderung die Vertrauenswürdigkeit der Au¬ thentisierung des ersten Teilnehmers beim zweiten Teilnehmer spezifizieren. Nur wenn die in der Anforderung festgelegte Vertrauenswürdigkeit, z.B. in der Form eines Vertrauenswerts, gegeben ist, wird das Zertifikat als gültig erachtet. Hier- durch kann berücksichtigt werden, dass sich die Vertrauens¬ würdigkeit einer Authentisierung mit der Zeit ändern kann, da z.B. ein Angriff auf einen bestimmten Teilnehmer bekannt geworden ist. In einer weiteren Aus führungs form des erfindungsgemäßen Verfahrens ist die Gültigkeitsbedingung eine logische Verknüp¬ fungskette umfassend eine oder mehrere AND- und/oder NAND- und/oder OR- und/oder XOR- und/oder NOR-Verknüpfungen, wobei die Verknüpfungskette vorzugsweise in dem Zertifikat codiert ist. Auf diese Weise können sehr gut z.B. Sperr-Anforderungen verarbeitet werden, wobei bei Vorliegen einer Sperr-Anforde¬ rung das Zertifikat als ungültig betrachtet wird. Durch eine NAND-Verknüpfung kann somit die Gültigkeit des Zertifikats an die Abwesenheit einer Sperr-Anforderung gekoppelt werden.
In einer weiteren, besonders bevorzugten Aus führungs form des erfindungsgemäßen Verfahrens findet im Rahmen der Authenti- sierung des ersten Teilnehmers gegenüber dem zweiten Teilnehmer neben der obigen Überprüfung der Gültigkeitsbedingung des Zertifikats auch eine Verifikation des Zertifikats statt. Diese Verifikation kann in an sich bekannter Weise durch Überprüfung der Signatur des Zertifikats erfolgen.
In einer weiteren Aus führungs form des erfindungsgemäßen Verfahrens wird mit einem im Zertifikat enthaltenen öffentlichen Schlüssel des ersten Teilnehmers sowie dem diesem öffentli¬ chen Schlüssel zugeordneten privaten Schlüssel eine kryp- tographisch gesicherte Verbindung zwischen dem ersten und zweiten Teilnehmer aufgebaut. Gegebenenfalls kann im Rahmen dieser kryptographisch gesicherten Verbindung auch eine Übermittlung der entsprechenden Anforderungen zur Überprüfung der Gültigkeitsbedingung erfolgen. Sollte sich dabei ergeben, dass die Gültigkeitsbedingung nicht erfüllt ist, wird die verschlüsselte Verbindung und somit die Authentisierung ab¬ gebrochen. In einer Variante erfolgt bei aufgebauter verschlüsselter Verbindung wiederholt, z.B. periodisch alle 5 Minuten oder stündlich, eine erneute Überprüfung der Gültig- keitsbedingung . Falls dies nicht der Fall ist, wird in einer Variante der Erfindung die Verbindung beendet. Die mit dem erfindungsgemäßen Verfahren durchgeführte Authen- tisierung kann auf an sich bekannten Protokollen basieren, z.B. dem SSL/TLS-Protokoll und/oder dem IKE/ IPsec-Protokoll und/oder dem IKEv2/IPsec-Protokoll, wobei zusätzlich die er¬ findungsgemäße Überprüfung der Gültigkeitsbedingung anhand entsprechender Anforderungen erfolgt. Ebenso kann das im Rahmen der Erfindung verwendete Zertifikat auf einem an sich be¬ kannten Zertifikat basieren. Insbesondere kann das Zertifikat ein erweitertes X .509-Zertifikat darstellen, welches zusätz¬ lich zu den an sich bekannten Einträgen eine oder mehrere Anforderungen spezifiziert.
Das erfindungsgemäße Verfahren kann gegebenenfalls auch zur gegenseitigen Authentisierung zwischen dem ersten und zweiten Teilnehmer genutzt werden. Das heißt, mit dem Verfahren au- thentisiert sich der erste Teilnehmer beim zweiten Teilnehmer und unter Vertauschung der Rollen von erstem und zweitem Teilnehmer analog der zweite Teilnehmer beim ersten Teilnehmer .
Das erfindungsgemäße Verfahren kann für beliebige erste bzw. zweite bzw. dritte Teilnehmer in der Form von Rechnern bzw. Maschinen eingesetzt werden. Vorzugsweise stellen die Teil¬ nehmer dabei Komponenten einer Automatisierungsanlage dar, wie z.B. entsprechende Steuerungsgeräte, Sensoren, Aktoren und dergleichen.
Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner ein Kommunikationsnetz mit einem ersten, zweiten und dritten Teilnehmer, wobei im Betrieb des Kommunikationsnetzes eine Zertifikats-basierte Authentisierung gemäß dem oben be¬ schriebenen Verfahren bzw. einer oder mehrerer Varianten des oben beschriebenen Verfahrens durchführbar ist.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben. Es zeigen:
Fig. 1 eine schematische Darstellung eines Kommunikations netz s, in dem eine Aus führungs form der Zertifi- kats basierten Authentisierung durchgeführt wird; und
Fig. 2 eine schematische Darstellung eines Nachrichtenaus¬ tauschs zwischen zwei Teilnehmern in einem Kommuni- kationsnetz, welche sich gegenseitig basierend auf e mer Aus führungs form des erfindungsgemäßen Verfah- rens authentisieren
Fig. 1 zeigt in schematischer Darstellung ein Kommunikationsnetz N mit einer Mehrzahl von Rechnern, wobei die an der nachfolgend beschriebenen Zertifikats-basierten Authentisierung beteiligten Rechner mit Rl, R2, und R3 bezeichnet sind. Der Rechner Rl entspricht dabei einem ersten Teilnehmer im Sinne von Anspruch 1, der Rechner R2 einem zweiten Teilnehmer und der Rechner R3 einem dritten Teilnehmer. Bei den Teilnehmern muss es sich nicht zwangsläufig um Rechner handeln, sondern die Teilnehmer können auch beliebige andere kommunizie¬ rende Einheiten, wie z.B. Automatisierungseinheiten bzw. Maschinen darstellen. Insbesondere kann es sich bei den Automatisierungseinheiten um entsprechende Komponenten einer Automatisierungsanlage handeln, welche einen automatischen Ferti- gungs- bzw. Produktionsprozess durchführt. Die einzelnen Au¬ tomatisierungseinheiten können z.B. eine programmierbare Steuerung, ein Sensor, ein Elektroauto, eine Stromladesäule für ein Elektroauto, einen Stromzähler, ein Energieautomati¬ sierungsgerät, einen Computer-Tomographen, ein Röntgengerät und dergleichen darstellen. Alle Automatisierungseinheiten zeichnen sich dadurch aus, dass sie über eine entsprechende Kommunikationsschnittstelle zur Kommunikation mit anderen Einheiten ausgestattet sind. Bei der Kommunikationsschnitt¬ stelle kann es sich z.B. um eine Ethernet-Schnittstelle, eine IP-Schnittstelle, eine WLAN-Schnittstelle, eine Bluetooth- Schnittstelle oder eine Zig-Bee-Schnittstelle handeln. In dem Szenario der Fig. 1 erfolgt eine Authentisierung des Rechners Rl gegenüber dem Rechner R2 unter Verwendung eines erweiterten X .509-Zertifikats . Dieses Zertifikat enthält in an sich bekannter Weise neben anderen Informationen einen öffentlichen Schlüssel des Teilnehmers Rl, der im Rahmen der Authentisierung zum verschlüsselten Austausch eines Geheimnisses und zur Generierung eines Sitzungsschlüssels für eine kryptographisch gesicherte Kommunikation zwischen Rechner Rl und R2 verwendet werden kann. Das Zertifikat ist dabei durch eine vertrauenswürdige Zertifizierungsstelle signiert. Zur Verifikation des Zertifikats wird dieses zum Rechner R2 übermittelt, der anschließend die Signatur in an sich bekannter Weise basierend auf einem Root-Zertifikat der das Zertifikat herausgebenden Zertifizierungsstelle bzw. einer Zertifikats¬ kette hin zum Root-Zertifikat verifiziert.
In der nachfolgenden Tabelle 1 sind die wesentlichen Informationen eines herkömmlichen X .509-Zertifikats wiedergegeben. Dieses Zertifikat wird z.B. bei der bekannten SSL/TLS-Authen- tisierung oder einer IKE/ IPsec-Authentisierung verwendet.
Tabelle 1:
Certificate
certificate! D: SerialNumber
issuedTo: Name
issuer: Name
validFrom: Time
validTo: Time
Public Key
Attributes
AttributeA
AttributeB
Signature
In obiger Tabelle bezeichnet der Ausdruck "certificatelD" eine Identität des Zertifikats, welche durch die Seriennummer "SerialNumber" spezifiziert wird. Durch den englischen Aus- druck "issuedTo" wird angegeben, für welchen Teilnehmer das Zertifikat ausgestellt ist, wobei der Ausdruck "issuedTo" von dem Namen des Teilnehmers gefolgt ist. Durch den Ausdruck "issuer" wird der Herausgeber des Zertifikats bezeichnet, der durch einen geeigneten Namen des Herausgebers spezifiziert wird. Durch die Ausdrücke "validFrom" und "validTo" wird der Gültigkeitszeitraum des Zertifikats spezifiziert, wobei der Ausdruck "validFrom" einen Zeitpunkt "Time" spezifiziert, an der die Gültigkeit des Zertifikats anfängt bzw. angefangen hat, und der Ausdruck "validTo" wiederum einen Zeitpunkt "Time" spezifiziert, der das Ablaufdatum des Zertifikats festlegt. Anschließend ist in dem Zertifikat der öffentliche Schlüssel "Public Key" des Teilnehmers enthalten. Zusätzlich können in dem Zertifikat mehrere Attribute vorhanden sein, welche im Abschnitt "Attributes" des Zertifikats definiert sind. Beispielhaft ist dabei ein Attribut AttributeA und ein Attribut AttributeB angegeben. Solche Attribute können bei¬ spielsweise Berechtigungen spezifizieren, durch welche festgelegt wird, welche Aktionen der Teilnehmer, dem das Zertifi¬ kat gehört, durchführen kann. Ebenso können Attribute Nut- Zungseinschränkungen des Zertifikats spezifizieren, z.B. kann festgelegt werden, dass das Zertifikat nur zur digitalen Sig¬ natur und zur Authentisierung geeignet ist, jedoch nicht zur Verschlüsselung verwendbar ist. Das Zertifikat enthält ferner die bereits oben beschriebene Signatur, welche mit "Signatu- re" bezeichnet ist und die Verifikation des Zertifikats ba¬ sierend auf einem Root-Zertifikat bzw. einer Zertifikatkette hin zum Root-Zertifikat ermöglicht.
Im Rahmen der weiter unten noch näher beschriebenen Authenti- sierung des Rechners Rl gegenüber dem Rechner R2 wird in der hier beschriebenen Aus führungs form ein erweitertes X.509- Zertifikat eingesetzt, dessen Aufbau in nachfolgender Tabelle 2 wiedergegeben ist. Tabelle 2:
Certificate
certificatelD: SerialNumber
issuedTo: Name
issuer: Name
validFrom: Time
validTo: Time
Public Key
Attributes
AttributeA
AttributeB
requiredClaims: Claim-Classifier
Signature
Der Aufbau des Zertifikats der Tabelle 2 entspricht weitest¬ gehend dem Zertifikat der Tabelle 1, so dass die gleichen Be standteile nicht nochmals erläutert werden. Im Unterschied zum Zertifikat der Tabelle 1 enthält das erweiterte X.509- Zertifikat nunmehr ein weiteres Attribut, welches als "requi redClaims" bezeichnet ist. Hierüber wird ein sog. Claim- Classifier spezifiziert, der einen oder mehrere sog. Claims angibt, welche erfüllt sein müssen, damit das Zertifikat als gültig betrachtet wird. Die Claims stellen dabei Ausführungs formen von Anforderungen im Sinne von Anspruch 1 dar. In der hier beschriebenen Aus führungs form beruht die Syntax der Claims auf dem sog. "Claims-based Authorization Model", das von der Firma Microsoft als Teil des Geneva Frameworks 2008 ermittelt wurde (siehe auch htt : //msdn .microsoft . com/en - us/iaagazlne/d.d278426. aspx) . Der Claim-Classifier kann direkt im Zertifikat eincodiert sein, jedoch kann gegebenenfalls auch eine Referenz auf einen Claim-Classifier (z.B. eine URL oder URI) im Zertifikat enthalten sein, über die auf den Claim-Classifier zugegriffen werden kann.
Ein Beispiel für eine Syntax, gemäß der ein Claim-Classifier durch das oben genannte Claims-based Authorization Modell spezifiziert werden kann, lautet wie folgt:
<claimTypeRequirements>
<add claimType= "http : // Schemas . xmlsoap .org/ws/2005/05/identity/ Claims /name" isOptional=" false"/>
<add claimType= "urn : remoteServiceApp/ 2010/04/ Claims /permission" isOptional=" false" />
</ claimTypeRequirements>
Die dargestellte Syntax ist an sich aus dem Stand der Technik bekannt und wird deshalb nicht im Detail erläutert. Durch den Ausdruck "claimType" wird auf die entsprechenden Claims bzw. deren Namen verwiesen. Der Ausdruck "isOptional" spezifiziert, ob das Vorhandensein des entsprechenden Claims optional ist oder nicht. Im obigen Claim-Classifier ist die Variable "isOptional" auf "false" gesetzt, d.h. die Claims müssen erfüllt sein, damit das Zertifikat als gültig betrachtet wird .
Anstatt der oben beschriebenen Claims zur Spezifikation von Anforderungen zu verwenden, besteht in einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens auch die Möglichkeit, SAML-Assertions in das Zertifikat einzucodieren . Durch diese SAML-Assertions, welche auf der bekannten XML-basierten SAML-Sprache beruhen, wird eine Aussage spezifiziert. Ein Beispiel einer Syntax, wie SAML-Assertions anstatt eines Claim-Classifiers in einem erfindungsgemäßen Zertifikat co¬ diert werden können, lautet wie folgt:
<samlSecurityTokenRequirement >
<roleClaimType value= "urn : remoteServcetApp/ 2010/04/ Claims /permission" /> </ samlSecurityTokenRequirement>
Diese Syntax ist an sich bekannt und wird deshalb nicht im Detail erläutert. Die Syntax enthält die Variable "value", welche eine SAML-Assertion spezifiziert, die erfüllt sein muss, damit das Zertifikat als gültig betrachtet wird.
Um in dem Kommunikationsnetz der Fig. 1 sicherzustellen, dass ein entsprechender Claim bzw. eine entsprechende SAML- Assertion tatsächlich erfüllt sind, wird der Rechner R3 verwendet, der einen Herausgeber für entsprechende Claims bzw. Assertions darstellt. Nur wenn dieser Rechner eine oder mehrere der in dem entsprechenden Zertifikat spezifizierten Assertions bzw. Claims herausgegeben hat, ist das Zertifikat als gültig anzusehen. In Fig. 1 ist dabei das entsprechende Zertifikat des Rechners Rl mit dem Bezugszeichen C und die darin enthaltenen Claims mit Bezugszeichen CL angedeutet. In einer Variante kann in dem Zertifikat zusätzlich angegeben werden, durch welchen herausgebenden Rechner die entsprechenden Claims bzw. SAML-Assertions ausgestellt werden müssen, damit das Zertifikat Gültigkeit hat. Diese Information kann gegebenenfalls wiederum in der Form eines entsprechenden Claims bzw. einer entsprechenden SAML-Assertion im Zertifikat codiert sein. Nachfolgend wird anhand von Fig. 1 eine Realisierung einer Authentisierung basierend auf dem oben beschriebenen erweiterten X .509-Zertifikat erläutert, wobei entsprechende Anfor¬ derungen in der Form von Claims CL in dem Zertifikat C spezifiziert sind. In einem Schritt Sl fordert der Rechner Rl, der sich gegenüber dem Rechner R2 authentisieren möchte, zunächst die entsprechenden Claims basierend auf dem Claim-Classifier in seinem Zertifikat bei dem Rechner R3 an. Wenn der Rechner R3 einen entsprechenden Claim herausgibt, so sichert er damit auch zu, dass die entsprechende Anforderung gemäß dem Claim erfüllt ist. Basierend auf den in Schritt Sl angeforderten
Claims bestimmt der Rechner R3, welche der Claims er tatsäch¬ lich herausgegeben hat. Diese Information überträgt der Rechner R3 dann in Schritt S2 an den Rechner Rl . In der hier beschriebenen Aus führungs form werden die Claims selbst an den Rechner Rl übermittelt.
Nachfolgend erfolgt schließlich die eigentliche Zertifikats¬ basierte Authentisierung, die durch Schritt S3 angedeutet ist. Dabei wird das Zertifikat C des Rechners Rl sowie alle oder eine Teilmenge der in Schritt S2 übertragenen Claims an den Rechner R2 übermittelt. Der Rechner R2 verifiziert dann das Zertifikat in an sich bekannter Weise und überprüft fer¬ ner, ob er das Zertifikat als gültig einstuft. Dies ist ins- besondere dann der Fall, wenn die im Zertifikat spezifizier¬ ten Claims mit den weiteren übermittelten Claims übereinstimmen. Wird das Zertifikat C nicht als gültig eingestuft, wird die Authentisierung abgebrochen. Die Authentisierung kann da- bei basierend auf an sich bekannten Protokollen, wie z.B. SSL/TLS bzw. IKE/IPsec bzw. IKEv2/IPsec beruhen, wobei im Rahmen dieser Protokolle nunmehr zusätzlich das Vorhandensein der Claims überprüft wird. Ist die oben beschriebene Authen¬ tisierung gemäß dem Schritt S3 abgeschlossen, kann anschlie- ßend über einen entsprechenden öffentlichen Schlüssel in dem Zertifikat ein Sitzungsschlüssel ausgehandelt werden und eine kryptographisch gesicherte Kommunikation zwischen den Rechnern Rl und R2 stattfinden. Dies ist in Fig. 1 durch den Schritt S4 angedeutet.
In einer Abwandlung der Aus führungs form der Fig. 1 besteht auch die Möglichkeit, dass die Überprüfung der in dem Zerti¬ fikat C spezifizierten Claims CL durch den Rechner R2 direkt vorgenommen wird, d.h. der Rechner R2 fordert die Claims selbst bei dem herausgebenden Rechner R3 an. In diesem Fall müssen die Claims nicht mehr von dem Rechner Rl zum Rechner R2 übertragen werden. In einer weiteren Ausgestaltung besteht ferner die Möglichkeit, dass im Rahmen der Authentisierung auch ein Zertifikat des Rechners R2 mit entsprechend darin enthaltenen Claims zum Rechner Rl übertragen und dort überprüft wird. Das heißt, es kann auch eine beidseitige Authen¬ tisierung sowohl von dem Rechner Rl gegenüber dem Rechner R2 als auch von dem Rechner R2 gegenüber dem Rechner Rl stattfinden. Um Missbrauch im Rahmen der Festlegung der Gültigkeit des Zertifikats über entsprechende Claims zu vermeiden, kann im Rahmen der Anforderung der Claims durch den Rechner Rl bzw. den Rechner R2 beim Rechner R3 auch eine Authentisierung vorgeschaltet sein, d.h. nur wenn sich die Rechner Rl bzw. R2 beim Rechner R3 authentisieren können, haben sie Zugriff auf die herausgegebenen Claims.
Im Rahmen von Fig. 2 ist nochmals schematisiert ein Informa¬ tionsaustausch zwischen den Rechnern R2 und Rl zur beidseiti- gen Zertifikats-basierten Authentisierung zwischen den Rechnern angedeutet. Dieser Informationsaustausch erfolgt dabei über das an sich bekannte SSL/TLS-Protokoll . Die nachfolgend genannten Schritte S101 bis S104 umfassen dabei in der Regel jeweils eine Vielzahl von Teilschritten, welche an sich aus dem SSL/TLS-Protokoll bekannt sind und deshalb nicht näher ausgeführt werden. Im Rahmen des Schritts S101 fordert der Rechner R2 von dem Rechner Rl dessen Zertifikat C mit den darin enthaltenen Claims CL an. In Schritt S102 wird dieses Zertifikat übermittelt, wobei in Schritt S103 die Überprüfung des Zertifikats erfolgt. Im Rahmen dieses Schrittes wird auch überprüft, ob die im Zertifikat C enthaltenen Claims auch tatsächlich von dem Rechner R3 herausgegeben wurden. In
Schritt S104 übermittelt auch der Rechner R2 sein Zertifikat C mit darin enthaltenen Claims CL' an den Rechner Rl . Nach Empfang des Zertifikats im Rechner Rl wird in Schritt S105 analog zu Schritt S103 eine Überprüfung des Zertifikats C dahingehend vorgenommen, ob die Claims CL' auch tatsächlich von dem Rechner R3 herausgegeben worden sind. Sind die Über- prüfungen in Schritt S103 und S105 beide positiv, werden beide Zertifikate von den entsprechenden Rechnern als gültig erachtet und es kann eine entsprechende Authentisierung erfol¬ gen, in deren Rahmen ein Sitzungsschlüssel SK zwischen den beiden Rechnern Rl und R2 eingerichtet wird. Mit Hilfe dieses Schlüssels kann nachfolgend eine vertrauensgeschützte Kommu¬ nikation stattfinden.
In der Variante der Fig. 2 erfolgt die Überprüfung der entsprechenden Anforderungen des Zertifikats im Rahmen des Pro- tokollablaufs . Diese Überprüfung kann jedoch alternativ auch außerhalb des Protokolls separat zwischen den authentisieren- den Kommunikationspartnern durchgeführt werden, z.B. mittels des HTTP-Protokolls nach einem abgeschlossenen SSL/TLS- Verbindungsaufbau über die aufgebaute SSL/TLS-Verbindung .
Wie sich aus den obigen Ausführungen ergibt, wird die Gültig¬ keit eines Zertifikats in den beschriebenen Ausführungsbei¬ spielen über entsprechend in den Zertifikaten spezifizierte Anforderungen festgelegt, wobei die Überprüfung, ob eine Anforderung erfüllt ist, unter Zuhilfenahme eines Teilnehmers erfolgt, der diese Anforderungen herausgibt und damit zusi¬ chert, dass die entsprechende Anforderung erfüllt ist. Zur Realisierung einer solchen Gültigkeitsbeschränkung können dabei an sich aus dem Stand der Technik bekannte Mechanismen basierend auf entsprechenden Claims des oben genannten
Claims-based Authorization Modells bzw. basierend auf SAML- Assertions eingesetzt werden. Das im Rahmen der Erfindung verwendete Zertifikat ist somit nicht alleine gültig, sondern nur zusammen mit entsprechend herausgegebenen Anforderungen. Durch Herausgabe bzw. Rücknahme der Herausgabe der entspre¬ chenden Anforderungen über den Teilnehmer, der die Anforderungen herausgibt, kann dabei flexibel die Gültigkeit eines digitalen Zertifikats gewährt bzw. widerrufen werden.
Die Anforderungen können dabei an beliebige Kriterien gekoppelt sein. Beispielsweise kann ein Zertifikat für einen Teil¬ nehmer herausgegeben werden, das nur solange gültig ist, wie dieser Teilnehmer in der aktuellen Kommunikationsumgebung betrieben wird, wobei die Kommunikationsumgebung z.B. durch eine entsprechende Netzadresse spezifiziert ist. Die Anforde¬ rungen können auch in Abhängigkeit von dem Teilnehmer ausgestellt werden, der sich authentisieren möchte, bzw. gegebe- nenfalls auch von dem Teilnehmer, gegenüber dem die Authenti- sierung erfolgt. Die Anforderung kann dabei derart festgelegt sein, dass sich ein Teilnehmer z.B. gegenüber einem Teilnehmer authentisieren kann, wohingegen eine Authentisierung gegenüber einem anderen Teilnehmer nicht möglich ist. In einer Weiterbildung der Erfindung kann über eine Anforderung auch ein Vertrauenswert spezifiziert sein, der die Vertrauenswür¬ digkeit in die durchgeführte Authentisierung festlegt. Hier¬ bei wird berücksichtigt, dass sich die Güte einer Authenti¬ sierung im Laufe der Lebensdauer eines Teilnehmers ändern kann, z.B. wenn Angriffe bekannt werden oder ein bestimmter Teilnehmer gehackt wurde oder wenn der Teilnehmer möglicherweise manipuliert sein könnte, z.B. bei einem nicht vertrau¬ enswürdigen Vorbesitzer. In einer weiteren Aus führungs form können die im Zertifikat spezifizierten Anforderungen auch geeignet verkettet werden. Damit ist es möglich, den Kreis der Teilnehmer einzuschrän- ken, die z.B. auf eine bestimmte, im Netz vorhandene Ressour¬ ce zurückgreifen darf. Eine mit einem Teilnehmerzertifikat assoziierte Anforderung kann hierbei eine weitere Anforderung vom Teilnehmer erfordern, welche beschreibt, wie dieser sich authentisiert hat. Die entsprechenden Anforderungen können z.B. von dem Gerätehersteller des entsprechenden Teilnehmers herausgegeben werden. Dieser Gerätehersteller stellt üblicherweise auch das Zertifikat für den Teilnehmer aus.
Die oben beschriebene Verkettung von Anforderungen kann mit an sich bekannten logischen Operatoren AND, NAND, OR, XOR und NOR erfolgen. Die entsprechende logische Verkettung ist dabei vorzugsweise im Zertifikat eincodiert. Durch eine solche Ver¬ kettung ist es z.B. möglich, Sperr-Anforderungen für entsprechende Zertifikate auszugeben. Diese Sperr-Anforderungen kön- nen dazu genutzt werden, Zertifikate einer Vielzahl von Teilnehmern für ungültig zu erklären. Wird eine Sperr-Anforderung dabei mit einer NAND-Verknüpfung mit anderen Anforderungen verknüpft, ist ein notwendiges Kriterium, dass das Zertifikat gültig ist, die Abwesenheit der Sperr-Anforderung .
Die im Vorangegangenen beschriebenen Aus führungs formen des erfindungsgemäßen Verfahrens weisen eine Reihe von Vorteilen auf. Insbesondere können Zertifikate für entsprechende Teil¬ nehmer mit praktisch unendlicher Gültigkeit ausgestellt wer- den. Dies kann bei einem X .509-Zertifkat beispielsweise da¬ durch erfolgen, dass die entsprechenden Spezifikationen "va- lidFrom" und "validTo" auf einen unendlich gültigen Zeitraum gesetzt werden. Um dennoch das Zertifikat zu widerrufen, genügt es dabei, dass eine Anforderung, welche zur Gültigkeit eines entsprechenden Zertifikats vorhanden sein muss, nicht mehr durch den Herausgeber der Anforderungen bereitgestellt wird . Ebenso besteht die Möglichkeit, dass die entsprechenden An¬ forderungen zur Regelung der Gültigkeit des Zertifikats in einem lokalen Kommunikationsnetz, z.B. in dem Kommunikationsnetz einer Automatisierungsanlage, durch einen lokalen Teil¬ nehmer in der Anlage herausgegeben werden. Insbesondere kann der Hersteller einer Automatisierungsanlage für die einzelnen Komponenten entsprechende Zertifikate mit darin spezifizierten Anforderungen ausstellen, wobei jedoch die Herausgabe der Anforderungen lokal durch den Betreiber der Automatisierungsanlage geregelt wird.

Claims

Patentansprüche
1. Verfahren zur Zertifikats-basierten Authentisierung, bei der sich ein erster Teilnehmer (Rl) gegenüber einem zweiten Teilnehmer (R2) mit Hilfe eines, dem ersten Teilnehmer (Rl) zugeordneten digitalen Zertifikats (C, C ) authentisiert , wo¬ bei
das Zertifikat (C, C ) eine oder mehrere Anforderungen (CL, CL' ) spezifiziert und die Erfüllung einer Anforde- rung (CL, CL' ) durch einen dritten Teilnehmer (R3) zugesichert wird, indem der dritte Teilnehmer (R3) die Anforderung (CL, CL' ) herausgibt;
im Rahmen der Authentisierung durch den zweiten Teilnehmer (R2) eine Gültigkeitsbedingung überprüft wird und das Zertifikat (C, C ) des ersten Teilnehmers (Rl) von dem zweiten Teilnehmer (R2) als gültig eingestuft wird, falls die Gültigkeitsbedingung erfüllt ist, wobei die Gültig¬ keitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat (C, C ) spezifizierten Anforderungen (CL, CL' ) durch den dritten Teilnehmer (R3) abhängt.
2. Verfahren nach Anspruch 1, bei dem der erste Teilnehmer (Rl) beim dritten Teilnehmer (R3) die Information abfragt, ob eine oder mehrere der im Zertifikat (C, C ) spezifizierten
Anforderungen (CL, CL' ) vom dritten Teilnehmer (R3) herausgegeben wurden, wobei der erste Teilnehmer (Rl) die abgefragte Information dem zweiten Teilnehmer (R2) bereitstellt, woraufhin der zweite Teilnehmer (R2) basierend auf dieser Informa- tion die Gültigkeitsbedingung überprüft.
3. Verfahren nach Anspruch 1 oder 2, bei dem der zweite Teilnehmer (R2) beim dritten Teilnehmer (R3) die Information abfragt, ob eine oder mehrere der im Zertifikat (C, C ) spezi- fizierten Anforderungen (CL, CL' ) vom dritten Teilnehmer (R3) herausgegeben wurden, wobei der zweite Teilnehmer (R2) basierend auf der abgefragten Information die Gültigkeitsbedingung überprüft .
4. Verfahren nach Anspruch 2 oder 3, bei dem sich der erste und/oder zweite Teilnehmer (Rl, R2 ) beim dritten Teilnehmer (R3) zur Abfrage des oder der Anforderungen (CL, CL' ) authen- tisieren müssen.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem in dem Zertifikat (C, C ) eine oder mehrere der folgenden An¬ forderungen (CL, CL' ) spezifiziert werden:
- eine Anforderung (CL, CL' ) in Bezug auf eine zeitliche Gültigkeit des Zertifikats (C) ;
eine Anforderung (CL, CL' ) in Bezug auf eine Kommunikati¬ onsumgebung, in welcher der erste Teilnehmer (Rl) betrieben wird;
- eine Anforderung (CL, CL' ) in Bezug auf eine oder mehrere Eigenschaften des ersten und/oder zweiten und/oder dritten Teilnehmers (Rl, R2, R3) ;
eine Anforderung (CL, CL' ) in Bezug auf die Vertrauens¬ würdigkeit der Authentisierung des ersten Teilnehmers (Rl) beim zweiten Teilnehmer (R2) .
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Gültigkeitsbedingung eine logische Verknüpfungskette um¬ fassend mehrere AND- und/oder NAND- und/oder OR- und/oder XOR- und/oder NOR-Verknüpfungen ist, wobei die Verknüpfungs¬ kette vorzugsweise in dem Zertifikat (C, C ) codiert ist.
7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anforderungen (CL, CL' ) auf SAML basieren.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem im Rahmen der Authentisierung des ersten Teilnehmers (Rl) gegenüber dem zweiten Teilnehmer (R2) eine Verifikation des Zertifikats (C, C ) des ersten Teilnehmers durch den zweiten Teilnehmer (R) erfolgt.
9. Verfahren nach einem der vorhergehenden Ansprüche, bei dem mit einem im Zertifikat (C, C ) enthaltenen öffentlichen Schlüssel des ersten Teilnehmers (Rl) sowie dem diesem öf¬ fentlichen Schlüssel zugeordneten privaten Schlüssel eine kryptographisch gesicherte Verbindung zwischen dem ersten und zweiten Teilnehmer (Rl, R2 ) aufgebaut wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Authentisierung auf dem SSL/TLS- Protokoll und/oder dem IKE/ IPsec-Protokoll und/oder dem IKEv2/IPsec-Protokoll basiert .
11. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Zertifikat ein erweitertes X .509-Zertifikat ist, wel¬ ches zusätzlich eine oder mehrere Anforderungen (CL, CL' ) spezifiziert .
12. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Verfahren zur Authentisierung des ersten Teilnehmers (Rl) beim zweiten Teilnehmer (R2) und des zweiten Teilnehmers (R2) beim ersten Teilnehmer (Rl) genutzt wird.
13. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der erste und/oder zweite und/oder dritte Teilnehmer (R2, R2, R3) Komponenten einer Automatisierungsanlage darstellen.
14. Kommunikationsnetz mit einem ersten, zweiten und dritten Teilnehmer (Rl, R2, R3), wobei im Betrieb des Kommunikations¬ netzes (N) eine Zertifikats-basierte Authentisierung durch¬ führbar ist, bei der sich der erste Teilnehmer (Rl) gegenüber dem zweiten Teilnehmer (R2) mit Hilfe eines, dem ersten Teil- nehmer (Rl) zugeordneten digitalen Zertifikats (C, C ) au- thentisiert, wobei
das Zertifikat (C, C ) eine oder mehrere Anforderungen (CL, CL' ) spezifiziert und die Erfüllung einer Anforde¬ rung (CL, CL' ) durch einen dritten Teilnehmer (R3) zuge- sichert wird, indem der dritte Teilnehmer (R3) die Anforderung (CL, CL' ) herausgibt;
im Rahmen der Authentisierung durch den zweiten Teilnehmer (R2) eine Gültigkeitsbedingung überprüft wird und das Zertifikat (C, C ) des ersten Teilnehmers (Rl) von dem zweiten Teilnehmer (R2) als gültig eingestuft wird, falls die Gültigkeitsbedingung erfüllt ist, wobei die Gültig¬ keitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat (C,
C' ) spezifizierten Anforderungen (CL, CL' ) durch den dritten Teilnehmer (R3) abhängt.
15. Kommunikationsnetz nach Anspruch 14, welches derart aus- gestaltet ist, dass in dem Kommunikationsnetz (N) ein Verfahren nach einem der Ansprüche 2 bis 13 durchführbar ist.
PCT/EP2011/062644 2010-09-07 2011-07-22 Verfahren zur zertifikats-basierten authentisierung WO2012031821A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201180043126.1A CN103109508B (zh) 2010-09-07 2011-07-22 基于证书的验证方法和通信网
EP11741165.2A EP2594047A1 (de) 2010-09-07 2011-07-22 Verfahren zur zertifikats-basierten authentisierung
US13/820,811 US9432198B2 (en) 2010-09-07 2011-07-22 Method for certificate-based authentication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102010044517A DE102010044517A1 (de) 2010-09-07 2010-09-07 Verfahren zur Zertifikats-basierten Authentisierung
DE102010044517.7 2010-09-07

Publications (1)

Publication Number Publication Date
WO2012031821A1 true WO2012031821A1 (de) 2012-03-15

Family

ID=44509274

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/062644 WO2012031821A1 (de) 2010-09-07 2011-07-22 Verfahren zur zertifikats-basierten authentisierung

Country Status (5)

Country Link
US (1) US9432198B2 (de)
EP (1) EP2594047A1 (de)
CN (1) CN103109508B (de)
DE (1) DE102010044517A1 (de)
WO (1) WO2012031821A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9432198B2 (en) 2010-09-07 2016-08-30 Siemens Aktiengesellschaft Method for certificate-based authentication

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103716794A (zh) * 2013-12-25 2014-04-09 北京握奇数据系统有限公司 一种基于便携式设备的双向安全验证方法及系统
DE102014000168A1 (de) 2014-01-02 2015-07-02 Benedikt Burchard Verfahren zur Abrechnung einer Internetdienstleistung
CA2966664C (en) 2014-01-31 2018-11-27 Goldcorp Inc. Process for separation of at least one metal sulfide from a mixed sulfide ore or concentrate
EP2958265B1 (de) * 2014-06-16 2017-01-11 Vodafone GmbH Widerruf eines in einer Vorrichtung gespeicherten Root-Zertifikats
DE102015200209A1 (de) 2015-01-09 2016-07-14 Wobben Properties Gmbh Verfahren zum Autorisieren für Steuerzugriffe auf Windenergieanlagen sowie Schnittstelle von Windenergieanlagen und Zertifizierungsstelle
US10193699B2 (en) * 2015-05-15 2019-01-29 Microsoft Technology Licensing, Llc Probabilistic classifiers for certificates
EP3208674A1 (de) * 2016-02-19 2017-08-23 Siemens Aktiengesellschaft Netzwerksystem und verfahren zur datenübertragung in einem netzwerksystem
US10419226B2 (en) 2016-09-12 2019-09-17 InfoSci, LLC Systems and methods for device authentication
US9722803B1 (en) 2016-09-12 2017-08-01 InfoSci, LLC Systems and methods for device authentication
CN106603519B (zh) * 2016-12-07 2019-12-10 中国科学院信息工程研究所 一种基于证书特征泛化和服务器变迁行为的ssl/tls加密恶意服务发现方法
US11463439B2 (en) 2017-04-21 2022-10-04 Qwerx Inc. Systems and methods for device authentication and protection of communication on a system on chip
WO2019045914A1 (en) * 2017-09-01 2019-03-07 InfoSci, LLC DEVICE AUTHENTICATION SYSTEMS AND METHODS
US11729160B2 (en) * 2019-10-16 2023-08-15 Nutanix, Inc. System and method for selecting authentication methods for secure transport layer communication

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5995625A (en) * 1997-03-24 1999-11-30 Certco, Llc Electronic cryptographic packing
US6058484A (en) * 1997-10-09 2000-05-02 International Business Machines Corporation Systems, methods and computer program products for selection of date limited information
US7581011B2 (en) * 2000-12-22 2009-08-25 Oracle International Corporation Template based workflow definition
US20070204078A1 (en) * 2006-02-09 2007-08-30 Intertrust Technologies Corporation Digital rights management engine systems and methods
EP2053531B1 (de) * 2007-10-25 2014-07-30 BlackBerry Limited Verwaltung von Authentifizierungszertifikaten für den Zugang zu einer drahtlosen Kommunikationsvorrichtung
US9973491B2 (en) * 2008-05-16 2018-05-15 Oracle International Corporation Determining an identity of a third-party user in an SAML implementation of a web-service
DE102009031817A1 (de) * 2009-07-03 2011-01-05 Charismathics Gmbh Verfahren zur Ausstellung, Überprüfung und Verteilung von digitalen Zertifikaten für die Nutzung in Public-Key-Infrastrukturen
US8522335B2 (en) * 2009-12-01 2013-08-27 International Business Machines Corporation Token mediation service in a data management system
DE102010044517A1 (de) 2010-09-07 2012-03-08 Siemens Aktiengesellschaft Verfahren zur Zertifikats-basierten Authentisierung

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0", 10 August 2010 (2010-08-10), pages 1 - 24, XP055016600, Retrieved from the Internet <URL:http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso.pdf> [retrieved on 20120116] *
CANTOR, SCOTT ET AL: "An X.509 Binding for SAML", 17 January 2007 (2007-01-17), pages 1 - 2, XP002667165, Retrieved from the Internet <URL:https://spaces.internet2.edu/display/GS/X509BindingSAML> [retrieved on 20120116] *
FARRELL TRINITY COLLEGE DUBLIN R HOUSLEY VIGIL SECURITY S TURNER IECA S: "An Internet Attribute Certificate Profile for Authorization; rfc5755.txt", AN INTERNET ATTRIBUTE CERTIFICATE PROFILE FOR AUTHORIZATION; RFC5755.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 25 January 2010 (2010-01-25), pages 1 - 50, XP015068164 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9432198B2 (en) 2010-09-07 2016-08-30 Siemens Aktiengesellschaft Method for certificate-based authentication

Also Published As

Publication number Publication date
EP2594047A1 (de) 2013-05-22
US9432198B2 (en) 2016-08-30
US20130173914A1 (en) 2013-07-04
DE102010044517A1 (de) 2012-03-08
CN103109508A (zh) 2013-05-15
CN103109508B (zh) 2016-10-19

Similar Documents

Publication Publication Date Title
WO2012031821A1 (de) Verfahren zur zertifikats-basierten authentisierung
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
AT513016B1 (de) Verfahren und Vorrichtung zur Steuerung eines Schließmechanismus mit einem mobilen Endgerät
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
EP3287925B1 (de) Computervorrichtung zum übertragen eines zertifikats auf ein gerät in einer anlage
EP2593897B1 (de) Verfahren zur zertifikats-basierten authentisierung
DE102011081804B4 (de) Verfahren und System zum Bereitstellen von gerätespezifischen Betreiberdaten, welche an ein Authentisierungs-Credential gebunden werden, für ein Automatisierungsgerät einer Automatisierungsanlage
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
DE102015220228B4 (de) Verfahren und System zur Absicherung einer erstmaligen Kontaktaufnahme eines Mobilgeräts mit einem Gerät
WO2008022606A1 (de) Verfahren zur authentifizierung in einem automatisierungssystem
EP3935808B1 (de) Kryptographisch geschütztes bereitstellen eines digitalen zertifikats
EP1468520B1 (de) Verfahren zur datenverkehrssicherung in einer mobilen netzumgebung
DE60219915T2 (de) Verfahren zur Sicherung von Kommunikationen in einem Computersystem
EP3288215A1 (de) Verfahren und vorrichtung zur ausgabe von authentizitätsbescheinigungen sowie ein sicherheitsmodul
EP3881486B1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar
EP4115584B1 (de) Gesicherter und dokumentierter schlüsselzugriff durch eine anwendung
EP3906653B1 (de) Verfahren zum ausstellen einer kryptographisch geschützten authentizitätsbescheinigung für einen benutzer
DE102017220493A1 (de) Verfahren und Vorrichtung zur Behandlung von Authentizitätsbescheinigungen für Entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen Zertifikaten
WO2023194051A1 (de) Ausbilden einer kryptographisch geschützten verbindung
EP4216489A1 (de) Verfahren zur änderung eines ist-zugangsschlüssels in einem feldgerät der automatisierungstechnik
DE102020202879A1 (de) Verfahren und Vorrichtung zur Zertifizierung eines anwendungsspezifischen Schlüssels und zur Anforderung einer derartigen Zertifizierung
EP4179758A1 (de) Authentisierung eines kommunikationspartners an einem gerät
EP3809661A1 (de) Verfahren zur authentifizierung einer clientvorrichtung bei einem zugriff auf einen anwendungsserver
EP4030321A1 (de) Authentifizierung von mindestens einem ersten gerät bei mindestens einem zweiten gerät
WO2023217645A1 (de) Abgesichertes zugriffssystem

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180043126.1

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11741165

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2011741165

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011741165

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13820811

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2013115292

Country of ref document: RU

Kind code of ref document: A