2. Proposed solution
RTLS (RTB Transport Layer Security) is simplified version of TLS to be used on PDM that does not have enough computation power to use proper TLS. This solution is intended only for PDMs without additional encryption hardware. It does not provide as strong security as TLS.
There is also encryption board (call our help desk for more info) which PDM can be additionally equipped with. It provides real TLS.
2.1. Unsecured areas
The solution below will not replace existing solution. It will leave possibility to use existing PDM identification mode within unsecured areas.
2.2. Secured areas
Secured areas will only accept authenticated (see PDM authentication) PDMs connected securely. Unknown PDM will be always rejected.
2.3. 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 only as a temporary solution during transition to secured mode or for area where are PDM5s.
3. Secured connection
3.1. Establishing of secure channel
If PDM communicates with server for the first time or if the key was lost it is necessary to initialize secure chanel. If there is a symmetric key already present PDM can use it directly.
Secure communication can be established by following steps:
-
Verify PDM.control identity
-
Create session key
-
Store session key
3.1.1. PDM.control’s identity verification
In order to verify that PDM talks to correct PDM.control its identity should be verified. This is done using asymmetric cryptography using following process.
First PDM gets a public key of the DPM control. Then PDM verifies validity of the key either using Ext - PKI by RTB infrastructure or by some other verification mechanism like list of fingerprints of trusted keys in configuration.
Next PDM generates random string end encrypts it by public key which it got from PDM.control and sends it for decryption. If PDM.control is the trusted one it will be able to decrypt the string by its private key and send it back to PDM. PDM compares original and decrypted string. It they match generation of session key may begin.
This step is important to eliminate man-in-the-middle attack. PDM has to be sure that it communicates with correct PDM.control and not with a proxy between.
3.1.3. Hello
First must PDM and PDM.control agree on used cipher suites. PDM reports to PDM.control which algorithms it supports. The message can look like this
{
"idKeys": ["rsa-2048", "rsa-1024", "rsa-128"],
"secretGenerators": ["dh-64","dh-128"],
"ciphers": ["aes-128","aes-196","aes-256"],
"macs": ["md5", "sha-1", "sha-224"] (1)
}| 1 | See list of hash algorithms in Wikipedia. |
Then PDM.control inspects key and based on configured security provide cipher suite parameters. The response can be following:
{
"secretGenerator": "dh-128",
"cipher": "aes-128",
"mac": "sha-1"
}3.1.4. Session key
Pre-session key exchange
The secret generator agreed in previous step is used to generate pre-session key. Currently is only Diffie–Hellman with prime numbers supported. Elliptic-curve may be added later.
Pre-session key generation requires common prime numbers \$P,G\$ which are the same for both sides. Because PDM does not have capability to generate big prime numbers they will be provided by PDM.control. Then both sides generates secret numbers \$x,y\$. Pre-session key (\$s_x\$ and \$s_y\$) is calculated independently on both like this.
-
\$s_x=P^xmodG\$
-
\$s_y=P^ymodG\$
Derived session key
Because number of bits in pre-session key usually does not match length of key of selected cipher a Hash Key Derivation Function must be applied to get required number of bits. Example of java implementation. The value calculated here will become the session key for agreed symmetric cipher.
Calculation of resulting key \$T\$ is flowing:
Number of iteration \$N\$ is calculated from required key length \$L\$ and length of hash of pre-session key \$H_"len"\$
Session key = first \$L\$ bytes of \$T\$
where:
-
\$T_0 = "empty string (zero length)"\$
-
\$T_1 = "Hash"(T_0 | "info" | "0x01")\$
-
\$T_2 = "Hash"(T_1 | "info" | "0x02")\$
-
\$...\$
-
\$T_n = "Hash"(T_(n-1) | "info" | "n")\$
Session key has to be stored together with session_id on both sides (PDM and PDM.control) and can be used as long as the session is valid. Valid session is usually longer then one message batch from PDM. It can be valid for days or weeks. From time to time it will be terminated from PDM.control and PDM must initiate new key exchange.
From now on is the communication chanel secure. PDM has to always send session_id as well to let PDM.control to find a correct key.
4. Trusted PDM
4.1. PDM authentication
PDM can be connected to PDM.control only using authentication on both sides.
-
User has to prove that he owns PDM by opening technical door.
-
User has to prove that he ons Area by log in to PDM.control.
-
At the end user has to re-type PIN from one device to the other.
From user point of view looks the connection operation like this
Underlined text represents what is shown of PDM display.
To resolve this problem following procedure is suggested.
4.2. Adding PDM to network
To verify that user own PDM and Area following process has to be performed:
-
User opens PDM’s technical door and click button.
-
PDM control generates PIN and send it to PDM
-
PDM displays it on the screen
-
-
User log in to PDM.control, open area and click button "Add PDM"
-
User enters PIN to PDM.control.
-
-
PDM.control generate UUID and send to PDM.
Image below demonstrate the case.
5. Existing vs new PMD
User can either connect new or existing PDM. The procedure is almost the same. The only difference is on PDM.control. User either indicates that he connects new PDM (with new history) or he want to connect to the context of existing history.
6. Key expiration (optional)
To address a problem of recycling of main boards (after reparation) and therefore accidental UUID reuse, may PDM control automatically disconnect PDM which does not communicate over certain period of time by deleting its AES128 key. In this case must user add the PDM to the network manually and generate new UUID.
However our repair center is generally responsible to invalidate UUID and AES key after reparation.
7. Encrypted communication
After confirmation of PDM.identity and assigning AES key works communication with this permanent key forever. If user loose the kye he needs to repeat the procedure.
8. New from 2022-05-17
8.1. Algorithm list
PDM.control provides a list of supported algorithms for creation of secure chanel. Algorithms are sorted in preferred order. PDM must use first supported one from the list. Sample answer is below.
{
"idKeys": ["rsa-2048", "rsa-1024", "rsa-128"],
"secretGenerators": ["dh-128", "dh-64"],
"sponge":["keccak"],
"ciphers": ["aes-512","aes-128"]
}