AD-SM2400AP04A-PWRLN. Application Note. G3 Coordinator Network Formation. Overview

Transcription

1 AD-SM2400AP04A-PWRLN Application Note Communication Technology by: Semitech Semiconductor Revision 1.0 August 2016 Overview This application note describes the Join procedure which performs G3 coordinator network formation through the SM2400 PLC modem. The material in this application note is based on and derived from the following standards: IETF RFC 4764 (The EAP-PSK Protocol) IETF RFC 3748 (Extensible Authentication Protocol [EAP]) ITU-T G.9903 Recommendation (Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks) Note: References herein to text, tables, and figures outside this document are for the ITU-T G.9903 Recommendation (Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks) except where otherwise noted. Much of the content of this application note originated in the ITU-T G.9903 recommendation.

2 Table of Contents 1. Introduction Preliminaries Command Descriptions Message Formats Network Join Procedure details General Step Step Step Step Step Step Step Step Abbreviations and acronyms Contact Information Revision Information

3 1. Introduction The network join procedure in G3 performs the following main tasks: Authenticate that the device is allowed on the network. Provide the device with appropriate encryption keys. Assign a short address to the device. Because the network join steps involve authentication and the sharing of secret information (keys), they need to be made secure. G3 uses EAP-PSK for the network join procedure (with minor modifications). The full details of EAP-PSK are found in IEC RFC The following is a summary of the EAP-PSK procedure. Note: A list of relevant acronyms and abbreviations is located in Section 4. Note: The symbol indicates concatenation. For example, this message: ID_S RAND_P. 3

4 2. Preliminaries 2.1 Command Descriptions Table 2-1. Command Descriptions Command ID Value Description 0x011C ADPM_LBP_REQUEST Request to send LBP message to server. nsdulength 2 bytes - The size of the payload in bytes. maxhops 1 byte - The number of times the frame will be repeated by network routers. dstaddrtype 1 byte - The type of address contained in the dstaddr parameter. 0=no address; 2=short address; 3=extended address. dstaddr[8] 8 bytes - The 16 bit address of the LBA or 64 bit address of the LBD. nsduhandle 1 byte - The handle of the NSDU to transmit. nsdutype 1 byte - The type of data contained in the NSDU: 0x00 = any data; 0x01 = UDP; 0x02 = ICMP; 0x03 = TCP. discoverroute 1 byte - If TRUE, a route discovery procedure will be performed prior to sending the frame if a route to the destination is not available in the routing table. qualityofservice 1 byte - The requested quality of service (QoS) of the frame to send. Allowed values are: 0x00 = normal priority; 0x01 = high priority securityenabled 1 byte - If TRUE, enables the MAC layer security for sending the frame. nsdu[] nsdulength bytes - The LBP message to send. 0x011D ADPM_LBP_CONFIRM Status of a LBP request. status 1 byte - The result of the LBP request nsduhandle 1 byte - The handle corresponding to the request. 0x011E ADPM_LBP_INDICATION Received LBP message from server. dstaddr 2 bytes - The short address of the destination of this message. srcaddr 2 bytes - The short address of the source of this message. If the device is unregistered, then will be 0xffff. nsdulength 2 bytes - The number of bytes in the payload. linkqualityindicator 1 byte - The link quality of this packet. securityenabled 1 byte - 0 is no security; otherwise security. nsdutype 1 byte - The type of the payload. nsdu[] nsdulength bytes - The LBP message. 4

5 2.2 Message Formats LBP Message Figure 2-1. LBP Message Format 0 1 Bits T Code Transaction-id A_LBD Bootstrapping data Table 2-2. LBP message format Field Length Definition T 1 bit Identifies the type of message. 0: Message from LBD 1: Message to LBD Code 3 bits Identifies the message code defined in Table 2-3. Transaction-id 12 bits Reserved by ITU-T, set to 0 by the sender and ignored by the receiver. A_LBD 8 bytes Indicates the EUI-64 address of the bootstrapping device (LBD). Bootstrapping Data Variable Contains additional information elements. Two types are defined: Embedded EAP messages (see clause ), Configuration parameters (see clause ). Table 2-3. T and code fields in LBP message T Code LBD Message Description 0 0b001 JOINING The LBD requests joining a PAN and provides the necessary authentication material 1 0b001 ACCEPTED Authentication succeeded with the delivery of device specific information (DSI) to the LBD 5

6 Table 2-3. T and code fields in LBP message T Code LBD Message Description 1 0b010 CHALLENGE Authentication in progress. PAN specific information (PSI) may be delivered to the LBD. 1 0b011 DECLINE Authentication failed. 0/1 0b100 KICK KICK frame is used by a PAN coordinator to force a device to lose its MAC address, or by any device to inform the coordinator that it left the PAN. On receipt of this frame, a device shall set its short address to the default value of 0xFFFF, disconnect itself from the network and perform a reset of the MAC and adaptation layers. See clause for details of the kicking procedure. 6

7 2.2.2 EAP Message Note: The G3 EAP message differs from the standard EAP message in the code field. The standard EAP message has the code field as 8 bits (compared with 6 bits and 2 0s in G3). For all EAP authentication, the G3 code field must be changed into the standard form. Figure 2-2. EAP Message Format 0 1 Bits Code 0 0 Identifier Length Data Table 2-4. Fields in embedded EAP message Field Length Definition Code 6 bits Identifies the type of EAP packet (6-bit). EAP codes are assigned as follows: 0b000001: Request (sent to the peer = LBD) 0b000010: Response (sent by the peer) 0b000011: Success (sent to the peer) 0b000100: Failure (sent to the peer) The code field is slightly different from a regular EAP code field as specified in [IETF RFC 3748]. The conversion appears straightforward in both directions. The proper conversion shall apply when the EAP message is propagated over another protocol (i.e., RADIUS) and in case of integrity protection covering the EAP header. Identifier 8 bits Aids in making responses with requests. Length 2 bytes Indicates the length, in bytes, of the EAP packet including the code, identifier, length, and data fields. A message with the length field set to a value larger than the number of received bytes shall be silently discarded. Data variable The format of the data field is determined by the code field. NOTE Refer to [IETF RFC 3748] for more details on: Specific format for request / response messages and the introduction of the type field (Identity, Nak, etc.) Specific format for success / failure messages with an empty data field. 7

8 2.2.3 Configuration Parameter Figure 2-3. Configuration Parameter Format 0 1 Bits Attr-ID M 1 Len Value Tables 2-5 and 2-6 below list EARP parameters as specified in ITU-T G Table 2-5. Fields in embedded EAP message Field Length Definition Attr-ID 6 bits Represents the ID of the attribute in the LoWPAN information base (LIB). M 1 bit Identifies the type of the attribute: 0: Device specific information (DSI) 1: PAN specific information (PSI) Len 8 bit Indicates the length, in bytes, of the Value field. Value variable (defined by Len field) Contains the value of the attribute. Its format is defined by Attr-ID. Table 2-6. Parameters for embedded EAP message T Code LBD Message Description Short_Addr 7 D 16 bit address for a new device. The address is unique inside the PAN. GMK 9 P Provide a GMK key. Upon receipt, the key is installed in the provided key identifier slot. Constituted of the following fields: id (1 byte): the key identifier of the GMK gmk (16 bytes): the value of the current GMK 8

9 Table 2-6. Parameters for embedded EAP message (Continued) T Code LBD Message Description GMK-activation 10 P GMK-removal 11 P Indicates the GMK to use for outgoing messages. Constituted of the following field: id (1 byte): the key identifier of the active GMK Indicates a GMK to delete. Constituted of the following field: id (1 byte): the key identifier of the GMK to delete Parameterresult 12 D Indicate the result of the reception of parameters: Constituted of the following fields: result (1 byte): can take the following values: 0x00: Success 0x01: Missing required parameter 0x02: Invalid parameter value 0x03: Unknown parameter ID Attr-ID+type (1 byte): indicates the parameter related to the result. Encoded as defined in Figure 2-3 first byte. If result = Success, Attr-ID = 0x00 and is ignored. 9

10 3. Network Join Procedure details Most of the processing for the network join procedure on the coordinator side is done in an EAP-PSK server that runs on the host. The procedure is illustrated infigure 3-1. Figure 3-1. Network Join Procedure Flowchart 10

11 3.1 General ADPM_LBP_REQUEST All messages from the host need to be sent via the ADPM_LBP_REQUEST message. Apart from the payload length and payload data, parameters will be the same for all messages. They are: maxhops 1 byte - 8. nsdutype 1 byte - 0. qualityofservice 1 byte - 0. If the ADPM_LBP_INDICATION has an src address of 0xffff: dstaddrtype 1 byte -3. dstaddr[8] 8 bytes -64 bit address of the LBD. discoverroute 1 byte - 0. securityenabled 1 byte - 0. Else: dstaddrtype 1 byte -2. dstaddr[8] 8 bytes - The 16 bit address of the LBA. discoverroute 1 byte - 1. securityenabled 1 byte Step 1. nsduhandle 1 byte - Incremented each request. In the current build the PSK is set to 0 (16 bytes long). The server needs to generate two keys from the PSK: AK and KDK, which are used for authentication and encryption. The details are on page 18 of RFC Step 2. When a device issues a join request command, a Lowpan Bootstapping Protocol (LBP) message is sent to the coordinator. The message triggers an ADPM_LBP_INDICATION event on the coordinator, which in turn sends an event indication to the host. The payload of the indication is an LBP message with T=0; Code = 1; A_LBD= extended address of device. There is no additional data. 11

12 3.4 Step 3. The host may perform access control based on the extended address on the device; however, it is not necessary. If the host agrees to allow the device to join, it must send an EAP-PSK first message to the device via an ADPM_LBP_REQUEST. The EAP-PSK first message will look like: Code = 1 Identifier = 0 Length = = 30 Data = Byte 0 = 47 Byte 1 = 0 Byte 2-17 = 16 byte random number RAND_S Byte = 8 byte extended address of the server ID_S This EAP-PSK message must then be packaged inside an LBP message with: T = Step 4. Code = 2 A_LBD= extended address of device Bootstrapping data = EAP-PSK first message The device processes the EAP-PSK first message and sends an EAP-PSK second message. This second message contains the RAND_S, a device generated RAND_P, the device extended address ID_P, and an authentication tag MAC_P. MAC_P is calculated using CMAC-AES-128 [same as OMAC1] with key AK and message ID_P ID_S RAND_S RAND_P ( is concatenation). 3.6 Step 5. The host receives an ADPM_LBP_INDICATION with a payload of an LBP message with an embedded EAP message (EAP-PSK second message). The host has to verify the MAC_P contained in the EAP-PSK second message by recalculating it. If it is verified, the host prepares an EAP-PSK third message. 3.7 Step 6. The EAP-PSK third message contains an authentication tag calculated by the host MAC_S, as well as a protected P- channel that is used to send configuration data. MAC_S is calculated using CMAC_AES-128 with key AK and message ID_S RAND_P. The following configuration parameters must be sent: Short address, GMK (at least one), GMK-activation The configuration parameters are concatenated, and are placed in the P-channel extension field. The ext-type is set to 0x2. The P-channel is protected by using EAX encryption over the result and ext bytes of the P-channel. The encryption key for EAX is derived using the KDK and RAND_P, as described in RFC 4764 pg The inputs to EAX are described in RFC 4764 pg

13 The EAP-PSK third message looks like: Code = 1; Identifier = 0; Length = length of P-channel Byte 0 = 47 Byte 1 = 0x80 Byte 2-17 = 16 bytes RAND_S Byte = 16 bytes MAC_S Byte 34 - end = Pchannel This EAP-PSK message must then be packaged inside an LBP message with: T = Step 7. Code = 2 A_LBD= extended address of device Bootstrapping data = EAP-PSK third message The device receives the EAP-PSK third message. It first authenticates the MAC_S, then decrypts the P-channel and installs the configuration parameters. If all the parameters are correct and present, the device sends an EAP-PSK fourth message with a P-channel containing a parameter-result configuration parameter with result = success. 3.9 Step 8. The host receives an ADPM_LBP_INDICATION with a payload of an LBP message with an embedded EAP message (EAP-PSK fourth message). The host decrypts the P-Channel and verifies that the configuration parameter has a result=success. The host then prepares a final LBP message to send to the device that says that it has been accepted into the network. The accepted message uses an embedded EAP message. The final EAP message looks like: Code = 3 Identifier = 0 Length = 4 This final EAP message must then be packaged inside an LBP message with: T = 1 Code = 1 A_LBD= extended address of device Bootstrapping data = final EAP message 13

14 4. Abbreviations and acronyms Following is a list of abbreviations and acronyms that may be used in this document. LQ LSB LSF MAC MIB Link Quality Least Significant Bit Last Segment Flag Media Access Control Management Information Base MPDU MAC Protocol Data Unit MSB MSE NACK NIB NPCW NSDU OFDM PAN PAR PCS PDC PHY PIB PICS PLC PN POS PPDU PPM PSDU PHY PSI PAN QPSK RA RADIUS RC Most Significant Bit Mean Square Error Negative Acknowledgement Neighbour Information Base Normal Priority Contention Window Network Service Data Unit Orthogonal Frequency Division Multiplexing Personal Area Network Peak to Average Ratio Physical Carrier Sense Phase Detection Counter Physical layer PAN Information Base Protocol Implementation Conformance Statement Power Line Communication Pseudo Noise Personal Operating Space PHY Protocol Data Unit Parts Per Million Service Data Unit Specific Information Quadrature Phase Shift Keying Router Advertisement Remote Authentication Dial in User Service Repetition Code Rec. ITU-T G.9903 (02/2014) 5 RERR RES RIFS rms Route Error Reserved (bit fields) Response Inter-frame Space Root Mean Square RREP Route Reply RREQ Route Request RS RX SC SCI S-FSK Reed-Solomon Receiver Segment Count Source Context Identifier Spread Frequency Shift Keying SN Sequence Number SNR SSCS TMI TMR TX TX VCS 6LoWPAN 8-PSK 16-QAM AAA ACK ADP AFE AGC AMM ARQ BPSK CIFS CP CRC D8PSK DBPSK DCI DQPSK DSI EAP ED EIFS FCH FEC FFT Signal to Noise Ratio Service-Specific Convergence Sublayer Tone Map Index Tone Map Request Transmitter Transmit Virtual Carrier Sense IPv6 over Low power Wireless Personal Area Network 8 Phase Shift Keying 16 Quadrature Amplitude Modulation Authentication, Authorization and Accounting Acknowledge Adaptation Analogue Front End Automatic Gain Control Automated Meter Management Automatic Repeat Request Binary Phase Shift Keying Contention Inter-Frame Space Cyclic Prefix Cyclic Redundancy Check Differential 8 Phase Shift Keying Differential Binary Phase Shift Keying Destination Context Identifier Differential Quadrature Phase Shift Keying Device Specific Information Extensible Authentication Protocol End Device Extended Inter-frame Space Frame Control Header Forward Error Correction Fast Fourier Transform 14

15 FL GF GI GMK Frame Length Galois Field Guard Interval Group Master Key GTS Guaranteed Time Slot (see [IEEE ]) HPCW IB ICI IFFT IFS IS LBA LBD LBP LBS LFSR LQ LSB LSF MAC MIB High Priority Contention Window Information Base Inter-Carrier Interference Inverse Fast Fourier Transform Inter-frame Spacing Information System LoWPAN Bootstrapping Agent LoWPAN Bootstrapping Device LoWPAN Boostrapping Protocol LoWPAN Bootstrapping Server Linear Feedback Shift Register Link Quality Least Significant Bit Last Segment Flag Media Access Control Management Information Base MPDU MAC Protocol Data Unit MSB MSE NACK NIB NPCW NSDU OFDM PAN PAR PCS PDC PHY PIB PICS PLC PN POS PPDU Most Significant Bit Mean Square Error Negative Acknowledgement Neighbour Information Base Normal Priority Contention Window Network Service Data Unit Orthogonal Frequency Division Multiplexing Personal Area Network Peak to Average Ratio Physical Carrier Sense Phase Detection Counter Physical layer PAN Information Base Protocol Implementation Conformance Statement Power Line Communication Pseudo Noise Personal Operating Space PHY Protocol Data Unit PPM Parts Per Million PSDU PHY Service Data Unit PSI PAN Specific Information QPSK Quadrature Phase Shift Keying RA Router Advertisement RADIUS Remote Authentication Dial in User Service RC Repetition Code Rec. ITU-T G.9903 (02/2014) 5 RERR Route Error RES Reserved (bit fields) RIFS Response Inter-frame Space rms Root Mean Square RREP Route Reply RREQ Route Request RS Reed-Solomon RX Receiver SC Segment Count SCI Source Context Identifier S-FSK Spread Frequency Shift Keying SN Sequence Number SNR Signal to Noise Ratio SSCS Service-Specific Convergence Sublayer TMI Tone Map Index TMR Tone Map Request TX Transmitter TX Transmit VCS Virtual Carrier Sense 15

16 5. Contact Information For more information regarding the SM2400EVK1 including application notes, product samples, demonstration modules, pricing and ordering please contact: Adesto Technologies Communication technology by: Semitech Semiconductor 6. Revision Information Table 6-1. Revision history Version Description Date 1.0 First publication 16

17 This page intentionally blank

18 Corporate Office California USA Adesto Headquarters 3600 Peterson Way Santa C;ara, CA Phone: (+1) Adesto Technologies. All rights reserved. / Rev.: PB2480A PWRLN 5/2016 Disclaimer: Adesto Technologies Corporation makes no warranty for the use of its products, other than those expressly contained in the Company's standard warranty which is detailed in Adesto's Terms and Conditions located on the Company's web site. The Company assumes no responsibility for any errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of Adesto are granted by the Company in connection with the sale of Adesto products, expressly or by implication. Adesto's products are not authorized for use as critical components in life support devices or systems.