1. Abstract

This document proposes a combined solution for two shortcomings in the PDM communication protocol (Siemens/95):

  • PDM identification — a PDM is identified only by its number and area. This can lead to:

    • duplicate PDMs sharing the same number and area;

    • development tools or attackers spoofing a PDM’s number and area to send malicious messages.

  • Lack of encryption — communications are transmitted in clear text. This allows eavesdropping and message injection by development tools or attackers.

The proposal below addresses both issues. To be effective, both parts must be implemented together.

The HTTP transport protocol is expected to be used.

It is not expected to implement this solution on Siemens/95 transport protocol. Such a solution would require adding meta data to the message from PDM. By doing this we would invent RTB-HTTP-like protocol which doesn’t not make much sense if there is a well established standard.

2. Feature overview

To allow an easy migration from unsecured to secured communication, the feature can be enabled per Area. A user can choose the security mode for an entire Area: * Secured - only known PDMs that have initiated secure communication are accepted. * Unsecured - secure and legacy (unsecured) communication are allowed concurrently.

Unsecured mode is recommended only temporarily (during migration) or for areas that still use PDM5 devices. It may also be retained longer for development and debugging, where raw Siemens/95 messages are useful.

3. Proposed solution

The proposed solution is to utilize AES-128 encryption, which is already implemented in the PDM firmware. Since AES is a symmetric encryption method, the challenge lies in securely transporting the key between the PDM and PDM.control.

The basic idea is as follows:

  1. The PDM generates a random number (see Initial key) that will serve as the encryption key.

  2. This key will be displayed on the PDM screen either as text or in the form of text a QR code.

  3. The operator opens PDM.control on their mobile phone, selects the PDM they are in front of, and either enters the key or scans the QR code.

This process transfers the key (which is known only to the PDM) to PDM.control. Simultaneously, the operator confirms the identity of the PDM by being physically present at the device. Any other PDM using the same GAC and number will have a different key and will be rejected.

This solution should comply with EU regulations while effectively addressing the issue of PDM identification (add JIRA link).

3.1. User control and compatibility

User can chose security mode of whole Area between * secured - only know PDMs with secure communication are accepted. * unsecured - both security concepts may work simultaneously. It is recommended unsecured only as a temporary solution during transition to secured mode or for area where are PDM5s.

3.2. Initial key

Since there is no secure random number generator available on the PDM, it must utilize as many variables as possible. These variables should include at least:

  • Current moment - time and date

  • Ticket queues - current ticket number, tracer number, and queue length

  • Network status - signal strength, cell ID, and other factors that change over time

  • Pseudo random number generator (if available)

  • Battery voltage, CPU serial number, and serial numbers from other components

  • Additional variable sources, such as various event counters used on the statistics page

The PDM must collect this information over a sufficient period to ensure adequate entropy. Collected entropy must be persisted across restarts and used as a seed for subsequent entropy collection.

The PDM will then calculate an SHA-128 hash from all this information, which will serve as our key. The key will be 128 bits (16 bytes) long, making it suitable for display in a QR code, even on a standard black-and-white display.

4. Detailed description

The key generated in the Proposed solution will be used as recovery key for the case that current key is lost. It means that right after generation of recovery key will be in the state as if the key was lost. Now PDM starts recovery process to obtain new encryption key.

4.1. Transport of encrypted messages

To transfer encrypted messages we must include metadata. For this purpose it is ideal to use the HTTP transport protocol, which already supports metadata and is widely available across platforms and services.

To identify encrypted messages and their properties, a header is introduced. Headers precede the actual message, are not encrypted, and convey only publicly available information.

4.2. Important headers

To be able to recognize encrypted messages and its property a header needs to be introduced. Headers precede the actual message and are not encrypted, transferring only publicly available information.

There are several important headers which are repeatedly used in the protocol below. Following sections describes them in detail.

4.2.1. Idempotency-Key

Many requests below contains header Idempotency-Key. This header allows PDM to safely repeat the request in case that previous request or response was lost. The value of this header must be unique for each recovery process.

The value must be unique for each recovery process and PDM must remember it until the current process is finished. Ideal value is UUID or GUID. But if there is no possibility to generate such value on PDM, it may use process described in section [<key_generator>] to generate random 128 bit number and encode it as Base64 string.

This allows PDM.control to identify repeated recovery requests and avoid generating multiple recovery request in case that PDM believes the previous request was lost. PDM can safely repeat recovery request as many times as needed until it receives an acknowledgment.

4.2.2. Rtb-Key

Header Rtb-Key contains parameters of encryption key used to encrypt/decrypt the message. It contains following parameters: * cs - cipher suite used for encryption/decryption. Currently supported values are: // 1 - AES/EBC/PKCS5Padding (May not by implemented) 1 - AES/CBC/PKCS5Padding * id - key id. Currently supported value is: 0 - recovery key n - other keys generated over time.

Value of this header is in form of key-value pairs separated by semicolon. The key id allows PDM.control to identify which key to use for decryption of the message.

4.3. Key exchange and recovery process

Key exchange and recovery process are fundamentally the same. The difference is only that for key recovery process is used key with id 0 (recovery key) instead of current encryption key.

4.3.1. Initiation of key exchange

When PDM detects that current encryption key is expired or lost (e.g. after power loss) it will start key exchange.

Key exchange creates new encryption key on PDM control and send it back to PDM. This key become new encryption key until it lost or expired.

If PDM is not sure about supported cipher suites and existing keys it may call Key Info.

Example of exchange request
POST /pdm/key/exchange/create HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Idempotency-Key: "B6PbXUkI70KILww0fKdq2A=="
Content-Type: application/json
{
    "cs": 1  (1)
}
1 The cipher suite to be used.

As a response there will be new key encrypted by current / recovery key. Additional salt can be added to increase security during transport.

Example of exchange response
HTTP 1.1 201 Created
Content-Type: application/binary
Rtb-PDM: pdm=3,gac=5
Rtb-Key: cs=1,id=0
Idempotency-Key: "B6PbXUkI70KILww0fKdq2A=="
Content-Type: application/vnd.rtb.s95/enc+json

<binary data>
Decrypted body
{
    "salt":"Random data. Ignored by PDM", (1)
    "keyId": 17,
    "keyData": "Base/64 encoded key",
    "verification": "Verification data",
    "83652e26-aff6-4c7c-9e62-74114b9edf7c": "32445b14-0493-49f7-aa6f-68da84668116" (1)
}
1 Random data can be put to JSON to make brute-force attacks more difficult. Those fields must be ignored by PDM.

If PDM sends the same request again (same idempotency key), there will no new exchange initiated. It is indicated by returning HTTP 200 OK status code instead of 201 Created.

Example of response of repeated exchange process
HTTP 1.1 200 OK
Content-Type: application/binary
Rtb-PDM: pdm=3,gac=5
Idempotency-Key: "B6PbXUkI70KILww0fKdq2A=="

<binary data>

If there is no match between cipher suites supported by PDM and PDM.control there will be HTTP 480 status code returned. In this case it is needed to manually upgrade PDM software start manual recovery process.

To avoid brute-force attack PDM.control may limit number of recovery attempts to e.g. once per 4 hours. If limit is exceeded there will be HTTP 481 status code returned. This response may be also send if exchange is not possible due to system maintenance or overload.

Starting new exchange process will not invalidate existing key. Even if an attacker would start the exchange process on behalf of existing PDM it would not limit it’s ability to communicate using existing key. Attacker would could only limit ability to recover lost key in case that PDM would really lost the key.

4.3.2. Verification of exchanged key

Then PDM has to confirm that it was able to decode the key. As a proof it will send the decrypted verification data encrypted with the new key.

Example of verification request
POST /pdm/key/exchange/verify HTTP 1.1
Rtb-PDM: pdm=3,gac=5  (1)
Rtb-Key: cs=1,id=17
Idempotency-Key: "B6PbXUkI70KILww0fKdq2A=="
Content-Type: application/vnd.rtb.s95/enc+json


<binary data> (2)
1 PDM identification.
2 Verification data encrypted by advertized key and cipher suite.

PDM may repeat the verification step several times to ensure the key was received correctly. If the key has already been successfully verified, no further action is taken.

As a response there will be standard HTTP 200 OK status code.

Example of verification response
HTTP 1.1 200 OK
Rtb-PDM: pdm=3,gac=5
Idempotency-Key: "B6PbXUkI70KILww0fKdq2A=="
Rtb-Key: cs=1,id=17
Content-Type: application/vnd.rtb.s95/enc+json

{ (1)
    "status": "verified",
    "id": 17,
    "length": 128,
    "validity": {
      "from": "2025-01-01T00:00:00",
      "until": "2025-12-31T23:59:59"
      }
    },
}
1 Actual data are encrypted by advertized key and cipher suite.

If verification fails there will be HTTP 482 status code returned.

PDM.control may limit number of exchange attempts to avoid brute-force attacks by responding HTTP 481.

If the exchange process is not successfully completed within certain time PDM.control will discard newly created key and force requestor to wait for certain time to start new exchange.

Key verification works with main database, therefore it is available immediately after key exchange.

5. Transport of encrypted Siemens/95 messages

During normal operation PDM sends Siemens/95 messages to PDM.control. These messages needs to be encrypted to avoid eavesdropping and message injection. This is done by encrypting the message body using agreed cipher suite and key.

Example of encrypted Siemens/95 message
POST /pdm/dispatch-s95 HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Rtb-Key: cs=1,id=17
Content-Type: application/vnd.rtb.s95/enc+s95 (1)
<binary-data>
1 Content type may be JSON or Siemens/95 format.

If the request is correctly received there will be HTTP 200 OK status code returned and content of the response of PDM.control in the same format as the request.

Example of response to encrypted Siemens/95 message
HTTP 1.1 200 OK
Rtb-PDM: pdm=3,gac=5
Rtb-Key: cs=1,id=17
Content-Type: application/vnd.rtb.s95/enc+s95 (1)
<binary-data>
1 Content type may be JSON or Siemens/95 format.

If request cannot be decrypted there will be HTTP 482 status code returned.

In such a case PDM may request Key Info to check if the key is still valid. If the key is expired or invalid PDM may use some other valid key or start recovery process to obtain new key.

6. Key Info

PDM may request a list of active keys and supported cipher suites from PDM.control at any time. Key IDs are increasing integers that start at 1. IDs need not be contiguous; a larger ID indicates a newer key.

Immediately after a new key is created, it may take time for PDM.control to propagate the key to all nodes. Thus, a newly created key might not appear in the list of active keys right away or it may be there but rejected by PDM.control.

If the latest key fails, the PDM should temporarily (for example, up to one hour) use the most recent valid key instead of immediately initiating a recovery process.

Generally, PDM should not use newly created key for abut 10 minutes after receiving it to allow propagation across all nodes.

Example of key info request
POST /pdm/key/info HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Example of key info response
HTTP 1.1 200 OK
Rtb-PDM: pdm=3,gac=5
Content-Type: application/json
{
    "cipherSuites": [
      {id: 1,type: "AES/ECB/PKCS5Padding"},
      {id: 2,type: "AES/CBC/PKCS5Padding"}
      ],
    "keys": [
      {id: 17,length: 128, validity: {from: "2025-01-01T00:00:00", until: "2025-12-31T23:59:59"}},
      {id: 63,length: 128, validity: {from: "2026-01-01T00:00:00", until: "2026-01-31T23:59:59"}},
      {id: 7954,length: 256, validity: {from: "2026-06-01T00:00:00", until: "2026-06-30T23:59:59"}}
    ]
}

7. Relation between JSON and Siemens/95 messages

Currently PDM uses Siemens/95 format to transfer messages to PDM.control. However, in the future we plan to migrate to JSON format, which is more versatile and easier to work with. During the transition period both formats will be supported.

The format used in the body is indicated by the Content-Type header. Below are examples of both Siemens/95 and JSON message in unencrypted format.

Example Siemens/95 message in plain text
POST /pdm/dispatch/s95 HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Rtb-Key: cs=1,id=17
Content-Type: application/vnd.rtb.s95/+txt;encoding="UTF-8"

PSA00010;GAC00011;DTM2025-10-06T23:33:01;VER7.5.5.177;PID1A26815A99;KEE;KAI0010;OPI{M:M17520-LTE_NT910 75,0 GPRS, SD:0x00, WU:4875 Bat:{a:12.2,n:12.2}};CRCD10F
Example JSON format in plain text
POST /pdm/dispatch/json HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Rtb-Key: cs=1,id=17
Content-Type: application/vnd.rtb.s95+json;encoding="UTF-8"

{"PSA":10,"GAC":11;"DTM":"2025-10-06T23:33:01","VER":"7.5.5.177","PID":"1A26815A99","KEE":true,"KAI":10;"OPI":{"M":"M17520-LTE_NT910 75,0 GPRS","SD":0, WU:4875", "Bat":{"a":12.2,"n":12.2}}

8. Unencrypted messages

Unencrypted messages are sent in plain text format. They are indicated by missing Rtb-Key header and content type without encryption parameters. Both formats are supported - Siemens/95 and JSON.

In case of JSON message a CRC field needs to be added to HTTP header to be able ot prevent anybody to tamper with the message.

Example JSON format in plain text
POST /pdm/dispatch/json HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Rtb-Key: cs=1,id=17
Rtb-Crc: 1,D10F (1)
Content-Type: application/vnd.rtb.s95+json;encoding="UTF-8"

{"PSA":10,"GAC":11;"DTM":"2025-10-06T23:33:01","VER":"7.5.5.177","PID":"1A26815A99","KEE":true,"KAI":10;"OPI":{"M":"M17520-LTE_NT910 75,0 GPRS","SD":0, WU:4875", "Bat":{"a":12.2,"n":12.2}}
1 Rtb-Crc: generator,checksum. E.g. 1 is CRC-16.
Example of encrypted message
POST /pdm/dispatch-s95 HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Rtb-Key: cs=1,id=17
Content-Type: application/vnd.rtb.s95/enc/txt;cs="1";key="78"

<binary-data>

For development and debugging cases there will be also unencrypted variant. It differs in content type and carries data in standard Siemens/95 format. In this case content type does not contain decryption parameters like cipher suite (cs) and key id (key)

Example of not encrypted message
POST /pdm/dispatch-s95 HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Content-Type: application/vnd.rtb.s95/+txt;encoding="UTF-8"

PSA00010;GAC00011;DTM2025-10-06T23:33:01;VER7.5.5.177;PID1A26815A99;KEE;KAI0010;OPI{M:M17520-LTE_NT910 75,0 GPRS, SD:0x00, WU:4875 Bat:{a:12.2,n:12.2}};CRCD10F

Please note that in the future we will migrate s95 to JSON which is more versatile. In such a case un-encrypted HTTP request may look like this.

Example of not encrypted Siemens/95 message in JSON format
POST /pdm/dispatch-s95 HTTP 1.1
Rtb-PDM: pdm=3,gac=5
Content-Type: application/vnd.rtb.s95+json;encoding="UTF-8"

{"PSA":10,"GAC":11;"DTM":"2025-10-06T23:33:01","VER":"7.5.5.177","PID":"1A26815A99","KEE":true,"KAI":10;"OPI":{"M":"M17520-LTE_NT910 75,0 GPRS","SD":0, WU:4875", "Bat":{"a":12.2,"n":12.2}}