Commissioning a device via a data connection
The method enables secure device commissioning by allowing initial unencrypted communication to avoid warnings, offering encrypted protocol options and certificate transfer, ensuring secure device setup without user warnings.
Patent Information
- Application Number
- PCT/EP2025/053567
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-02-15
- Filing Date
- 2025-02-11
- Publication Date
- 2025-08-21
AI Technical Summary
Existing methods for commissioning devices via data connections, such as HTTPS, result in user warnings due to missing certificates, compromising security when using unencrypted protocols like HTTP, especially during initial setup.
A method that allows devices to initially communicate unencrypted to avoid user warnings, offering a choice for encrypted communication, and facilitates certificate transfer or upload to establish secure HTTPS connections.
Ensures secure, user-friendly device commissioning by preventing unencrypted data transmission warnings and enabling secure actions without compromising security.
Smart Images

Figure EP2025053567_21082025_PF_FP_ABST
Abstract
Description
[0001] Commissioning a device via a data connection
[0002] The invention relates to a computer-implemented method for commissioning a device via a data connection. Furthermore, a data processing device is proposed, which comprises means for executing said method. The invention further relates to a computer program product, comprising instructions which, when the program is executed by a computer, cause the computer to execute said method.
[0003] In process automation technology, field devices are often used to record and / or influence process variables. Examples of such field devices include level measuring devices, point level measuring devices, and pressure measuring devices with sensors that record the corresponding process variables (level, limit level, or pressure). Typical application scenarios for such field devices include areas such as flood forecasting, inventory management, or other decentralized measurement tasks. Common field devices of the aforementioned type enable the transmission of measured values so that a higher-level unit triggers a predetermined action based on the measured value. For example, based on the measured value of a level measuring device, an inlet can be closed or an outlet opened if a limit value is exceeded.
[0004] Field devices typically have an interface for a data connection. A common example is communication via a two-wire system. A two-wire field device is a field device that is connected to a higher-level unit via two wires, with these two wires carrying both power and measured value transmission. Power and / or signal transmission between such a field device and the higher-level unit typically follows the well-known 4 mA to 20 mA standard, which uses a 4 mA to 20 mA current loop, i.e. a two-wire line, between the field device and the higher-level unit. However, other data connection interfaces are also conceivable, such as a wireless data connection interface or an Ethernet interface. Measurement data from a field device can be read out via a data connection.Some field devices also support remote configuration. A web server application is implemented in some field devices for data access. Communication with field devices is sometimes carried out via the Hypertext Transfer Protocol (HTTP), particularly for management and configuration purposes. The HTTP protocol is a stateless protocol for transferring data at the application layer over a computer network. It is primarily used for transferring web pages. The HTTP protocol does not offer data encryption.
[0005] Secure data transmission is possible via the Hypertext Transfer Protocol Secure (HTTPS). This protocol uses SSL / TLS encryption at the transport layer. A certificate can be used to enable a web browser connecting to a web server to determine the identity of the web server. The certificate is stored in the web browser. It contains a public key. A corresponding private key is stored in the web server, which the web server can use to identify itself to the web browser. It is understood that a web browser on a device cannot store the certificates of all web servers or web services. Instead, web browsers are typically delivered with a limited number of so-called root certificates.When communicating via HTTPS, web browsers accept communication not only with web servers that can identify themselves using root certificates, but also with web servers that can identify themselves using sub-certificates derived from them.
[0006] If a web browser does not have a certificate from a web server, it cannot authenticate the web server via the HTTPS protocol. In this case, web browsers typically behave as follows: When attempting to access the web server via the HTTPS protocol, the user is shown a warning message indicating that authentication has failed. The web browser may also display a message indicating that it does not recognize the website's certificate or its certification authority. For example, the error message "NET: : ERR_CERT_AUTHORITY_INVALID" may be displayed. The user is usually given the opportunity to access the web server anyway. If the user chooses to do so, encrypted access to the web server occurs via the HTTPS protocol.It is possible that a field device or other device is delivered with a certificate that is not stored in a user's web browser and that is not derived from a root certificate pre-installed on the user's device. The user accesses the device for the first time via a network connection to put it into operation. In such cases, the previously described warning message would be displayed in the user's web browser when attempting to establish an HTTPS connection. This behavior is undesirable, as it could cause user insecurity.
[0007] To prevent this, the device could deactivate the delivery of web pages via the HTTPS protocol and instead use only the HTTP protocol. In this case, no warning message is displayed to the user. However, data is transmitted via the HTTP protocol unencrypted. If the user performs a security-relevant action, data is transmitted in plain text and can therefore potentially be viewed by third parties monitoring network traffic. This could pose a security risk if the user sets a new device password for the device via the data connection, or if other confidential data is transmitted between the device and the user.
[0008] The invention is therefore based on the object of providing a secure and user-friendly method for commissioning a device via a data connection. A further object of the invention is to provide a data processing device that enables secure and user-friendly commissioning via a data connection. The invention is further based on the object of providing a computer program product with which the method can be carried out or the device can be operated.
[0009] The problem is solved by the computer-implemented method according to claim 1, the device according to claim 14, and the computer program product according to claim 15. The dependent claims relate to optional embodiments of the invention. It is pointed out that the features listed in the independent and dependent claims can be combined with one another in any way, provided this is technically reasonable. This also applies across claim categories and even if a claim is not dependent on another claim. The description further characterizes and specifies the invention, particularly in connection with the figures. The features contained in the description can also be freely combined with one another, provided this is technically reasonable. Insofar as elements with numerals such as "first," "second," etc., are used in the claims or the description,are provided, the numbers only serve to make the elements distinguishable, but do not make any statement about an order, a total number or other characteristics of the elements.
[0010] According to a first aspect of the invention, a computer-implemented method for commissioning a device via a data connection is proposed, comprising the steps of: receiving a first request from a remote station via an unencrypted data transmission protocol, communicating with the remote station via the unencrypted data transmission protocol to establish whether the remote station wishes to operatively use the device via an encrypted data transmission protocol, and, if the remote station communicates that it wishes to operatively use the device via the encrypted data transmission protocol, transmitting a certificate associated with the encrypted data transmission protocol, and, after the transmission of the certificate, performing a security-relevant action via the encrypted data transmission protocol based on the transmitted certificate.
[0011] According to the invention, the remote station can be a terminal operated by a user. The terminal can be a personal computer, a smartphone, a tablet, or the like. According to the invention, access to the device is initially unencrypted. This prevents a warning message from being issued in a user's client application, for example, in a web browser, due to a missing certificate. According to an advantageous variant of the method, it is also determined unencrypted whether the remote station wishes to use the unencrypted data transmission protocol. According to the invention, the device can query this via the data connection.
[0012] According to a preferred variant of the invention, the remote party can be given the option of choosing between encrypted and unencrypted data transmission. To use the encrypted data transmission protocol, a certificate must first be transmitted. After the certificate has been transmitted, the device preferably uses the transmitted certificate for encrypted data transmission. Preferably, after the certificate has been transmitted, the device does not display any further web pages via the unencrypted data transmission protocol. If the remote party nevertheless attempts to communicate via the unencrypted data transmission protocol, the device can, according to embodiments of the invention, offer the remote party communication via the encrypted data transmission protocol.According to the invention, this can be achieved by the device issuing a redirect in response to a request from the remote party via the unencrypted data transmission protocol, which triggers a request from the remote party via the encrypted data transmission protocol. For example, in response to a request via the HTTP protocol, a redirect can be issued that triggers an HTTPS request from the remote party. The redirect can be, for example, a 301 redirect.
[0013] The transmission of the certificate ensures that the user knows it. Consequently, no warning message is displayed in the user's client application, such as a web browser, when the client application connects to the device. Security-relevant actions can now be performed securely, as an encrypted data connection exists. According to possible variants of the invention, a security-relevant action can be understood as an action that concerns security-relevant and / or sensitive data.
[0014] The data connection can, in particular, be a network connection. According to the invention, the device can be equipped with a web server application or a web server. The server application preferably receives requests and / or generates outputs, wherein the outputs are preferably web pages. The first request can, in particular, be a request to call up a web page. According to the invention, the first request can be an HTTP request or another data packet or another sequence of data packets provided for requesting, transmitting and / or retrieving data. However, according to embodiments of the invention, the first request can also be based on a different data format and / or transmitted via a different protocol.To the extent that the present disclosure refers to outputs that occur in response to requests, the communication preferably occurs such that a request via an unencrypted data transmission protocol is responded to by an output via the unencrypted data transmission protocol, and a request via an encrypted data transmission protocol is responded to by an output via the encrypted data transmission protocol. For example, if an HTTP request to call up a website is transmitted to the device, then in response thereto, website data can be output from the device to the remote party via the HTTP protocol. According to another example, if an HTTPS request to call up a website is transmitted to the device, then in response thereto, website data is output from the device to the remote party via the HTTPS protocol.
[0015] The certificate is preferably a digital certificate. In particular, the certificate can be a public-key certificate according to the X.509 standard. Encrypted data transmission preferably occurs according to the Transport Layer Security (TLS) protocol. According to advantageous embodiments of the invention, operational use is understood to mean access to and / or use of the device via the data connection.
[0016] In the context of the method described here and specified in the patent claims, all queries, outputs and other data transmissions between the device and the remote station preferably take place via a data connection, preferably via a digital data connection.
[0017] Preferably, the communication with the remote station comprises, in response to the first request, outputting a first commissioning page to the remote station via the unencrypted data transmission protocol, wherein the first commissioning page includes a selection option for using the encrypted data transmission protocol. According to embodiments of the invention, outputting the first commissioning page can be understood as a transmission or provision of a website. The selection option can be provided via any graphical, textual, or other input option. It is advantageous if the first commissioning page also includes a selection option for using the unencrypted data transmission protocol. The remote station can thus make a selection as to whether the encrypted or unencrypted data transmission protocol should be used subsequently.The selection option can be provided via any graphical, textual or other input option.
[0018] After the first commissioning page is displayed, a second request is preferably received from the remote station via the unencrypted data transmission protocol. The second request contains information that the encrypted data transmission protocol is to be used operationally. In this case, the device consequently receives information from the remote station that encrypted communication is desired. According to the invention, the second request can be an HTTP request or another data packet or another sequence of data packets intended for the request, transmission, and / or retrieval of data.
[0019] It is advantageous if the communication with the remote station further comprises an offer of at least one option for transmitting the certificate to the remote station, wherein the offer is contained on the first commissioning page and / or on a second commissioning page which is sent to the remote station via the unencrypted data transmission protocol in response to the second request. According to variants of the invention, information, a note, an input option and / or a selection option for transmitting the certificate are already present on the first commissioning page. Alternatively, the offer is only made on a second commissioning page, which the device only outputs to the remote station after the remote station has communicated that communication via the encrypted data transmission protocol is desired.The offer on the second commissioning page preferably includes information, a note, an input option and / or a selection option for the transfer of the certificate.
[0020] Communication with the counterpart preferably further comprises receiving a request for the transmission of the certificate from the counterpart. The request can trigger receipt of the certificate from the counterpart or initiate issuance of the certificate from the device to the counterpart. With the request, the counterpart indicates whether and, optionally, how the certificate is to be transmitted, and the device receives the corresponding information. According to a first variant of the invention, this can occur in response to the first commissioning page if the first commissioning page contains information, a note, an input option, and / or a selection option for the transmission of the certificate.According to a second variant of the invention, information, a hint, an input option, and / or a selection option for transferring the certificate are output from the device to the remote station via the second commissioning page. In this case, the remote station can transmit the request to the device in response to the second commissioning page.
[0021] According to a preferred embodiment of the invention, the certificate is transmitted by sending the certificate to the remote station or by enabling the remote station to download the certificate. According to a possible variant of the invention, the device offers the certificate for downloading. A user of the remote station can decide to download the certificate. For example, a link, a button or another option for downloading the certificate can be found on the first commissioning page and / or on the second commissioning page. The certificate can thus be transmitted to the remote station. The remote station can transmit a third request to the device for this purpose. According to the invention, the third request can be an HTTP request or another data packet or another sequence of data packets intended for the request, transmission and / or retrieval of data.In response to the third request, the certificate is transferred from the device to the remote party. The certificate is then preferably installed in a client application of the remote party, such as a web browser, or stored on the remote party in another way so that the remote party can use the certificate for encrypted communication with the device.
[0022] After downloading, the remote party knows the certificate, and therefore, no warning message is displayed in the remote party's client application during encrypted communication with the device that the device's certificate is unknown. The certificate transfer to the remote party does not necessarily have to be done via download in a client application such as a web browser. Alternatively, the device can send or transfer the certificate to the remote party by other means.
[0023] The certificate is preferably a device certificate. The device certificate is assigned to the device. The device can authenticate itself to the remote party based on the device certificate when communicating via the encrypted data transmission protocol. The device certificate is preferably already present and / or installed in the device in an initial state of the device. The initial state of the device is preferably a delivery state, an original state, and / or a reset state of the device. The device certificate is preferably stored in a web server application of the device. In addition to the device certificate, a key assigned to the certificate can be stored in the device. Using the key, it is possible to encrypt and / or sign messages.Messages encrypted and / or signed in this way can be decrypted and / or authenticated based on the certificate. The key is preferably a private key. This private key is preferably complementary to a public key contained in the certificate.
[0024] Alternatively, the certificate can be transmitted by receiving the certificate or by allowing the remote party to upload the certificate. According to this variant of the method, the aforementioned device certificate is not used when using the encrypted data transmission protocol. Instead, it is possible to provide the device with a certificate from an external source, which the device should use when communicating via the encrypted data transmission protocol.
[0025] For example, a user of the remote site can generate or select a corresponding certificate themselves. The certificate can be uploaded from the remote site to the device. This can be done by means of an eighth request. This is preferably an HTTP post-request. For this purpose, an upload form or another option is preferably available on the first commissioning page or on the second commissioning page to initiate an upload of the certificate from the remote site to the device. However, the device can also make an option for uploading the certificate available on a different page or website or in another way. However, it is also possible according to the invention to use a different method for transmitting the certificate from the remote site to the device, so that the device receives the certificate in a different way.
[0026] In the variant of the method in which the certificate is transferred from the remote party to the device, the certificate is preferably a third-party certificate. This means that the certificate was not originally stored in the device. The third-party certificate is preferably not yet present in the device in an initial state of the device. The initial state of the device is preferably a delivery state, an original state, and / or a reset state of the device. The third-party certificate is preferably stored in a web server application of the device after receipt or upload.
[0027] According to the invention, the method can be configured such that, if the remote party communicates that it wishes to use the device operationally via the unencrypted data transmission protocol, a security-relevant action is performed via the unencrypted data transmission protocol. For example, a user of the remote party may decide not to use the encrypted data transmission protocol. This may be the case, for example, if the user cannot or does not want to download the device's certificate or does not want to transfer their own certificate to the device. Another reason may be that a client application of the remote party does not support the encrypted data transmission protocol.
[0028] If the unencrypted data transmission protocol is to be used, then communication with the remote station can advantageously further comprise, after the first commissioning page has been output, receiving a fourth request from the remote station via the unencrypted data transmission protocol, wherein the fourth request contains information that the unencrypted data transmission protocol is to be used operationally. According to the invention, the fourth request can in particular be an HTTP request or another data packet or another sequence of data packets intended for the request, transmission, and / or retrieval of data. In response to the fourth request, operational use can be granted immediately, which can also include security-relevant operations.Alternatively, before security-relevant operations are carried out, it is possible to obtain further confirmation from the remote party that the unencrypted data transmission protocol is actually intended for operational use. According to the invention, this further confirmation can be transmitted from the remote party to the device via a fifth request. According to the invention, the fifth request can be, in particular, an HTTP request or another data packet or another sequence of data packets intended for the request, transmission, and / or retrieval of data.
[0029] It is advantageous if the first request is received while the device is in an initial state. The initial state of the device is preferably a delivery state, an original state, and / or a reset state of the device. The method is thus initiated at a time when the device has just been delivered and has not yet been set up or reset. When a user contacts the device via the remote station to put it into operation for the first time, the method steps listed above should be carried out so that the encrypted data transmission protocol can be activated without issuing a user-side warning message.
[0030] The unencrypted data transmission protocol is preferably the HTTP protocol, and the encrypted data transmission protocol is preferably the HTTPS protocol. This includes any version of the HTTP protocol or the HTTPS protocol. Alternatively, the unencrypted data transmission protocol and the encrypted data transmission protocol can be other data transmission protocols at the application layer. However, it is also conceivable that protocols from other OSI layers are used.
[0031] The security-relevant action preferably comprises receiving a password via the encrypted data transmission protocol. Ideally, a password should not be transmitted in plain text. If it were transmitted via the unencrypted data transmission protocol, it could potentially be read by third parties en route between the remote station and the device. This is prevented by the use of the encrypted data transmission protocol. According to a variant of the invention, however, the password can be transmitted via the unencrypted data transmission protocol if a user decides to do so. In this case, the user assumes this risk. The password can, for example, be a device password for the device. According to an advantageous variant of the method, the password is stored in the device as a new password after receipt.It is particularly preferred if the device does not have a preset password. This means there is no "default password" that could be the same across multiple devices and be easily guessed. Instead, it is preferable that the user enters a unique password upon commissioning.
[0032] According to an advantageous embodiment of the invention, the device displays a password entry page. The password entry page preferably contains a form for entering the password. The remote station transmits the password from the password entry page to the device, preferably by means of a sixth request. According to the invention, the sixth request can be, in particular, an HTTP request or an HTTPS request. However, other security-relevant actions can also be performed by the device. This includes, for example, sending data, in particular security-relevant data. The security-relevant data can be, for example, measurement data and / or configuration data.
[0033] According to a particularly advantageous embodiment of the invention, the device is a field device. This term refers to devices that are used to record and / or influence process variables. In particular, these can be level measuring devices, point level measuring devices, and pressure measuring devices. However, the use of other field devices is also conceivable. The field device preferably has a network interface, which can preferably be a two-wire interface, a four-wire interface, an Ethernet interface, a GSM interface, or a WAN interface. According to the invention, the field device can have at least one sensor. The field device preferably also has at least one computer, for example a microcontroller or another computer system. A server application is preferably implemented in the field device.For the purposes of the present disclosure, a server application is understood to mean, in particular, an application that can receive requests and output data. The server application is preferably a web server application. This preferably supports standardized transmission protocols such as HTTP and HTTPS, as well as network protocols such as IP and TCP.
[0034] According to a further aspect of the invention, a data processing device is provided, comprising means for carrying out the method described above. According to advantageous variants of the invention, the data processing device is a server, preferably a web server. According to another advantageous embodiment of the invention, the data processing device is a field device or a computer unit in a field device.
[0035] According to a further aspect, the invention relates to a computer program product comprising instructions that, when executed by a computer, cause the computer to perform the previously described method. Computer program products comprise a sequence of instructions that, when the program is loaded, cause hardware to perform a specific method that leads to a specific result.
[0036] Advantageous embodiments of the invention are illustrated by way of example in the drawings. In the drawings:
[0037] Fig. 1 is a schematic representation of a first commissioning page,
[0038] Fig. 2 is a schematic representation of a confirmation page,
[0039] Fig. 3 a schematic representation of a password input page,
[0040] Fig. 4 is a schematic representation of a second commissioning page,
[0041] Fig. 5 is a sequence diagram illustrating a process in the case that an unencrypted data transmission protocol is to be used operationally, Fig. 6 is a sequence diagram illustrating a process in the case that an encrypted data transmission protocol is to be used operationally and a certificate is downloaded from a device, and
[0042] Fig. 7 is a sequence diagram illustrating a process in the case where an encrypted data transmission protocol is to be used operationally and a certificate is uploaded to a device.
[0043] Fig. 1 shows a schematic representation of a first commissioning page 1. The first commissioning page 1 is a web page that is output by a device via a data connection. The device communicates with a remote station via the data connection. In an initial state, the device receives a first request from the remote station via the HTTP protocol and then outputs the first commissioning page 1. The device has a web server application to output the first commissioning page 1 and other web pages. The device is a field device. The remote station is a computer that, with the aid of a web browser, can display the first commissioning page 1 and other web pages output by the device. The first commissioning page 1 contains a first text field 2, an HTTPS button 3, and an HTTP button 4.The first text field 2 indicates that the use of the HTTPS protocol is mandatory for secure communication between the remote site's web browser and the device, and that the device supports the HTTPS protocol setup via a wizard. A remote site user can now click either the HTTPS button 3 or the HTTP button 4 via the web browser to select the HTTPS protocol or the HTTP protocol.
[0044] Fig. 2 shows a schematic representation of a confirmation page 5. The confirmation page 5 is a web page. It is displayed if the device receives a fourth request from the remote station via the HTTP protocol, whereby the fourth request indicates that the HTTP protocol should be used. Consequently, the user has opted to use the HTTP protocol on the first commissioning page. The confirmation page has a second text field 6. The second text field 6 states that device data and its settings can be viewed unprotected in network traffic if they are transmitted via the HTTP protocol, and that this would also severely limit the protection of a password to be assigned. The user of the remote station now has the option of pressing an Accept button 7. By clicking the Accept button 7, the user confirms that they accept the risk.This triggers a fifth request from the remote station to the device. Alternatively, the user can press a first back button 8, which takes them back to the initial setup page.
[0045] Fig. 3 shows a schematic representation of a password input page 9. The password input page 9 is a website. The device outputs the password input page 9 via the HTTP protocol after receiving the fifth request from the remote station. By pressing the Accept button, the user has finally decided to use the HTTP protocol. On the password input page 9 there is a third text field 10. In the third text field 10, the user is prompted to enter a password. Below the third text field 10 there is a password input field 11 and a password repeat field 12. The desired password is to be entered in the password input field 11. The desired password is to be entered again in the password repeat field 12. Once the user has done this, they can press a Send button 13.This means that the password is transmitted unencrypted from the remote station to the device via the HTTP protocol using a sixth request.
[0046] Fig. 4 shows a schematic representation of a second commissioning page 14. The second commissioning page 14 is a web page. The second commissioning page 14 is transmitted from the device to the remote station via the HTTP protocol if the remote station, starting from the first commissioning page, transmits a second request to the device indicating that the use of the HTTPS protocol is desired. The second commissioning page 14 has a fourth text field 15. The fourth text field 15 instructs the user of the remote station to activate the HTTPS protocol either by downloading an HTTPS certificate from the device or, alternatively, by uploading a certificate to the device themselves. If the user wishes to download and use the HTTPS certificate from the device, they must press a first switch 16. To use the certificate, they press a download button 17.This triggers a third request from the remote device to the device. The certificate is then transferred from the device to the remote device. This certificate, along with a key associated with the certificate, is stored in the remote device's web server application. The user installs the certificate in the remote device's web browser and then clicks a confirmation button 18 on the second commissioning page 14.
[0047] To allow the remote user to verify the authenticity of the certificate before installing it, a fingerprint is displayed in a fifth text field 19 on the second commissioning page 14. The fingerprint is a cryptographic checksum of the certificate. This can be calculated from the received certificate by the remote user and compared by the user with the fingerprint displayed in the fifth text field 19.
[0048] If the remote user alternatively chooses to upload a local certificate, they press a second switch 20. The local certificate is a certificate stored on the remote device and installed in its web browser. They then press an upload button 21 to upload the local certificate to the device. This triggers an eighth request from the remote device to the device, which transfers the local certificate to the device. The local certificate is subsequently installed in the device's web server application. The user then presses the confirmation button 18.
[0049] The device now only allows web pages to be displayed via the HTTPS protocol. In response to an HTTPS request, it immediately displays a web page via the HTTPS protocol. In the case of a request via the HTTP protocol, it redirects to an HTTPS-protected website. This does not result in warning messages in the web browser from the remote station, as the certificate has been exchanged between the device and the remote station. For example, the user can now access a password entry page as shown in Fig. 3, with the difference that the remote station accesses it via the HTTPS protocol, and a password can only be transmitted to the device via the HTTPS protocol. If the user decides against using the HTTPS protocol, they can press a second back button 22 as an alternative to the confirmation button 18. This takes them back to the first commissioning page.
[0050] Fig. 5 shows a sequence diagram illustrating a process when an unencrypted data transmission protocol is to be used operationally. Data is exchanged between a remote station 23 and a device 24. The remote station 23 sends a first request 25 to the device 24. The first request 25 is an HTTP request. With a first output 26, the device 24 then sends a first commissioning page to the remote station 23. The first commissioning page is displayed by the remote station 23. Based on the first commissioning page, a user of the remote station 23 decides to use the HTTP protocol, so the remote station sends a fourth request 27 to the device 24. The fourth request 27 is an HTTP request. The device 24 then transmits a confirmation page to the remote station 23 with a second output 28. The confirmation page is displayed by the remote station.Starting from the confirmation page, the user of the remote station 23 confirms that the HTTP protocol is indeed to be used by initiating a fifth request 29 from the remote station 23 to the device 24. The fifth request 29 is an HTTP request. The device 24 then transmits a password entry page to the remote station 23 with a third output 30. The remote station 23 displays the password entry page. A password can be entered on the password entry page. The password is then transmitted to the device 24 via a sixth request 31, which then saves the password. The sixth request 31 is an HTTP POST request.
[0051] Fig. 6 shows a sequence diagram illustrating a process in the case where an encrypted data transmission protocol is to be used operationally and a certificate is downloaded from a device 24. Data is exchanged between a remote station 23 and the device 24 via a data connection. The remote station 23 sends a first request 25 to the device 24. The first request 25 is an HTTP request. With a first output 26, the device 24 then sends a first commissioning page to the remote station 23. The remote station 23 represents the first commissioning page. Based on the first commissioning page, a user of the remote station 23 decides to use the HTTPS protocol and initiates a second request 32 from the remote station 23 to the device 24. The second request 32 is an HTTP request.In response to the second request 32, the device 24 performs a fourth output 33, with which it transmits a second commissioning page to the remote station 23. The remote station 23 displays the second commissioning page.
[0052] On the second commissioning page, a certificate for device 24 is offered for download. On the second commissioning page, the user selects that they wish to use the certificate for device 24. As a result, a third request 34 is triggered from the remote station 23 to the device 24. The third request 34 is an HTTP request. With a certificate output 35, the device 24 then transmits the certificate to the remote station 23. The certificate is then installed in a web browser on the remote station 23. The user then decides, starting from the second commissioning page, to confirm their settings for encrypted transmission. The remote station 23 thus transmits a seventh request 36 to the device 24. The seventh request 36 is an HTTP request. The device 24 responds with a redirect 38 to HTTPS.The remote station 23 then sends a forwarding request 39 to the device 24 to access an HTTPS address specified in the forwarding request 38. Subsequent communication between the device 24 and the remote station 23 thus takes place via the HTTPS protocol.
[0053] Device 24 transmits a password entry page to remote station 23 via a third output 30. The third output 30 is transmitted via the HTTPS protocol. Remote station 23 represents the password entry page. A password can be entered on the password entry page. The password is then transmitted to device 24 via a sixth request 31, which then stores the password. In this case, the sixth request 31 is an HTTPS request, preferably an HTTPS POST request.
[0054] Fig. 7 shows a sequence diagram illustrating a process in the case where an encrypted data transmission protocol is to be used operationally and a certificate is uploaded to a device 24. Data is exchanged between a remote station 23 and the device 24 via a data connection. The remote station 23 sends a first request 25 to the device 24. With a first output 26, the device 24 then outputs a first commissioning page to the remote station 23. The remote station 23 represents the first commissioning page. Based on the first commissioning page, a user of the remote station 23 decides to use the HTTPS protocol and initiates a second request 32 from the remote station 23 to the device 24. The second request 32 is an HTTP request.In response to the second request 32, the device 24 performs a fourth output 33, with which it transmits a second commissioning page to the remote station 23. The remote station 23 displays the second commissioning page.
[0055] The second commissioning page provides an option for uploading a local certificate. On the second commissioning page, the user selects to upload a local certificate already present on the remote station 23 to the device 24. This triggers an eighth request 37 from the remote station 23 to the device 24. The eighth request 37 is an HTTP request, preferably an HTTP POST request, with which the certificate is transferred from the remote station 23 to the device 24. The certificate is then installed in a web server application on the device 24.
[0056] The user then decides, starting from the second commissioning page, to confirm their settings for encrypted transmission. The remote station 23 then transmits a seventh request 36 to the device 24. The seventh request 36 is an HTTP request. The device 24 responds with a redirect 38 to HTTPS. The remote station 23 then sends a redirect request 39 to the device 24 to access an HTTPS address specified in the redirect 38. Subsequent communication between the device 24 and the remote station 23 thus takes place via the HTTPS protocol.
[0057] Device 24 transmits a password entry page to remote station 23 via a third output 30. The password entry page is displayed by remote station 23. A password can be entered on the password entry page. The password is then transmitted to device 24 via a sixth request 31, which then stores the password. The sixth request 31 is an HTTPS POST request.
[0058] List of reference symbols
[0059] 1 First commissioning page
[0060] 2 First text field
[0061] 3 HTTP button
[0062] 4 HTTPS button
[0063] 5 Confirmation page
[0064] 6 Second text field
[0065] 7 Accept button
[0066] 8 First back button
[0067] 9 Password entry page
[0068] 10 Third text field
[0069] 11 Password input field
[0070] 12 Password repeat field
[0071] 13 Send button
[0072] 14 Second commissioning page
[0073] 15 Fourth text field
[0074] 16 First switch
[0075] 17 Download button
[0076] 18 Confirmation button
[0077] 19 Fifth text field
[0078] 20 Second switch
[0079] 21 Upload button
[0080] 22 Second back button
[0081] 23 Remote station
[0082] 24 Device
[0083] 25 First inquiry
[0084] 26 First Edition
[0085] 27 Fourth Inquiry
[0086] 28 Second Edition
[0087] 29 Fifth Inquiry
[0088] 30 Third Edition
[0089] 31 Sixth Inquiry
[0090] 32 Second request
[0091] 33 Fourth Edition
[0092] 34 Third request 35 Certificate issue
[0093] 36 Seventh Inquiry
[0094] 37 Eighth Inquiry
[0095] 38 Forwarding 39 Forwarding request
Claims
Patent claims 1. A computer-implemented method for commissioning a device (24) via a data connection, comprising the steps of: - receiving a first request (25) from a remote station (23) via an unencrypted data transmission protocol, - communication with the remote station (23) via the unencrypted data transmission protocol in order to establish whether the remote station (23) wishes to operatively use the device (24) via an encrypted data transmission protocol, and, - if the remote station (23) communicates that it wishes to use the device (24) operationally via the encrypted data transmission protocol: a. transmitting a certificate associated with the encrypted data transmission protocol, b. following the transmission of the certificate, performing a security-relevant action via the encrypted data transmission protocol based on the transmitted certificate.
2. Computer-implemented method according to claim 1, characterized in that the communication with the remote station (23) comprises: - in response to the first request (25), outputting a first commissioning page (1) via the unencrypted data transmission protocol to the remote station (23), wherein the first commissioning page (1) includes a selection option for using the encrypted data transmission protocol.
3. Computer-implemented method according to claim 2, characterized in that the first commissioning page (1) further includes a selection option for using the unencrypted data transmission protocol.
4. Computer-implemented method according to claim 2 or 3, characterized in that the communication with the remote station (23) further comprises: after the output of the first commissioning page (1), receiving a second request (32) via the unencrypted data transmission protocol from the remote station (23), wherein the second request (32) contains information that the encrypted data transmission protocol is to be used operationally.
5. Computer-implemented method according to claim 4, characterized in that the communication with the remote station (23) further comprises: - Offering at least one possibility for transmitting the certificate to the remote station (23), the offer being included on the first commissioning page (1) and / or on a second commissioning page (14) which is sent to the remote station (23) via the unencrypted data transmission protocol in response to the second request (32), - Receipt of a request to transfer the certificate from the counterpart (23).
6. Computer-implemented method according to one of the preceding claims, characterized in that the transmission of the certificate takes place by sending the certificate to the remote station (23) or by enabling the remote station (23) to download the certificate.
7. Computer-implemented method according to one of claims 1 to 5, characterized in that the transmission of the certificate takes place by receiving the certificate or by allowing the remote station (23) to upload the certificate.
8. Computer-implemented method according to one of claims 1 to 3, characterized in that the method further comprises: - if the remote station (23) communicates that it wishes to use the device (24) operatively via the unencrypted data transmission protocol: Carrying out the security-relevant action via the unencrypted data transmission protocol.
9. Computer-implemented method according to claim 8 and claim 3, characterized in that the communication with the remote station (23) further comprises: - after the output of the first commissioning page (1), receiving a fourth request (27) via the unencrypted data transmission protocol from the remote station (23), wherein the fourth request (27) contains information that the unencrypted data transmission protocol is to be used operationally.
10. Computer-implemented method according to one of the preceding claims, characterized in that the receipt of the first request (25) occurs while the device (24) is in an initial state.
11. Computer-implemented method according to one of the preceding claims, characterized in that the unencrypted data transmission protocol is the HTTP protocol and that the encrypted data transmission protocol is the HTTPS protocol.
12. Computer-implemented method according to one of the preceding claims, characterized in that the security-relevant action comprises receiving a password via the encrypted data transmission protocol.
13. Computer-implemented method according to one of the preceding claims, characterized in that the device (24) is a field device.
14. Device (24) for data processing, comprising means for carrying out the method according to one of claims 1 to 13.
15. A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of claims 1 to 13.
Citation Information
Patent Citations
Method for providing an operating menu for a field device in process automation technology
DE102010029655A1
Internet of Things Device Interface
US20190173684A1