hash = RPA && 0x000000FFFFFF
hash = 0xE51944
Next, we verify the address mode by looking at the two most significant bit of prand:
mode = (prand && 0xC00000) >> 22 mode = 0b01
Referring to chapter 4.4.2, the setting of 0b01 indicates resolvable private address mode. To generate the
hash, we add 104 bit of padding (all zeros) to prand:
0x00000000000000000000000000493970
We can now generate the hash as AES128 operation between the IRK and the thus padded
prand:
hash = AES128(IRK; Padded prand)
hash = AES128(0xBE759A027A4870FD242794F4C45220FB;
0x00000000000000000000000000493970)
At the time of writing, a suitable online AES calculator could be found here:
http://testprotect.com/appendix/AEScalc
With this, we can calculate the result as:
hash = 0x286ACB1F9C8A80EE21B3F02225E51944
With that, we can verify that the lowest 24 bit of the calculated hash (0xE51944) match the hash that was
received as part of the resolvable private address. Therefore, the transmitter of this telegram used this specific
IRK to generate this resolvable private address.
C. Authentication of SR-SBP2801-BLE-E data telegrams
SR-SBP2801-BLE-E provides the option to authenticate its data telegrams as described in chapter 4.6.3. The
authentication mechanism used by SR-SBP2801-BLE-E is standardized as RFC3610. The full RFC3610
specification could be found here at the time of writing and should be used as primary source of information:
https://www.ietf.org/rfc/rfc3610.txt
The following description aims to summarize the security processing steps for users not deeply familiar with
cryptography in general or RFC3610 in particular.
C.1 Algorithm input parameters
The purpose of the security processing in SR-SBP2801-BLE-E is to calculate a unique signature that can be
used to verify authenticity (telegram has not been modified) and originality (telegram comes from the assumed
sender) of a telegram.
To do so, two types of algorithm parameters are required:
1. Constant algorithm input parameters
These parameters identify high level algorithm and telegram properties and are the same for any SR-SBP2801-
BLE-E telegram
2. Variable algorithm input parameters
These parameters identify telegram-specific parameters and therefore depend on the specifics of the
transmitted telegram
C.1.1 Constant input parameters
The RFC3610 implementation in SR-SBP2801-BLE-E requires two constant input parameters:
1. Length field size
This is the size (in byte) of the field used to encode the length of the input data
(which is the payload to be authenticated).
The maximum size of SR-SBP2801-BLE-E payload to be authenticated is 13 byte; therefore one byte would be
easily sufficient to encode the payload size. The minimum value
permitted by the standard is however 2 bytes which is therefore chosen.
2. Signature size
This is the desired size of the generated signature which is 4 byte for SR-SBP2801-BLE-E
Table 11 below summarizes these constant algorithm parameters.
Parameter
Comment / Description
Example
Length Field Size
Size (in bytes) of the field used to
encode the input length
2 (always, minimum permissible size)
Desired size (in byte) of the signa-
ture generated by the algorithm
Signature Size
4 (always)
Table 11 – Constant algorithm input parameters
C.1.2 Variable input parameters
The RFC3610 implementation in SR-SBP2801-BLE-E requires four variable input parameters:
1. Source address
The 6 byte source address used to identify the sender of an authenticated message. The source address is
required in little endian (least significant byte first) format.
2. Input data (Payload to be authenticated)
The authenticated payload contains source address, sequence counter, switch status and optional data (if
present). See chapter 4.6.3 for a description of the authenticated payload.
3. Input length (Size of the payload to be authenticated)
The length of the payload to be authenticated depends on the amount of optional data used in the telegram.
This is configured via the Configuration register, see chapter 6.7.3.
By default, no optional data is present and the length of the authenticated payload is 9 byte.
4. Sequence counter
Each SR-SBP2801-BLE-E contains a sequence counter which is initialized to zero during production and
increased for each telegram that is sent.
The sequence counter is transmitted as part of the input data.
The receiver of SR-SBP2801-BLE-E telegrams keeps track of this counter and will accept only telegrams with
counter values higher than the highest previously used value. This eliminates the possibility of reusing
previously transmitted telegrams.
Note that the individual (identical) advertising telegrams used to encode the same data telegram use the same
sequence counter value.
5. Security key
Each SR-SBP2801-BLE-E is programmed with a random 16 byte security key during manufac- turing. This key
can be modified using the NFC interface, see chapter 6.7.5.
Table 12 below summarizes these parameters.
Parameter
Comment / Description
Example
Source Address
Unique source address of the SR-
SBP2801-BLE-E module (little endian)
Telegram data to be authenticated
Input Data
0CFFDA035D04000011
B819000015E2 (little endian
representation of E2801000019B8)
Input Length
Length of input data (in bytes, en-
coded using 2 bytes)
0x0009 (if optional data size = 0, default)
0x000A (if optional data size = 1)
0x000B (if optional data size = 2)
0x000D (if optional data size = 4)
Sequence Counter
Incrementing counter to avoid replay
Part of the input data (byte 4 … 7)
5D040000 (little endian representation
of the counter value 0000045D)
Security Key
128 bit random key that is known both
to sender and receiver
3DDA31AD44767AE3CE56DCE2B3CE
2ABB
Table 12 – Variable input parameters
C.1.3 Obtaining the security key
All required parameters except the security key can be directly extracted from the received message that shall
be authenticated.
The security key –the common secret shared between sender and receiver – has to be obtained via specific
mechanisms. As described in chapter 5, there are three different ways to obtain the security key of a given SR-
SBP2801-BLE-E module:
