DE102017211267A1 - Method for protecting a certificate request of a client computer and corresponding communication system - Google Patents

Abstract

The invention generally relates to a method for protecting a certificate request of a client computer, in which the client computer requests a security token from an IAM server, in which the computer for identification and access management has client-specific attributes for a certificate signature request and optionally creates additional attributes for insertion into the certificate, where the IAM server sends a security token to the client machine containing the client-specific attributes and optionally also the additional attributes where the client computer uses the Security token generates a keypair and thus sends a protected certificate sign-on request to the registration / certification computer at which the registration / certification computer performs a signature validation and an authorization verification based on the protected certificate sign-on request Optionally extract the additional attributes for insertion into the certificate, generate the certificate and send it as a protected response to the client machine, where it is stored. The digital certificates can be issued fully automated yet protected. The invention is particularly advantageous in industrial application scenarios in which an IAM solution established on the Internet for device authentication is used in order to protect (authorize) a digital certificate for the devices (eg field device, IoT device). The devices can use the digital certificate for authentication even if the IAM server is currently not available.

Description

The invention relates to a method for protecting a certificate request of a client computer, in which the client computer generates a key pair and thus sends a protected certificate signature request to a registration / certification computer and in which the registration / certification computer a Validate the signing and verify the authorization, generate the certificate and send it as a protected response to the client machine, where the certificate is then stored.

An access from a client machine, e.g. an IoT device, an internet service is usually done with a server-side TLS authentication, the client having a token, e.g. a JSON Web token authenticated by an IAM service. The client authentication usually takes place via an HTTP protocol above the TLS channel. The client transmits the client token for HTTP requests. 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.

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. Therefore, such an approach is not always applicable in industrial application scenarios.

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

Methods for authentication and authorization between two communication participants are known per se. 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 also mutual (client / server) authentication during the negotiation of the security parameters for a session as part of the handshake phase of the protocol. Within the TLS protocol, not only a server but also a client can authenticate by means of a digital certificate (mutual authentication, mutual authentication).

Furthermore, methods for authentication and authorization between two communication participants via a third are known.

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

RFC 2698 (PKCS # 10, Certificate Signing Request (CSR)) defines the format for a certificate request. It is possible to send a password, which is used to authorize the certificate request.

Certificate Request Message Format (CRMF) 4211 describes another format for certificate requests. With this format it is possible to use different "controls" to influence the certificate creation. As controls, different approaches are defined by the standard: a password (for Authorization), an authenticator (for a non-cryptographic check) and other data concerning the request. The controls used are not encrypted and integrity protection of the information is not described.

Also known are different solutions for enrollment of certificates. Examples are Simple Certificate Enrollment Protocol (SCEP), Enrollment over Secure Transport (EST) or Certificate Management Protocol (CMP). Common to all methods is the support of the requestor's authorization. This typically uses a password (in the case of SCEP a one-time password, in the case of EST it is the information for binding to the TLS session, and in the case of CMP a password or an already existing certificate). The applicant receives this password in advance. The CA as the issuing side can use this to reconcile with the security policy.

From the registration US 2012042160 A1 Finally, a method is known in which the key negotiation for TLS is supported by an authentication server. This person has contact with both the client and the server during the connection setup in order to support the negotiation of the session parameters.

The object underlying the invention is now to specify a method for protecting a certificate request of a client computer and a corresponding communication system in which the device communication and the authentication are improved.

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 6 according to the invention. The further claims relate to preferred embodiments of the invention.

The invention essentially relates to a method for protecting a certificate request of a client computer, in which the client computer requests from a computer for identification and access management (IAM server) a security token in which the computer for identification and access management client- generates specific attributes for a certificate signing request and optionally additional attributes for insertion into the certificate where the identification and access management computer sends a security token to the client computer containing the client-specific attributes and optionally also the additional attributes in which the client computer generates a key pair and, with the help of the security token, sends a protected certificate signing request to the registration / certification computer, at which the registration / certification computer performs a signature validation check and a verification check Authorization based on the protected certificate signing request and optionally extracting the additional attributes for insertion into the certificate, generating the certificate and sending it as a secure response to the client computer where it is stored. The digital certificates can be issued fully automated yet protected, as the certificate request message is protected by a security token of an IAM server. The invention is particularly advantageous in industrial application scenarios where an Internet-based device authentication IAM solution is used to provide a digital certificate to the devices (e.g., field device, IoT device) protected. The devices can use the digital certificate for authentication even if the IAM server is currently not available.

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

• 1 ein Ablaufdiagramm zur Erläuterung eines bekannten und
• 2 ein Ablaufdiagramm zur Erläuterung des erfindungsgemäßen Verfahrens.

It shows

• 1 a flowchart for explaining a known and
• 2 a flowchart for explaining the method according to the invention.

1 shows a flowchart for explaining a known method for protecting a certificate request of a client computer, in which a client computer CR a one-time password OTP from a registration / certification calculator RA / CA receives and thus a protected certificate signing request HTTP (PKCSReq.) to a registration / certification computer RA / CA sends 3 , The registration / certification calculator RA / CA then performs signature validation and authorization verification based on the protected certificate signing request, generates the certificate, and sends 4 it as a protected HTTP (PKCSResponse (Cert) response to the client machine CR where the certificate is then saved 5 becomes.

In such a certificate enrollment protocol, a client creates a certificate request message requesting a digital certificate from an issuing PKI (Public Key Infrastructure). The certificate request message contains information about the content of the requested certificate, ie the values of the attributes. It should be protected, which client creates and sends a certificate request message.

The invention thus provides an alternative solution to protect a certificate request message. This is particularly advantageously applicable advantageously in IoT applications and automation applications since fully automatic, i. without user interaction, certificates can be issued for devices. Devices can use these certificates to establish an authenticated communication connection to a server or to a second device independently of an IAM server. This achieves high availability since authenticated connections can be established independently of the IAM server during the validity period of the issued device certificates. Furthermore, the invention is also advantageously applicable to realize a protected device-to-device communication. In this case, both devices, the protected communicate with each other, each independently a device certificate according to the invention. The two devices can use the respective device certificates to establish a mutually authenticated TLS connection with each other protected. It is not necessary for a device to verify an IAM token of the other device. This is advantageous in a large number of devices where, unlike web services or web servers, respectively, a security relationship with an IAM server that is required to establish the validity of security tokens can not be practicably established to check other participants.

2 shows a flowchart for explaining the erfi inventive method for protecting a certificate request a client computer with a client computer CR , a registration / certification calculator RA / CA and a calculator I AM for identification and access management, using the client machine CR from the computer I AM for identification and access management with a request HTTP (TokenReqest) requests a security token 1 and in response HTTP (TokenResponse (JWT)) receives a security token that includes at least client-specific attributes, using the client machine CR a key pair consisting of public key and private key, forming a certificate signing request HTTP (PKCSReq.) that includes the public key as a client-specific attribute and the security token, and associated with the public key generated private key protected certificate signing request HTTP (PKCSReq.) to the registration / certification machine RA / CA sends 3 which in turn performs signature validation and authorization verification based on the protected certificate signing request and the security token contained therein, and then generates the certificate, and the client computer CR then from the registration / certification calculator RA / CA The certificate receives a protected response of HTTP (PKCSResponse (Cert) 4 and stores the certificate 5 ,

The certificate signing request HTTP (PKCSReq.) Is protected by a security token, in particular by a JSON Web Token or a JWT. The certificate signing request HTTP (PKCSReq.) Itself is still protected by the digital signature of the requesting client computer CR protected, which is formed using the generated private key.

The security token is given to a requesting client by one I AM -Server I AM provided when the client CR opposite the I AM Server has authenticated.

The JSON Web Token is preferably by the I AM -Server cryptographically protected, so that it can not be manipulated by the client unnoticed. The security token is transferred from the client to a public key infrastructure or PKI, specifically to a registration authority RA transferred to the PKI and checked there for validity. After successful verification, a digital certificate is created by the PKI, specifically by the Certification Authority CA of the PKI, and made available to the client computer CR.

The security token issued by the IAM server can optionally include information that defines or limits the attributes of the certificate. In particular, the security token may include indications of a device identification (e.g., device type, manufacturer serial number, projected device name) which may then be stored as an attribute, e.g. as a common name, are included in the issued certificate. The RA can also check whether the attributes received from the client in the certificate signing request HTTP (PKCSReq.) Match those specified by the IAM server in the security token or restrictions.

Enrollment protocols such as SCEP and EST use PKCS # 10 to define the structure of a request. PKCS # 10 (RFC 2986) defines the Certificate Signing Request (CSR) as follows:

Das JWT kann optional zusätzlich, im Gegensatz zu einem bekannten Passwort, Attribute des Anfragenden bestätigen oder auch weitere Attribute enthalten. Das bedeutet, dass ein IAM-Server IAM, der das JWT ausstellt, als Teil des JWT eine Information über den Client bestätigen kann, die die RA der PKI bzw. des Registrierungs-/Zertifizierungs-Rechner RA/CA prüft.The attributes can optionally be additional information about the certificate request. In the case of SCEP, the attributes are used to transport a Challenge Password. The challenge password is defined in PKCS # 9 (RFC 2985) as:

The JWT can optionally additionally confirm, in contrast to a known password, attributes of the requestor or also contain other attributes. This means that an IAM server IAM issuing the JWT can, as part of the JWT, confirm information about the client that checks the RA of the PKI or the registration / certification computer RA / CA.

This allows a digital certificate issuing PKI (Registration Authority, Certification Authority) to check the correspondence of the attributes of the certificate request message set by the client with the information of the IAM server IAM contained in the JWT. In particular, this makes it possible for an IAM server issuing a JWT to specify the attribute values or to define permissible value ranges. This enables an automatic check of a certificate request message by a PKI or by the Registration Authority RA of a PKI. These attributes may be e.g. confirm the name or other information of the applicant.

In addition, additional attributes, eg based on a Security Policy Database, can be added to the token via the IAM server as an option. An example is the assignment of roles for Certificate users to support role-based access control. This provides an efficient way to use attributes of an IAM system as the basis for automatically issuing a correct digital certificate.

Das Attribut selbst ist dann im Falle eines JWT die base64-kodierte Information des Claims in „JwtClaim OCTETSTRING“.For example, the syntax required for the token could be defined as follows, with the following example using a JWT and following attribute type extension for PKCS # 9.

The attribute itself is then in the case of a JWT base64 encoded information of the claim in "JwtClaim OCTETSTRING".

The approach shown here of extending a certificate request using PRCS # 10 can thus also be mapped to other definitions of the syntax of a certificate request. In addition to PKCS # 10, RFC 4211 defines the Certificate Request Message Format. In addition to the controls defined here for authentication, the above-mentioned token can also be used.

Conventional long term certificates, e.g. for device authentication or user authentication, but also short-term certificates are issued.

As a result, an IAM application widely used on the Internet can be advantageously used to issue a digital certificate, e.g. is usable for a local, backend-independent device-to-device communication. As a result, in particular, a communication can also be realized if the backend IAM system IAM is not available. The IAM backend system need only be "occasionally" available to issue new short term certificates. Also, the issued certificates can be easily used to protect a direct communication between devices (Device-2-Device Communication).

The backend IAM system can be used as a server or as a cloud service, e.g. Microsoft Azure, Amazon AWS, IBM Bluemix or Siemens Mindsphere running, be realized.

The security token may be a signed token, e.g. XML DigSig or JWS. In addition to the pure authorization information, the token can, for example, contain additional information in plain text or else encrypted (XMLEnc, JWE).

This additional information may e.g. Role information for the requesting client, which can then optionally be encoded as an extension into the certificate. Thus, an authorization information of the client, which is stored in the IAM system, can be transmitted to the PKI via the client tamper-proof, so that the PKI can check the authorization or encode the authorization information into the issued client certificate.

The client computer CR uses the attributes in the PKCS # 10 request in order to send this authorization information of the IAM server IAM to the registration / certification computer RA / CA. The registration / certification computer RA / CA evaluates the information and then creates a certificate with the potential extensions, e.g. the role of the user.

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 [0012]

Claims (6)

Method for protecting a certificate request of a client computer (CR), in which the client computer (CR) requests a security token from a computer (IAM) for identification and access management (1), in which the computer (IAM) for identification and access management generates at least client-specific attributes for a certificate signing request (HTTP (TokenReqest)), in which the computer (IAM) for identification and access management sends in response a security token (HTTP (Token Response (JWT)) to the client computer (CR) (2) which contains at least the client-specific attributes, in which the client computer (CR) generates a key pair in which the security token is integrated, and a certificate signature request (HTTP (PKCSReq.)) protected by the generated private key is sent to a registration / certification computer (RA / CA) sends (3) and in which the Registration / Certification Calculator (RA / CA) performs signature validation and authorization verification based on the protected certificate signing request, generates the certificate and sends it as Protected Response (HTTP (PKCSResponse (Cert)) to the Client computer (CR) sends (4) where the certificate is then stored (5). Method according to Claim 1 in which the computer (IAM) for identification and access management generates additional attributes for insertion into the certificate, in which the computer (IAM) for identification and access management issues a security token (HTTP (TokenResponse (JWT)) to the client Computer (CR) sends (2) containing the additional attributes and - in which the registration / certification computer (RA / CA) extracts the additional attributes for insertion into the certificate. Method according to one of the preceding claims, in which the security token additionally confirms attributes of the requesting client computer. Method according to one of the preceding claims, in which the security token contains additional information with role information for the requesting client computer, which are then coded as an extension into the certificate. Method according to one of the preceding claims, in which the certificate signing request (HTTP (PKCSReq.)) Is protected by a security token in the form of a JSON Web token. Communication system with a client computer (CR), a registration / certification computer (RA / CA) and a computer (IAM) for identification and access management at the client computer (CR) is present such that it requests a security token (HTTP (TokenReqest) from the computer (IAM) for identification and access management, and in response receives a security token (HTTP (TokenResponse (JWT)) containing at least the client-specific attributes, - That he uses the security token generated a key pair and thus a protected certificate signing request (HTTP (PKCSReq.)) to a registration / certification computer (RA / CA) sends, which in turn a validity check of the signature and performs a verification of the authorization based on the protected certificate signing request and generates the certificate, and - That he then receives from the registration / certification computer (RA / CA) the certificate as a protected response (HTTP (PKCSResponse (Cert)) and stores the certificate.

Images