DE102017210721A1 - Method and communication system for the efficient establishment of a secure data connection between a client computer and a server computer - Google Patents

Abstract

The invention essentially relates to a method for the efficient establishment of a secure data connection between a TLS client computer and at least one TLS server computer with application programs, in which the client computer first authenticates itself to a server computer for identification and access management, wherein the authentication and access management server computer after authentication sends encoded TLS session state information to the TLS client computer as a token in which the TLS client computer decodes the TLS session state information and on the TLS client computer establishes a corresponding session state and in which, via a TLS handshake between the TLS client computer and the at least one TLS server computer with application programs with an authentication and a mutual key assignment, based on the TLS session state information, a TLS session resumption causes and a corresponding kryp tographically protected data connection is established. This can reduce the connection establishment time for the respective IoT services and the energy consumption for communication, authentication and key agreement. A separation of the authentication and authorization for the service access from the actual security of the communication channel is particularly advantageous when using embedded systems, eg in the context of IoT. The method is particularly suitable for simple, z. B. battery-powered devices in industrial application scenarios.

Description

The invention relates to a method for the efficient establishment of a secure data connection, in which an access from a client computer to an Internet service takes place with a server-side TLS authentication and in which the client authenticates itself with a token issued by an IAM service.

An access from a client machine, e.g. an IoT device, an Internet service is usually done with a server side TLS authentication and the client authenticates with a token, e.g. a JSON Web token issued by an IAM service.

"TLS" means Transport Layer Security and is a hybrid encryption protocol for secure data transmission over the Internet, which is also known under its predecessor Secure Sockets Layer (SSL). "IAM" means identity and access management in computer security that allows the right individuals to access the right resources at the right time and with the right rationale. A "JSON Web Token (JWT)" is a JSON based and according to RFC 7519 standardized access token. JSON Web Token (JWT) is a lightweight, URL-safe means of representing claims to be transferred between two parties. It is used to verify claims.

The client authentication is usually done via an HTTP protocol. The client transmits the client token for HTTP requests. Typically, the HTTP request, which contains a client token, is transmitted protected by the TLS protocol and can therefore be assigned to the HTTPS request tamper-proof). Here, in addition to the traditional approach of unilateral server authentication, client-based authentication and authorization is also used, e.g. out-of-band or over another communication channel, regardless of the TLS connection setup. The network access can be e.g. via Ethernet, WLAN or a mobile network. In this environment, there is a need for improved authentication. In particular, there is a need to provide an Internet-aware type of client authentication to Internet services, particularly for simple, e.g. to improve battery powered devices.

It is known to protect access to Internet services with server side TLS authentication and JSON web token (JWT) based client authentication. A server is authenticated by a digital certificate (one-sided TLS authentication). The client can then authenticate in an application protocol, e.g. by a password (e.g., HTTP Digest) or by a security token (JSON Web Token), which it transmits as part of an HTTP or CoAP message. The security token is provided by an IAM server after successful client authentication against the IAM server. Such a solution is widely used on the Internet. However, it is only usable if the IAM server is available for the corresponding client request. Therefore, such an approach is not always applicable in industrial application scenarios.

Are known methods for authentication and authorization between two communication participants. These scenarios are typical Web scenarios in which a client accesses a server directly.

The TLS protocol (RFC 5246) describes options for server-side authentication or even mutual (client / server) during the negotiation of the security parameters for a session. TLS is generally expandable in terms of the handshake, but also in the record layer.

"TLS Extensions", describes the general approach to extend the TLS handshake, as well as some concrete extensions.

A so-called "client session state ticket" is described in RFC 5077 (https://tools.ietf.org/html/rfc5077) and enables the outsourcing of the security state of the TLS server to the client in order to establish a connection using session resumption in particular, to reduce the amount of data held to already running sessions on the TLS server.

"Kerberos TLS" (https://tools.ietf.org/html/rfc2712) defines the use of Kerberos tickets in TLS to authenticate client and server. The prerequisite is a security relationship between TLS Server and Kerberos Server, in order to protect server-specific tickets with a shared secret. The client requests a ticket from Kerberos server and uses it in the TLS handshake to establish the premaster secret.

"EAP-TLS" (https://tools.ietf.org/html/rfc5216) defines a procedure in which TLS is tunneled for authentication in EAP. In this case, mutual authentication and also a key negotiation for potentially additional services can be realized.

The "Token Binding Protocol",
(https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11) defines extensions to bind long-lived tokens to TLS sessions. These more durable tokens are essentially asymmetric key pairs generated by the client. It can be established tokens that are used with the same server. However, it is also possible to generate tokens that are used with other servers.

Furthermore, the following methods for authentication and authorization between two communication participants via a third party, so another server known:
EAP-TTLS (https://tools.ietf.org/html/rfc5281) defines a procedure in which TLS is tunneled up to an Access Server for authentication by EAP. In this case, mutual authentication and also a key negotiation for potentially additional services can be realized.

"JSON Web Token" or "JWT"
(https://tools.ietf.org/html/rfc7519) describes a generic approach to describe claims as JSON objects. These can then be protected by JWS (Signature) and JWE (Encryption). A JWT consists of 3 fragments separated by a ".": Header.Payload.Signature.

From the patent application US2012042160A1 For example, a method is known in which key negotiation for TLS is supported by an authentication server. It has contact with both the client and the server during connection setup to support the negotiation of the session parameters.

The object underlying the invention is now to provide a method and a communication system for efficiently establishing a secure data connection between a client computer and a server computer, in which the above-mentioned disadvantages are avoided and in which the connection time for the server Services and energy needs for communication, authentication and key agreement.

This object is achieved in terms of the method by the features of claim 1 and in terms of the communication system by the features of claim 5 according to the invention. The further claims relate to preferred embodiments of the invention.

The invention essentially relates to a method for the efficient establishment of a secure data connection between a TLS client computer and at least one TLS server computer with application programs, in which the client computer first at a server computer for identification and access management (IAM Server), in which the authentication and access management server computer sends, after authentication, encoded TLS session state information to the TLS client computer as a token at which the TLS client computer decodes and asserts the TLS session state information the TLS client computer establishes a corresponding session state and in which a TLS handshake between the TLS client computer and the at least one TLS server computer with application programs with authentication and mutual key assignment, based on the TLS session state information causes a TLS session recovery and an appropriate appropriate cryptographically protected data connection is established. In a variant, the client is further sent a mapping information that assigns the sent token identification information of the TLS server computer. The assignment information may e.g. an IP address, a DNS name or a URL. This allows the TLS client computer before connecting to the TLS server to check that the provided token is actually assigned to the addressed TLS server computer. Furthermore, the server computer for identification and access management can provide a plurality of tokens, each with a TLS server allocation information. Furthermore, in a variant, the TLS client computer can provide the server computer for identification and access management with a single or a plurality of identification information from TLS server computers, for each of which a token is requested.

In essence, the actual handshake between the client and the server is affected by an IAM server in which the token information is provided by it. This can reduce the connection establishment time for the respective IoT services and the energy consumption for communication, authentication and key agreement. In addition, a centrally defined security Policy in terms of the chosen procedures and keys are enforced more easily consistent, since both the client and the server, the parameters are given. A separation of the authentication and authorization for the service access from the actual security of the communication channel is particularly advantageous when using embedded systems, eg in the context of IoT. The method is particularly suitable for simple, z. B. battery-powered devices in industrial application scenarios.

The invention will be explained in more detail with reference to embodiments shown in the drawing.

• 1 ein Ablaufdiagramm zur Erläuterung des erfindungsgemäßen Verfahrens,
• 2 eine Prinzipdarstellung zur Erläuterung der Bereitstellung eines 3rd Party Token für eine TLS Session Resumption und
• 3 zeigt eine Prinzipdarstellung für ein Anwendungsbeispiel mit einem 5G-Mobilfunksystem und einem Netzzugangsserver mit einem Mobile Access Gateway und einem IAM-Server.

It shows

• 1 a flow chart for explaining the method according to the invention,
• 2 a schematic diagram for explaining the provision of a 3rd party token for a TLS Session Resumption and
• 3 shows a schematic diagram for an application example with a 5G mobile radio system and a network access server with a Mobile Access Gateway and an IAM server.

The TLS protocol offers the possibility of rebuilding a previously successfully established and degraded session (session resumption). This is more efficient than a full reconnect.

1. 1. Nativ nach RFC 5246 speichern TLS Client und Server den Session Status incl. der assoziierten Security Parameter. Erlaubt es die Security Policy des Servers, kann ein Client eine schon abgebaute Session mit dem Server basierend auf dem alten Sitzungskontext wieder aufbauen. Dabei wird ausgenutzt, dass beide Seiten auf den zuvor ausgehandelten Sitzungsschlüssel zugreifen können und damit eine Bindung an die erste Session existiert. Wird eine Session resumed, wird keine Authentisierung der beiden Seiten durchgeführt.
2. 2. Mittels RFC 5077 kann ein TLS-Server den Session State auch in einem Ticket gesichert speichern und an den Client senden. Die Sicherung wird über eine Verschlüsselung des Tickets mit einem, nur dem Server bekannten, Key realisiert. Der Server sendet dieses Ticket an den Client und kann damit bei Abbau der Verbindung die zugehörigen Sitzungsschlüssel bzw. den kompletten Kontext der Verbindung löschen. Will der Client die Verbindung wieder re-etablieren, sendet er das Ticket an den Server, der dieses entschlüsselt und seinen Sitzungskontext wiederherstellt, sofern es seine Security Policy. Der RFC 5077 definiert dabei nicht das Format des Token, sondern nur seinen Inhalt.

This TLS feature - Session Resumption - is typically used in two ways:

1. 1. Native to RFC 5246, TLS client and server store the session status including the associated security parameters. If the security policy of the server permits, a client can rebuild an already degraded session with the server based on the old session context. It is exploited that both sides can access the previously negotiated session key and thus a binding to the first session exists. If a session is resumed, no authentication of both sides is performed.
2. 2. Using RFC 5077, a TLS server can store the session state in a ticket and send it to the client. The backup is realized by encrypting the ticket with a key known only to the server. The server sends this ticket to the client and can thus delete the associated session key or the complete context of the connection when disconnecting. If the client wants to re-establish the connection, it sends the ticket to the server, which decrypts it and restores its session context, as long as it has its security policy. The RFC 5077 does not define the format of the token, but only its content.

These two approaches known in the art are based on an existing master key.

The advantage of both approaches is that you can dispense with the asymmetric crypto operations and the TLS Handshake is shortened. Likewise, the verification of certificates on client and server side is eliminated.

In the invention, an alternative, flexible variant is used to set up a "TLS session state".

1 shows a flowchart for explaining the method according to the invention, wherein a client computer in the form of a field device FD, a server with a service IoT service and an IAM server, for example. A network access server, with a service IAM service are available.

The field device FD authenticates itself to the service IAM service and this service sends, for example, a JWT-coded, TLS session state back to the field device FD. The field device receives the TLS session state information in a form decodable for the field device (eg encrypted with a key between the field device and the IAM service) and in a form decodable for the IoT service (eg encrypted with a key between the IoT service and the IAM service), which is sent by the field device and the IoT service as part of the TLS handshake.

The TLS server session state can optionally also be sent to the service IoT service. The TLS server session state provided to the TLS server can be identical to that of the field device FD be provided session state or he may be assigned to this (but eg be formatted differently or have additional information, such as the client assigned permissions).

In the field device FD, the JWT-coded TLS session state is decoded, and then between the field device FD and the service IoT service, a TLS handshake with authentication and key agreement for session resumption takes place.

Finally, a cryptographically protected data exchange takes place between the field device FD and the service IoT service based on TLS.

For this purpose, a TLS session state information is transferred to the TLS client via a security token, in particular a JSON web token (JWT). This security token is then used to establish a TLS connection via the "TLS Session Resumption" mechanism known per se. As a result, the TLS protocol itself does not have to be extended or adapted.

A client node thus receives from the IAM server, after authentication with respect to an IAM server, at least one TLS session state information for another TLS server. The session resumption state (session resumption state) is therefore not, as in the prior art, set up by the actual TLS server itself, but by the IAM server.

Preferably, a so-called "Stateless TLS Session Resumption" according to RFC5077, in which TLS server IoT service does not need to hold state, but determines the server state from the provided by the client encrypted SessionTicket information.

The client-provided SessionTicket information is preferably in the JWT-encoded TLS Session State Information provided by the IAM service.

Since a TLS session state information for a TLS connection can be set up independently of the TLS connection to which the session state information relates, greater flexibility is achieved. In particular, an IoT server for IoT nodes may set the session state for one or a plurality of TLS connections to IoT backend services. This will reduce call setup time and power consumption on the IoT node.

The provision of the token by the IAM server can also centrally enforce a specific security policy for the protection of the communication links, as the session state contains the used cipher suites and keys.

Furthermore, the communication effort for a TLS connection setup is reduced. This is particularly advantageous in narrowband communication technologies (e.g., IEEE 802.15.4, 6LoWPAN, cellular IoT).

After all, less energy is needed for communication and for authentication and key agreement, reducing power consumption. This is particularly advantageous in IoT devices that are powered by a battery or by energy harvesting.

The backend IAM system can be implemented as a server or as a cloud service.

2 shows a schematic diagram for explaining the provision of a 3rd party token for a TLS Session Resumption.

The client C1 logs on to the network access server NZS and authenticates using a public key PubK_c1.
After successful login of the client C1 at the network access server NZS done by the client C1 a request for a token T-C1-AS1 for the application server AP1 ,

Is the client C1 are authorized by the network access server NZS Two tokens for access to the application server AP1 generated and the client C1 cleverly.

In the example shown, the network access server takes over NZS thus the tasks of an IAM server. In another variant, network access servers NZS and the IAM server also be two separate instances.

Likewise, the network access server NZS additional security tokens during the network login of the client C1 at the network access server NZS provide, eg for a second application server AP2 , This can be a resource-limited client node C1 eg a battery powered IoT device, efficiently with a plurality of application servers, eg. AP1 . AP2 , communicate safely. The power consumption for building multiple TLS connections is reduced.

For example, a client C1 can set up an IPsec tunnel (VPN) to a network access server NZS during the establishment of the network access by means of a MOBIKE authentication protocol. The client C1 can authenticate itself here for example by means of EAP-TLS, EAP-AKA or EAP-SIM within MOBIKE.

Optionally, according to the invention, the security tokens can be sent to the client via the MOBIKE protocol C1 to be provided.

3 shows a schematic diagram for an application example with a 5G mobile radio system and a network access server with a Mobile Access Gateway and an IAM server. The figure shows a variant in which the network access system is given by a 5G mobile radio system with a Mobile Access Gateway and an IAM server (AAA server, Home Subscriber Server). As part of the network logon to a mobile access gateway using a 5G SIM for client authentication here the client security tokens are provided for accelerated TLS connection to application servers.

An IAM server or a separate network access server NZS for authentication of a client C1 , provides the client at least one security token T-C1-AS1 for a TLS session resumption with at least one application server AP1 out. Using the session state information SS_NZS-AP1, which is contained in the provided security token, the client can use a shortened TLS Session Resumption with these application servers AP1 and AP2 carry out. As the application server AP1 he gets the security token in the TLS handshake, he can also reconstruct the session state.

The network access server NZS puts the client C1 In this embodiment, two tokens.

A first token T-C1-AS1, with which the client C1 according to the invention locally in the client TLS Session context with an application server AP1 manufactures.

A second token T-AS1-C1, with which the application server AP1 one TLS Session context with a client C1 manufactures. This is a SessionTicket, which is the client C1 as part of the TLS handshake (ClientHello [T-AS1-C1], ServerHello) to the TLS server AP1 transfers.

This second token may be included in the first token or provided separately.

The tokens used are typically coded (ASN.1, XML, JWT,...) And can optionally have a cryptographically secured communication connection between the IAM server and the network access server NZS and the client C1 be transported.

Optionally, tokens can also be encrypted with an endpoint-specific asymmetric key, e.g. T-C1-AS1 with an X.509 certificate (using public-key encryption, for example by means of RSA) of the client C1 and the second token T-AS1-C1 with an RSA certificate of the application server AP1. Other existing methods such as XMLDIGSig and XMLEnc can be used with XML coded tokens.

In the case of JWT, mechanisms such as JWE can be used to encrypt the token.

Alternatively, a symmetric encryption key can be used. Again, the information is backed up with endpoint-specific keys.

The client now wants to connect to the application server AP1 first, the TLS Session cache at the client C1 updated with the parameters from the token T-C1-AS1.

After that, the client can C1 in the TLS handshake, use the second token T-AS1-C1 to start a session with the application server AP1 manufacture. For both sides, the session appears as a continuation of an earlier session, whereby the authentication of the two communication partners C1 and AP1 via the network access server NZS was carried out. Likewise, the basic key material was made by the network access server NZS provided. Based on this key material, a new session key is now negotiated for the new session.

In the following, a session resumption in TLS via a 3rd party token, ex. JWT, described in more detail, which according to RFC 5077 session resumption between client and server based on a issued by the server token (ticket) is known per se.

Initial Handshake (RFC 5077, Section 3.1): client server ClientHello (empty SessionTicket extension) --------> ServerHello (empty SessionTicket extension) Certificate * ServerKeyExchange * Certificate Request * <-------- Server Hello Done Certificate * ClientKeyExchange CertificateVerify * [ChangeCipherSpec] finished --------> NewSessionTicket [ChangeCipherSpec] <-------- finished Application Data <-------> Application Data

Resumed Handshake (RFC 5077, Section 3.1): client server client Hello (Session Ticket extension) --------> server Hello (empty session ticket extension) NewSessionTicket [ChangeCipherSpec] <-------- finished [ChangeCipherSpec] finished --------> Application Data <-------> Application Data

 struct {
 opaque key_name[16];
 opaque iv[16];
 opaque encrypted_state<0..2^16-1>;
 opaque mac[32];


 } ticket;

RFC 5077 already proposes a format for the token (ticket) in Section 4 (proposal, unspecified):

 struct {struct
 opaque key_name [16];
 opaque iv [16];
  opaque encrypted_state <0..2 ^ 16-1>;
 opaque mac [32];


 ticket; 

 struct {
     ProtocolVersion protocol_version;
     CipherSuite cipher suite;
     CompressionMethod compression method;
     opaque master secret[48];
     ClientIdentity client_identity;
     uint32 timestamp;
 } StatePlaintext;
 enum {
     anonymous (0),
     certificate_based (1),
     psk(2)
 } ClientAuthenticationType;
 struct {
     ClientAuthenticationType client authentication_type;
     select (ClientAuthenticationType) {
     case anonymous: struct {};
     case certificate based:
          ASN.1Cert certificate_list<0..2^24-1>;
     case psk:
          opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
     } ;
 } ClientIdentity;

Here, the actual information about the session context is encoded in encrypted_state.

 struct {struct
     Protocol Version protocol_version;
     CipherSuite cipher suite;
     CompressionMethod compression method;
     opaque master secret [48];
     ClientIdentity client_identity;
     uint32 timestamp;
 } StatePlaintext;
 enum {
     anonymous (0),
     certificate_based (1),
     PSK (2)
 } ClientAuthenticationType;
 struct {struct
     ClientAuthenticationType client authentication_type;
     select (ClientAuthenticationType) {
     case anonymous: struct {};
     case certificate based:
          ASN.1Cert certificate_list <0..2 ^ 24-1>;
     case psk:
          opaque psk_identity <0..2 ^ 16-1>; / * from [RFC4279] * /
     };
 } ClientIdentity; 

The actual handshake between the client C1 and the server AP1 or AP2 is inventively influenced by a third server NZS, in which the token information [T-AS1-C1] and [T-C1-AS1] is provided by this.

Deviating from RFC 5077, the structure of the token must be known to all parties involved, or at least between the network access server and the respective communication partner. The token from RFC 5077 is generated by the server and evaluated again by it. So it does not have to be interoperable.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 2012042160 A1 [0015]

Claims (8)

Method for the efficient establishment of a secure data connection between a TLS client computer (FD, C1) and at least one TLS server computer with application programs (IoT_Service, AP1), in which the client computer first authenticates with a server computer for identification and access management (IAM_Service, NZS), in which the server computer for identification and access management after authentication sends a coded TLS session state information to the TLS client computer, - In which the TLS client computer decodes the TLS session state information and establishes a corresponding session state on the TLS client computer and - In the case of a TLS handshake between the TLS client computer (FD, C1) and the at least one TLS server computer with application programs (IoT_Service, AP1) with authentication and mutual key assignment, based on the TLS Session state information causes a TLS session recovery and a corresponding cryptographically protected data connection is established. Method according to Claim 1 in which, after the authentication, the server computer for identification and access management (IAM_Service, NZS) also sends the encoded TLS session state information to the TLS server computer with application programs (IoT_Service, AP1). Method according to Claim 1 in which a cryptographic key is used between the identification and access management server computer (IAM_Service, NZS) and a TLS client computer (FD, C1) to encrypt the TLS session state information. Method according to Claim 1 or 2 in which a cryptographic key is used between the identification and access management server computer (IAM_Service, NZS) and a TLS server computer to encrypt the TLS session state information. Method according to Claim 1 or 2 in which the TLS session state information is transferred to the TLS client computer (FD, C1) via a security token. Method according to Claim 5 in which the server for identification and access management (IAM_Service, NZS) provides the security token in the form of a JSON web token containing a JWT-encoded TLS session state information. Communication system with a client computer (C1), at least one application server (AP1, AP2) and a network access server (NZS) in which the client computer (C1) is present in such a way that it first authenticates with a server computer for identification and access management (IAM_Service, NZS) and, after authentication, receives from the latter a coded TLS session state information, that it decodes the TLS session state information and establishes a corresponding session state with it, and - That he causes a TLS session recovery using a TLS handshake with at least one TLS server computer with application programs (IoT_Service, AP1) based on the TLS session state information and establishes a corresponding cryptographically protected data connection. Communication system after Claim 7 in which the network access server (NZS) has a Mobile Access Gateway (MAG) and an IAM server (IAM (AAA) connectable thereto) and the client has a 5G SIM card for communication with the Mobile Access Gateway (MAG) ,

Images