© 2020 EnOcean | www.enocean.com
PTM 210 / PTM 215 / PTM 215U / PTM 215J User Manual May 2020 | Page 15/37
USER MANUAL
PTM 210 / PTM 215 / PTM 215U / PTM 215J
DC Step code and later
For details on the secure mechanisms please refer to the security specification of the
http://www.enocean.com/en/security-specification/
. Or for practical
explanation with examples please see APP note.
Secure telegrams include a rolling code based on an incrementing counter which guaran-
tees that identical message content will be encrypted differently.
The counter can be:
Included in each data message - explicit (recommended)
Or
Not included in data messages – implicit (legacy, not recommended)
The counter value is also part of the teach-in telegram. The selection if the counter is im-
plicit or explicit is done via the NFC interface (see) or special button combinations at mode
switching (for details visit chapter 3.3).
There is no advantage in term of being “more secure” or “more protected” by using the im-
plicit mode over explicit or vice versa. The “protection level” and security mechanisms are
same.
The RLC starts at production with value 0. By the size of the RLC counter (24 bit) it is prac-
tically ensured it will not run over and use the same value twice during the PTM lifetime.
The RLC counter is internally restarted to 0x0 once the AES key was changed via the NFC
interface.
By doing factory reset (see chapter 3.4 for details) the PTM module returns to using the
factory set AES key but does not reset the RLC counter associated with the key. The last
used RLC value associated with the factory set AES key will be used.
3.2.1
Implicit RLC – legacy, not recommended
This mode is relevant only for the European market – 868 MHz because of legacy receivers.
For the J and U market 928 MHz and 902 MHz, there are no legacy receivers and thus not
reason to use this mode at all.
The initial counter value is transmitted from PTM 21x to the receiver only as part of the
teach-in telegram. Subsequent secure telegrams do not include it. Therefore, receiver has
to automatically increment his counter at every received telegram to keep it synchronized
with the PTM Module.
When telegrams are not received by the receiver this may lead to a de-synchronization of
PTM Module and receiver counters, i.e. the PTM Module counter will have a greater value
than the receiver counter.
In order to prevent failure, the receiver will usually test the received rolling code against a
defined window of future expected rolling codes and – if successful - resynchronize its
counter automatically. The size of this rolling code window is defined on the receiver side.
It is important that the amount of consecutive, non-received telegrams does not exceed the
size of this window.
For more details please refer to
