CHANGE TO THE CONTENTS OF A ROOT CERTIFICATE STORAGE

Description

[0001] The invention relates to a method for operating a technical device having a certificate memory in the form of a trackside or vehicle-side component of a railway facility. Such a method is known from German patent application DE 10 2016 204 630 A1.

[0002] The document US 6,816,900 B1 discloses a method for updating a root certificate store with a view to verifying the identity of the website provider when communicating with external websites.

[0003] US Pat. No. 9,621,356 B2 discloses a method for revoking stored certificates. This method uses two signatures to revoke a certificate that is self-validating and cannot be externally validated from another source.

[0004] The invention is based on the object of specifying a method for operating a trackside or vehicle-side component of a railway facility which is particularly tamper-proof with regard to changes to software or files.

[0005] This object is achieved according to the invention by a method having the features according to claim 1. Advantageous embodiments of the method according to the invention are specified in subclaims.

[0006] According to the invention, the certificate store is a root certificate store in which root certificates considered valid are stored, based on which the device can check whether newly transmitted or newly installed software or newly received files are to be classified as trustworthy and may be used or executed, wherein the content of the root certificate store is changed in such a way that a data container is created on the operator side, which contains at least the following: a command for changing the content of the root certificate store and, in the case of adding a new root certificate to the root certificate store, the respective root certificate, an operator-side signature certificate containing a public key, a trust chain data record,which refers to a base root certificate and enables verification of the operator-side signature certificate and a signature generated with a private key of the operator-side signature certificate, the signature is checked for trustworthiness on the device side, based on the public key in the operator-side signature certificate, the trust chain record, and at least one base root certificate stored on the device side and considered trustworthy on the device side, and in the case of a signature check confirming trustworthiness, the command contained in the data container for changing the contents of the root certificate store is executed on the device side.

[0007] A key advantage of the method according to the invention is that access to the root certificate store on the device side only occurs when a data container is input or transmitted that enables verification of a signature also contained in the data container based on a trust chain data record and a base root certificate known to the device. Using the data container provided according to the invention with the described content prevents operating personnel, who are authorized to make technical changes to the technical device, from also gaining access to and manipulating the device's root certificate store. Changing the root certificate store is only possible if a data container has been created that contains a verifiable, trustworthy operator-side signature certificate.Only those data containers that meet the specified conditions will be considered. Due to the verifiability of their authenticity, the data containers may, for example, be transmitted over insecure data transmission lines or implemented on-site by personnel not authorized to create data containers.

[0008] It is advantageous if a data container is created on the operator side which also contains one or more of the following information: a validity information specifying the temporal validity of the data container, a usage information specifying the use of the new root certificate in the event of a new root certificate being added, an affiliation information specifying the affiliation of the data container to the addressed technical device and / or an information (application information) of one or more applications of the technical device which should be able to use the new root certificate in the event of a new root certificate being added.

[0009] As a data container, a data container with a header section, a payload section and a signature section containing the signature is preferably created.

[0010] In the latter variant, the trust chain record and the operator-side signature certificate are preferably placed in the header section.

[0011] The command for changing the contents of the root certificate store and, in the case of adding a new root certificate to the root certificate store, the respective root certificate are preferably placed in the payload section.

[0012] The validity information and the usage information of the root certificate in the case of adding a new root certificate, the affiliation information to the technical device in question and / or the application information of one or more applications of the technical device that should be able to use the new root certificate in the case of adding a new root certificate are preferably placed in the header section.

[0013] The signature is preferably formed over the contents of the header section and the payload section.

[0014] A signature of type RFC7515 is preferably generated as the signature.

[0015] A JSON web signature is particularly preferred as a signature.

[0016] The method is particularly preferably used for the following railway components: axle counters, track vacancy detection devices, communication devices, mobile radio devices and / or signal boxes.

[0017] The invention further relates to a railway device which is a trackside or vehicle-side component of a railway facility and is equipped with a certificate memory.

[0018] According to the invention, the certificate store is a root certificate store in which root certificates considered valid are stored, based on which the component can check whether newly transmitted or newly installed software or newly received files are to be classified as trustworthy and may be used or executed, and the component has a checking device that can process a data container that contains at least the following: a command to change the content of the root certificate store and, in the case of adding a new root certificate to the root certificate store, the respective root certificate, an operator-side signature certificate containing a public key, a trust chain data record,which refers to a base root certificate and enables verification of the operator-side signature certificate and a signature generated with a private key of the operator-side signature certificate, and the verification device is designed such that it checks the signature for trustworthiness, specifically on the basis of the public key in the operator-side signature certificate, the trust chain data record, and at least one base root certificate stored on the device and considered trustworthy, and in the case of a signature verification confirming trustworthiness, releases the command contained in the data container for modifying the contents of the root certificate store for execution or executes it itself.

[0019] With regard to the advantages of the technical device according to the invention, reference is made to the above statements in connection with the technical method according to the invention.

[0020] The invention is explained in more detail below using exemplary embodiments; by way of example, Figure 1 shows an arrangement with an embodiment of a technical device according to the invention and a parameterization device connected to the technical device, in a first phase of a method for changing the content of a root certificate memory of the technical device, Figure 2 shows the arrangement according to Figure 1 in a second phase of the method for changing the content of the root certificate memory, Figure 3 shows an embodiment of a data container according to the invention with which a change in the content of the root certificate memory in the technical device according to the Figures 1 and 2 can be carried out, Fig.4-7 further embodiments of data containers for changing the content of the root certificate store of the technical device according to the Figures 1 and 2, Figure 8 shows an embodiment of a test device which is used in the technical device according to the Figures 1 and 2 can be used, and Figure 9 shows a further embodiment of a test device which can be used in the technical device according to the Figures 1 and 2 can be used.

[0021] For the sake of clarity, the same reference symbols are always used in the figures for identical or comparable components.

[0022] The Figure 1 shows a technical device 10 that is connected to an external parameterization device 30 via a data transmission line 20. The data transmission line 20 may be a non-secure data transmission line, i.e., one that could potentially be manipulated.

[0023] The technical device 10 comprises a root certificate memory 11 and a testing device 12. The external parameterization device 30 enables external modification of the content of the root certificate memory 11 with the assistance of the testing device 12 via the data transmission line 20.

[0024] In the embodiment according to Figure 1 For example, it is assumed that a new root certificate ZW is to be added to or stored in the root certificate memory 11 of the technical device 10 using the external parameterization device 30. A corresponding command B for changing the content of the root certificate memory 11, in this case the command B for adding the new root certificate ZW, is stored in a data container DC, which, after completion, is transmitted to the testing device 12 via the data transmission line 20.

[0025] In addition to the root certificate ZW and the command B for modifying the contents of the root certificate store 11, the data container DC also contains a trust chain record VDS and an operator-side signature certificate Z, which contains a public key OS of an operator authorized to create the data container DC. The term "operator" here refers not only to human operators but also to autonomously operating machines, such as appropriately programmed computers.

[0026] The trust chain record VDS refers to a base root certificate ZWB and enables verification of the operator-side signature certificate 2.

[0027] In addition, the data container DC contains a signature SIG(PS(Z)) that was generated with a private key PS of the operator-side signature certificate 2.

[0028] The testing device 12 of the device 10 checks the trustworthiness of the data container DC by checking, in a first step, on the basis of the public key OS in the operator-side signature certificate Z, the trust chain data set VDS and a base root certificate ZWB stored in the root certificate memory 11, whether the signature SIG(PS(Z)) is based on a trustworthy base root certificate ZWB and has thus been generated by an operator considered trustworthy.

[0029] The Figure 2 shows the arrangement according to Figure 1 after the testing device 12 has determined the trustworthiness of the data container DC and thus considers itself legitimately instructed to execute the command B to change the contents of the root certificate store 11 and to store the root certificate ZW contained in the data container DC in the root certificate store 11.

[0030] In the embodiment according to the Figures 1 and 2 For example, it is assumed that a new root certificate ZW is to be stored in the root certificate store 11 and that command B includes a corresponding request to add to the root certificate store 11. Alternatively, command B can also refer to the deletion of a root certificate already stored in the root certificate store 11 or to some other change to the root certificate store 11; in this case, too, command B describes the respective desired change.

[0031] The Figure 3 shows a first embodiment of an advantageous structure of the data container DC according to the Figures 1 and 2 . In the embodiment according to Figure 3 The data container DC has three sections, namely a header section KA, a payload section NA and a signature section SA.

[0032] The header section KA preferably stores the trust chain data record VDS and the operator-side signature certificate 2, which contains the operator's public key OS.

[0033] The payload section NA preferably contains the command B for changing the contents of the root certificate store 11 as well as the root certificate ZW that is affected.

[0034] The signature section SA contains the previously explained signature SIG(PS(Z)), which enables verification of the trustworthiness of the data container DC based on the trust chain data set VDS, the base root certificate ZWB stored in the root certificate store 11, and the public key OS in the signature certificate 2. The signature SIG(PS(Z)) is preferably formed from the content of the header section KA and the payload section NA.

[0035] The signature generated is preferably an RFC7515 type signature, in particular a JSON web signature.

[0036] The Figure 4 shows a second embodiment of an advantageous configuration of a data container DC, which is used to change the content of the root certificate memory 11 in the technical device 10 according to the Figures 1 and 2 In contrast to the embodiment shown in Figure 3 The data container DC has Figure 4 additionally an application specification App, which defines one or more applications of the technical device 10, which should be able to use the new root certificate in case of adding a new root certificate ZW.

[0037] The Figure 5 shows a third embodiment of an advantageous configuration of a data container DC, which is used to change the content of the root certificate memory 11 in the technical device 10 according to the Figures 1 and 2In contrast to the exemplary embodiments according to Figures 3 and 4 The data container DC has Figure 5 Additionally, a usage specification Vw is included, which indicates the use of a new root certificate ZW. For example, the usage specification can indicate that the new root certificate ZW should be used to verify the authenticity of newly installed software modules.

[0038] The Figure 6 shows a fourth embodiment of an advantageous configuration of a data container DC, which is used to change the content of the root certificate memory 11 in the technical device 10 according to the Figures 1 and 2 In contrast to the exemplary embodiments according to the Figures 3 to 5 According to Figure 6, the data container DC additionally has an affiliation indication Zghk, which confirms the affiliation of the data container DC to the technical device 10.

[0039] The Figure 7shows a fifth embodiment of an advantageous configuration of a data container DC, which is used to change the content of the root certificate memory 11 in the technical device 10 according to the Figures 1 and 2 In contrast to the exemplary embodiments according to the Figures 3 to 6 According to Figure 7, the data container DC additionally has a validity indication Tmax, which indicates a temporal validity of the data container DC and thus enables a temporal limitation of the usability of the data container DC, so that after expiry of the validity period the use of the data container DC is automatically blocked.

[0040] The Figure 8 shows an embodiment of a test device 12 which is used in the technical device 10 according to the Figures 1 and 2The test device 12 comprises a computer 120 and a memory 121. In the memory 121, a test program PM is stored which, when executed by the computer 120, enables the computer to operate as a test device 12, as described above in connection with the Figures 1 to 7 has already been explained.

[0041] The Figure 9 shows a further embodiment of a test device 12 which is used in the technical device 10 according to the Figures 1 and 2 The test device 12 is used in the embodiment according to Figure 9 formed solely by a computer 120, which - programmed by a test program PM, which is stored in the root certificate memory 11 - is enabled to check the Figures 1 and 2to carry out the described verification procedures, i.e. to check received data containers DC for trustworthiness and, if necessary, to execute commands B contained therein to change the contents of the root certificate store 11.

[0042] The data container DC created by the parameterization device 30 does not need to be fed into the technical device 10 via a data line 30 or immediately after its generation. Alternatively, it can be temporarily stored and fed into the device at a later time by operating personnel on-site at a device-side interface.

[0043] With the latter variant, a two-stage security check is possible: First, it can be checked whether the operating personnel are even authorized to make changes to the technical device 10; if this is the case, the trustworthiness of the data container 10 can be checked in a second step. In this case, the authorizations can be structured differently: For example, the on-site operating personnel do not need to be authorized to create data containers DC themselves; it is sufficient for the on-site operating personnel to bring a valid data container DC created by another authorized operator to modify the root certificate store 11.

[0044] Although the invention has been illustrated and described in detail by means of preferred embodiments, the invention is not limited by the disclosed examples and other variations can be derived therefrom by those skilled in the art without departing from the scope of the invention. List of reference symbols

[0045] 10technical device 11root certificate memory 12test device 20data transmission line 30parameterization device 120computer 121memory App specification / application specification BCommand DCData container KAHeader section NAPayload section OSPublic key PMCheck program PSPrivate key SASignature section SIG(PS(Z))Signature TmaxValidity specification VDSTrust data record VwUsage specification 2Signature certificate ZghkAffiliation specification ZWRoot certificate ZWBBase root certificate

Claims

1. Method for operating a technical device that is a trackside or vehicle-side component of a railway technical facility, wherein the technical device is equipped with a certificate store, characterised in that the certificate store is a root certificate store in which root certificates regarded as valid are stored, with which the technical device can check whether newly transmitted or newly installed software or newly received files are to be classified as trustworthy and may be used or executed, wherein the procedure for modifying the content of the root certificate store (11) is such that - a data container (DC) is generated on the operator side and contains at least the following: - a command (B) for modifying the content of the root certificate store (11) and, in the event of a new root certificate (ZW) being added to the root certificate store (11), the respective root certificate (ZW), - an operator-side signature certificate (Z) containing a public key (OS), - a chain-of-trust data record (VDS) that refers to a base root certificate (ZWB) and allows a verification of the operator-side signature certificate (Z), and - a signature (SIG(PS(Z)) generated with a private key (PS(Z)) of the operator-side signature certificate (Z), - the trustworthiness of the signature (SIG(PS(Z)) is checked on the device side, namely on the basis of the public key (OS) in the operator-side signature certificate (Z), the chain-of-trust data record (VDS) and at least one base root certificate (ZWB) stored on the device side and regarded as valid on the device side, and - in the event of a signature check confirming the trustworthiness, the command (B) for modifying the content of the root certificate store (11) contained in the data container (DC) is executed on the device side.

2. Method according to claim 1, characterised in that a data container (DC) is generated on the operator side and additionally contains one or more of the following indications: - a validity indication (Tmax) indicating the validity time of the data container (DC), - a usage indication (Vw) indicating the usage of the new root certificate (ZW) in the event of a new root certificate (ZW) being added, - an association indication (Zghk) indicating the association of the data container (DC) with the aforementioned technical device (10), and / or - an indication (App) of one or more applications of the technical device (10) that the new root certificate (ZW) is to be able to use in the event of a new root certificate (ZW) being added.

3. Method according to one of the preceding claims, characterised in that a data container (DC), having a header section (KA), a payload section (NA) and a signature section (SA) containing the signature (SIG(PS(Z)), is generated as the data container (DC) .

4. Method according to claim 3, characterised in that the chain-of-trust data record (VDS) and the operator-side signature certificate (Z) are placed in the header section (KA).

5. Method according to one of the preceding claims 3 to 4, characterised in that the command (B) for modifying the content of the root certificate store (11) and, in the event of a new root certificate (ZW) being added to the root certificate store (11), the respective root certificate (ZW), are placed in the payload section (NA).

6. Method according to one of the preceding claims 3 to 5, characterised in that a validity indication (Tmax) and a usage indication (Vw) of the root certificate (ZW) in the event of a new root certificate (ZW) being added, an association indication (Zghk) with the aforementioned technical device (10) and / or an indication (App) of one or more applications of the technical device (10) that the new root certificate (ZW) is to be able to use in the event of a new root certificate (ZW) being added, are placed in the header section (KA).

7. Method according to one of the preceding claims, characterised in that the signature (SIG(PS(Z)) is formed using the content of the header section (KA) and the payload section (NA).

8. Method according to one of the preceding claims, characterised in that a signature of the type RFC7515 is generated as the signature (SIG(PS(Z)).

9. Method according to one of the preceding claims, characterised in that a JSON Web Signature is generated as the signature (SIG(PS(Z)).

10. Method according to one of the preceding claims, characterised in that the content of a root certificate store (11) of one of the following railway technical facilities is modified: axle counter, track vacancy detection facility, communication facility, mobile radio facility and / or interlocking.

11. Railway technical device that is a trackside or vehicle-side component of a railway technical facility and is equipped with a certificate store, characterised in that - the certificate store is a root certificate store in which root certificates regarded as valid are stored, with which the component can check whether newly transmitted or newly installed software or newly received files are to be classified as trustworthy and may be used or executed, and - the component has a checking facility (12) that can work with a data container (DC) that contains at least the following: - a command (B) for modifying the content of the root certificate store (11) and, in the event of a new root certificate (ZW) being added to the root certificate store (11), the respective root certificate (ZW), - an operator-side signature certificate (Z) containing a public key (OS), - a chain-of-trust data record (VDS) that refers to a base root certificate (ZWB) and allows a verification of the operator-side signature certificate (Z), and - a signature (SIG(PS(Z)) generated with a private key (PS(Z)) of the operator-side signature certificate (Z), and - the checking facility (12) is configured such that it - checks the trustworthiness of the signature (SIG(PS(Z)), namely on the basis of the public key (OS) in the operator-side signature certificate (Z), the chain-of-trust data record (VDS) and at least one base root certificate (ZWB) stored on the device side and regarded as valid, and - in the event of a signature check confirming the trustworthiness, allows the execution of, or itself executes, the command (B) for modifying the content of the root certificate store (11) contained in the data container (DC).