Echelon FTXL - Manual (Page 57)

FTXL User’s Guide 45
Alternatively, your application can use a combination of the
LonQueryDomainConfig() and LonUpdateDomainConfig() API calls to specify the
authentication keys during application start-up.
If you set the authentication key during device manufacturing, you must perform
the following tasks to ensure that the key is not exposed to the network during
device installation:
1. Specify that the device should use network-management authentication
(set the configuration data in the LonConfigData data structure, which is
defined in the FtxlTypes.h file).
2. Set the device’s state to configured. An unconfigured device does not
enforce authentication.
3. Recommended: Set the device’s domain to an invalid domain value to
avoid address conflicts during device installation.
If you do not set the authentication key during device manufacturing, the device
installer can specify authentication for the device using the network management
tool, but must specify an authentication key because the device has only a default
key.
How Authentication Works
Figure 8 on page 46 illustrates the process of authentication:
1. Device A uses the acknowledged service to send an update to a network
variable that is configured with the authentication attribute on Device B.
If Device A does not receive the challenge (described in step 2), it sends a
retry of the initial update.
2. Device B generates a 64-bit random number and returns a challenge
packet that includes the 64-bit random number to Device A. Device B
then uses an encryption algorithm (part of the FTXL LonTalk protocol
stack) to compute a transformation on that random number using its 48-
bit authentication key and the message data. The transformation is
stored in Device B.
3. Device A then also uses the same encryption algorithm to compute a
transformation on the random number (returned to it by Device B) using
its 48-bit authentication key and the message data. Device A then sends
this computed transformation to Device B.
4. Device B compares its computed transformation with the number that it
receives from Device A. If the two numbers match, the identity of the
sender is verified, and Device B can perform the requested action and
send its acknowledgment to Device A. If the two numbers do not match,
Device B does not perform the requested action, and an error is logged in
the error table.
If the acknowledgment is lost and Device A tries to send the same message again,
Device B remembers that the authentication was successfully completed and
acknowledges it again.