EP3613193A1 - Procédé, dispositifs et produit-programme d'ordinateur pour vérifier des paramètres de liaison d'une liaison de communication protégée de manière cryptographique pendant l'établissement de la liaison - Google Patents

Procédé, dispositifs et produit-programme d'ordinateur pour vérifier des paramètres de liaison d'une liaison de communication protégée de manière cryptographique pendant l'établissement de la liaison

Info

Publication number
EP3613193A1
EP3613193A1 EP18734099.7A EP18734099A EP3613193A1 EP 3613193 A1 EP3613193 A1 EP 3613193A1 EP 18734099 A EP18734099 A EP 18734099A EP 3613193 A1 EP3613193 A1 EP 3613193A1
Authority
EP
European Patent Office
Prior art keywords
communication device
communication
connection
attestation
data structure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP18734099.7A
Other languages
German (de)
English (en)
Inventor
Rainer Falk
Steffen Fries
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Mobility GmbH
Original Assignee
Siemens Mobility GmbH
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 Mobility GmbH filed Critical Siemens Mobility GmbH
Publication of EP3613193A1 publication Critical patent/EP3613193A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0827—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving distinctive intermediate devices or communication paths
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/26—Testing cryptographic entity, e.g. testing integrity of encryption key or encryption algorithm
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the invention relates to a method, a Decunikationssys ⁇ system, a communication device and a monitoring device for checking connection parameters a cryptographically protected communication link between a first communication device and a second communication device during the establishment of kryptogra ⁇ phisch protected communication link.
  • Crypto protected communication protocols like ⁇ play, an IP security protocol IPsec / IKE or the transport layer security protocol TLS, DTLS, QUIC, shakers ⁇ zen data to be transmitted from manipulation and spying. In this case, an authentication of the communication partners and an agreement of a session key.
  • Connection setup via the TLS protocol initiates a first communication device as a so-called TLS client connects to a second communication device, which is referred to as TLS server.
  • the TLS server typically authenticates itself to the TLS client with a certificate.
  • the TLS client checks the trustworthiness of the certificate and checks whether the name of the TLS server, ie its DNS name, matches the name specified in the certificate.
  • the TLS client can also authenticate itself to the TLS server with its own certificate. Then, either the TLS client sends the TLS server a secret random number encrypted with the public key of the TLS server, or the two parties compute a shared secret via a Diffie-Hellman key exchange.
  • a cryptographic key is derived, which is used to encrypt the payload messages of the connection.
  • the TLS protocol is placed in a session layer (layer 5) of the OSI reference model for network protocols, ie above the TCP protocol or UDP protocol.
  • the cryptographically protected Internet Protocol Security IPsec protocol enables secure communication over potentially unsafe Internet Protocol (IP) networks, such as the Internet.
  • IP Internet Protocol
  • Key management is especially the In ⁇ ternet Key Exchange Protocol IKE, preferably used in the version of the second
  • IKE In ⁇ ternet Key Exchange Protocol
  • a device which makes it possible to check supported by a terminal options of a cryptographically protected communication protocol to ⁇ .
  • a communication unit actively initiates a communication connection to the terminal or the communication unit receives an initiation message from the terminal and sets up a test communication.
  • the configura- tion of the communication protocol to be checked on the terminal via ⁇ is checked on the terminal via ⁇ .
  • such an additional construction of a test communication creates additional load on a Kom ⁇ munikationsnetz, as well as on the terminal to be checked.
  • the auditable data is limited to information used in authentication and authentication
  • an object of the present invention is to be able to monitor an extended number of kauspara ⁇ meters, thereby burdening the communication partners and the communication network as little as possible and not endanger the protection of end-to-end transmission.
  • the invention relates to a method for checking connection parameters during the establishment of a cryptographically protected communication connection between a first communication device and a second communication device, with the method steps:
  • the cryptographically protected communication link in accordance with a transport layer security protocol TLS / DTLS / SSL or in ⁇ ternet protocol IPsec security protocol is established and the Attest istskorfigured as an extension of a protocol message, in particular a TLS handshake message or an Internet Key exchange IKE message trained.
  • connection parameters of the first communication connection which initiates the connection setup and is usually referred to as a client
  • connection parameters of the second communication device which is usually referred to as a server
  • the attestation data structure is cryptographically protected by an attestation key.
  • the cryptographically protected te Attest istschal MUST can be, in particular by a cryptographic checksum, in particular a digital signature or thentleiterscode by a cryptographic horrenau- message authentication code (MAC), ge ⁇ protects. It is also possible that the cryptographically protected attestation data structure or individual fields of the cryptographically protected attestation data structure are encrypted.
  • the cryptographic checksum is part of the attestation data structure, ie the attestation data structure consists of an attestation information and a cryptographic attestation checksum.
  • the extracted information is preferably be a copy of the data received from a communication device data structure.
  • the original data structure is preferred to the receiving communication device the communication connection is issued.
  • the attestation key of an evaluation device is provided via a separate connection different from the communication connection.
  • the communication connection is the connection monitored by the method according to the invention.
  • One of these different, separate connections may be one over another data transmission path be guided connection.
  • the separate connection can also use the same data transmission path as the monitored communication connection, but be a separate, logically separate connection.
  • the attestation information is provided by the sending communication device to a storage device, in particular a database or a logging server.
  • the attestation data structure comprises only a reference value and the Attest istsinformation on the Spei ⁇ cher worn is determined on the reference value.
  • the communication link is charged with little additional load.
  • the sending communication device the Attest istsinformation can be deposited over another, for example, a ⁇ be already existing and / or secure connection on a storage cher worn as the aforementioned database or a logging server.
  • the reference value may be a cryptographic hash of the Attestie ⁇ insurance information in particular.
  • predefined measures in particular outputting of a warning signal and / or blocking of the communication connection, are carried out if a deviation from the directive is detected during the check.
  • the invention relates to a Kiru ⁇ nikationssystem for verification of connection parameters during the establishment of a cryptographically protected communication nikationsitati between a first communication device and a second communication device, wherein at least the first and / or second communication device, is configured to send a attestation data structure to the second and / or first communication device, and the Attest istschalfigured at least one connection parameter of the first and / or second communication device as attestation information, comprising:
  • a verification unit designed to check the attestation information against a given policy.
  • a data transmission path is a physical link composed of one or more physical communication links between the first and second communication devices.
  • the physical data transmission path of a logical communication connection may comprise a plurality of data transmission links and transmission components, such as routers, switches or firewalls.
  • a monitoring device extracts the protocol messages from the data within a transmission component or also at an output of a transmission component and extracts therefrom the attestation data structure.
  • the communication system makes it possible to make security-relevant information of the communication devices and the communication connection accessible to third parties.
  • the invention relates to a Kiru ⁇ nikationsvorraum for checking kausparame- tern during the construction of a cryptographically protected
  • Communication link between the communication device and a second communication device comprising a transmitting device, which is designed such, a Kryp- tographically protected attestation data structure containing at least one connection parameter as Attest istsinforma ⁇ tion to send to the second communication device.
  • the communication device thus allows kauspara ⁇ meter, which are used for the currently established communication connection to provide on the communication link itself, so that they can be read for monitoring purposes.
  • the communication device is designed as a client device or as a server device.
  • the invention relates to an over ⁇ wachungsvoriques for verification of connection parameters during the establishment of a cryptographically protected communication link between a first communication device and a second communication apparatus, comprehensively a Mit Anlagenhow which is locatable within the data transmission ⁇ path of the communication link and configured such is to listen in on the attestation data structure and provide the attestation information to a verifier, and a verifier configured to verify the attestation information against a given policy.
  • Listening is a passive process in which the data is copied and that copy is output to the review unit.
  • the original data is output unchanged to the communication partner.
  • Listening in does not change or supplement the original data. Listening does not cause any or one lent short delay time.
  • Attest istsinforma ⁇ tions can be tapped without significantly affecting the original communication link.
  • the monitoring device additionally comprises an enforcement unit, which is designed to perform predefined measures, in particular to output a signal and / or to block the communication connection, if a deviation from the policy is detected during the check.
  • an enforcement unit which is designed to perform predefined measures, in particular to output a signal and / or to block the communication connection, if a deviation from the policy is detected during the check.
  • the invention relates to a Compu ⁇ program product, directly loadable into a memory of a digi tal ⁇ and computer program code portions which are suitable to carry out the steps of the above procedural ⁇ proceedings.
  • Figure 1 shows an embodiment of an inventive
  • Figure 2 shows an embodiment of the method according to the invention as a flowchart
  • Figure 3 shows an embodiment of the inventive method integrated into a TLS handshake as Ab ⁇ flow diagram
  • Figure 4 shows an embodiment of the method according to the invention carried out in a monitoring device as a flowchart
  • Figure 5 shows a first embodiment of a erfindungsge ⁇ MAESS monitoring device in a schematic representation
  • Figure 6 shows a second embodiment of a erfindungsge ⁇ MAESSEN monitoring device in a schematic representation.
  • FIG. 1 shows an example of a communica ⁇ tion system according to the invention, which is formed for example as an automation network with multiple field devices as communication devices FDI, FD2, FD3.
  • the communication devices FD1, FD2, FD3 are connected via a gateway GW and a public network 2 to a back-end server BS, for example an Industrial Internet of Things backend system.
  • the communication devices FD1, FD2, FD3 in particular transmit diagnostic data via a gateway GW to the back-end server BS.
  • a cryptographically protected communication setup by means of a TLS protocol sends the first communication ⁇ tion devices FDL as TLS client in addition to the usually exchanged information tenth structure with at least one connection parameter as Attest michsinformation to the back-end server as a second communication device.
  • the second communication device as TLS server can also send its connection parameters in an attestation data structure to the first communication device.
  • the Attest istskortechnik is sent, for example, as an extension of a message of use ⁇ th TLS protocol or as a separate message via the gateway to the back-end server OS as a TLS server.
  • a monitoring device AMF1 is integrated, which reads out and evaluates the attestation data structure.
  • the gateway GW can verify not involved component reliably example, as the actual connection establishment of protected communication link wel ⁇ ches application program on which communication device initiates the cryptographically protected communication link or terminated.
  • the gate ⁇ way GW check in particular whether the communication connection is established by a shared application on a valid field device with the latest firmware version, and whether the contacted backend service is actually the default service.
  • connection parameters are encoded as attestation information in an attestation data structure and transmitted to the second communication partner FD2 in the same way from the first communication partner FD1 initiating the communication connection.
  • a monitoring device AMF2 disposed within the data transmission path of the communi cation compound ⁇ can overhear this Attest istsda ⁇ ten Modell from the data transmission path and check on ⁇ .
  • the first communication device and / or the second communication device FD1, FD2, FD3, BS send only a reference value of attestation information.
  • the first communication device FD1 transmits the attestation information to a memory device DB, for example via a second protected connection.
  • the certification information is stored there labeled with the same reference value.
  • the reference value can be game, a hash value of the Attest michsinformation at ⁇ .
  • a Uniform Resource Locator URL can play as examples used ⁇ the over which the Attest istsinformation can be determined.
  • the checking unit AMF1, AMF2 can be used on the basis of the Reference value determine the actual Attest michsinformation in the memory device DB and evaluate.
  • the Attest istsinformation can be made available to a logging server loading, also logs all about wearing ⁇ nen news of particular or. Similarly, the attestation ⁇ information an intrusion detection system or a
  • a transport layer security protocol TLS or also its predecessor is, for example gerversion, which will be as secure socket layer protocol SSL ⁇ lines, an Internet Protocol security protocol IP sec to the Internet key exchange protocol IKEv2, or other appropriate protocols.
  • a first communi ⁇ nikationsvorraum sends a Attest istskortechnik, comprising at least one connection parameter of the sending communication device as Attest michsinformation to the second communication device.
  • the first communication device that initiates the structure of the cryptographically protected communication is usually referred to as a client
  • the second communication device that receives the request for a secure communication connection is usually referred to as a server.
  • the second communication device also determines the connection parameters used in the second communication device and sends them as Attest istschal poetic to the first communication device.
  • the Attest istsrtz Modell via the data transmission path to the respective other communi ⁇ nikationspartner transmitted will now be processing in step 12 by a Matterwachungsvorrich-, for example AMF1 or AMF2, coupled in FIG. 1
  • a communication connection that is logically established between the first communication device and the second communication device is physically transmitted through a data transmission path that may be composed of a plurality of partial transmission paths. Cables for a ⁇ ragungsumble is terminated for example by êtskompo ⁇ component, eg. A router or switch. This performs routing functions or other actions, but the actual cryptographically protected communication connection remains unaffected.
  • a monitoring device may for example be formed as part ei ⁇ ner such a transmission component or be incorporated into the transmission path between two transmission components. If the attestation data structure is monitored, the received data or messages are copied and the copy is decoupled for further evaluation. The received data or messages themselves are passed on unchanged over the transmission link.
  • the attestation information is checked against a given policy. See process step 13.
  • predefined measures can be carried out if the check reveals a deviation from the guideline.
  • Connection parameters contained in attestation information are, for example, a used public key of the first communication device or its used certificate, a used public key of the second communication device or its certificate.
  • the first and second communication device can communicate as connection parameters, if and if so, which operations performed for Certificate validation, such as certificate trail validation or validation using a certificate whitelist.
  • a communication device can communicate as a connection parameter whether and with what method it has checked a certificate revocation.
  • the agreed version of the security protocol and / or the negotiated encryption functions, the so-called cipher suite may be included.
  • connection parameters a hash / signature used may algorithm combination for a TLS handshake operation, IP address and port of the TLS clients or IP address and port of the TLS server, the time of connecting, appli ⁇ applications or applications that TLS Connection is established, for example by the identifier, and the version identifier is specified. This affects both the client and the server.
  • connection parameters may be an additional attestation of a local system status, for example a TPM quota, for attesting the current platform configuration for the client as well as the server.
  • TPM Trusted Platform Module
  • a communication device can also confirm, for example, its version or its publisher.
  • the communication device is a gateway for exchanging industrial data, for example an Industrial Data Space Gateway.
  • a firewall at the edge of a corporate network can record and check the attestation data structure.
  • app or service use a data transmission path.
  • Wei ⁇ terhin it is possible that the Attest istsrtz Decor includes identification information of the data to be transmitted. This has the advantage that it is possible to monitor which data is transmitted via the data transmission path.
  • WEI terhin it is possible information about the exchanged data audit-proof, ie to capture storage or paid storage privileged information and spei ⁇ manuals.
  • the attestation data structure is cryptographically protected by an attestation key of the respectively transmitting communication device.
  • the Attest ists slaughterl may for example be the public key of the first BE ⁇ relationship, the second communication device, to the each other's extension during construction of the cryptographically protected connects.
  • the Attest ists slaughterl may for example be the public key of the first BE ⁇ relationship, the second communication device, to the each other's extension during construction of the cryptographically protected connects.
  • this attestation key must be communicated to the supervisor outside the communication link.
  • the logical communication connection between the first and the second communication device FD, BS is via a physical data transmission path of the Automatmaschinesnet ⁇ zes 1 to the gateway GW and from there via an example ⁇ public network 2 to the second communication device led BS.
  • a eavesdropping over ⁇ inspection unit is for example combined in a surveil ⁇ monitoring device arranged AMF.
  • the communication connection is now established, for example, according to the transport layer safety protocol TLS. That in a sogenann ⁇ th TLS handshake, the communication devices are mutually authenticated and negotiated a session key for the cryptographic protection of the subsequent data transmission.
  • This TLS handshake is now extended as follows.
  • the first communication device FD generates in block 20 a Attest istsinformation and encodes it as a Extension C ⁇ tion of an existing TLS message, for example in egg ⁇ ne Client Hello message 21st
  • the first communication device FD or the second communication device BS can support the following extension in the server Hello: struct ⁇
  • the authentication data structure can be integrated as an additional message in the TLS handshake.
  • ⁇ at the Attest istsinformation in the coding is called a "session Attestation”, sent as part of a newly defi ⁇ alternating message type, such as "SESSIONS on_attestation”.
  • the structure of the coded evaluation information as a SessionAttestation can correspond to the above-mentioned data structure.
  • hello_request (0) client_hello (1), server_hello (2), certificate (11), server_key_exchange (12), certificate_request (13), server_hello_done (14), certificate_verify (15), client_key_exchange (16), finished (20), session_attestation (21), (255)
  • HandshakeType msg_type / * handshake type * /
  • case server_key_exchange ServerKeyExchange
  • case certificate_request CertificateRequest
  • case certificate_verify CertificateVerify
  • case client_key_exchange ClientKeyExchange
  • case finished Finished
  • the monitoring device AMF now reads the TLS message as a whole or the Attest michs stylistfigured alone from the Client Hello message 21 and checks it, see block 22. Preferably, also generates the second communica ⁇ tion device BS a Attest réellesinformation, see block 23, with connection parameters, the second communica - Used cation device, orandme ⁇ mechanisms according to the information generated for the first communication device and sends them in a ServerHello message 24 to the first Ltdunikationsvorrich ⁇ device FD. The attestation information is read out and verified by the monitoring device AMF, see block 25. Subsequently, in the further TLS handshake sequence, the public key of the second communication device is sent to the first communication device, and accordingly the public key of the first communication device FD can the second communication device BS are sent.
  • both communication devices confirm with a ChangeCipherSpec that the following message protected using the negotiated security parameters, see message 26.
  • the first Ltdunikationsvor ⁇ direction FD generates a checksum, for example by means of a hash function over all previously exchanged messages. This checksum is included in a key derivation for the actual session key.
  • the second Kommunikati ⁇ onsvortechnisch BS performs the same calculation.
  • both communication devices, FD and BS exchange a final message of the handshake with a finish message 27. This message is encrypted so that both communication devices detected by the use of locally derived session key that they are at Be ⁇ fitting the correct key and implied that all the messages of the handshake were the same on both sides.
  • the monitoring device AMF checks the attestation information against a given policy, the attestation information deviates from the policy, so preferably an alarm signal is generated and / or blocking the further connection setup.
  • the verification of the attestation data structure in the monitoring device AMF is explained in FIG. 4 with reference to a flowchart. The process begins with the start state 30, in which the monitoring device decouples or hears connection establishment messages, such as the TLS messages mentioned. Listening includes
  • the Attestie ⁇ approximate information is then in a check unit checked against a security policy, see 32. Does the Attest michsinformation not the security policy, an error signal is provided readiness, see 33. Does the Attest michsinformation the security policy, so op ⁇ tional in the next step 34, the Message of the second communication device to the first communication device coupled and listened and also checked in step 35 against the security rule.
  • the Attest istsinformation does not match the security policy, an error ⁇ signal 33 is provided.
  • Attestie ⁇ ⁇ insurance information will give comfortablege to an enforcement unit.
  • valid Attestie- be approximately information, for example, evaluated and / or till ⁇ stores, see 36.
  • Error signals according vordefinier ⁇ th measures are implemented. For example, error signals are provided to an associated unit, or blocks the Kom ⁇ munikationsMIS and for example aborted. Thus, the final state 37 is reached.
  • a network component has the functions of a monitoring device is integrated, provided in Figure 5 and Figure 6 represents ⁇ .
  • the network component 40 for example a rou- ter, switch or access point of a communication network receives data 45 of a communication link, for example, in a routing function 41.
  • the routing function 41 contains routing tables through which an output port for Next Tier ⁇ th data transmission path is determined 49, and outputs the data corresponding to on a data link 49 from.
  • the monitoring device AMF picks up the connection set-up messages via a listening unit 47.
  • the listening unit 47 may be formed, for example, as a mirroring port of a network switch or as a one-way communication component such as a data diode.
  • the listened, mirrored in ⁇ play as messages are now passed on to the check unit 42nd There the Attestie ⁇ insurance information is exceeded over a security policy reviewed.
  • the security policies are provided from a policy database 44 of the review unit 42.
  • Security policies may be provided or updated via a connection 46 from a policy database.
  • the checking unit 42 analyzes the messages of the TLS handshake executed in plain text on the existence of an attestation data structure in the client Hello message and / or the server Hello message.
  • the evaluation result ⁇ provides the check unit 42 of a fürset ⁇ wetting unit 43rd This is in accordance with a positive test result, the data unchanged to the REMtra ⁇ transmission link 49 from.
  • an error message 48 from the enforcement ⁇ unit 43 is output.
  • the data output at ei ⁇ ner violation of the Directive can also be blocked.
  • Blocking or locking can ⁇ by done, for example because that network connectivity is interrupted by a network filter policy will be adjusted, that is disabling the corresponding IP address or port number used for the construction of the illegal communication link will be blocked.
  • a connection release message can also be sent to the communication partner.
  • the monitoring device AMF3 thus consists of a listening unit 47, a checking unit 42 and a
  • the monitoring device AMF4 in FIG. 6 comprises a combined listening and checking unit 52, which in turn is integrated in a network component 50.
  • the combined listening and checking unit 52 is formed di ⁇ rectly in the data transmission path.
  • the listening and checking unit 52 performs the same functions as the units 42 and 47 in the network component 40 Enforcing the actions resulting from the review, the monitoring device AMF4 comprises the enforcement unit 43 having the functions as described in Figure 5 for the monitoring device AMF3.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé permettant de vérifier des paramètres de liaison pendant l'établissement d'une liaison de communication protégée de manière cryptographique, entre un premier dispositif de communication (FD) et un second dispositif de communication (BS), ledit procédé comprenant les étapes suivantes : envoyer (11, 20) une structure de données d'attestation qui contient au moins un paramètre de liaison du premier et/ou du second dispositif de communication (FD, BS) en tant qu'information d'attestation, du premier et/ou du second dispositif de communication (FD, BS) au second et/ou au premier dispositif de communication (BS, FD), procéder à l'écoute (12, 22) de la structure de données d'attestation par un dispositif de surveillance (AMF, 47) à l'intérieur d'un chemin de transmission de données de la liaison de communication, vérifier (13, 22) l'information d'attestation par rapport à une directive prédéfinie. L'invention concerne également un système de communication correspondant, un dispositif de communication, un dispositif de surveillance ainsi qu'un produit-programme d'ordinateur pour mettre en oeuvre ledit procédé.
EP18734099.7A 2017-07-20 2018-06-07 Procédé, dispositifs et produit-programme d'ordinateur pour vérifier des paramètres de liaison d'une liaison de communication protégée de manière cryptographique pendant l'établissement de la liaison Withdrawn EP3613193A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017212474.1A DE102017212474A1 (de) 2017-07-20 2017-07-20 Verfahren und Kommunikationssystem zur Überprüfung von Verbindungsparametern einer kryptographisch geschützten Kommunikationsverbindung während des Verbindungsaufbaus
PCT/EP2018/065020 WO2019015860A1 (fr) 2017-07-20 2018-06-07 Procédé, dispositifs et produit-programme d'ordinateur pour vérifier des paramètres de liaison d'une liaison de communication protégée de manière cryptographique pendant l'établissement de la liaison

Publications (1)

Publication Number Publication Date
EP3613193A1 true EP3613193A1 (fr) 2020-02-26

Family

ID=62748914

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18734099.7A Withdrawn EP3613193A1 (fr) 2017-07-20 2018-06-07 Procédé, dispositifs et produit-programme d'ordinateur pour vérifier des paramètres de liaison d'une liaison de communication protégée de manière cryptographique pendant l'établissement de la liaison

Country Status (5)

Country Link
US (1) US20210176051A1 (fr)
EP (1) EP3613193A1 (fr)
CN (1) CN110892695A (fr)
DE (1) DE102017212474A1 (fr)
WO (1) WO2019015860A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3767909A1 (fr) * 2019-07-17 2021-01-20 Siemens Mobility GmbH Procédé et dispositif de communication destiné à la transmission unidirectionnelle de données protégée de maniere cryptographique des données utiles entre deux réseaux
DE102021209579A1 (de) * 2021-08-31 2023-03-02 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Automatisierungssystems mit mindestens einem Überwachungsmodul und Attestierungseinrichtung
WO2023031131A1 (fr) * 2021-08-31 2023-03-09 Siemens Aktiengesellschaft Procédé de fonctionnement d'un système d'automatisation comprenant au moins un module de surveillance et dispositif d'attestation

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7127740B2 (en) * 2001-10-29 2006-10-24 Pitney Bowes Inc. Monitoring system for a corporate network
US20030105952A1 (en) * 2001-12-05 2003-06-05 International Business Machines Corporation Offload processing for security session establishment and control
US6874089B2 (en) * 2002-02-25 2005-03-29 Network Resonance, Inc. System, method and computer program product for guaranteeing electronic transactions
US7289632B2 (en) * 2003-06-03 2007-10-30 Broadcom Corporation System and method for distributed security
CN100391172C (zh) * 2006-01-06 2008-05-28 华为技术有限公司 一种信令监控系统及方法
US8537665B2 (en) * 2009-04-20 2013-09-17 Motorola Mobility Llc Method and apparatus for blocking messages from a sender by a wireless communication device
US8838781B2 (en) * 2010-07-15 2014-09-16 Cisco Technology, Inc. Continuous autonomous monitoring of systems along a path
DE102011078309A1 (de) * 2011-06-29 2013-01-03 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Überwachen eines VPN-Tunnels
US9756527B2 (en) * 2011-10-03 2017-09-05 Intel Corporation Communication devices and flow restriction devices
WO2013131276A1 (fr) * 2012-03-09 2013-09-12 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil destinés à la transmission d'informations de sécurité
MY166563A (en) * 2012-09-07 2018-07-16 Mimos Berhad A system and method of mutual trusted authentication and identity encryption
DE102014222300B4 (de) * 2014-10-31 2024-03-21 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Verfahren zur überprüfung eines vertrauensstatus eines zertifikats oder schlüssels
US9998425B2 (en) * 2015-01-27 2018-06-12 Sonicwall Inc. Dynamic bypass of TLS connections matching exclusion list in DPI-SSL in a NAT deployment
DE102015223078A1 (de) 2015-11-23 2017-05-24 Siemens Aktiengesellschaft Vorrichtung und Verfahren zum Anpassen von Berechtigungsinformationen eines Endgeräts
US10250596B2 (en) * 2016-06-29 2019-04-02 International Business Machines Corporation Monitoring encrypted communication sessions

Also Published As

Publication number Publication date
CN110892695A (zh) 2020-03-17
DE102017212474A1 (de) 2019-01-24
WO2019015860A1 (fr) 2019-01-24
US20210176051A1 (en) 2021-06-10

Similar Documents

Publication Publication Date Title
DE60209475T2 (de) Datensicherungs-kommunikationsvorrichtung und -verfahren
EP3270560B1 (fr) Procede d'etablissement de liaisons de communication securisees avec un systeme d'automatisation industriel et systeme pare-feu
EP3125492A1 (fr) Procede et systeme de fabrication d'un canal de communication sur pour des terminaux
EP1777907B1 (fr) Méthode et dispositifs pour effectuer des opérations cryptographiques dans un réseau type client-server
EP3518492B1 (fr) Procédé et système de divulgation d'au moins une clé cryptographique
DE10392208T5 (de) Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung
EP3562115A1 (fr) Transfert de données protégé utilisant la cryptographie post-quantum
WO2019015860A1 (fr) Procédé, dispositifs et produit-programme d'ordinateur pour vérifier des paramètres de liaison d'une liaison de communication protégée de manière cryptographique pendant l'établissement de la liaison
EP3759958B1 (fr) Méthode, appareil et produit-programme informatique pour la surveillance d'une liaison chiffrée dans un réseau
DE102006060040B4 (de) Verfahren und Server zum Bereitstellen einer geschützten Datenverbindung
DE102015200279A1 (de) Einwegübertragungseinrichtung, Vorrichtung undVerfahren zum rückwirkungsfreien Erfassen von Daten
EP3171570B1 (fr) Dispositif et procédé d'adaptation d'informations d'autorisation d'un terminal
EP3767909A1 (fr) Procédé et dispositif de communication destiné à la transmission unidirectionnelle de données protégée de maniere cryptographique des données utiles entre deux réseaux
EP1468520B1 (fr) Procede de securisation du trafic de donnees dans un environnement de reseau de telephonie mobile
EP1879350A1 (fr) Système informatique distribué avec un réseau local
EP3267619B1 (fr) Procédé de fabrication d'une sécurité intégrée dans un réseau
EP4179758B1 (fr) Authentification d'un partenaire de communication sur un appareil
EP1496665B1 (fr) Procédé de configuration de sécurité dans un réseau d'automatisation
EP3937451B1 (fr) Procédé de génération d'une connexion cryptée
DE102005050047B4 (de) Verfahren, Anordnung und Sicherheitsgateway zur sicheren Authentifizierung und Datenübertragung zwischen zwei Datenverarbeitungseinheiten über mindestens ein Netzwerk
EP3700171A1 (fr) Vérification et confirmation de la configuration de sécurité de l'accès réseau sur un serveur de rendez-vous
DE102022208754A1 (de) Authentifizierungsverfahren
EP3823235A1 (fr) Transfert de données vérifié de manière spécifique à la connexion à l'aide d'une connexion réseau authentifiée de manière cryptographique
WO2020244830A1 (fr) Procédé et système pour surveiller des messages d'une liaison de communication
EP3809661A1 (fr) Procédé d'authentification d'un dispositif client lors d'un accès à un serveur d'application

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191122

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

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

18D Application deemed to be withdrawn

Effective date: 20220104